Agile手法の採用 -Part 1-

今日も現実逃避。Adopting an Agile Method - Part 1の無断邦訳。

Agile手法の採用 Part-1
Alan S. Koch, http://www.ASKProcess.com
概要
「Agileソフトウェア開発手法を使うべきだ」という議論の結果が出て、「じゃ、そうしなさい！」という指示が下ったとしよう。で、どうする？ Agileを使うというたった一行の「要求」をどうやって実現するの？
Agile手法を採用するということは、他の手法やツールを取り込むことと何の違いもないんだ。なぜこうするのかを明確にし、需要に最も近い手法を選択し、その新しい手法に移行する道順を明確にすること。これで「じゃ、そうしなさい」という指示を実行に移せるよね。

なぜAgile手法を採用するの？
やり方を変えてしまう前に、まずは一歩下がって、これから変えようとしていることをきちんと理解してみよう。そもそも、今のやり方で何の問題もないのなら、別にそのやり方を変更する必要はないよね。ということで、まずはAgile手法を採用するという最初の議論に戻るわけ。
新しいやり方を採用することについて事前に激しい議論があったのなら、必要な情報はすでに揃っているはず。それほど議論されてないのなら（あるいは、何が議論されたのかの記録が残ってないのなら）、その新しいやり方を推薦している人に、どうしてそのやり方が良いのかを聞くべきでしょ。今、自分達が使っている手法で何か問題はあるのか？その問題ってのはどんな問題なのか？どれくらいひどい問題なのか？その問題で影響を受けているのはどいつだ？あるいは、今の所そんなに問題はないけど、Agile手法ってのは今自分達が使っている手法を改善してくれるものなのか？どんな改善が見込まれているのか？どれくらいの改善なのか？その改善で誰が利益を享受できるのか？
このアイデアを最終的に採用するかどうか決めてくれる意思決定者とも議論する必要があるよね。描いていた将来像はどんなものか？どんな利益を期待しているのか？この新しい手法を採用することで、何がどう変化すると思っているか？そして何よりも大事なことは、その意思決定者にとっての「成功」の定義とは何ぞや？ということでしょ。
複数の人達とこういう話をしていくうちに、なぜAgile手法を採用するのかということについて議論する必要がでてくるはずだよね。意見がまとまっていない人達を（できれば一つの部屋に）集めて、その意識の違いを互いに認識し、なぜAgile手法にするべきかについて意識を統一しておくことも必要でしょ。
なにをするにせよ、なぜこの新しい方法を採用するのかということについて、皆が明確できちんと説明された理由を共有しておかなければならない。そうしておかないということは、実は失敗に終わるということを想定しちゃっているわけだし、不幸な結果につながるだけなんだね。対照的に、「なぜ」苦労しなければならないかを皆が明確に理解しているということは、快適に前進する準備が整っている、ということになるんだ。

どのAgileプラクティスを選択するか？
さて、自分達が達成したいことはわかった。次にやることは、いろいろあるAgileプラクティスから自分達の組織に適切なものを選ぶことだよね。これは実は忘れがちなプロセスなんだね。特に、特定のAgile手法(XPだとかScrumだとか)の採用が強制されてない場合はなおさらだよ。でも、たとえ特定のAgileが選択されていても、その手法が規定する全てのプラクティスを採用するかどうかの決め手にはならないよね。自分達の組織や対象となるプロジェクトの特性をきちんと分析して、どのプラクティスが自分達の設定したゴール達成に役立つのかを押えておく必要があるんだ。
ここで考慮すべき主な項目には以下のようなものがあるよ。

自分達の組織における文化

自分達の顧客が、自分達とどのように関わりたいのか

プロジェクトの形態

今使っているプロセスやツール

開発関係者の強みや弱み

組織文化
Agile手法は、自己管理型チームコンセプトの上に組み立てられている。開発チームは何を作るのかとか、いつ終わるかとかいったことは説明されない。開発者には大きな視点でのゴールが提示され、あとは顧客とともにそのゴールにどうやって到達するかを決めていくだけだ。
もしあなたの組織文化が「指令と管制」に基くマネージメントを土台にしているのなら、Agile手法が規定する多くのプラクティスを実行するのはかなり厳しい挑戦となるだろうね。マネージャは従来のマネージメント手法を捨てて、開発チームとの共働的な関係を築かないといけない。これは古風なマネージャ達には非常に困難な意識転換だし、多くのAgileプラクティスがつまづく原因となりかねないよ。
組織的な課題はまだ他にもあるよ。計画とその確約をどう扱うか、ということだ。もしあなたの組織がプロジェクト計画と要件定義を事前に確定させ、プロジェクトはそれらを遵守するという文化なら、Agile手法の漸増型なプロジェクト計画や要件定義は「なんじゃそりゃ」ということになるだろうね。Agile手法では、プロジェクトの途中で発生すること全てについて事前に把握することなどできない、という立場をとるわけだ。なので、Agileではプロジェクトの初期には、高い視野での計画や要件定義しかおこなわない。そして、プロジェクトと通じて細部を足していったり、訂正していったりするわけだ。もちろん、プロジェクトを通じてのゴールは常に意識しながら、だ。
これから採用しようとしているAgile手法にはどんなプラクティスがあるのか調査し、それぞれのプラクティスが組織の文化に実際に適合するのか、そして期待している利益を享受できるのかをしっかりと見極めることだね。

顧客
Agile手法では、顧客が開発チームと共にプロジェクトに密接に関わることが求められている。これは多くの場合、顧客の代表が開発チームと「近い位置で」働くことで実現されるわけだ。(その密接度合いはAgile手法によってまちまちである。最も過激なのはXP。)
あなたの顧客は現状のプロジェクトでどれくらい活発に動いてくれている？もし、もっと頻繁に開発チームと働いてくれ、と依頼したら、顧客はそれにどれくらい応じてくれるかを確認しておくことも大事だ。ほとんどの顧客は、プロジェクトに専任できる人材に限りがあるし、共に働く時間を劇的に増加させるようなことは顧客には迷惑にしかならないでしょ。あなたの顧客はAgile手法が期待する時間と労力を確約してくれるだろうか？
顧客との契約がどうなっているかも確認しておく必要があるね。契約でソフトウェアを開発しているのなら、顧客とのやり取りも契約に明記されているはずだし、それは簡単には変更できないでしょ。仮に交わされた約束を変更できるような状況であったとしても、顧客は本当に変更してくれるかね？契約というのは、企業が契約相手の組織から自分達を保護するために使われることもあるでしょ。あなたの顧客が契約を自己防衛のために使うような場合、顧客は開発チームと共働するということには興味を示さないだろうね。
これから採用しようとしているAgile手法にはどんなプラクティスがあるのか調査し、それぞれのプラクティスが顧客に実際に適合するのか、そして期待している利益を享受できるのかをしっかりと見極めることだね。

Part-2の訳は id:masayang:20060505#1146854489 までどうぞ。