熊とワルツをトム･デマルコ／ティモシー・リスター（日経ＢＰ社）

1.なぜリスクを管理するのか
(1)リスクと利益とは相関関係がある。
　ハイリスクなプロジェクトほどハイリターンが見込まれる。
　リスクのないプロジェクトは誰がやっても結果は同じであり、
　利益も少ないため通常誰も手をつけず残っている。
　また、そうしたプロジェクトは完遂させても得られる利益は少ない。
(2)リスクは上ろうとする階段に対する下りエスカレータとして考える。
　新しい競争相手は自分より昇ったところからエスカレータに参入する事になる。
　対象リスクが高まると全エスカレータの速度が上がる事になる。
　最初に昇り切った者のみに全エスカレータの速度調整が可能となるため、
　リスクにうまく対処していかないと昇り切った相手に対象を支配されてしまう。
(3)リスクが移行（＝実現、発覚）した事が判断できる指標（＝きっかけとなる定量値）
　の管理が必要
(4)リスク分析後、管理すべきリスクを選別し、選別したリスクに対する目安（指標）
　を考え、移行までに可能な措置を計画実施（軽減）し、相対的重要度（確率と影響度）
　を評価（エクスポージャ分析）する。
(5)管理すべきリスクを見つけるための継続的なしくみの導入（継続的リスク発見プロセス）
(6)リスク実現後、何をすべきかの計画（危機対応計画）
(7)管理するリスクの追跡や監視（移行監視）
(8)ソフトウェアプロセス以外のリスク（外部要因）もある。
・要求定義
・組み合わせ
・環境の変化
・人材
・上層部
・サプライチェーン（外部の関係者）
・政治
・対立
・イノベーション
・規模
(9)リスクのエクスポージャ分析により、クリティカルパス上にあるリスクを発見し、
　軽減すること（＝クリティカルパス上にあるリスクを外す）が重要。
(10)コスト増となるリスクの最終的な責任はリスクを無視した場合の代償を
　支払うことになる当事者になる。通常、当事者はコストを発注した担当となる。

2.リスクを管理すべき理由
(1)積極的なリスクをとることがリスク管理であり、それを論理的にクライアントへ説明する事が必要。
　リスク＝不確定なものであるため、リスクの数量化（リスク項目リスト化）による不確定要素の限定、
　納期の幅の定量化、リスクへの対策（最小限のコストによる保険）を含めた提案をクライアントに行う。
(2)リスク管理はクライアントにも責任があることを明確にする。
(3)一部のプロジェクトが失敗した場合でも全体への影響が緩和できる。

3.なぜリスクを管理しないのか
(1)発注者がリスク管理できるほど成熟していない。
(2)リスクとなる不確定範囲が広すぎる。
(3)不確定幅を決めてしまうと、最大の幅（最も遅いスケジュール）で作業してしまい、
　仕事の生産性が低くなる。
（ソフトウェアマネージャは、クライアントや上層部への約束と開発担当への約束（目標）を
　別に設定すべきである。）
(4)「成功のための管理」の方が効率が良い。
(5)リスク管理に必要なデータが不足している。
(6)プロジェクトマネージャだけがリスクを管理することになり危険である。
・上記(1)〜(5)までは対策可能だが、
　(6)については組織で対応がよい。（リスク管理は個人では対応すべきでない。）

4.リスク管理の方法
(1)不確定性はリスク図で定量化する。
　リスク図は縦軸を相対確率、横軸を納期とし、まずはＮ（相対確率０の最大納期）を設定する。
　Ｎから立ち上がる曲線でリスク発生確率を示すが、曲線のピーク（予想納期幅の中で一番完成確率の高い期日）
　は通常予想納期幅の前半（通常予想納期幅の三分の一）にくることが多い。
　ただし、完成確率の一番高い期日＝安全である確率が３３％程度となるため、
　クライアントとの約束納期は安全である確率が７５％程度の期日（通常予想納期幅の三分の二）とするのが良い。
(2)不確定性幅は、プロジェクト開始からＮまでの期間の１０〜１５％程度で収まるのが理想だが、
　ソフトウェア業界全体では１５０〜２００％となるのが現実である。
(3)リスクを評価するためのツール
RISKOLOGY(http://www.systemsguild.com/riskology)
(4)ソフトウェアプロジェクトのコアリスク
・スケジュール欠陥のリスク
超過期間は予定に対する３０％以上とみるのが妥当（実現確率５０％程度）
・要求の増大
・人員の離脱
・仕様の崩壊
何も完成しないまま中止されるプロジェクトは全体の１０〜１５％
仕様書が明確になるまで、作業中止リスクを見込むべきである。
仕様書の決定とは、開発ソフトのデータフローをデータ要素レベル
まで決めた定義書の関係者全員による正式承認、合意を意味する。
・生産性の低迷
予定に対して納期が短ければ生産性のばらつきも少ない。
生産性のばらつきはプラス、マイナス何れも同じ程度に振れるとみてよい。

5.数量化の方法
(1)リスクを管理すること＝効果（価値）をコストと同様に数量化すること
（コスト効果分析）
(2)開発マネージャ及び発注者は、効果に対して説明責任を負う。
(3)効果（価値）もリスクと同様に不確定性の範囲がある。
(4)市場機会が失われることを理由にクライアントは短納期を要求するが、
　過去の実例（市場機会が失われた後に登場したExcel、Google等）から
　その理由が絶対かつ二者択一的なものではない。
(5)開発者と発注者の説明責任は平等であり、発注者は価値が生み出される事を
　確認する責任がある。また、開発者はプロジェクト完了後に効果がどれだけ実現
　されたかどうかを追跡調査する必要がある。
(6)価値はシステム全体に不均等に分散しているため、インクリメンタルな価値コスト
　を発注者に予想してもらうのが理想である。
　それが無理でも各コンポーネントの作業優先順位の指示だけでも引き出す事が必要である。
(7)潜在価値が高ければ多くのリスクをとる価値があるが、潜在価値が低ければたいていのリスクは
　避けるべきである。（価値とリスクのバランスをとる。）