アジャイルのスクラム開発における共通的なリスクの考察

久しぶりに手に取ったワインバーグの「熊とワルツを」を読んでいて、これアジャイルのスクラム開発ならどうなるんだろうなと言う思い付き的な考察。
プロジェクトの共通的なリスクは5つあって、どんなプロジェクトでもプロジェクトを定期的にモニタリングしておけ、というリストがこれ。

・内在的なスケジュールの欠陥
・要求の増大（要求の変更）
・人員の離脱
・仕様の崩壊
・生産性の低迷 ※仕事の能力に関係するのはこれだけ

その中でプロジェクト開始前にアセスメント出来る項目は2つ。

・内在的なスケジュールの欠陥
・人員の離脱

内在的なスケジュールの欠陥ならプロジェクト計画時のスケジュールの抜け漏れのチェックをしておくことが事前のアセスメントとして必要な作業になる。
事前のアセスメントでは、過去の類似のプロジェクトマネージャやPMOなどのレビューアが入り、レビューすることで人的に防ぐか、プロジェクトのアセットとしてのWBSテンプレートなどで抜け漏れを防ぐことになる。
人員の離脱なら、プロジェクトのメンバのセンシティブな情報になるので、ラインマネージャがプロジェクトメンバの健康や家庭の事情を把握できる範囲で聞いておくくらいしかないだろう。
勿論、プロジェクトメンバが話してくれたら、の場合に限る。

プロジェクト開始後には、5つの共通的なリスクを定期的にモニタリングする必要がある。
まず、プロジェクトの共通的リスクとアジャイルの開発手法を当てはめてみるとこんな風になった。

プロジェクトの共通的なリスク	スクラムでのリスク対応方法	ウォータフォールでのリスク対応方法	備考
内在的なスケジュールの欠陥	Doneの定義からベロシティを予測する。Doneでプロセスを明示的に定義してもスケジュールが抜けたらどうしようもない。	見積もり時に、経験者なりPMOが知見からレビューするしかない	アジャイルの方がスケジュールの欠陥を生じることの可能性がすくなそうなのだけど
要求の増大（要求の変更）	バックログに入れ、次のスプリントの候補にすることをプロダクトオーナと合意する	見積もり仕様をベースとして要件定義フェーズでの要件をシステム要件として落とし込む、そのプロセスの制御がすべて
人員の離脱	人数の少ないスクラム開発のメンバ離脱は致命的	タイムスパンの長いウォータフォールの方が入れ替えしたメンバが立ち上がれる時間が取れる可能性が高いがキーパーソンの場合は悲観するしかない	タイムスパンの短いスクラム開発でのメンバの離脱インパクトは致命的
仕様の崩壊	バックログのリストに入れた段階でプロダクトオーナと仕様を詳細に詰めよ	見積もり時にプロジェクトの進め方や見積もり時のシステム方式や機能仕様をシステムの軸がぶれないように書ききれるかが要
生産性の低迷	少人数で進めるスクラムにとっては致命的だ	アウトプットが最後になるウォータフォールの方がリカバリできる可能性がある	ウォータフォールでもスクラムでも痛いのは同じ