ゴールドラッシュ
アリスター・コバーン氏のアジャイルプロジェクト管理 (アジャイルソフトウェア開発シリーズ)は監訳がアレで、内容も今一つなのですが、「付録A リスク削減戦略カタログ」は見るべきものがあります。中でも今日は、「ゴールドラッシュ」という戦略について考えてみたいと思います。
ゴールドラッシュとは、要件がなかなか決まらないということは、ままあることですが、そういうときにも設計・プログラミングを始めようというものです。
この戦略は、当然のことながら慎重に実行しないと、まずうまくいかないでしょう。コバーンは、以下の点を成功条件に挙げています。
- チーム内のコミニュケーションが良好な状態であること
- やり直しを行う要員は、プロジェクト全体の進捗を律速していないこと。
- 要件収集、分析、設計の一般的なプロセスがあること
コバーンの本はちょっと古く20世紀のものです。アジャイル開発プロセスが一般化した現代では、これに加えて以下の点を工夫するとよいでしょう。
- 変化を受け入れることをメンバにコミットする。XPの「Embrace Changes」や達人プログラマの「There are no final decisions 」をチームのキャッチフレーズとする。
- 要件がなかなかきまらない箇所は、Fix後も変更が入る可能性は相対的に高く、ホットスポットとして交換可能なように設計する。
- 変更に備えて、可能な限りテストを自動化する。
- 前倒して得られる時間的なバッファを、学生症候群やパーキンソンの法則によって喰い潰すされないよう、チームとして管理する。
そもそも、この要件がきまらずプロジェクトが進まないというリスクは、システムの発注者側に責務があり、受注者側が一方的にそのリスクを引き受けるのはおかしなことです。ゴールドラッシュの採用は、必ず顧客とリスクについて合意の上行うことが肝要です。
ゴールドラッシュは、顧客・開発者双方にメリットのあるハイリスク・ハイリターンな戦略で、かつリスクもコントロールしやすいので、成功条件を揃えて積極的に採用したいものです。
