本書について

Amazonで本を購入する

本書のまとめ

まえがき

プロローグ信念の倫理

第1部　なぜリスクを管理するのか

第1章　リスクに立ち向かう

リスクのないプロジェクトには手をつけるな。

リスクから逃げずに立ち向かおうとするなら、両目を開けてしっかりと行く手にあるものを見据える必要がある。

リスクとは厳密にどのようなものか。それを管理するとは、どういうことか。（第２章）
リスクを管理しないとどうなるのか（第３章）
なぜわざわざ違った手法に投資する必要があるのか。（第４章）
リスク管理を行うことによって、どのような問題が生じるか。（第2部）
それについてどうすればよいか。（第3部）
リスクと機会のバランスをとるにはどうすればよいか。（第4部）
成功したかどうかはどのように判断するのか。（第５部）

第2章　リスク管理は大人のプロジェクト管理だ

リスクの当面の定義
- [名詞]１.将来起こりうる出来事で、望まない結果を生むもの。2.臨まない結果そのもの。

「リスク」とはまだ起きていない問題であり、「問題」とはすでに実現したリスクである。

リスク管理の反対を「危機管理」といい、問題が発生した後に何をすべきかを考えることを意味する。

リスクが問題になった瞬間＝リスクが「実現」した。「リスク移行」の瞬間。

目に見えるのは、以降が起きたことを示す「移行指標」。

以降の前にやっておくべきこと。その作業を「軽減」という。

リスク発見
- まずリスクにかんするブレーンストーミングを行い、次にリスクを選別する。さらに、プロセスを継続する仕組みを導入する。
エクスポージャー分析
- それぞれのリスクが実現する確率と、それによる影響を数量化する。
危機対応計画
- リスクが実現した場合に何をするべきかを計画する。
軽減
- 計画した危機対応措置が必要なときに実行でき、効力をもつように、移行前にとるべき対策をとる。
継続的な移行監視
- 管理するリスクを追跡し、実現しないかどうかを監視する。

第3章　デンバー国際空港再考

要求定義
- 正確に、システムは何をする必要があるのか。
組み合わせ
- システムは、オペレーターやほかのシステムとどのようにやりとりするのか。
環境の変化
- 開発期間中に、ニーズや目標はどのように変化するか。
人材
- プロジェクトの進行にともない必要になったとき、主要な人材をどこまで確保できるか。
上層部
- 上層部には、生産性の高いチームを作り、士気を保ち、離職率を抑え、複雑に絡み合った作業を調整することが可能な人材がいるか。
サプライ・チェーン
- 外部の関係者は期待どおりに動くか。
政治
- 政治権力を利用して、実現を無視し、プロジェクトの成功を妨げる無理難題を押しつける者がいたらどうなるか。
対立
- さまざまな利害をもつ関係者が、どのようにお互いに相容れない目標を解決するのか。
イノベーション
- プロジェクト固有の技術や手法が、最終結果にどのように影響するか。
規模
- 過去に経験したプロジェクトより作業の量や範囲を広げることが、プロジェクトの出来にどのような影響を与えるか。

Q1〜Q12。類似の前例として4年かかるプロジェクトを2年でやろうしていたのに、エクスポージャー分析を行わず、リスク管理の努力がまったくされなかったことが問題。

リスク管理の責任は、リスクを無視した場合に代償を支払うことになる当事者が負わなければならない。

この例では、財務リスクを管理する責任はデンバー市にあったのに、市はこれといった努力をなにひとつしなかった。

第4章　リスクを管理すべき理由

リスク管理は積極的にリスクをとれるようにする
リスク管理は不意打ちを防ぐ
リスク管理は成功するプロジェクトを作る
リスク管理を不確定要素を限りあるものにする
リスク管理は最小限のコストによる保険である
リスク管理は目に見えない責任転嫁を防ぐ
リスク管理は一部が失敗したプロジェクトを救える
リスク管理は人材の成長機会を高める
リスク管理は管理者への不意打ちを防ぐ
リスク管理は注意すべきところに注意を向ける

第2部　なぜリスクを管理しないのか

第5章　リスク管理をすべきでない理由

発注者がリスクに直面できるほど成熟していない
不確定範囲が広すぎる
はっきり不確定幅を決めると、出来の悪い仕事を許すことになる
「成功のための管理」の方があてになる
リスク管理を有効に行うための必要なデータが不足している
単独でリスク管理をするのは危険である

第6章　不確定性への非難

「間違えるのはかまわないが、不確かなのはだめだ。」このルールが自分の会社に当てはまったら、おしまいである。
このルールを言い換えると、遅れたことに対して後から「赦し」を請うのはかまわないが、遅れることに対して前もって「許し」を求めてはならない。
不確定性を口に出すことを許さない企業文化の中では、リスク管理はできない。

1回目にリスクを洗い出すときに、思いつくかぎりの破滅的な結果を並べる。「失敗」「拒否」「中止」といった言葉を口に出す。

第7章　運

管理対象からはずしてもよいと思われるリスク。

「小惑星が会社を粉砕する」

実現の確率が無視できるほど小さい。
万一実現した場合、現在管理している仕事（開発中の製品）など、大したことではなくなる。

他の理由

リスクの影響がきわめて小さく、軽減する必要がない
他人のリスクである

第3部　リスク管理の方法

第8章　不確定性を数量化する

不確定性を数量化する→図に表す

縦軸をプロジェクト完了の相対確率、横軸を日時。

参考: http://pcmdays.cocolog-nifty.com/blog/images/2_1.jpg

「確率がゼロではない最初の日」をN（ナノパーセント日）と呼ぶ。

ソフトウェア業界全体でみると、不確定幅はNまでの期間の150から200パーンセント。

不確定性の幅は、その組織の開発プロセスにどれだけノイズ（変動）があるかで決まるのであり、どれくらいが適当だといった人間の感覚とは関係がない。

第9章　リスク管理のしくみ

「ソフトウェア・プロジェクト・マネージャのほとんどは、やらなければいけない作業についてはほぼ正確に予想できるが、**やらなければならないかもしれない＊＊作業は正しく予想できない。」

「きのうの問題は今日のリスクである。」

→事後分析プロセス、リスク・リスト作成

プロジェクトの問題は何度も繰り返されることが多いため、過去のプロジェクトを5、6件も分析すれば、十分なデータが得られるだろう。

リスクについてできることは次の４つ。

避ける
- プロジェクトの中でリスクを伴う部分に手をつけないこと
- 利益を見逃すことになる
抑制する
- リスクが実現した場合にかけなければならない時間と資金を準備しておくこと
軽減する
- リスクが実現する前に、後の抑制コストを軽減するための措置を取っておくこと
かわす
- たまたまリスクの襲来をまずがれる場合のこと

「リスク管理は、プロジェクトについて心配することとは違う。」

リスクをかわす計画を立てるのは、良い戦略とは言いがたい。全部で12項目の短いリスク・リストしかなかったとしても、12個全てかわせる確率は極めて低い。
リスク1個あたりの実現確率が10%だと、1つ以上が襲いかかってくる確率は、ほぼ75パーセントである。（1-0.9^12）

リスク・エクスポージャー = コスト x 確率

ショートストッパー

リスク準備とは、リスクを抑制するために用意しておく時間的、資金的な余裕である。

移行指標と移行監視

「ボールが転がってきたあとには、必ず子供が走ってくる。」

第10章リスク管理の手順

リスク管理とは、基本的に、次のステップをプロジェクトに組み込んで実施することである。

リスク発見プロセス（第14章を参照）を使って、プロジェクトが直面するリスクの調査をまとめる。
ソフトウェア・プロジェクトのコア・リスク（第13章を参照）が全て調査に含まれていることを確認する。
個々のリスクごとに次の作業をすべて行う。
- リスクに名前と番号をつける。
- ブレーンストーミングによって、そのリスクの移行指標（リスクの実現を最も早く実用可能な精度で示す指標）を特定する。
- リスクが実現した場合にコストとスケジュールに与える影響を推定する。
- リスクが実現する確率を推定する。
- そのリスクの時間的、資金的なエクスポージャーを計算する。
- 移行が始まったときにとるべき危機対応措置を事前に決めておく。
- 選択した危機対応措置を実行できるように、移行の前にとるべき軽減措置を決める。
- 全体的なプロジェクト計画に軽減措置を追加する。
- ふろくBのような書式に詳細を記入する。
ショートストッパーのプロジェクトの仮定条件として指定する。これらの各リスクを上層部に引き渡す儀式を実行する。
リスクがいっさい実現しないものと仮定して、最初のスケジュール見積もりを作成する。この最初の見積もり作業は、ナノパーセント日、つまりわずかでもプロジェクトが完成する可能性のある最初の日を決定するための作業である。
社内と業界全体の不確定要素（第13章を参照）を使って、Nから始まるリスク図を作成する。
リスク図を使って約束を発注者に伝える。その際、それぞれの予想日程や予算に関連する不確定要素をはっきり示す。
リスクが実現したり終了したりしないか監視し、実現したいときには危機対応計画を実行する。
プロジェクトの期間中、後から出現したリスクに対応するため、リスク発見プロセスを継続する。

Nを基点としたスケジュール

濫用される可能性
- どうしても12ヶ月で納品すると約束させたがっている人がいて、Nは４ヶ月後だから、リスク図の基点は4にすべきだと主張するかもしれない。
- しかし、証明する責任は主張する側にある。その人は、4ヶ月で完成させることが少なくとも論理的に可能であり、過去のプロジェクトと同じ条件のもとで全てがうまくいったときにそれが実現するのだと、証明しなければならない。

スケジュール＝目標＝N　←あきれた式である

スケジュール＞目標＞N　←この方がいい

約束した納期への信頼を高めるには、早く完成することの正当性を取り戻さなければならない。そのためにも、企業文化を本気で改革する必要がある。プロジェクトが予定より早く完成することが安全になれば、発注者も、予定通りに納入されることを期待できるようになってくる。納期とは別に現実的な目標を設定し、約束を守れることを周囲に示すという、長年先延ばしにしてきた仕事を始めることができる。

第11章　基本に返る

リスクの再定義：　考えうる結果と、それによる影響を表す加重パターン。

Q.「年明けまでにできないリスクはどのぐらいだ？」

「間違いなくできます」（ほぼ100パーセントの確率）
「半々というところだと思います」（50パーセント）
「とうてい見込みはありません」（1パーセント以下）

複数の原因リスク　+ 複数のサイズ・パラメータと技術要員 → リスク・モデル → 全体リスク

2種類の不確定図。

漸増図
- 縦軸：相対確率（MAX:1。ただしありえない。）
- 横軸：時間
累積図
- 縦軸：確率（MAX:100%）
- 横軸：時間

第12章　ツールと手順

RISKOLOGY

http://www.systemsguild.com/riskology
Excelファイル

第13章　ソフトウェア・プロジェクトのコア・リスク

あらゆるソフトウェア・プロジェクトに共通のリスク

内在的なスケジュールの欠陥
要求の増大（要求の変更）
人員の離脱
仕様の崩壊
生産性の低迷

第14章　リスク発見プロセス

第15章　リスク管理の力学

第16章　リスク軽減のためのインクリメンタル手法

先見的インクリメンタル手法

クライアントに提供する価値
リスクにかんする仮定条件の確認

納品されないバージョン

インクリメンタル開発計画

詳細設計図
- インプリメントすべき最低レベルのモジュールやクラスと、その相互関係を示すず。
作業分析図(WBS)
- 遂行すべき作業のネットワークと、その依存関係。
バージョン受入検査票
- 製品の最終受入検査をバージョンに分け、どの中間ビルドにどの検査を適用できるかを示すもの。

バージョンnが完成したとき、作業分解図(WBS)上のどの作業が完了したと証明できるか。

1バージョンにつき1行の表形式と考えれば良い。

バージョン番号
組み込まれる機能の概要。仕様書に含まれる基本要件コンポーネントへの参照もあることが望ましい。
バージョン受入検査へのポインター。
バージョンの完成が証明されると予想される日。
実際に完成が証明された日（後日記入）。
WBSの中で、そのバージョンの完成によって完成したと証明される全作業のリスト。
バージョンのEVR。

EVR

獲得価値とは、プロジェクトの各サブセットに含まれる予想作業コストを示す尺度である（金額か人日であらわす）。
その作業が終わった時点でプロジェクトはその価値を「獲得」したといえる。

第17章　究極のリスク軽減戦略

第4部　数量化の方法

第18章　価値の数値化

IT業界が生まれたころ

投資収益率 = (価値 - コスト) / コスト

今は何が違うのか

コスト = 623万5812ドル55セント
効果 = 「どうしてもいるのだ」
→ コストと効果は同じ精度で表す必要がある。

説明責任の問題

発注者も予想された効果と実施の効果について説明責任を負う必要がある。

効果計算の五つの要素

発注者は、開発者が予想されるコストとスケジュールを宣言するのと同時に、同じ精度で予想される効果を宣言する。
発注者は、開発者がコストとスケジュール計算の不確定性を示すのと同じ方法で、効果予測の不確定性をあらわす（第21章を参照）。
発注者は、バージョン選択の基準を示し、妥当な感度分析とインクリメンタルなコスト効果分析を行うため、システムの各コンポーネントの相対的価値を評価する（第22章を参照）。
上層部は、効果とコスト、それにともなう不確定性を注意深く比較したうえで、プロジェクトを実施すべきかどうかを判断する（第23章を参照）。
上層部は、プロジェクト後に実現した効果を評価し、その評価を事後分析プロセスへの入力とする。

第19章　価値も不確定

第11章の2種類の不確定図と同じ図で示せる。

市場機会

第20章　感度分析

第21章　価値はリスクを相殺する

価値に見合ったリスクをとる

第22章　リスク管理手順の修正

リスク管理とは、基本的に、次のステップをプロジェクトに組み込んで実施することである（第10章から大きく変更したのは6から12までの各項だが、プロセス全体を通して見直しほしい）

リスク発見プロセス（第14章を参照）を使って、プロジェクトが直面するリスクの調査をまとめる。
ソフトウェア・プロジェクトのコア・リスク（第13章を参照）が全て調査に含まれていることを確認する。
個々のリスクごとに次の作業をすべて行う。
- リスクに名前と番号をつける。
- ブレーンストーミングによって、そのリスクの移行指標（リスクの実現を最も早く実用可能な精度で示す指標）を特定する。
- リスクが実現した場合にコストとスケジュールに与える影響を推定する。
- リスクが実現する確率を推定する。
- そのリスクの時間的、資金的なエクスポージャーを計算する。
- 移行が始まったときにとるべき危機対応措置を事前に決めておく。
- 選択した危機対応措置を実行できるように、移行の前にとるべき軽減措置を決める。
- 全体的なプロジェクト計画に軽減措置を追加する。
- 付録Bのような書式に詳細を記入する。
ショートストッパーのプロジェクトの仮定条件として指定する。これらの各リスクを上層部に引き渡す儀式を実行する。
リスクがいっさい実現しないものと仮定して、最初のスケジュール見積もりを作成する。この最初の見積もり作業は、ナノパーセント日、つまりわずかでもプロジェクトが完成する可能性のある最初の日を決定するための作業である。従来の業界の慣行と異なる点として、このナノパーセント日（N）をスケジュール設定プロセスの出力としてではなく、「入力」として使うよう提案する。パラメトリック見積もりツールがあれば、それを最も楽観的な設定を使ってNを計算するとよい。
RISKOLOGY(http://www.systemsguild.com/riskology)をダウンロードする。メイン・ワークシートにプロジェクトのパラメータを入力する。いっぽう、会社の実績を示す補助データがあれば、それを元にカスタマイズする要素をすべて入力する。コア・リスクについてはシミュレーターには業界のデータが入っているので、なるべく自社の環境から得られた信頼できるデータに置き換えたほうがよい。コア・リスク以外に追跡するリスクがあれば、カスタマイズしたワークシートを追加する。シミュレーションを実行し、ナノパーセント日から始まるプロジェクトのリスク図を作成する。
この時点から、リスク図を使って約束を発注者に伝える。その際、それぞれの予定日程や予算に関連する不確定要素をはっきり示す。発注者に知識がない場合、リスク図の概念を説明するのではなく、これはプロジェクトのシミュレーションを500回実行したもので、起こりうる結果とその相対確率を全て示したものだと言う。
プロジェクトのを完成させるために必要な全ての作業を示した作業分解図を作成する。現在使っている方式で、それぞれの作業に必要な労力を見積もる。これらの見積もりは、通常とは若干違った使い方をする。重要なのは作業にかかる労力の絶対値ではなく、相対的な比重だけである。これらの比重が、エVRメトリックを計算するt目に必要な入力となる。
プロジェクトを開始するにあたって、製品上で入出力するデータフローについて承認を得る。スケジュール全体の最初の１２から15パーセントのうちに、すべての入力フローと出力フローを、データ要素のレベルまで完全に定義できることが条件となる。これらのデータフローに対するしょうにんを、プロジェクトの重要な中間目標と考える。この中間目標を達成するまで、その後の作業に進んではいけない。このデータフローの承認という進捗メトリックを達成できないと、致命的な結果を迎える可能性がある。
インプリメンテーションの前に、設計を完全に分割する。これはインクリメンタル開発計画を作成するための入力として使う。
設計の分割が完了したら、再び作業分解図に戻って作業の比重を見直し、作業を残っている作業量全体に対する比率で洗わず。
価値をコストと同じ精度で評価する。
仕様書に書かれている要求を、基本要素のレベルまで分解する。それらに優先順位をつける。優先順位を決定するにあたっては、ユーザーにとっての正味価値と、技術的なリスクの二つを基準とする。
製品全体を複数バージョンに分けるインクリメンタル開発計画を作成する（バージョン数はできるだけ多くし、少なくとも週に一度は新しいバージョンが完成するように計画を立てる）。これらのバージョンに、優先度の高いものが先になるように、すべての要求の基本要素を割り当てる。各バージョンのEVRを計算し、計画に記録する。インクリメンタル開発計画は、プロジェクトの重要な成果物として扱う。
最終製品全体の受入検査表を作成し、バージョンごとのバージョン受入検査（VAT）に分割する。
EVRと各バージョンの予定納品日をグラフにする。バージョンがVATに合格したら、同じグラフに実績を記入する。
プロジェクトの残りの期間、リスクが移行したり終了したらしないか監視し、リスクが実現したときには危機対応計画を実行する。EVRの飛行経路を監視し、予想経路に対して実績はどうか観察する。予想から実績が離れたら、リスクが発生している兆候である。
プロジェクトの期間中、後から出現したリスクに対応するため、リスク発見プロセスを継続する。

第5部　嘘かまことか

第23章　リスク管理の検証

TODO

付録A 「新年の倫理」

付録B リスク・テンプレート

TODO

本書について

本書のまとめ

まえがき

プロローグ信念の倫理

第1部　なぜリスクを管理するのか

第1章　リスクに立ち向かう

第2章　リスク管理は大人のプロジェクト管理だ

第3章　デンバー国際空港再考

第4章　リスクを管理すべき理由

第2部　なぜリスクを管理しないのか

第5章　リスク管理をすべきでない理由

第6章　不確定性への非難

第7章　運

第3部　リスク管理の方法

第8章　不確定性を数量化する

第9章　リスク管理のしくみ

第10章リスク管理の手順

第11章　基本に返る

第12章　ツールと手順

第13章　ソフトウェア・プロジェクトのコア・リスク

第14章　リスク発見プロセス

第15章　リスク管理の力学

第16章　リスク軽減のためのインクリメンタル手法

第17章　究極のリスク軽減戦略

第4部　数量化の方法

第18章　価値の数値化

第19章　価値も不確定

第20章　感度分析

第21章　価値はリスクを相殺する

第22章　リスク管理手順の修正

第5部　嘘かまことか

第23章　リスク管理の検証

付録A 「新年の倫理」

付録B リスク・テンプレート

参考文献

解説　エコノミー・クラス的ソフトウェア・リスク管理のススメ

訳者あとがき

索引

著者紹介・訳者紹介

本書について

本書のまとめ

まえがき

プロローグ 信念の倫理

第1部 なぜリスクを管理するのか

第1章 リスクに立ち向かう

第2章 リスク管理は大人のプロジェクト管理だ

第3章 デンバー国際空港再考

第4章 リスクを管理すべき理由

第2部 なぜリスクを管理しないのか

第5章 リスク管理をすべきでない理由

第6章 不確定性への非難

第7章 運

第3部 リスク管理の方法

第8章 不確定性を数量化する

第9章 リスク管理のしくみ

第10章 リスク管理の手順

第11章 基本に返る

第12章 ツールと手順

第13章 ソフトウェア・プロジェクトのコア・リスク

第14章 リスク発見プロセス

第15章 リスク管理の力学

第16章 リスク軽減のためのインクリメンタル手法

第17章 究極のリスク軽減戦略

第4部 数量化の方法

第18章 価値の数値化

第19章 価値も不確定

第20章 感度分析

第21章 価値はリスクを相殺する

第22章 リスク管理手順の修正

第5部 嘘かまことか

第23章 リスク管理の検証

付録A 「新年の倫理」

付録B リスク・テンプレート

参考文献

解説 エコノミー・クラス的ソフトウェア・リスク管理のススメ

訳者あとがき

索引

著者紹介・訳者紹介

プロローグ信念の倫理

第1部　なぜリスクを管理するのか

第1章　リスクに立ち向かう

第2章　リスク管理は大人のプロジェクト管理だ

第3章　デンバー国際空港再考

第4章　リスクを管理すべき理由

第2部　なぜリスクを管理しないのか

第5章　リスク管理をすべきでない理由

第6章　不確定性への非難

第7章　運

第3部　リスク管理の方法

第8章　不確定性を数量化する

第9章　リスク管理のしくみ

第10章リスク管理の手順

第11章　基本に返る

第12章　ツールと手順

第13章　ソフトウェア・プロジェクトのコア・リスク

第14章　リスク発見プロセス

第15章　リスク管理の力学

第16章　リスク軽減のためのインクリメンタル手法

第17章　究極のリスク軽減戦略

第4部　数量化の方法

第18章　価値の数値化

第19章　価値も不確定

第20章　感度分析

第21章　価値はリスクを相殺する

第22章　リスク管理手順の修正

第5部　嘘かまことか

第23章　リスク管理の検証

解説　エコノミー・クラス的ソフトウェア・リスク管理のススメ