変更要求に対する選択肢

「成功する要求仕様 失敗する要求仕様」で、変更への対応に関する選択肢の解説がとても素晴らしいと思ったのでメモ。
＃ラフなメモ書き。

開発プロジェクトは、現在、Ver3.0へ向けて開発中で、その次のリリース予定のバージョンは4.0であると仮定する。
この時に、突然、顧客から大きな変更要求が提示され、どうしても対応せざるを得なかったと仮定する。

「成功する要求仕様 失敗する要求仕様」では、下記の9種類の選択肢を比較検討している。
この解説が非常に面白い。

１・変更を受け入れて、Ver3.0に組み入れて、スケジュールや予算は現状のまま変更しない
２・変更を受け入れて、Ver3.0に組み入れて、リリース日を遅らせる

３・変更を受け入れて、Ver4.0に組み込む計画を立てて、Ver3.0のリリース日を確実に守る
４・変更を受け入れて、Ver3.1という新たなVerを作り、変更をVer3.1に組み込む計画を立てる
５・変更を受け入れて、次のトリアージ会議で、将来のリリースのどこかのVerに組み込む計画を立てる

６・変更を却下する
７・変更を受け入れて、Ver3.0に組み入れて、Ver3.0のリリース計画に含まれている重要度の低い要求を削除し、スケジュールや予算は現状のまま変更しない
８・変更を受け入れて、Ver3.0に組み入れて、スケジュールを遅らせないように、開発プロジェクトへリソースを追加する
９・現行の開発プロジェクトを中止し、最初からやり直す

１と２、そして７、８を選択した場合、そのプロジェクトはデスマーチに追い込まれるだろう。
１は、スコープが増えたのに、スケジュールやコストを増やさない訳だから、バランスが既に崩れている。

２は、スコープが増えたので、スケジュールを遅らせるわけだが、その分、当然コストも増える。
SIerがビジネスしている限り、非常にリスキー。

８は、スコープが増えたので、スケジュールを守るために、リソースを増やすやり方は、人月の神話のように既に破綻すると経験的に知られている。

７は、スケジュールとコストを変えないように、増えたスコープを優先順位付けして整理し直そうとするやり方で一見、正しそうに見える。
しかし、実際は、優先順位の低い要求を捨てて、作業工数を確保しようとしたとしても、工数は簡単な引き算と足し算で解決はできない。
例えば、40時間の作業工数を削減して確保し、その工数を増えた要求に対応したとしても、その工数に関わるメンバーは、疲労していたり、増えた要求を理解するために時間を取られることが多いだろう。

６と９は、顧客とSIerのパワーバランスで、選択できるかどうか決まる。
普通はこの選択肢はありえない。

３、４、５は、増えた要求を新たなバージョンに組み込んで、別に独立してリリースすることで対処しようとする。
これは、いわゆるタスクブランチで解決するやり方だ。

僕が最も現実的と考える選択肢は、４のようにVer3.1のタスクブランチを作ることだ。
理由は、顧客満足度をクリアできて、かつ、開発チームがリリースを制御できるには、開発中のVer3.0と次回のVer4.0の間に、Ver3.1というイテレーションを組み込むのがBetterだと考えるからだ。

３は、増えた要求が納期にそれほどこだわらない場合に選択できると考える。
例えば、品質を重視するために、スケジュールが1年後では困るが、時間がややかかっても良い場合など。

５は、一部のマネージャや現場リーダーの判断では決めることができず、変更管理会議(CCB)のように開発プロジェクトに関わる全てのステークホルダーに参加してもらって、議論して決める場合に選択するだろう。

アジャイル開発を実践できる開発チームならば、イテレーションという短いサイクルで小刻みにリリースできる開発プロセスを持っている。

だから、突然振ってきた変更要求をきちんと仕様化して設計さえできれば、新たなVerに対応するタスクブランチを作り、それをリリースすることで変化に対応できる。

そんな開発プロセスを実現するには、継続的インテグレーションやメインラインモデルなどのような高度なSW構成管理と、チケット駆動開発のような強力なタスク管理(変更管理)の仕掛けが必要だと思う。