Mercurialの資料

MercurialのPDF資料が公開されているのでリンクしておく。
以前よりもMercurialの資料があるので便利になった。

【1】Mercurialによる分散リビジョン管理

hgbook 日本語版のHTML公開: プログラマの思索に書いた内容がPDFで無料で公開されている。
この1冊があればMercurialの使い方は一通り分かる。

本来は、Mercurial: The Definitive Guideを日本語化したものです。

"Mercurial: The Definitive Guide" 日本語訳の公開 - 彷徨えるフジワラ

【2】Mercurial Cheat Sheet 日本語版

Mercurialをよく使うコマンドが1枚のシートにまとめられているので便利。

【3】TortoiseHg+v2.0.0+docs.pdf索

TortoiseHgのWebマニュアルがPDF化されて公開されている。
v2.0.0なので今となっては古いけれども参考になる。

【4】www.jemander.se/MercurialByExample.pdf

Mercurialの別のチュートリアル。

【5】MercurialのホスティングはBitbucketを使う時が多いのが、下記のマニュアルが公開されている。

Bitbucketの最初の一歩 - Bitbucket - アトラシアン ウィキ

Mercurial の利点を説明した資料も公開されている。WindowsならMercurialの方が使いやすいように思う。

Mercurial 対 Git：なぜ Mercurial を選ぶのか？　Atlassian Japan

TortoiseSVNでマージする方法

TortoiseSVNでマージする方法が書かれたHPがあったのでリンクしておく。

【元ネタ】
Subversion(TortoiseSVN)でマージする方法(手順)(1)

Subversion(TortoiseSVN)でマージする方法(手順)(2) バージョン1.5以降 [機能ブランチ]

Subversion(TortoiseSVN)でマージする方法(手順)(3) [ベンダブランチ]

TortoiseSVN　Version 1.7　マージ

TortoiseSVN編（11）マージ｜ムービー企画「Subversionによるバージョン管理入門」

SVNはマージ作業が面倒なのだが、上記の方法で作業は可能。
基本はマージ元とマージ先のリビジョンを指定しておくのがミソ。

とはいえ、PerfoceのP4Mergeの方がGUIで3ペインでグラフィカルに表示してくれるので便利。
マージ作業のロールバックができるのもありがたい。

Googleでも採用されているPerforce社製のマージツールPerforce Visual Merge Tool (P4Merge)を使ってみる - 大人になったら肺呼吸

Subversion/TortoiseSVNメモ/お勧め差分、マージツール - TOBY SOFT wiki

TortoiseHgとたわむれてみる - watawata日記

課題管理のチケット駆動開発part2

チケット駆動開発を運用していると課題管理が難しい。
その難しさの理由の殆どは、課題や問題、リスクなどの概念をきちんと区別していないからだと思う。
以下メモ書き。

【元ネタ】
課題、問題、リスクを区別できていますか？｜プロジェクトマネジメントの現場

Redmineでスクラム実践！～アジャイル開発始めました～ (3/3) - ＠IT

課題管理のチケット駆動開発: プログラマの思索

チケット駆動開発の適用範囲Part2～チケット駆動開発の運用パターン: プログラマの思索

「問題」とは目的を阻害するような「現象」「事象」「症状」。
「課題」とは「問題」を発生させる原因。
「リスク」とは現時点で顕在化していないものの、ある確度で将来課題になりうる事象。

RedmineやTracで課題管理を行う場合、問題という事象をチケットに登録してしまいがち。
でも、本来はいくつかの問題を分析して、どこにその原因があるかを見出し、その原因をチケットに登録して、チケットに対策の提案や対策を実施した履歴を記録していく。
例えば、バグが多い原因が単体テスト不足だったとしたら、それが課題となり、テストケースをきちんと書いて事前レビューするなどの対策が作られて実施していくだろう。

実際のチケット駆動開発では、タスクも課題も両方登録していく状況が多い。
課題があるからこそ、その課題を解決するためにタスクが発生し、そのタスクを実施した結果、課題が解決されたかどうか評価される。
そのサイクルを早く回しながら、次々に出てくる課題を消し込んでいく。
その課題を消し込む際に、課題チケットの内容はソースや設計書などの成果物にパッチあてのように反映される。
チケット駆動開発のトレーサビリティの機能を使えば、それら成果物の更新理由がどんな課題なのか、を後から追跡できるのもチケット駆動開発の利点になる。

Scrumを運用できるRedmineのBacklogsプラグインには「スプリント障害事項」というチケットを登録できるが、これがまさに課題に相当するだろう。
つまり、チームの開発の障害となる課題を登録して、スクラムマスターを中心として課題を解決していくわけだ。

また、チケット駆動開発の運用が慣れたら、リスクもチケットに登録していくようになる。
「この機能にはユニットテストが足りないかもしれない」「この実装部分は将来のためにリファクタリングした方がいいかもしれない」などのように、現在は大きな問題にならないが将来に問題となるような気づきは結構ある。
それらもチケットに備忘録として登録しておくが、リスクのチケットは優先度が低いから現在すぐに作業は実施しない。
次のイテレーション計画を作る時やリリース計画全般を見直す時に、それらリスクのチケットを入れるかどうか判断する運用になるだろう。

Velocity計測の注意

Velocityの計測について@ryuzeeさんの記事が参考になるのでリンクしておく。

【元ネタ】
[Scrum]ベロシティに対する誤解 | Ryuzee.com

Redmineでアジャイルチームのスピードやパワーを見える化する | 世界のdaipresents

工数見積もりで陥りやすい罠: プログラマの思索

チームは加速するのか～Velocityの使い方 #agilesamurai: プログラマの思索

Velocityの本来の定義は、実際に納品できたストーリーポイントの合計値。
Velocityの単位が人日ではなくストーリーポイントという開発規模を表す単位である点が重要。
しかも、ストーリーポイントはファンクションポイントとは違って、開発規模を相対比較する。
だから、イテレーションを実施するたびにチームが成長して、アウトプットの規模が大きくなったとしても、規模を相対比較しているから誤差はあまり生じない。
人日で計測する場合、実績のコストと実際の出来高の単位が混同されてしまう。
そのため、本来作った開発規模はどれだけだったのか、過去のデータと狂ってしまう。

また、ストーリーポイントで計測するという意味は、顧客がそのストーリーを作っていることから、ビジネス要求そのものに対応している。
つまり、LOCのようなコーディング量ではなく、ビジネス要求そのものの規模に対応している。
だから、顧客の観点と開発者の観点のシステム規模で認識相違が起きにくい。

また、他チームとVelocityを比較する意味がないという指摘も重要。
ストーリーポイントは相対比較だから、基準値は各チームで異なるのが普通だし、基準値が異なっていれば各チームのVelocityを比較しても意味がない。
つまり、Velocityはそれぞれのプロジェクトだけでしか意味を持たない。
だが、一プロジェクトのVelocityを計測し続けていれば、そのチームの開発ペースが分かるし、チームに見合った仕事量がどれだけなのか、も把握できる。

Velocityの概念はXPのプラクティス「週40時間労働」「持続可能な開発ペース」にもつながる。
色々考えてみる。

IPAから日本のアジャイル事例報告

@hiranabeさんのTwitterから、IPAから日本のアジャイル事例報告書を見つけたのでリンクしておく。

【元ネタ】
Twitter / @hiranabe: IPAから日本のアジャイル事例報告。「中大規模事例でよく行われた工夫」が末尾にある(パタン言語への入り口か)！

｢非ウォーターフォール型開発の普及要因と適用領域の拡大に関する調査」報告書を公開～情報処理推進機構：ソフトウェア・エンジニアリング

「非ウォーターフォール型開発の普及要因と適用領域の拡大に関する調査」調査概要報告書[2.29MB]～情報処理推進機構：ソフトウェア・エンジニアリング

「非ウォーターフォール型開発の普及要因と適用領域の拡大に関する調査」調査報告書[3.87MB]～情報処理推進機構：ソフトウェア・エンジニアリング

160ページもの報告書には、11社のアジャイル開発12事例が掲載されている。
注目すべきは、組織構成と契約スタイルを中心に書いていることと、背景・考慮点・解決したかった問題・効果のようにパターンカタログのような形式で書いていること。
前者に関しては、特に組織構成が面白いと思った。
何故なら、アジャイル開発の運用が難しい理由は、顧客と開発者が密接に関係しあうような体制が必要なのに、実際の開発現場では互いの利害が衝突してしまいがちだから。
顧客から一方的に納期と工数、スコープが固定されて提示されてしまったら、アジャイルに開発のしようがない。
こういう事例がIPAという日本のIT業界のエスタブリッシュメントから出たことが感慨深い。

なお、IPAの下記サイトから、日本の大手ベンダーの開発事例を定量化したデータが無料で公開されている。
中身を見ると、FP法による開発規模、工数、納期などの定量データが公開されていて、とても参考になる。

Twitter / @akipii: IPAのサイトから日本のソフトウェア開発の定量データを無料で落とせる。資料を収集する時にこれほど役立つものはない。すごいね。ソフトウェア開発データ白書 http://sec.ipa.go.jp/publish/index.html

SEC BOOKS～情報処理推進機構：ソフトウェアエンジニアリング

＜第2版＞ソフトウェア開発データ白書2010-2011～IT企業2584プロジェクト　実践的活用に役立つ定量データ～情報処理推進機構：ソフトウェアエンジニアリング

興味深いのは、日本のソフトウェア開発では、反復型開発(アジャイル開発も含む)はわずか2.7%に満たず、それ以外はWF型開発であること。
上記のアジャイル開発の事例は、日本の大手SIではかなりの少数派と見なした方がいいだろう。

IPAの他の資料も無料で公開されているので読んでみると面白いだろうと思う。

コミュニティがチケット駆動開発を支えている

コミュニティとチケット駆動開発の関係についてメモ書き。

チケット駆動開発は元来、@machuさんがTracのチケット管理を運用した経験を発表資料として公開されたのが始まりだった。

チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07)

そして、Redmineを運用していた時に、その発表資料にあるエッセンスに刺激を受けて、アジャイル開発へ適用して試してみて、かなりうまくいった。
その経験を元にKOFで初めてRedmineによるチケット駆動開発について発表した。

【公開】KOF2008講演資料「Redmineでチケット駆動開発を実践する～チケットに分割して統治せよ」: プログラマの思索

そこから「Redmineによるタスクマネジメント実践技法」が出版された後、アジャイル開発に興味のある一部の人たちにチケット駆動開発が注目された。

Redmineの設定方法や使い方よりもRedmineを用いてのアジャイル開発手法に重きを置いて解説してた　チームメンバーに是が非でも共有したい　する　はてなブックマーク - jiska - 2011年4月4日

デブサミ2011でチケット駆動開発について講演したら、既にチケット駆動開発を実践されている人達は多くて驚いた。
ネットでも、製薬業や製造業の人達もRedmineによるチケット駆動開発を実践していたらしく、「Redmineによるタスクマネジメント実践技法」で書かれているアジャイル開発の言葉(例えば、イテレーション、バックログ、小規模リリースなど)がよく分からないという感想があった。

なぜか分からないけど、「チケット駆動開発」という言葉が急速に普及したように思う。

そんな情勢の中、Tracのコミュニティは以前からShibuya.tracが活発に活動されていたが、Redmineの注目度が上がっている割にはRedmineコミュニティは日本に存在しなかった。
だが、2011年の夏に関西でRxtStudy、関東でshinagawa.redmineが有志で立ち上がった。
僕もその立ち上げに関わった。

【公開】RedmineのFAQとアンチパターン集 #Rxtstudy: プログラマの思索

【公開】第1回品川redmine勉強会の発表資料「障害管理からチケット駆動開発へ～ソフトウェア開発の3種の神器」 #47redmine: プログラマの思索

第1回RxtStudyは、Redmine本の著者4人全員が揃ったという事実が一番大きかったと思う。
Redmineのマーケットが日本にあるということがよく分かった。
@kuranukiさんの話もRedmineから離れた話になったけど、皆釘付けになって聞き入っていたのが印象的だった。

そして、東京ではshinagawa.redmineがIPA様のご厚意で提供された場所で、Redmineコミッタの丸山さんをお招きして開催された。
東京でもRedmineに関心のある人が多いというのがよく分かった。

そんな経緯を振り返ると、チケット駆動開発はコミュニティが育ててくれたのだと思う。
@machuさんがそのアイデアを公開しなければそんな話は出てこなかった。
チケット駆動開発をアジャイル開発へ適用した経験をXPJUG関西やSEA関西の人達と議論できなければ、これほど深く突き詰めて考えることもなかった。
そして、チケット駆動開発の講演場所を提供してくれたRuby関西、XPJUG関西、そしてアジャイルに関係するコミュニティがなければ、発表しながらチケット駆動開発のアイデアを育てていくこともなかった。

更に、Redmine非公式サイトを運営される@g_maedaさん、Redmineプラグインを次々に開発する人達(@daipresentsさん、@suerさん、@haru_iidaさんたち)、Redmineの機能改善に貢献する人達(@naitohさんたち)、Redmineのインストールツールを開発する人達(@mikoto20000さんたち)がいなければ、ここまでRedmineコミュニティが日本で大きく目立つこともなかった。

Redmineに関する課題と展望: プログラマの思索

RedmineもTracも、GitやMercurial、JenkinsやHudsonのようなツールは実際、コミュニティがその発展を支えている。
更に、Redmineは丸山さん、Gitは濱野さん、Jenkinsは川口さんのように日本人コミッタがツールの発展に大きな役割を果たしている。
日本人コミッタがいるおかげで、日本人開発者も積極的にこれらツールに関われるし、ツールの発展に大きく寄与していると思う。
日本のソフトウェア業界は輸出が殆ど無く海外で勝てないと言われるけど、コミュニティに出た限り、日本人開発者で優れた人はたくさんいる。
少なくともソフトウェア開発の3種の神器に関しては、日本人技術者が世界へ大きく貢献していると言えるのではないだろうか？

開発現場で試行錯誤して見出したチケット駆動開発というアイデアがどこまでソフトウェア開発の本質を変えてくれるのか、考えていく。

WordやExcelから直接SVNにコミットできるアドオンmsofficesvn

WordやExcelから直接SVNにコミットできるアドオンがあるらしいのでリンクしておく。

【元ネタ】
WordやExcelから直接SVNにコミットできるアドオンmsofficesvn - 大人になったら肺呼吸

Introduction_ja - msofficesvn - Microsoft Office (Excel, Word, PowerPoint) add-ins that invoke TortoiseSVN commands - Google Project Hosting

アドオンmsofficesvnはマクロで作られているらしい。
WordやExcelのファイル1個を編集中に即座にSVNコミットできるのは楽だ。
また、差分表示やログ表示もできるので、履歴を辿りながら編集できる。
プログラムも文章も、少しずつ作ったらコミットして、少しずつ育てていくのが基本。
まとめて一気にコミットすると、修正の意図が分からなくなるし、ロールバックもやりにくい。

個人的にはMercurialにも対応してくれると嬉しいかな。

エクストリーム・プログラミング入門を読み直す

今頃になって、XPエクストリーム・プログラミング入門(白本)を読み直してみた。
考えたことをラフなメモ書き。

【元ネタ】
Hot Heart, Cool Mind.: エクストリームプログラミング(XP)

邦訳(XP エクストリームプログラミング入門)へのコメント

パターン、Wiki、XPは良書: プログラマの思索

【1】XPエクストリーム・プログラミング入門は第2版になって、原理・原則・プラクティスが覚えきれないほど大幅に増加している。
だから、以前の僕は第1版にあるプラクティスの方が分かりやすくて好きだった。
しかし、今になって見直すと、現在までのアジャイル開発の流れを予測しているかのような概念が出てくることに驚かされる。
応用プラクティスにある各プラクティスを考えてみる。

「インクリメンタル配置」は小規模リリースと同じ。インクリメンタルな開発、つまりイテレーション単位の機能改善によるリリースと同義。

「根本原因の分析」は、トヨタ生産方式のなぜなぜ分析そのもの。なぜを5回繰り返して、技術要素だけでなく心理的要素まで問題を突き詰める。

「単一のコードベース」はメインラインモデルないしtrunkによるソース管理と同義。

「日次配置」は継続的デプロイ、あるいはもっと発展させれば継続的デリバリーと同義。ソフトウェアを本番環境へ頻繁に配置することで、顧客に価値あるソフトウェアを納品できる。
継続的デプロイと継続的デリバリーの違いは「継続的デリバリー」に書かれている。
前者はアプリケーションの単なる頻繁なデプロイに過ぎないが、後者は、アプリケーションだけでなくデータ移行やサーバーの構築なども含んでいる。

「協議によるスコープ契約」「利用分払い」はまさにアジャイルな契約と同義。
「協議によるスコープ契約」は、イテレーション単位にスコープを決めて契約するわけだから、準委任契約に相当するだろう。
「利用分払い」は、SaaSのようにサービスを利用したコストだけ支払うという契約。
@kuranukiさんが提唱する「納品しない受託開発」や木下さんの価値創造契約もこの範疇に加わるのではなかろうか？

【2】また、@sugimoto_keiさんが言われている箇所もとても指摘が鋭いと思う。

(引用開始)
「計画ゲーム」をとってみよう。スコープ管理が大切だとは誰もが知っている。
しかし私たちが（少なくとも私が）そう口にするとき、本当に意味しているのは、「スコープの拡大を抑制せよ」という意味である。ケント=ベックは、スコープを自由変数として扱い積極的に制御せよ、という。
このとき彼の言わんとしていることは、たとえ当初想定されていた機能であっても重要性の低いものは削ぎ落とせ、しかもサブシステムや画面・帳票といった大粒度の単位だけではなく「機能特性（feature)」という小粒度の単位でも削ぎ落とせということだ。
反対に、重要性が高い機能特性なら後になってでも盛り込めとも言う。
しかもそれを二、三週間おきにやれという。
私はこんなにきめ細かいレベルでスコープを制御している例を見たことがなかった。
しかし言われてみると、決して不可能とも不合理とも思えない。
(引用終了)

XPでは、スコープを抑制するのではなく、開発者やユーザがスコープを変数とみなして積極的にコントロールする所に重要な主張がある。
WF型開発ならば、外部設計終了時に要件定義で発生した曖昧な要求や不相応に多い機能を削減して、スコープを減らして固定する。スコープが確定して初めて開発が始まる。
「仕様凍結」がWF型開発のキーワードの一つ。
だが、XPでは「ドライブ」という概念があるように、変化を敵視するのではなく逆に制御しようとする。

更に「パターン、Wiki、XP」で説明されているXPでは、プロジェクトの4つの変数という概念が提示されている。
それは、スコープ・品質・リソース・時間の4つだ。
4つの変数には特徴がある。

(引用開始)
・時間とリソースは限られている
・品質の目標は少しだけフレキシブルだが、振れ幅は狭い
・変更できるのはスコープだけである
・これらの4つについて、誰が決定権を持っているのかを確認し、彼らが適切な判断を下せるように開発状況と見積もりを報告する
(引用終了)

この特徴は「アジャイルサムライ」の「荒ぶる四天王」という話でも出てきた。
ソフトウェア開発とは、4つの変数を意識的に制御しながらプロジェクトを進める、つまりドライブするものと考えることができる。

【3】エクストリーム・プログラミングの底流に流れている思想の一つは、利用者と設計者のバランスを重視することだ。
XPエクストリーム・プログラミング入門の第23章「時を超えたプログラミングの道」でケント・ベックは自身の考え方を散文的に説明している。
僕の理解では下記のようになる。

アレクサンダーの建築の世界では、パターン・ランゲージ設計者と利用者の間にある力の均衡を取る手段として使われる。
その力の均衡はどちらが優位であるわけでもなく、設計者の深い技術的理解と利用者が持つ希望や社会的関係に対する理解が相互に結びつけて調和させることが本来の目的。

しかし、その力の不均衡は建築だけでなくソフトウェア開発でもある。
XPエクストリーム・プログラミング入門ではこう書かれている。

(引用開始)
ビジネス上の理由で設定された納期とスコープでは、チームの完全性を維持できない。
ユーザとスポンサーの関心事項は重要だが、開発者の要求にも正当な根拠がある。
3者全員が互いに情報を提供する必要がある。
(引用終了)

XPの目的は、調和とバランス。
つまり、設計者と利用者が一致する世界を目指している。
ソフトウェア開発における利用者と開発者の関係は固定された関係ではない。
そもそもコンピュータ、ソフトウェアの歴史は建築に比べるとはるかに短く、社会的関係も含めて新しく定義し直せる機会がある、と。

利用者と開発者が一致する世界とは、例えば、ユーザ企業自身が自分たちの業務やサービスのためにソフトウェア開発する場合があるだろう。
つまり、自分たち自身が利用者であり開発者であること。
最近、SNSやゲームに関する企業がアジャイル開発を積極的に取り入れている理由の一つは、ここにあるのかもしれない。

【4】更に、XPエクストリーム・プログラミング入門ではこう書いている。
この文章が一番心に残った。

(引用開始)
XPはソフトウェアについての信頼性の高い見積もり、実装、配置を迅速に行うことができる、強力なプログラマが増えることに依存している。
このようなプログラマはチームに対してなされたビジネス指向部分の方向転換ができる。
チーム間の権力と責任の適切な共有は、非現実的に思えるかもしれない。
このバランスには相互尊重が不可欠である。
絶対的な権力は存在しない。
XPでの権力は、悪用すると消滅する。
見積もりをごまかし、プライドを捨てて仕事を急いで終らせるたびに、チームは力を発揮できなくなっていく。
XPは、重役、マネージャ、顧客など全員が責任をもって全力を尽くすチームにかかっている。
協力して作業するチームは、それぞれのメンバの労力を合計する以上のことを成し遂げられる
(引用終了)

XPの価値の一つに「尊重」があるけれど、その発端は上記の引用にあるのだろう。

XPを批判する人たちは、XPは能力の高いプログラマに依存しすぎるとよく言うけれども、XPはそれを肯定している。
更に、技術志向な開発スタイルをナイーブに提唱しているのではなく、ソフトウェア開発では様々な権力の相互作用、つまり政治力を必要としていることも考慮に入れている。
開発現場では、有能なプログラマは発言そのものが大きな影響力を持つ。
でも、当然、顧客(プロダクトオーナー)も会社の上司(プロジェクトオーナー)も相当の権力を行使している。
僕自身もそのような経験をして下記に書いた。

プログラマにコミュニケーションが足りないと言われる時: プログラマの思索

SE、PL、そしてPMになるほど、開発チーム・顧客・SIの3つの立場を配慮しながら、その権力を行使する。
3者のバランスを取りながら、本来作るべきシステムは何なのか、を考えて、システムを漸進的に作っていく。
その開発現場は一つの社会的関係とも言えるわけだ。

アジャイル開発については今後も考えていく。

パターン、Wiki、XPは良書

「パターン、Wiki、XP」を読んだ。「ThoughtWorksアンソロジー」のようにエッセー風だが、本質的なことがたくさん書かれているような気がした。
感想をラフなメモ書き。

【元ネタ】
パターン、Wiki、XP - 第1部：建築 - Li:d tech

パターン、Wiki、XP - 第2部：ソフトウェア開発 - Li:d tech

パターン、Wiki、XP - 第3部：Wiki - Li:d tech

Smile Experience: パターンランゲージの会

404 Blog Not Found:時を超える創造の原則 - 書評 - パターン、Wiki、XP

書評リンク集 - 『パターン、Wiki、XP』サポートWiki

『パターン、Wiki、XP - 時を超えた創造の原則』感想、少しばかりの余談 - antipop

『パターン、Wiki、XP』と「協働＝お互い様」のマーケティング | JOURNAL | FERMAT

Wikiの起源と進化(論文PDF)

なぜそんなにもWikiは重要なのか(論文PDF)

【1】「パターン、Wiki、XP」を読んで、デザインパターンやXPの思想に触れたような気がした。
分かったと言うのはおこがましいが、本質に手を触れた感触。

XPがすごいと思いながらも、なかなか実践できなくて腑に落ちないと感じた理由は、それらのプラクティスや原則、価値を有機的に理解できていなかったからだと思う。
XPのプラクティスは最初は12個あって、それぞれのプラクティスの意味は理解できるが、何故そんなにたくさんあるのか、という疑問がいつもあった。
著者によれば、XPのプラクティスは、下記のアレクザンダーの6つの原理から生成されたものだと言われる。

(引用開始)
・有機的秩序の原理 (The principle of organic order)：計画や施工は，全体を個別的な行為から叙々に生み出してゆくようなプロセスによって導かれること．
・参加の原理 (The principle of participation)：建設内容や建設方法に関するすべての決定は利用者の手に委ねること．
・漸進的成長の原理 (The principle of piecemeal growth)：各予算年度に企画される建設は，小規模なプロジェクトに特に重点を置くこと．
・パターンの原理 (The principle of patterns)：すべての設計と建設は，正式に採択されたパターンと呼ばれる計画原理の集合によって指導されること．
・診断の原理 (The principle of diagnosis)：コミュニティ全体の健康状態は，コミュニティの変遷のどの時点でも，どのスペースが生かされ，どのスペースが生かされていないか，を詳しく説明する定期的な診断に基づいて保護されること．
・調整の原理 (The principle of coordination)：最後に，全体における有機的秩序の緩やかな生成は，利用者の推進する個々のプロジェクトの流れに制御を施す財政的処置によって確実なものとされること．
(引用終了)

「パターン、Wiki、XP」の説明で分かりやすかったのは、「参加の原理」がオンサイト顧客、「漸進的成長の原理」が小規模リリース、「診断の原理」が常時統合(CI)やテストファースト(TDD)を生み出したという箇所。
「パターン、Wiki、XP」には書かれていないけれど、XPのメタファは「パターンの原理」から生成されたのだろうと思う。

つまり、XPはパターンランゲージの思想を開発プロセスへ適用して生まれた斬新なプロセスなのだ。
だから、表面的なインパクトのあるプラクティスの名前にこだわるのではなく、その背後にあるパターンランゲージの思想を理解しなければ、本当に理解できた事にならないのだろう。

また、アジャイル開発における「ユーザに価値あるソフトウェアを届ける」というユーザ重視の姿勢は、パターンランゲージにある利用者重視の思想から来ていると考えることもできる。
その考え方がリーンソフトウェア開発や継続的デリバリーの概念まで発展していく。
アジャイルマニフェストの内容もまさにその思想そのものだ。

(引用開始)
・プロセスやツールより人と人同士の相互作用を重視する。
・包括的なドキュメントより動作するソフトウェアを重視する。
・契約上の交渉よりも顧客との協調を重視する。
・計画に従うことよりも変化に対応することを重視する。
(引用終了)

最近のアジャイルUXなどの考え方も、この思想の延長にあると思えば理解しやすくなる。
何故なら、利用者に使いやすいユーザインターフェースとは何か、という考え方はまさにユーザ重視の姿勢と同じだから。

【2】同様にパターンランゲージがプログラミング言語に影響した例は、GoFのデザインパターンだろう。
僕は、パターンと言う考え方がとても好きだ。
その理由は下記で書いた。

Twitter / @akipii: 「パターン、Wiki、XP ~時を超えた創造の原則」を読んで僕はパターンという考え方がとても好きだ。開発現場で良いと思われるノウハウを他人に説明できる概念に変換してくれる。パターン化することで暗黙的に理解していた内容を自分でも認知できる。パターンはボトムアップ指向なのも良い

開発現場のノウハウをパターンでまとめることで、他人に説明しやすくなるだけでなく、事象から本質的な概念を見出すことで暗黙的に理解していた内容を自分自身も理解できるようになるからだ。
パターンは事例に基づくので、どの文脈(コンテキスト）でそのパターンが有効なのか、そして他の状況では何故あまり有効でないのか、を明確に指摘してくれる。
パターンを作り上げる過程で自分の経験や考えていることを整理してくれるから、パターンはとても有用な考え方だと思う。
そして、パターンを作り上げるには、たくさんの事例を収集したり、経験しておくととても作りやすいだろうと思う。
但し、パターンが全ての事象を説明してくれるわけではない。
それぞれの事象をどのように分類するのかという観点を見出さない限り、パターン集はある特定の状況でしか適用できないノウハウに過ぎないから、MECEにパターンを作り上げるのはとても難しいと思う。

個人的にいつも思うのは、日本のIT業界では昔から品質管理やDOA、プロジェクト管理などで数多くの経験値があるにも関わらず、そのノウハウは散らばっていて、他人が使えるような概念にまとめていなかった。
むしろ、それらノウハウをIT企業独自の知的所有権として公開しなかったという背景もあるだろう。
だから、そんな昔の日本人の知見が今の日本人に生かされず、むしろアメリカ経由でアジャイルの発想に触れて熱狂しているという経緯もあるのだろうと思う。

忘れ去られた日本のIT技術～プロジェクト管理: プログラマの思索

忘れ去られた日本のIT技術～DOAと品質管理: プログラマの思索

【3】パターンランゲージを源流として発展した概念に、オブジェクト指向のデザインパターンやXPだけでなく、Wikiもあると「パターン、Wiki、XP」は説明している。
僕が興味を惹いたのは、TracはWikiエンジンとして生まれたという説明の箇所。
チケット駆動開発の発端となったTracは、Wikiを中核としたソフトウェア開発の支援ツールと見なすことができるわけだ。
そして、当初はTracのクローンとしてRedmineが生まれて、Redmine上でチケット駆動開発をアジャイル開発に適用できると気付いた経験が「Redmineによるタスクマネジメント実践技法」へつながっていく。
そう思うと、チケット駆動開発もパターンランゲージの思想を受け継いだ子孫と言えるかもしれない。

【4】今後考えてみたいのは、チケット駆動開発のプラクティスをパターンランゲージの文脈で置き換えたら、どのようにまとめられて、どのような関係性が見えてくるのか、という問題。
ラフに下記に書いた。

Twitter / @akipii: 「パターン、Wiki、XP 時を超えた創造の原則」によれば、XPのプラクティスはアレグザンダーの6つの原理に深く関係していて、各プラクティスはお互いを補完する構造を持つ。XPのプラクティスは有用だが個数が多すぎて把握しづらいけど、背後に原理があるという指摘でようやく納得できた。

Twitter / @akipii: チケット駆動開発のプラクティス「No Ticket, No Commit」「Ticket First」「Version is Iteration」「No Ticket, No Work」などもアレグザンダーの原理やパターンランゲージで理論化したい。それらは有機的で独自の存在を持つ

Twitter / @akipii: XPのオンサイト顧客はアレグザンダーの原理「参加の原理」から。小規模リリースは「漸進的成長の原理」から。常時統合やTestFirstは「診断の原理」から発生していると「パターン、Wiki、XP」では言う。ではチケット駆動開発のプラクティスはどの原理から導き出されたのか？

【追記1】
著者が何故「パターン、Wiki、XP」を書いたのか、という理由が下記に書かれている。
この本はまさに歴史書、哲学書と言えるのかもしれない。

『パターン、Wiki、XP』という本を書きました - えとダイアリー

下記で「はじめに」「あとがき」は読むことができる。

パターン、Wiki、XP ―― 時を超えた創造の原則（WEB+DB PRESS plusシリーズ）｜gihyo.jp … 技術評論社

【追記2】
システム提案や要件定義でよく出る絵として「オレゴン大学の絵」がある。
「オレゴン大学の絵」は、利用者・設計者・開発者それぞれの立場で作るべき対象は何なのかを理解しようとするものの、それぞれの理解が異なるとどれだけずれてくるのか、を表現した教訓にようなもの。
顧客が本来作りたいものは何なのか、を考える時に役立つ比喩のような資料と言っていい。
その発端はアレグザンダーにあったのが驚き。

オレゴン大学の絵 Dora_PaPa_san's_Pages/ウェブリブログ

［姿勢編］理由無き要求は機能化してはいけない - プロジェクト・マネージャの「やってはいけない」：ITpro

【追記3】印象に残った文章 - 『パターン、Wiki、XP』サポートWiki
から「印象に残った文章」を引用しておく。

(引用開始)
(p.45) パターンランゲージによる建築は、表面的な言葉だけをとらえると、パターンを組み合わせて建築するのだと思いがちです。ある意味、レゴブロックを組み合わせて建築を作り上げるように、それぞれのパターンに適する実体があって、それを単につなぎ合わせるようなイメージを生じさせます。しかし、それはアレグザンダーが言おうとしたことの正反対です。あらかじめ部品を用意してつなぎ合わせるだけといった考え方は、彼が最も反対した考え方なのです。

(p.194) デザインパターンは書籍に取り上げられた23個のパターンがすべてで、それを使いこなすことがパターンを使いこなすことだという考え方は、まったく間違っています。そうではなく、プログラマがプログラミングする際に、自分のプログラムにどのようなパターンが見いだされるかを自分自身で考え続けながらプログラミングすることが、本当の意味でパターンを使いこなす道なのです。つまり、デザインパターンは、読者が自分自身のパターンを見いだすための土台として使うのが正しい使い道なのではないでしょうか。

(p.195) XPではさまざまなプラクティスが提唱されていますが、それを「決まりごと」として受け取ってしまうと、開発プロセスはまったく改善されないでしょう。そうではなく、XPのプラクティスを入り口として、自分たちの開発プロセスを改善する方法を自分たち自身で考え続け、そこから得た経験をまたプラクティスとして抽出するようにする。そのようなプロセスを続けることによって初めて、XPのプラクティスが有効に働くようになると思います。

(p.195) Wikiは、非常に自由度が高いコラボレーションツールです。その自由度の高さのもとで、どのように使えばいいのかを自分たち自身で考えながら使うようにします。利用のルールを自分たち自身で考え続けて実践することで、初めてWikiをWikiらしく使いこなせるようになるのではないでしょうか。

(p.46) 建築計画では、往々にしてそれまであった古い建物を取り壊して更地にし、その上に新しい建物を建てるというスクラップ＆ビルドの考え方がとられます。しかし、古い建物を活かし、新しい建物と有機的な関係を保ち続ける方法を模索し、そのための手段をさまざまに講じることが、パターンランゲージの目指す方法論です。

(p.42) これは非常に難しい問いです。自然都市は自然にできたのだから自然都市なのであって、それを「意図的」に繰り返せば人工都市になってしまうのではないでしょうか。

(p.105) しかし、ソフトウェア開発における利用者と開発者は、まだ固定した関係には至っていないとベックは続けます。誕生して間もないコンピュータの世界であれば、利用者と開発者という社会的な関係を含めて新しく定義しなおせるかもしれません。ベックは、「ソフトウェアでは、新たな社会構造を作る機会がある」(p.156)と語っています。つまりXPの本当の目的は「新たな社会構造を作る」ことにあるのです。
(引用終了)

【追記4】
「パターン、Wiki、XP」書籍中の全URLを下記で一覧化してくれている。

Idea, Design, Engineering, Architecture, etc: [読書]パターン、Wiki、XPのリンク

下記の資料も参考になる。
翻訳 - オブジェクト指向プログラムのためのパターン言語の使用

【追記5】
平鍋さんもパターンランゲージとXPの関係について過去に書かれている。
とても分かりやすい。

パターン･ムーブメントからアジャイル・ムーブメントへ：An Agile Way：ITmedia オルタナティブ・ブログ

XPとパターン Ralph Johnson'sの見解

【追記6】
@daipresentsさんも本の感想を書かれています。

『パターン、Wiki、XP ? 時を超えた創造の原則』から感じた時を超えたソフトウェア開発の道 | daipresentsの世界

【追記7】

江渡さん（と角谷さんと懸田さん）のトークセッションのログが下記に書かれています。

パターン、Wiki、XP――時を超えた創造生成の原則(2009-07-10)

プロジェクトマネージャが抱えるプロジェクト管理の問題

プロジェクトマネージャが抱えるプロジェクト管理の課題について考えことをメモ。

現場リーダーやプロジェクトマネージャの立場になると、単なる開発者の役割だけでなく、チーム全体を鳥瞰する役割も担う。
更に重要な役割が、自分一人の責任だけでなく、チーム全体の責任、更には売上やコストの責任まで背負うようになることだ。

数年前に、別の会社の部長さんから、プロジェクトマネージャに必要なスキルは何か？と質問を受けた時がある。
その時の僕は、進捗管理とチームビルディングが大切です、と答えて笑われた。
その部長さんからは、進捗管理は全体の3割、チームビルディングは1割に過ぎない、リスク管理やコスト管理がそれぞれ3割は必要だ、と言われた時があった。

プロジェクトリーダーやマネージャに問われる能力は何か？: プログラマの思索

今になってその言葉がようやく腑に落ちる。
それらを一つずつまとめてみる。

【1】チームビルディング
現在のソフトウェア開発では、3～6ヶ月の短期間に開発者をかき集めてチームを形成し、アウトプットを出すという開発サイクルが多い。
しかし、優秀な開発者を揃えたからと言って、翌日からチームとして有機的に機能するわけではない。
タックマンモデルが示すように、メンバー同士が本音を出し合って混乱期を経なければ、チームとして機能しないのだ。
そして、プロジェクトマネージャはコミュニケーション計画をプロジェクト立上げ段階に作り、定期的にコミュニケーションを行う場を設けて、チーム全体のコミュニケーションが円滑に行われるようにする。
開発チームが一つの場所に集中しているならば、朝会や定期的なふりかえりの会議がそのような場になるだろう。
チケット駆動開発は朝会やふりかえりと相性がとても良い。
朝会やふりかえりに必要な情報はチケット駆動開発が提供するし、その情報を元にチームの見える化が促進される。
何よりも開発のリズムが生まれるので、メンバー自身がそのリズムに合わせて作業し始めるようになる利点がある。

プロジェクトファシリテーションはIT企業の中間管理職研修みたいだ: プログラマの思索

TiDDを実践して気付いたことpart1～解ける問題であれば人は自然に解決する方向へ動き出す: プログラマの思索

遠隔地にある開発チームや設計チームと協力して開発する場合は、意図的に報告や課題をやり取りする場を朝会やふりかえり以外に設定する事が必要になってくる。
特にオフショア開発はそうだ。
TV会議やSkype、GoogleDocsなどのツールが必要になってくるだろう。
オフショア開発チームとのチームビルディングは、今後のプロジェクトファシリテーションの課題であると思っている。

現代のAgile開発が抱える課題: プログラマの思索

プロジェクトファシリテーションに足りないもの: プログラマの思索

ペア作業やミーティングをクラウド化する: プログラマの思索

【2】進捗管理
ウォーターフォール型開発ならば、外部設計完了時に開発対象が確定するので、詳細なWBSを作るのが可能になる。
そのWBSを線表に引いて、詳細設計や開発やテスト工程のスケジュール管理を実施していく。
だが、ソフトウェア開発の進捗管理は当初の計画通りに進まないことが大半であり、計画外の作業が大量に発生しやすい特徴がある。
だからこそ、アジャイル開発のように変化に強い開発スタイルが必要になってくるし、アジャイル開発の実装例の一つであるチケット駆動開発が現場に適用しやすい。

【3】リスク管理(課題管理)
チームで発生する課題、遠い将来に発生しそうなリスクもチケットに登録して管理できるインフラがチケット駆動開発にはある。
進捗管理はチケット駆動開発がもたらす見える化によって作業そのものが不要になる。
むしろ、プロジェクトリーダーの仕事の大半は、メンバーが解決できない課題やチームに出てきた予兆のリスクに対して対応することだ。
次々に現れる課題やリスクをいち早く潰して、メンバーの作業の進捗が滞らないように、メンバーの環境を守る役割に変化する。
つまり、プロジェクトリーダーの役割は管理者よりもファシリテーターのように変わっていく。

XPのトラッカーの役割はTiDDがサポートする: プログラマの思索

【4】コスト管理
プロジェクトリーダーよりもマネージャレベルになると、プロジェクトの実際のコスト管理も逐一追跡していなかければならない。
当初の計画通りに進捗が進まなければ、人員を投入するか、納期を延長するか、開発対象を削るか、という判断を迫られる。
チケット駆動開発ではメンバーに担当チケットへ予定・実績工数を入力してもらう運用ができていれば、日々のコストを計測することが可能になる。
コスト管理で使われる指標はWF型開発ならPMBOKのEVM、Agile開発ならVelocityになるだろう。
つまり、WF型開発の場合、達成価値(EV)の変化に注目するし、Agile開発の場合、開発規模(ストーリーポイント)に着目する。

PMBOKのEVMの計測方法は下記に書いた。

RedmineからPMBOKのEVMを計測する方法: プログラマの思索

チケット駆動開発にEVMの概念を導入してみる: プログラマの思索

Velocityの計測方法は下記に書いた。

アジャイルサムライで一番難しくて面白い概念～Velocity: プログラマの思索

チームは加速するのか～Velocityの使い方 #agilesamurai: プログラマの思索

ソフトウェア開発の工数見積もりが混乱しやすい理由: プログラマの思索

工数見積もりで陥りやすい罠: プログラマの思索

現時点では、EVMを集計表示してくれるRedmineプラグインはないので、元ネタとなるPV・EV・ACをCSV出力した後、Excelのマクロで集計する必要はある。
IPAが開発中のプラグインの中にEVMを出力してくれる機能があるので、公開されたら楽しみだ。

【公開】RedmineのFAQとアンチパターン集 #Rxtstudy: プログラマの思索

VelocityはRedmineのバーンダウンチャートプラグインやBacklogsプラグインで計測可能だ。
いずれにしても、チケット駆動開発で収集した工数から計測可能だし、将来のコストを予測することも原理的に可能だ。

プロジェクトマネージャが抱えるプロジェクト管理の上記の問題はチケット駆動開発を徹底的に運用できれば、解決できるだろうと考えている。

「Agileな開発からAgileな組織へ」の資料は読むべき #aj12

@ryuzeeさんがAgileJapan2012の大阪会場で講演された資料がとても素晴らしいのでリンクしておく。
実際、@ryuzeeさんの講演では立ち見が出るほどの大人気だったし、平鍋さんもBlogで絶賛されていた。

【元ネタ】
Twitter / @akipii: とても素晴らしい発表資料。継続的デリバリー、リーンなプロセスや組織からリーダーシップ、自己組織化まで。すごい資料。Agileな開発からAgileな組織へ（Agile Japan 2012）#aj12 http://www.ryuzee.com/contents/blog/4778 @ryuzeeさんから

Agileな開発からAgileな組織へ（Agile Japan 2012）#aj12 | Ryuzee.com

AgileJapan 2012 in 大阪、ありがとう：An Agile Way：ITmedia オルタナティブ・ブログ

Agileな開発からAgileな組織へ #aj21 #b2

View more presentations from Ryuzee YOSHIBA

アジャイルな開発プロセスの話だけでなく、リーンソフトウェア開発におけるバリューストリームの考え方をベースに「顧客に価値あるソフトウェアを届けるには何が必要なのか」を色んな角度から説明している。

最近よく見かける「継続的デリバリー(Continuous Delivery)」の考え方も、リーンソフトウェア開発の観点で考えれば、必然的な考え方だ。
「ThoughtWorksアンソロジー ―アジャイルとオブジェクト指向によるソフトウェアイノベーション」に出てくる「ラストマイル問題」を解決するために、継続的デリバリーという概念が必要になったのだとも言える。

プロジェクト管理やテスト工程をクラウド化する: プログラマの思索

インフラやデータ移行の自動化～アジャイル開発の最後の問題: プログラマの思索

Continuous Delivery～TDDとCIの次に現れた自動化の概念: プログラマの思索

継続的インテグレーションから継続的デプロイへ: プログラマの思索

また、XP→Scrum→リーンへアジャイルの概念が発展していく流れの中で、組織のあり方として自己組織化に必要なアイデアをいくつも提示されている。
個人的には、アジャイルな組織のあり方の話では、最終的にはアジャイル開発に向く契約も議論しなければ完成しないだろうと思っている。

請負契約がソフトウェア開発者を苦しめている: プログラマの思索

アジャイルな契約と請負契約の比較: プログラマの思索

【告知】XP祭関西2012が4/7に開催されます

【元ネタ】
4月7日 XP祭関西2012　～技術指向で行こう！～(大阪府)

XP祭り関西2012 - XPJUG関西wiki

XP祭り関西2012～技術指向で行こう！～

2012年度の最初に、関西最大のアジャイル系イベント「XP祭り関西2012」を開催します。今年は「技術指向で行こう！」をキーワードに、関西で活躍されているアジャイルマインド120%の熱い技術者による大量のコンテンツをご用意！皆様のご参加を、スタッフ一同お待ちしています。

【開催概要】
タイトル XP祭り関西2012～技術指向で行こう！～
開催日時 2012年4月7日(土) 10:30～16:40
開催場所 福島区民センター
定員 90名
参加費 無料です。カンパ(ワンコイン500円)受け付け中。※懇親会は有料。
懇親会 お一人様 4、000円
参加申込み 4月7日 XP祭関西2012　～技術指向で行こう！～(大阪府)

<<プログラム>>
10:00-10:30 受付
10:30-12:00 【基調講演】
12:00-13:00 昼休み
13:00-14:30 【1-1】 【1-2】
13:30-14:40 休憩
13:40-16:10 【2-1】 【2-2】
16:10-16:20 休憩
16:20-16:40 【ライトニングトークス】
16:40-17:00 クロージング

<<「アジャイルマインド同人誌」即売します>>
アジャイルマインドにあふれる著者達によって作り上げられた
「アジャイルマインド同人誌」。
当日、この同人誌を即売します。
■Agile Mind同人誌

【講演内容】
【基調講演】

▼ 「アジャイル開発の計画と管理」

～アジャイルのプロジェクトマネジメント～

梅田 弘之氏 /株式会社システムインテグレータ　代表取締役社長

アジャイル開発にはスクラムボードやバーンダウンチャート、プラニングポーカーなど、ユニークな管理方法があります。

これまでのウォーターフォール開発で使われてきた伝統的なプロジェクト管理方法とこれらの管理方法の関係はどうなのか、アジャイル向きの管理方法とは、ウォーターフォール型の管理手法はどの程度有効なのか、

などなどアジャイル開発におけるプロジェクトマネジメントのあり方について、デモや事例を中心にご説明します。

【1-1】PIVOTALとRUBYルーム(301)定員50名

▼「PIVOTALとSCALAとRUBY ON RAILS」

川端 光義氏　／アジャイルウェア　代表

プログラマーがプログラミングに専念できる環境を考える
・重要性を増しているツールたち
・Pivotal Trackerによるアジャイルにマッチしたタスク管理デモ
アジャイル開発に必要なプログラマーとは？
Android開発をScalaでやってみた
新しく覚えてまでRuby on Railsは必要なのか
・早くて変更に強いだけではない
・Rubyの魅力を伝えるRailsデモ

【1-2】TDDルーム(302)定員40名

▼「TDDサイクルを加速する技術たち」

irof氏　／TDDBC

テスト駆動開発の概要と、実践で学んだことを話します。
その中から特にTDDサイクルを加速する技術たちを紹介。
直接関わるテスティングフレームワークやIDE、間接的にはバージョン管理システムやCIサーバ。
デジタルなツールだけでなく、マインドマップなどアナログな技術もあります。
また、ディスカッションとかも出来たらなと思っています。

【2-1】ワークショップルーム(301)定員50名

▼「システム要求の源」

～ITエンジニアも知ってる方がお得なビジネスモデリング～」

猪原 信彦氏　／一般社団法人 西日本アジャイルプロセス協議会 副会長

エンタープライズ系のITシステムは企業の事業戦略を具現化した施策です。当然、ITシステムに対する要求はその企業のビジネスモデルや事業戦略に影響されます。

このセッションではITエンジニアを対象にビジネスや事業戦略を理解するための切り口を紹介します。

【2-2】事例発表ルーム(302)定員40名

▼「大規模なゲーム開発をスクラムで」

田口 昌宏氏 ／株式会社ディンプス

近年、日本のゲーム業界にもアジャイルやスクラムの名前が徐々に定着してきたように思います。弊社でも５名の認定スクラムマスターがおり、積極的に社内での導入を検討しています。
今回は100名規模の大規模ゲーム開発における現場主導によるスクラムの導入の経緯、また運用上の問題点やその改善点などの導入事例をお話したいと思います。

▼「継続的インテグレーション環境を作れ！(JENKINS編)」

神谷 厚輝氏 ／株式会社ブレイン

発表者が自社やXPJUG関西分科会で試みた継続的インテグレーション環境構築のノウハウや構築する意義についての考察をお話します。

▼【ライトニング・トークス】

＜定員となりました。たくさんのお申し込みありがとうございます＞
求む！挑戦者！
今年はどんな発表が聞けるのか？
請うご期待！！

アジャイルな契約と請負契約の比較

最近注目されているアジャイルな契約が何故請負契約よりも優れていると思われるのか、考えたことをラフなメモ書き。
理解が間違っていたら後で直す。

【元ネタ】
Twitter / @akipii: その資料が是非見たい！委任契約と請負契約以外の選択肢はあるかな？ RT @haradakiro: アジャイル契約のプレゼン資料つくってたら、ウォーターフォール成立の歴史だけで時間を使い尽くしそうな勢い。

Twitter / @haradakiro: @akipii 発表前なのでちょっとお待ちを、というかまだできていないww 「次のアジャイルソフトウェアプロジェクトに使える10の契約」はご存知でしたか？ http://bit.ly/93lTtB 自分の話は、三者契約によってリスクと責任を分散させる話です。

Twitter / @akipii: @haradakiro 知らないので読んでみます。委任契約と請負契約の制約を誰かぶち壊して欲しいです。WF型開発と多重請負の源泉だから。アジャイル開発がアジャイルごっこになってしまうから。

情報処理推進機構：アジャイル型開発を推進するための活動成果を公開

翻訳 - 次のアジャイルソフトウェアプロジェクトに使える10の契約

[コラム] Bent Jensen 来日: アジャイル開発に適した契約 ～ ハイブリッド契約の例: TDD.NET

請負契約がソフトウェア開発者を苦しめている: プログラマの思索

再見積もり、Velocity、そしてアジャイルな契約: プログラマの思索

アジャイル開発の契約スタイルに関するIPAの報告書: プログラマの思索

請負契約はFixed price 契約と同じ。
スコープとコストと納期が固定ゆえに、アジャイル開発の特徴であるスコープの変更がやりにくい。
だから、アジャイル開発に向いた契約にするには、委任契約をベースにスコープを柔軟に変更出来る仕組みが必要。

イテレーション単位にリリースしていく開発スタイルを契約に反映させるならば、イテレーション単位に委任契約を結ぶのがいい。
そうすれば、イテレーションが完了するタイミングで、開発対象の機能を入れ替えるのがやりやすくなる。
昨今のようにビジネス環境がすぐに激変する時代では、リリース計画を柔軟に変更でき、急ブレーキ急発進できるアジャイルな契約スタイルの方が向いているのだろう。

実際、IPAが推奨している契約スタイルを読むと、アジャイルな契約は本質的には委任契約であると言える。
例えば、Time and Material 契約はいわゆる工数比例契約、つまり 準委任契約だ。 掛かった工数に比例して支払ってもらうやり方。
AgileJapanの懇親会で原田さんが話されていたインセンティブのある契約も工数契約つまり委任契約だと思う。
実費精算契約も委任契約に相当すると思う。

委任契約の弱点は、成果物の完成責任がないこと。
工数に比例する契約ゆえに、工数がかかるほど受託側は儲かるし、発注側は損をする。
だから、発注側は請負契約をSIと結んで、スコープとコストと納期を固定した契約にし、成果物の完成責任を負わせる。

請負契約が開発者に多大な負担を強いている点は、請負契約がソフトウェア開発者を苦しめている: プログラマの思索に書いた通り、「成果物の完成責任が無限責任にすり替わっている」点と「要員の変動が激しいため動員力のある企業が有利」という点にある。
特に、請負契約でシステム開発が終わった後、普通はリリース後１年間はSIが瑕疵担保責任として、バグが見つかったら無償で直す場合が多い。
だから、１次開発で赤字を覚悟の上で２次開発や運用保守で定期的にお金をもらうビジネスモデルになるので、資金力の無い会社は耐えられないだろう。
資金力の無い中小SIは下請けとして入って要員の変動をなくす。
そこに日本のIT業界特有の多重下請構造が発生する。

また、SI企業に勤務する技術者は裁量労働制の契約を結ぶ時が多いが、その理由の一つは請負契約のプロジェクトに従事する場合が多いからだろう。
委任契約のプロジェクトが多いならば、工数比例契約で労働してもいいからだ。
従って、サービス残業や休日出勤を強いられる時もある。

アジャイルな契約については今後も注視していく。

【追記】
@chomukyuさんと有意義な議論ができたので残しておく。
@chomukyuさん、ご指摘ありがとうございました。

Twitter / @chomukyu: @akipii こんにちは。システムの「完成形」を決めずに育てていくアジャイルでは、瑕疵と仕様変更を区別しようとする請負契約は向かなさそうですね。受託側が保証するとすれば、ベロシティでしょうか？ RT: アジャイルな契約と請負契約の比較

Twitter / @akipii: @chomukyu こんばんは。顧客の観点ではVelocity(開発規模)を保証されても、そのコストは工数ベースですか？成果物ベースですか？と質問されると思います。「成果物の完成責任」「瑕疵担保責任」が結局ボトルネックになると思うのです。

Twitter / @chomukyu: アジャイルではシステムの完成形を決めないので、瑕疵担保という考え方とは相性が悪そう。かといって、バグだらけでもOKとは発注側も言えない。とすると、落とし所はベロシティ保証？　という発想に。

Twitter / @chomukyu: でも、事前にベロシティを保証することも難しいので、契約単位を短くして「気に入らなければ切ってください」という倉貫さん方式か、「システムを使っている間だけ支払ってください」という平鍋さん方式になっていると理解してます。

Twitter / @chomukyu: @akipii 顧客のことを考えれば、成果物視点（ストーリーポイント単位など）になるでしょうね。ただし事前に保証することも難しいので、倉貫さんも平鍋さんも「気軽に使ってみて駄目だったら切ってください」という仕組みにしているんだと想像しています。

Twitter / @akipii: @chomukyuさんが仰る通り「気軽に使ってみて駄目だったら切ってください」という仕組みにならざるを得ないと思います。そのビジネスモデルはパッケージ製品やWebサービスなら自社で制御できるのでやりやすい。受託開発の請負契約はアジャイル開発にとって鬼門だと思います。

Twitter / @chomukyu: @akipii ちょっと視点を変えると、成果物責任や瑕疵担保責任は「あるべき成果物の姿」がないと定義不能なので、それらの責任を要求される時点で、アジャイルとしては詰みな気もします。『アジャイル契約でひどい目にあった話256』とか出版されたら、一万円くらいでも買うんですがｗ

Twitter / @akipii: @chomukyu なるほど、アジャイル開発では「あるべき成果物の姿」は未確定(常に変化)なので請負契約における「あるべき成果物の完成責任」を果たすのは元々無理ですね。一つ理解できました。ありがとうございました。

【公開】AgileJapan2012講演資料「チケット駆動開発の課題と展望」 #aj12

本日のAgileJapanでは、多くの人がチケット駆動開発の講演を聞いて下さりありがとうございました。
また、スタッフの皆様、お疲れ様でした。
AgileJapan2012講演資料「チケット駆動開発の課題と展望」をCCアトリビューションライセンスで公開します。

AgileJapan2012講演資料「チケット駆動開発の課題と展望」 from akipii Oga

昨年のAgileJapanは聴衆の一人に過ぎなかったのに、今年は講演者としてメイン会場の午後1番のセッションで発表することになり、とても光栄でした。
自分としては資料をもう少し練れたかなと反省していたのですが、平鍋さんや岡山から来て下さった人から、今日の発表は良かったよ、と言われて正直ホッとしてます。

パネルディスカッションで良い議論ができたと思うのは、チケット管理で朝会やふりかえりを組み合わせて運用するのは効果的なのか？という質問があった時です。
朝会やふりかえりはプロジェクトファシリテーションのプラクティスの一つであり、僕個人の経験としてチケット駆動開発ととても相性が良いです。

朝会では必ず昨日の実績を報告する状況があり、チケット1枚を完了したと報告するのと、チケットをまだ作業中ですと報告するのでは全く評価が異なります。
特に、新人や若手にとって、朝会で自分がチケットを少なくとも1枚は完了できたと報告できるようにうまく作業を渡すようにすれば、彼らはどんどん自信をつけて力を伸ばしていくでしょう。

ふりかえりでは、チケット管理で良かった点ややりにくかった点を議論して、次回のイテレーションでは、こういう新しい運用を試してみようというTryが出るととても良いです。
Problem→Try→Keepという流れが回れば、自然にプロセス改善できる仕組みが出来上がるからです。

講演中に、チケット駆動開発を実践している又は経験したことがある人に手を上げてもらったら、半数近くの人が手を上げて頂き、改めてチケット駆動開発の知名度が上がっている事実を知りました。
ですが、チケット駆動開発は「Redmineによるタスクマネジメント実践技法」しか書籍で紹介されておらず、まだまだ理論化する余地が沢山あります。

個人的には、平鍋さんが日本の環境に合うようにアジャイル精神を吹き込んだプロジェクトファシリテーションのように、チケット駆動開発を日本発のアジャイル開発の実践技法として提唱できればいいなと思っています。

【追記】
公式レポートが公開されています。

[早版] 大阪「チケット駆動開発の課題と展望」 – Agile Japan 2012レポート(22)

チケット駆動開発の展望part2

ソフトウェア構成管理とチケット駆動開発の関連についてメモ。

【1】Twitter / @akipii: この資料はかなり良い！昨今のGit/Mercurialがどんな問題を解決したのか、詳しく書かれている。　分散リポジトリ型時代のソフトウェア構成管理

分散リポジトリ型時代のソフトウェア構成管理

GitやMercurialなどの第3世代のバージョン管理ツールの特徴や利点が詳しく書かれていて参考になる。
最後のまとめにある「「構成管理が面倒」なのではなく、「面倒なツールで構成管理していた」ことが実感できて幸せ」に同感する。
ツールが我々の作業や思考そのものを規定しているだけでなく、制約をかけている。

ソフトウェア構成管理がソフトウェア開発の作業手順に制約をかける: プログラマの思索

【2】Twitter / @akipii: MercurialやGitを使う技術の方が単なるプログラミングよりも重要という指摘。人の足を踏まずに仕事をするということ：ある nakagami の日記：So-netブログ

人の足を踏まずに仕事をするということ：ある nakagami の日記：So-netブログ

チームでプログラミングする時、patch(diff)でのやり取りができるか、GitやMercurialの作業に慣れているか、マージ作業が出来るか、と言ったスキルの方がはるかに重要という指摘をしている。
この指摘は、日曜プログラミングと違い、オープンソースでもチームでプログラミングする場合、お互いの成果物を差分比較してマージして一つの成果物を作っていく連携作業に慣れているかどうかが重要ということにつながる。

TortoiseSVNでもpatchを出力したり、逆にpatchをソースに取り込んで反映できる仕組みがある。
どのリビジョンのソースを改変して、どんなソースを追加したのか、というパッチを見て、コミッタはコードレビューするし、検証もする。
パッチがあれば、マージ作業もやりやすくなる。

【3】Twitter / @akipii: RedmineのREST APIを使った良い例。Mercurial のフックを利用して Redmine のチケット操作を自動化する (フェンリル | デベロッパーズブログ)

Mercurial のフックを利用して Redmine のチケット操作を自動化する (フェンリル | デベロッパーズブログ)

Redmineの設定画面にはAPIキーを生成してWebサービスを実行できる仕組みがある。
上記の記事では、post-commit-hookをAPIキーを使ってWebサービス化する手法を提示しているだけでなく、PythonのフックスクリプトでチケットをCloseする機能も追加している。

post-commit-hookは、チケット駆動開発の運用ルールであるNo Ticket, No Commitの発端となった機能であるがゆえにとても重要な機能の一つ。
SCM連携の機能強化はもっと研究される余地があるだろう。

【4】Twitter / @akipii: 良い記事。No Ticket,No Commitを実践する時コミットの単位にとても気を使う。コミットにはプログラマの意思が込められている。クリアなコードの作り方: 意図が伝わるコミットのしかた - ククログhttp://www.clear-code.com/blog/2012/3/13.html #redmine

クリアなコードの作り方: 意図が伝わるコミットのしかた - ククログ(2012-03-13)

チケット駆動開発でソースをcommitするとき、commitする粒度にとても神経を使うようになる。
駄目なプログラマはコミットするソースの差分を見ても、何を変更したいのか、分かりにくい。
特に、機能追加やバグ修正を混ぜ込んで、Fatなcommitする時は特にそうだ。

上記の記事では、コミットする粒度についていくつかのアドバイスが書かれていてとても参考になる。
基本は、コミットする理由が分かるように細かく分ける方がいいだろうと思う。

僕も、コミットログの書き方はメンバーに口うるさく言うようにしている。
一度コミットログの書き方に慣れれば、自分の意思を持ってソースを修正するようになる。

SVNのコミットログの書き方: プログラマの思索

No Ticket, No Commitには教育的効果があると思う。

No Ticket, No Commitの効果: プログラマの思索

特に、ソースに書かれた障害管理番号や無駄な仕様の記述は、ソースではなくチケットやコミットログに書くべきだ。
そうしなければ度重なるソース修正で、すぐに古くなりガラクタのコメントになるからだ。

SCMコミットログはファイルのメタ情報: プログラマの思索

変更理由や仕様はソースのメタ情報であり、そのメタ情報はSCMコミットログやBTSチケットに記載して管理されていくべきだと思う。
SCMやBTSに貯められたメタ情報は、BTSの優れたレポート機能によって色んな観点でメトリクス出力でき、分析したり是正対策を取ることも可能になる。

色々考えてみる。

ゲーム市場が大きく変化している

東京に来て思うのは、SNSやゲームに関わるIT企業が多いこと。
僕は業務系システム開発でずっと来たから、そういうIT企業の会場で勉強会があった時、等身大のキャラグッズがあったり、お菓子やジュースが飲み放題になっている施設を見て驚いた時がある。
ゲーム市場について下記のBlogを読んで思ったことをメモ。

【元ネタ】
Life is beautiful: 携帯型ゲーム市場の大幅シフトと据え置き型ゲーム市場の未来と

Life is beautiful: iPod touch と Angry Bird に駆逐された Nintendo 3DS

Twitter / @akipii: 日本企業が制覇していたTV・PC・携帯が海外勢に次々に奪われて、最後のゲーム機も奪われるのか？世の流れがスマートフォンに移っている世相を反映しているようだ。　携帯型ゲーム市場の大幅シフトと据え置き型ゲーム市場の未来とhttp://t.co/bzbputzz

イノベーションのジレンマ～過剰技術・過剰品質の罠: プログラマの思索

日本のゲーム市場は、ソニーのPS3やPSP、任天堂のDSiやWiiが今も主流だろう。
今でもファイナルファンタジーとか売れ筋のゲームがまだあるから。

でも、iPhoneやAndroidがソニーや任天堂のゲーム機を駆逐しつつあるという上記の記事は興味深い。
その本質は上記の記事に書かれている通り「イノベーションのジレンマ」にある。
つまり、最初は品質も機能も劣っていた製品が、瞬く間に従来の高価で高機能な製品を駆逐してしまう症状のこと。

現代のビジネスは常に「イノベーションのジレンマ」にさらされていると言っていい。
ゲーム機だけでなく、携帯電話、家電製品、自動車など日本が得意としてきた製造業の分野は、当初は品質も機能も劣っていた新興国の製品群に押されている。
イノベーションのジレンマ～過剰技術・過剰品質の罠: プログラマの思索にも書いたけれども、日本の企業は過剰品質にこだわりすぎ。
PMBOKの品質管理では、顧客が要求する以上の品質を作る過剰品質を金メッキと呼んでけなしている。
いくら高品質で高価格な製品を作っても、マーケットに合わせて変化しなければ、結局売れていない。

「イノベーションのジレンマ」が主流のビジネス世界では、急ブレーキ・急発進できる意思決定の仕組みやビジネスモデルが必要になってくるだろうと思う。
そうでなければ、意思決定にもたついている間にマーケットのNo.1からあっという間に滑り落ちてしまう。

アジャイル開発は短い期間にイテレーション単位に開発していくスタイルゆえに、急ブレーキ急発進の意思決定をイテレーション完了時に意図的に取り入れやすい。
イテレーションが終わるタイミングで、当初予定していた機能を止めて新たな機能を最優先に作るという判断の切り替えがやりやすいのだ。
つまり、当初の長期計画をビジネスの環境の変化に応じて柔軟に変える仕組みがあると思える。
計画は不変ではなく、状況に応じて常に最新化しなくてはならないのだ。

アジャイル開発にはたくさんの可能性が秘められていると思う。

請負契約がソフトウェア開発者を苦しめている

IT業界で仕事していて、何故かデスマーチプロジェクトに数年に1回はぶち当たる。
デスマーチに陥る原因は技術力の不足やプロジェクト管理の能力不足などがあるけれども、IT業界で一般的な請負契約そのものに根本原因があるような気がしている。
請負契約が日本のソフトウェア開発者を苦しめているのではないかという仮説について考えたことをラフなメモ書き。

【元ネタ】
Twitter / @akipii: 日本のソフトウェア開発者を苦しめている根源に請負契約があるという仮設を考えてる。平鍋さんや倉貫さんが試しているアジャイルな契約は請負契約のアンチテーゼと考えると分かる気がする。

Twitter / @akipii: @mr_amichan 請負契約の制約条件は開発者の想像以上にソフトウェア開発者に厳しいのです。請負契約である限り本当のアジャイルな開発でないと体験してます。それをうまく説明したい。

Twitter / @sugimoto_kei: @akipii 僕は、成果物コミットなしの契約でずっとシステム開発をしていますが、その場合、お客様の側からみてコミットなしでも安心できるような仕事の枠組みをどう作るがポイントと考えています。これについて書いた文章があります。ご参考になれば→http://t.co/5et4iFiB

Twitter / @akipii: @sugimoto_kei @hiranabeビジネスだからソフトウェア開発者も責任あるけど請負契約にある成果物の完成責任がソフトウェア開発者だけの無限責任にすりかわるのが諸悪の根源と思います。アジャイルな契約では開発者の責任を減らして顧客も分担し責任のリスクを減らしてる気がする

Twitter / @itachidon: おー。そのとおり。RT @akipii: SEの仕事の大半は顧客や社内部署、他チームの調整という名前のコミュニケーション。ネゴシエーション、ハンドリングとも呼ばれる。IT業界でコミュニケーションが重要なのは役職ほど調整能力がいるから。面倒で仕方ない。

Twitter / @hiranabe: RE:請負契約 @akipii @raito3 @MasayukiToyoda IPAでも契約は１つの大きな問題だと捉えている。同じゴールを共有しにくくなる。海外事例の多くは１つの会社の製品（もしくはサービス）開発なので契約の問題を含まない。

Twitter / @hiranabe: @akipii @MasayukiToyoda @raito3 請負の中でもソフトウェア開発者がいきいきと活躍できる場は作れると思って、そのトライがプロジェクトファシリテーションでした。さらに、ブラジルで受託開発の100%アジャイル化を見て、まだぼくらに足りないことがあると知る。

Twitter / @akipii: 請負契約が主流のビジネスは動員力がモノを言う。外部設計までに仕様を固めて開発は請負契約で開発者を大量動員する。テストで最大人数になりリリース直前に一気に減らす。動員力を自社や外部で調達できる会社だけが有効なビジネスモデル。アジャイルと正反対だ。

新しい契約形態での受託開発サービス「価値創造契約」 ｜ 永和システムマネジメント

「価値創造契約」と「納品のない受託開発」そして二人の男の運命～アジャイルジャパンの見どころ - Social Change!

再見積もり、Velocity、そしてアジャイルな契約: プログラマの思索

【1】日本の受託ソフトウェア開発の契約スタイルは、委託契約と請負契約の2種類がある。
WF型開発では、工程単位で委託契約と請負契約を分けて開発する。

見積りのタイミングは、システム提案完了時と外部設計完了時の2回がある。

システム提案時は顧客の要望を聞き出して概算見積りを行い、顧客とSIの双方で大きな隔たりが無いことを確認するのを目的とする。
普通は、システム提案から外部設計が完了するまでは委託契約を結び、少数精鋭のSEチームで要件から仕様を詰めていく。
理由は、開発対象の範囲が確定していないので、見積りが大きく変る可能性があるから。だから労働時間単位の契約を結んで、早めに再見積を行うための外部設計を行う。

そして、外部設計で仕様を詰めて開発範囲を決定後に再見積もりを行い、その再見積もりの結果を元に請負契約を結ぶ。
請負契約の期間は、内部設計、開発、単体テスト、結合テストまでが普通だろう。
特に顧客は請負契約をSIと結びたがる。
何故なら、開発したシステムの瑕疵担保の責任の所在を明確にして、もし瑕疵があればSIに責任をとってもらいたいからだ。
そのためにも外部設計後の再見積もりはとても重要な指標になる。

そして、システムテストや受入テストでは委任契約になり、リリース後は保守契約に進んでいく。
SIの受託開発の基本的なビジネスモデルは、1次開発は赤字になっても、その後の運用保守や2次開発で黒字化して定期的にお金が入ってくる仕掛けを作ること。
日本のSIもクラウドに対応しようとしているが、所詮はプライベートクラウドであり、自分たちが作ったデータセンターにあるシステムが稼働している間、顧客から定期的にサービス利用料としてお金をもらう仕組みにすり替わってる。

【2】だが、請負契約が主体の受託開発はとてもリスキーな気がしている。
請負契約では、開発者は成果物の完成責任を負う。
だから、自分たちが作ったプログラムでバグが見つかれば、そのバグが直るまで、最後まで見届ける責任がある。
そのために、開発者がどれだけ苦労していることか。
単体テスト、結合テスト、システムテストとテスト工程が進むと共に、開発者の責任は大きくなっていく。

請負契約に成果物の完成責任はビジネス上、責任を明確にする意味では当たり前だが、ソフトウェア開発では、開発者に対する成果物の無限責任にすり替わっている点に問題があると思う。
ソフトウェアはバグをゼロにするのは至難の業なのに、バグが出る度に残業して休日出勤して徹夜で作業しなければならない。
バグ修正しても、逆にデグレードしたり、別のバグを埋め込んだりするから、いくらやってもキリがない。

開発者が成果物の完成責任を果たそうと頑張るほど、逆に無限責任となり、無限地獄に陥る。

【3】請負契約のビジネスモデルでは、動員力がモノを言う。
開発からテストに至る工程で、大量の開発者を短期間にかき集めて、システムを作り上げる。
WF型開発では、プログラミングを「製造」という工程で呼ぶが、それはまさに工場の生産ラインでプログラムを大量生産していることを連想させる。
そして、テストが終わり、リリース直前にかき集めた大量の開発者を切り、システム開発を収束させていく。

何故、そのようなビジネスモデルになるのかという理由は、WF型開発では、要員の変動があまりにも大きい点にあるからだと思う。
外部設計で確定した機能を元に、リリースまでの短期間にどれだけ開発者の頭数が必要か見積もりする。
この時の要員表を作るのがマネージャの一番の仕事だ。
要員表はコスト管理に直結するため、自社で不足したリソースを外部から調達する手段をとるのが普通。

だから、大手SIは動員力に物を言わして、下請けのSIからたくさんの開発者を集めてもらう。
大手SIは外部調達能力に優れているからこそ、短期間に大量の人員を動員することができる。
大手SIは資金力があるからこそ、リソースの大きな変動に耐えれるわけだし、逆に中小SIは、下請けの仕事を常にかき集めなければ生きていけない。

でも、開発者から見れば、苦痛なことこの上ない。
何故なら、現場には入ればいきなり内部設計や開発を任されて、その後のテストでバグ出ししていかないといけない。そして、テストが追われば、自分の首が切られることを知っている。
開発者は、開発現場を渡り歩くジプシーや流れ板みたいな存在。

最近の日本のソフトウェア開発では、オフショア開発をうまく利用して、動員力を更に柔軟にしようとする姿勢が見られる。
日本国内で開発するよりもオフショアの方が1/5のコストで済むならば、プロジェクト管理能力さえあれば受託開発をコントロールするのはそう難しくない。
そのビジネスモデルは日本のソフトウェア開発の技術力を貶めている。

【4】請負契約の受託開発には、「成果物の完成責任が無限責任にすり替わっている」点や「リソースの変動が大きいために動員力が必要」な点という特徴が見られる。
その特徴は、アジャイル開発とは無縁な開発スタイルだ。

アジャイル開発では、顧客同席やプロダクトオーナーという概念によって、成果物の責任が開発者から減るような仕組みがあると思われる。
実際、顧客はどの機能をリリースするか決定する権限を持つが故に、どの機能を先に作るべきか、という決断の責任も持つ。
もしリリース後に、リリースした機能が本来の価値を生み出していなければ、それは開発者の責任だけでなく、リリースすると決定した顧客にも責任の一端はある。
だから、成果物の責任の一端を顧客は担っていると言える。
つまり、開発者の責任は減っている。

また、アジャイルなチームは結束力が高く、イテレーション単位に開発していくから、リソースの変動は殆どないと言っていい。
2～4週間のサイクルでリリースしていくには、いきなり新規の開発者を大量動員してもたかが知れているし、逆に新規の開発者に色々説明するために時間を取られて、逆にチームの生産能力が落ちてしまうからだ。

【5】請負契約は開発者にとってたくさんの不利な点がある。
アジャイル開発の契約では、開発者にとって不利な従来の請負契約ではなく、開発者の責任を減らして顧客にもシステム開発の責任の一端を取ってもらうような契約スタイルに変化していると言える。

平鍋さんの会社の「価値創造契約」や倉貫さんの「納品の無い受託開発」は、僕は詳細は知らない。
でも、その契約の背後には、開発者が本来の能力を発揮できるような環境を作るための契約である気がする。
その契約で本当にビジネスとして成り立つのか、そしてビジネスモデルとして請負契約を駆逐していくのか、正直分からない。
でも、従来の請負契約が日本のソフトウェア開発者を苦しめているのは事実だ。

色々考えてみる。

SCMコミットログはファイルのメタ情報

バージョン管理ツールがCVS、Subversion、MercurialやGitへ進化するに連れて、構成管理の意味合いが変化しているのに気付いた。
考えたことをメモ。

【元ネタ】
Twitter / @akipii: 良い記事。僕もPrivateファイルはMercurialで管理している。コメントや履歴のようなファイルのメタ情報はコミットログで保持すべき。重要ファイルはSubversionで管理する - Basic　

重要ファイルはSubversionで管理する - Basic

SVNのコミットログの書き方: プログラマの思索

TortoiseSVNの差分機能は素晴らしい: プログラマの思索

TortoiseSVNからBTSと連携する: プログラマの思索

TortoiseHgはSVNクライアントとしても優秀: プログラマの思索

TortoiseHgからBTSチケットへリンクできるようになった: プログラマの思索

僕は、仕事ではなく、自分だけのプライベートPCでも、ファイルのバックアップ代わりにMercurialで履歴管理している。
他に、自分で書いたソース、ApacheやRedmineの設定ファイルなども履歴管理している。
特にコミュニティの講演資料や記事などの原稿は、書きながら試行錯誤して完成していくため、その過程の履歴を後で思い出したいから。

重要ファイルはSubversionで管理する - Basicにも書いてあるように、履歴管理が必要になってくる理由は、バックアップだけでなく、修正時のコメントや理由なども記録したいからだ。
つまり、修正理由や変更理由のような情報は、ファイルのメタ情報であることを示唆している。
ファイルのメタ情報は、SubversionやMercurialのコミットログとして記録しておけばいい。

これは、ファイルのメタ情報をどこに配置すべきなのか、という問題につながる。
従来は、ソース自身に「@history」のようなJavaDocで履歴を書いたりしていたが、履歴や変更理由のような情報はSCMコミットログなりITSチケットに記録して分離した方がいい。
その方がソースは綺麗になるし、外出ししたコミットログやチケットに情報を追記したり更新することも可能になる。

最近は、TortoiseHgやTortoiseSVNのようなクライアントツールがとても優れているので、どんどん使った方がいいと思う。
実際、ExcelやWord、Powerpointの差分表示、BTSへのリンクなどの機能もあるので、とても作業しやすくなった。

チケット駆動開発では、成果物のメタ情報は、SCMコミットログに書かれたチケットNoを経由して、ITSで一括して保持する。
その利点は、ITSの統合DBにメタ情報が一括管理されているために、全文検索や変更理由の追跡も楽になる点にある。

ITSというプロジェクト管理ツール、そして、TortoiseHgやTortoiseSVNという優れたSCMクライアントツールのおかげで、作業の生産性は確実に上がってきている。
ツールが作業の内容を本質的に変えているという重要性にいちはやく気づくべき。
それは、ITリテラシーの一部とも言える。

優れたソフトウェアを使いこなすことで、未だに手作業で頑張っている人達よりも格段にアウトプットを作れる時代になってきている。
バージョン管理ツールを使いこなすことも、現代の一般人のITリテラシーになってきているのだ。

epub出版システムの作り方

電子書籍の記事はたくさん見かけるが、まだどこもビジネスモデルとして確立していない。
オライリージャパンやオーム社は、独自のepub出版システムを作って、今までにない新しい出版スタイルを築こうとしている。
技術的側面とビジネス的側面についてメモ書き。

【元ネタ】
オライリー・ジャパンのePUBフォーマットを支える制作システム - O'Reilly Japan Community Blog

技術書をアジャイルに作る: プログラマの思索

Geekなぺーじ:オーム社開発部での開発体制

Geekなぺーじ:オーム社開発部の方とのやり取り

電子書籍はSaaSの一つに過ぎない: プログラマの思索

【1】電子書籍の本命はepubフォーマット。
epubは所詮、HTMLとCSSをZIP化したファイルに過ぎないが、iBooksやStanzaのような電子書籍リーダーの上で滑らかに紙の本のように読むことができる。
epubは電子媒体ゆえに、コピーも簡単だし、ネット上で配布も簡単。

技術的には、テキストというオリジナルの原稿があれば、epub用のHTMLに変換してZIP化すればいいから、バッチ処理として実装すればいい。
オライリージャパンやオーム社のepub出版システムは、GitやSVNにあるテキスト原稿からバッチ処理でepubフォーマットの電子書籍を常時ビルドする仕組みと同じだ。

技術的に面白い点は、バッチ処理で常時ビルドする仕組みとして、CIツールのJenkinsが現れること。
Jenkinsは単なるビルド管理ツールではなく、高機能なCronだけでもなく、高機能なバッチ制御ツールとして認識すべきだ。

個人的には、高橋征義さんが主催する達人出版会が持つ「ReVIEW」というEPUB/PDF生成ツールに興味がある。
テキストをepubやPDFへ変換する処理をRubyで実装している点が興味深い。

EPUB生成ツール「ReVIEW」について達人出版会の高橋氏に聞いてみた - builder

1つのソースでEPUBとPDFを生成できる「ReVIEW」を試す - builder

kmuto/review ・ GitHub

【2】ビジネスモデルとしては、本来はAppleのiTunesとiPhoneのようなソフトとデバイスを組み合わせた上で、epub形式の電子本を提供することをどの会社も狙っている。
だが、再販制度などの法律や日本独特の出版の商慣行のために、変化が見られる気配はない。

Appleが音楽をソフトウェアに変換したことで、音楽を聞く行為そのものは本質的に変わってしまった。
電子書籍も紙の本をソフトウェアに変換することで、書籍を読む行為そのものが本質的に変わる可能性がある。
個人的には、週刊誌や漫画、雑誌などのように生鮮食料品並に購読期間が極端に短い書籍は、エコの観点からも積極的に電子書籍にしてしまうべきだと思う。
1週間後、1ヶ月後には、週刊誌や漫画、雑誌はゴミ箱に捨てられてしまうのだから。

新聞も電子書籍に変えてしまうべきだ。新聞は粗悪な紙で印刷されていて、肌触りも悪いしあまり読みやすい代物とは言えない。1日の賞味期限しか無く、翌日にはゴミ箱に直行するから。

電子書籍はSaaSの一つに過ぎない: プログラマの思索にも書いたけれど、電子書籍はAppleの音楽配信と言うSaaSと同じく、SaaSの一つと捉えた方がいい。
だからこそ、ソフトウェアの技術力が高い会社が電子書籍のビジネスモデルを制覇する資格を持つ。
お金や権威のある会社がそのビジネスモデルを創りだそうとするのは自己破綻に近いのでありえないから。

チケット駆動開発の展望part1

チケット駆動開発について思ったことをラフなメモ書き。

【1】Twitter / @SIN0306MK: RT @akipii: RT @hino666: 「障害管理ツールとして生まれたBTSがチケット駆動開発の主役として欠かせない存在になったように、CIツールも開発現場で必要不可欠な役割を果たすのではないかと思っている。」≫ Jenkins本を読んで使いこなし方を学ぶ -...

「チケット駆動開発」という言葉がそれほど巷で知られてきたという事実の方が感慨深い。
チケット駆動開発が従来のBTSやITS何が違うのか、従来のBTSやITSからどのように発展してきたのか、を考えると、単なるタスク管理だけでなく、アジャイル開発をサポートするインフラである事実の方が重要な気がしている。

【2】Twitter / @akipii: redmineでチケット駆動開発が自然に問題解決してくれる訳は断じてない。むしろプロジェクトの残タスクや課題が溢れて手に負えない状況を見える化するだけ。混乱した状況を立て直すには優先度を付けてクリティカルパスを見つけて一つ一つ潰すしかない。チケット駆動はマネジメントを補助するだけ

Redmineによるチケット駆動開発で、ソフトウェア開発のタスク管理の諸問題がすべて解決するのは幻想だ。
むしろ、チームのタスクや課題が溢れて、手に負えなくなる状況をメンバーだけでなく、上司にも顧客にも見せてしまう。
1週間で10枚のチケットしか消化できないチームが1週間で20枚もチケットが増え続けたら、チケットで溢れかえって、チームは混乱しているだろう。

チケット駆動開発が教える所では、バージョン単位にチケットをタイムボックス化し、ロードマップでリリース計画を作るのがチケット管理の基本だ。
この手法はScrumのバックログ、PMBOKのスコープ管理にも通用する。
マイルストーン単位にタスクの量を抑えて、チームがタスクをコントロールできる能力を付与するのだ。

【3】Twitter / @akipii: @black__se @empiriLLC はい、ツールやプロセスの運用が自己目的化する事例は、マネージャのプロジェクト管理でもありますし、我々が作る業務システムを顧客が使う場合もあります。ERPやCMMIの導入事例ではそんな失敗例が山ほどあります。

チケット駆動開発を運用すること自身が自己目的化する罠は、特にマネージャ層に多いと思う。
そもそも開発者は、チケットの粒度を整えたり、チケットを綺麗に書いたりすることに執着しない。
プログラミングを通じて価値あるソフトウェアを作るのが目的なのであり、Redmineを運用するのはあくまでもその過程のタスク管理を有効にサポートしてくれるから使っているだけ。

でも、マネージャは、Redmineに貯まったデータから進捗一覧、課題一覧、障害一覧のような帳票を綺麗に出してみたくなる。
実際、Redmineに貯まった予定・実績工数は、コスト管理やコストの予測にとても有効に使えるからだ。
だから、開発者に無理強いして、予定・実績工数を入力させたがり、プロセスそのものがどんどん重くなっていく。

その話は、丁度ERPやCMMIの導入による失敗事例にとても似ている。
いくら効果的なツールやプロセスであっても、社員やメンバーに強制させれば、業務は回るだろうが、本来の崇高な目的から離れた運用になってしまう。

【4】Twitter / @Sean_SF: 「いわゆる「チケット駆動開発」はレベルが高い。チケットを発行してまわるぐらいアーキテクチャとプロセスが安定している必要がある。チケット駆動にしたからといってプロセスが安定するわけではない。運用、改善フェーズには良い」 #devsumiC

Twitter / @kjsuited: Pivotal Trackerに対しての実践論として適切な解釈だ。最上級のコンテキストじゃないと運用できないんだよなあ。 > Pivotal Trackerに似ているツールFulcrum　http://bit.ly/o7nMo8

Pivotal Trackerとredmineの違い: プログラマの思索

チケット駆動開発はレベルが高いと思ってしまう理由は、チケットをストーリーカードのように扱うPivotal Trackerのような使い方を想定しているからだろうと推測する。
倉貫さんが実運用している事例では、自社パッケージ製品開発において、ストーリーカードを1人日未満で細分化してチケット駆動で開発されている。
この手法が有効なのは、自分たちで作っている製品だから設計もアーキテクチャも知り尽くしているが故に、わざわざタスクカードまで落とさなくてもストーリーカードで、メンバーが十分理解できて作業できる環境にあるから。

でも、普通はそんなソフトウェア開発ばかりではない。
むしろ、フィーチャのような荒い粒度のストーリーを更にタスクへ分割し、それをチケットに当てはめて試行錯誤しながら開発していく方が普通だ。
チケット駆動開発は、チケットをストーリーカードのように扱うこともできるし、タスクカードとして扱ってタスク駆動として運用することもできる。
つまり、適用範囲(コンテキスト)に応じて、使い分けることの方が重要だ。

逆に、チケットをコンテキストに応じてどの概念にマッピングした方が良いのか、をもっと研究する方が大切だろうと思う。

※追記
@kuranukiさんからコメントがきたのでリンクします。

Twitter / @kuranuki: ..@akipii 記事にひとつ誤解が。SonicGardenではお客様のいる受託の仕事もこのスタイル( http://bit.ly/wwL24i )で、お客様とチケット＝ストーリーカードで共有して運用していますよ！（チケット駆動開発の展望 http://bit.ly/zkoNtT

Twitter / @akipii: @kuranuki お客様とストーリーカードレベルで仕様を詰められるのは素敵です。お客様がシステムの実現性や重要度を決めるくらい業務を理解しているわけだから。僕の現場はもっと泥臭いです(笑)

【5】Twitter / @akipii: トピックブランチ、コミットフックのバッチ化。チケット駆動の進化形。RT @t0k0_garannodou: 新しい記事を投稿しました： JIRA+Github+Jenkinsによるチケット駆動開発 - http://bit.ly/xQjm3N #伽藍の堂

Twitter / @akipii: Jenkinsの本質はバッチジョブ制御ツール。継続的インツグレーションからバッチ処理の簡易化へ進化してる。

Twitter / @hayato_1980: @akipii 最近、画面に"最近の成功ビルド"とかでてるのが違和感あるくらいビルド以外に使ってます。.

チケット駆動開発では、@haru_iidaさんが提唱されたSW開発の3種の神器という概念が出てくる。
つまり、ITS・SCM・CIの3つのツールが組み合わさることによって、新たな使い方や概念が出てくることを意味している。

上記の記事では、Gitのトピックブランチをチケットに対応付けて、トピックブランチからマスター(trunk)へマージする場合、Jenkinsがテストを走らせてOKならマージし、常時ビルドする仕組みを提供している。
この記事が示唆する重要なポイントは二つある。

一つは、コミットフックはJenkinsによるバッチ処理でチケットと連携できる点。
チケット駆動開発の運用ルールとして「No Ticket, No Commit」があるが、これはSVNやGitのpost-commit-hookないしpre-commit-hookの機能を利用して実現される。
pre-commit-hookによって、コミットログにチケットNoが書いていなかったり、決められフォーマットで書かれていないコミットログは弾かれる。
post-commit-hookによって、コミット後に、コミットログに書かれたチケットNoがリビジョンとリンクすることによって、トレーサビリティを実現できる。

その場合、post-commit-hookの実現方法は、Redmineのリポジトリ画面をリフレッシュしたり、RedmineのWebサービス機能を使って自動化する方法があげられる。
だが、最もエレガントな方法は、Jenkinsでpost-commit-hookをイベントドリブンないしポーリング化することだろうと思う。そのアイデアは下記に書いた。

Redmineを業務システム化するアイデア～メトリクス集計の本質は集計バッチ処理: プログラマの思索

もう一つは、Jenkinsが単なるビルド管理ツールではなく、バッチ処理を制御するバッチ監視ツールである点。
Redmineを業務システム化するアイデア～メトリクス集計の本質は集計バッチ処理: プログラマの思索にも書いたけれども、Redmineのチケット集計機能の本質はバッチ処理に落ち着く。
何故なら、複雑なレポート(帳票)を出力したいならば、大量データを一括処理するバッチ処理の設計が必要になってくるからだ。
実際、IPAもRedmineやTracに貯められたプロジェクトの作業データからバッチ処理で意味あるメトリクスを出力するツールを開発されている。

【公開】RedmineのFAQとアンチパターン集 #Rxtstudy: プログラマの思索

その場合、バッチ処理を制御するツールとしてJenkinsが有力候補になるだろう。
実際、Jenkinsにはジョブという概念がまさにバッチジョブに相当するし、複数のジョブを組み合わせることでジョブフロー図らしきものを作ることができる。
そして、Jenkinsの優れたレポート機能を使えば、ジョブの状態をリアルタイムにモニタリングできる。
Jenkinsはたくさんのプラグインがあり、カスタマイズもしやすいので、バッチ処理を制御するためにもっと使いやすいUIや環境を作ることができるはずだ。
そうすれば、ソフトウェア開発の中で昔から難しいバッチ処理をてなずけることができるようになるかもしれない。

色々なアイデアを試してみたい。