radioc@?

レディオキャットハテナ

【読書メモ】熊とワルツを

熊とワルツを - リスクを愉しむプロジェクト管理

熊とワルツを - リスクを愉しむプロジェクト管理

ソフトウェア工学界の巨匠トム・デマルコ氏とティモシー・リスター氏によるリスク管理の名著。古典と書こうとしたが2003年とのことで古典というほど古くはない。とはいえ、ソフトウェア開発の書籍でこれだけリスク管理にスポットを当てた本はあまり無いのでいずれ古典的名著と呼ばれる日が来るのは間違いないだろう。ソフトウェア開発をマネジメントするうえでは必読書と言って良いのではないかと思う。

本書の後半ではリスク軽減の方法としてインクリメンタルな開発の重要性を挙げており、その思想はアジャイル開発の手法に受け継がれているようにも感じる。言い換えればリスク管理の側面でアジャイル開発のルーツの1つとも言えるかもしれない。個人的にはじっくり読むには非常に良いタイミングでした。

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

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

リスクと利益は切っても切れない関係にあるので、リスクのないプロジェクトに手を出しても何も得るものはない。

リスクとは

  1. 将来起こりうる出来事で、望まない結果を生むもの。
  2. 望まない結果そのもの。

リスク管理とは1を管理すること。

問題とは

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

リスク移行

リスクが問題になることを「リスク移行」といい、リスクが「実現」したという。

リスク管理の各要素

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

デンバー国際空港再考

1993年に開港する予定だったデンバー国際空港(DIA)の自動手荷物処理システムが完成せず、莫大な遅延コストが発生したというソフトウェア開発の失敗事例。

※参考

agnozingdays.hatenablog.com

プロジェクトが失敗した原因は、DIAのリスク管理の方法にあるのではない。リスク管理の努力がまったくされなかったことにある。

リスクを管理すべき理由

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

リスク管理の方法

不確実性を数量化する

プロジェクトの完了について、縦軸に確率、横軸に時間をとったとき以下の3点を曲線で結んだ図を「リスク図」という。

  1. 可能性は極めて低いが最も早く完了する日
  2. 可能性が最も高い日
  3. 可能性は極めて低いが最も遅く完了する日

1をナノパーセント日と呼ぶ。

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

※参考

http://pcmdays.cocolog-nifty.com/blog/2006/09/post_5a24.html

リスク管理のしくみ

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

過去に起きた問題を元に新しいプロジェクトのリスク・リストを作る。

リスクについてできること

  • 避ける
  • 抑制する
  • 軽減する
  • かわす

「かわす」は何もしなかったがリスクが実現しなかったこと。

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

リスク・エクスポージャー

リスクの抑制コストの期待値。

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

コストのかわりに時間的なリスクにも使える。例えばプロジェクトが5ヶ月遅れるリスクが20%の場合はリスク・エクスポージャーは1ヶ月。

ショートストッパー

発生すると何もかも犠牲になって進めなくなるような自分では手に負えないリスク。リスクを監視する必要はあるが、自分が管理するのではなく上司や会社の上層部が管理するように正式な儀式を行って託す。

リスク管理の手順

9つのステップを実施する

  1. リスク発見プロセスによってリスクを調査する
  2. ソフトウェア・プロジェクトのコア・リスクが調査に含まれていることを確認する
  3. 個々のリスクごとに次の作業を行う
    • リスクに名前と番号をつける
    • ブレーンストーミングによって、そのリスクの移行指標を特定する
    • リスクが実現した場合にコストとスケジュールに与える影響を推定する
    • リスクが実現する確率を推定する
    • そのリスクの時間的、資金的なエクスポージャを計算する
    • 移行が始まった時にとるべき危機対応措置を事前に決めておく
    • 選択した危機対応措置を実行できるように、移行の前にとるべき軽減措置を決める
    • 全体的なプロジェクト計画に軽減措置を追加する
    • ドキュメント化する
  4. ショートストッパーをプロジェクトの仮定条件として指定し、上層部に引き渡す儀式を実行する
  5. リスクがいっさい実現しないものと仮定して、最初のスケジュール見積もりを作成し、ナノパーセント日を決定する
  6. 社内と業界全体の不確定要素を使って、Nから始まるリスク図を作成する
  7. リスク図を使って約束を発注者に伝える
  8. リスクが実現したり終了したりしないか監視し、実現したときには危機対応計画を実行する
  9. プロジェクトの期間中、あとから出現したリスクに対応するためリスク発見プロセスを継続する

RISKOLOGY

リスク評価のツール

Riskology Home Page

※メモ

Rで実装

smrmkt.hatenablog.jp

リスク発見プロセス

  1. 破壊的結果のブレーンストーミング
    • 悪夢に絞って考える
    • 水晶玉を使う
    • 視点を変える
    • 誰も責任のない不幸
    • 非難すべき失敗
    • 部分的な失敗
  2. シナリオの構築
  3. 根本原因の分析

共存共栄モデル

  • 利害関係と特定し勝利条件の対立や緊張を探る

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

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

リスク管理の力学

天罰期

  • リスクが問題として顕在化し問題を認識するプロジェクトの中盤ごろ

進捗メトリック

  • 境界要素の決定
    • データの流れからシステムの境界を明確化する
    • 仕様の崩壊のコア・リスクを防ぐ
  • EVR(現在稼得価値)
    • 実質的な進捗状況を表す指標(完成度%)
    • 仕様の崩壊意外の4つのコア・リスクの影響を追跡する

インクリメンタル開発

  • 設計をほぼ完全に行い、サブセットごとにインクリメンタルな開発を行う
    • 進捗メトリックの重要な拠り所
    • EVRをメトリクスに使う

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

  • 詳細設計図
  • 作業分解図(WBS
  • バージョン受入検査表

究極のリスク軽減戦略

究極のリスク低減は少しでも早く着手すること

数量化の方法

投資収益率=\frac{価値-コスト}{コスト}

リスクのことだけを考えると、リスクをどこまでとるべきか、理由を示して説明できない。

コストと効果は同じ精度であらわす必要がある

参考

qiita.com

yabit.hatenadiary.jp