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

はじめに～プロローグまで。 ウィリアム・キングドン・クリフォードを引き合いに出し、信じられないことを疑念をねじ伏せて信じることの問題点はそこに権利があったのかという点に触れる。 眼の前の証拠に基づき信じる権利があったものだけを信じるのがリスク管理ととく。 リスク管理をすべき理由と準備が整うまですべきでない理由がるのが興味深い。 日本版序文にて、みずほ銀行の失敗でリスクという言葉を 20 回近く使ったという話に触れ、(当時の)日本のリスク管理の遅れを嘆いている。 現代でも割と最近のみずほがスカイツリー 7 本分のコストを費やした体たらくを見れば何も変わっていないのがよく分かるな。

2025-10-31, read count: 1, page: i ~ viii, 1 ~ 6, pages read: 14

1 ~ 3 リスクを取らなければチャンスを得ることはできない。変化の時代においては尚更で、リスク回避するだけでは競争に負けてしまう。 リスクを無視できるのはリスクを全て洗い出し評価した結果対応しようがないものだけ。 リスク管理は将来起こり得る問題を管理する。 リスクが実現することをリスク移行、実現したことは移行指標という。実現したリスクを管理するのが危機管理。 リスクが実現したとき危機管理が適切に機能するよう事前に対策する。これがリスク軽減。 リスク発見、エクスポージャー分析、危機対応計画、軽減、継続的な移行監視、これらは大抵の人が生活で実践しているが、仕事では組織文化との衝突などで難しい場面がある。 リスク管理不在の例としてデンバー国際空港。 DIA の ABHS ではデンバー市がリスク管理すべきだった。 リスク管理はおとなのプロジェクト管理、というのが面白い。 これが意味するのは、バラ色の目標を夢見るのでなく現実を見て理性的に計画しましょう、ということろかな。

2025-11-01, read count: 1, page: 7 ~ 32, pages read: 26

4 ~ 6 リスク管理すべき理由。 不確定性・未知の要素を減らプロジェクトの成功率を高める。 リスクの程度が分かり、積極的にリスクを取ることで成功と成長の機会を高める。 リスク管理をすべきでない理由。 組織が未成熟で、現実を受け入れられない、ひとりでリスクすると危険に見合われるような場合。 またはデータが不足し不確定範囲が広すぎる場合。 不確定要素を嫌う組織ではリスク管理が機能しない。 失敗・拒否・中止という言葉を恐れるあまり、迫りつつある重大なリスクに目を瞑る。 程度の低い組織で批判的思考でいると世界のどこでもバカにされるんやなというのがよく分かる。その場合に取れる手段は場所を変えることというのもどこでも同じか。 リスク管理がプロジェクト成功率を高めるというのを示してもらえると背中を押してもらえる感じがする。

2025-11-02, read count: 1, page: 33 ~ 52, pages read: 20

7 ~ 8 プロジェクト管理は一か八かの勝負に出るのでなく失敗をする前提で失敗の程度を抑えるのが重要。よって運に頼ってはいけない。 プロジェクトの完成までの不確定性を定量化するすべとしてリスク図がある。 完成する可能性がある最初の日(N(ナノパーセント)日と書かれている)から最後の日までを不確定幅とすると、その幅の広さはその組織の開発プロセスにどれだけノイズがあるかで決まる。 過去の実績が記録されていれば経験的にノイズの量を決定でき、それだけ不確定性を減らすことができる。 ソフトウェア業界全体では概ね不確定幅は 150 ~ 200% 、 N 日まで 25 ヶ月の場合は最大 + 50 ヶ月で 75 ヶ月かかる可能性がある。 わたしが計画を立てるときは真のデッドラインと目標日を分けるが、確率的に図示はしてこなかったから参考になる。 図示すれば N 日を計画に採用するのが如何にアホらしいかも説明しやすかろう。

2025-11-03, read count: 1, page: 53 ~ 68, pages read: 16

9 プロジェクトが遅れる要因として計画の遅れるより計画外の作業の発生が多い。 このようなリスクを認識する情報源として過去のプロジェクトの実績が使える。 一覧したリスクに対してできるのは回避(機会の損失)・抑制(実現した場合の準備)・軽減(実現する前の措置)・かわす(ただの運)のいずれか。 請負業者に作業を依頼していても明示的に託したリスク以外は自分たちで管理する必要がある。 個々の抑制に対するコストはリスク・エクスポージャー(コスト(時間・資金)×確率)を算出、それに基づきリスク準備(時間的・資金的余裕)を確保する。 軽減コストはリスクが実現しなくてもかかるが、リスクが実現した際のリスク準備を減らす。 市場が失われるとかのすべて台無しにするようなリスクをショーストッパーといい、発生しないという仮定でのみ対策できる。この責任は組織の上層部が担う。 移行指標の精度と早さはトレードオフの関係にある。危機対応の緊急性と誤報のコストも考慮して設定する必要がある。 次の長期案件でやってみようか。どのみちひとりなので色々試せる。

2025-11-04, read count: 1, page: 69 ~ 84, pages read: 16

10 ~ 11 リスク管理を 9 つのステップ(本書参照)で実施する上で厄介な点がある。 最も楽観的なスケジュール N(ナノパーセント日) を基点に許容できる納期を約束すべき点。 無茶な期日を N に設定したがる人はそれが実現可能なことを証明しなければならない。 顧客に約束する納期は完成する確率が高いためプロジェクトの目標とするには低すぎる点。 N から納期までの間で高めの目標を設定しなければならない。 期日がハードコミットされるとどうしても遅れてしまう点。この場合バージョンを細かく区切って段階的なリリースをするインクリメンタルな開発手法をで対応しなければならない。 リスク調査を組織内に公表できるようにすべき点。万が一正直者が不利に立たされるようであれば誰もリスク調査を公表しない。 わからない内のわかっていことを可視化する術としてリスク図を使う。リスク図の切り口の % を使うのでなく図自体がリスク全体を表す。 生産モデルの出力 N(ナノパーセント日) と原因リスク(Slack でいうところの部分リスク)を入力にするリスクモデルの出力が全体リスクとなる。 リスク図の表示形式としては漸増図と累積図がある。 このリスク管理の基礎の部分はデッドラインで直感をモデル化したシミュレーションとして出てたやつよな。 つまりリスク管理と直感はつながってるわけか。

2025-11-05, read count: 1, page: 85 ~ 106, pages read: 22

12 ~ 13 RISKOLOGY はモンテカルロ法のシミュレーションを表計算ソフトで表現したツール。 このツールでソフトウェアビジネス共通の問題(コア・リスク)である、スケジュールの欠陥・要求の増大・人員の離脱・仕様の崩壊・生産性の低迷をリスク管理する例を示す。 生産性の低迷以外のコア・リスクはチームの能力とは関係がないが、それは管理者の能力を無視した上での話。 仕様の崩壊はつまり要求仕様策定における対立が生み出す曖昧な仕様で製品が作れなくなること。これだけは他と違い発生するとプロジェクトが破綻する。 仕様の崩壊が顕現した形のひとつとして、ピーター・キーンが「カウンター・インプリメンテーション」と呼ぶ過剰な機能要求がある。 過小見積、変更・離脱者ゼロの幻想、プロジェクト内の対立、この辺は失敗もあろうけど大体は怠慢よな。

2025-11-06, read count: 1, page: 107 ~ 133, pages read: 27

14 ~ 15 コアリスク以外にプロジェクト固有のリスクも存在するが、リスクを指摘することがチームの利益に反するかのように取られるため、発見が難しい。 破滅的結果を想像し、そのシナリオを構築し、根本原因を分析するという決められたプロセスを踏むことで、バイアスを除去してリスクを発見できる。リスク移行するのと逆順にすることで恐怖を和らげる。 バリー・ベームの共存共栄スパイラル・プロセス・モデルにプロジェクトの勝利条件を定める方法は、プロジェクトに内在する対立を見つけられる可能性がある。 リスク管理を継続的に行う必要があるのは中盤になって計画不足、見落とし、関係づくりの不良、仮定条件見逃し、幸運への依存といった初期から存在する問題が顕現するため。 継続監視のために使えるメトリックとして境界要素・現在稼働価値(EVR)がある。境界要素はシステムの入出力の定義であり仕様の崩壊を防ぐ。 EVR はプロジェクトの完成度を表し進捗状況を表す。インクリメンタル手法と強い関係にある。 ビッグバン方式で完成度を証明できるのは最後の受入検査だけだが、インクリメンタル手法はバージョン毎の受入検査であらかじめ計算した EVR の割合で全体の進捗を証明できる。 リスクブレストやってみたくなるな。「天罰期」って言葉遣いも面白いので真似たくなるが日本文化で伝わるかな？

2025-11-07, read count: 1, page: 134 ~ 151, pages read: 18

16 ~ 17 インクリメンタル開発は最初に詳細な全体の設計をし機能の優先順位を定めバージョンを区切りリリース計画を立てる。 部分的なリリースで仕事の区切りがつき士気を保ちやすい、プロジェクト仮定条件の確認や顧客からフィードバックを得やすいという利点もある 必ず最初に全体の詳細を設計しないと見積が破綻する、優先順位を決めなければ機能しないシステムがリリースされる恐れがある 最も効果的なリスク軽減策はプロジェクトのスケジュールにゆとりを持たせること。 ゆとりのない「勇敢な」スケジュールは調整を恐れた臆病者のスケジュール。 インクリメンタル開発を全面的に推してるけど、全体設計や優先順位のところは無し崩しスクラムに対する痛烈な批判に感じるな。

2025-11-08, read count: 1, page: 152 ~ 170, pages read: 19

18 ~ 19 システムを開発する理由がコスト削減だった時代は終わり、コストとその効果も厳密に求められるようになった。 効果の定義は曖昧なままにされがちだが、コストと効果は同じ精度で表す必要がある。効果が不確定ならコストも不確定にしなければならない。 組織は価値のないプロジェクトに労力を費やさないようリスク管理する必要がある。 効果もその不確定性をリスク図で表現できる。市場機会のような曖昧な効果は認められない。 上手くいく組織では、プロジェクトを意図的に評価し、予想される効果に応じて予算を削減する傾向がある。 効果が曖昧なでかいプロジェクトを立案したことがないのでなんともやが、いつか機会があるかも知れないし覚えておこう。

2025-11-09, read count: 1, page: 171 ~ 186, pages read: 16

20 ~ 22 システムのユーザーや発注者がその価値を測る責任がある。その手法としてインクリメンタル開発の各コンポーネントに価値をつければ全体の価値の偏りがわかるが、そう上手くはいかない。 いずれにせよインクリメンタル手法は顧客から優先順位を引き出すきっかけになる。 得られる価値が大きければ重大なリスクも負える。デスマーチプロジェクトは価値が低くコストを掛けられないのでメンバーの犠牲が無条件に求められる。 不確定図を使って価値とコストがバランスするか正味効果をシミュレーションすればプロジェクトの価値を予想できる。 20 はこれまでのリスク管理を反映させたリスク管理の手順。 価値の可視化とその過程で無駄を削ぎ落とすということかな。デスマーチが価値のないものにコストを掛けれない代わりに犠牲を払ってるってのは言い得て妙。

2025-11-10, read count: 1, page: 187 ~ 199, pages read: 13

23 ~ 付録 A 「信念の倫理」第一部 リスク管理がされているか客観的に評価しなければならない。 リスク調査が行われる、定期的なリスク発見プロセスが行われる、不確定図が頻繁に使われる、目標と予想が別である、リスクに移行指標・危機対応計画・軽減計画がある。 最低限これらを実施していればリスク管理が行われていると見なせる。 他、リスクのエクスポージャーが評価されている、プロジェクトの価値が定量化され、何らかのインクリメンタル手法が使われている。 「信念の倫理」は、何かを信じること自体に倫理的責任が伴う、という感じ。エンジニアの職業倫理とも強く関係した話やな。

2025-11-11, read count: 1, page: 201 ~ 214, pages read: 14

付録 B ~ 最後まで。これで終わり。 リスク管理フォームから本書中であった管理ポイントをより具体時に見て取れる。 解説では日本でリスク管理が育たない事情にも触れられている。 JIT 生産なんかはある種リスク管理を削ってると見れるし。 あとがきでこれまでの著作とのつながりについて触れられているのも良い。 本書を読み終えて、本書でいうインクリメンタル手法にあたるアジャイル関連の本でリスク管理をあまり見たことがない気がした。アジャイルな見積りと計画づくりには載ってる。 わたしが開発者向けの本を好んで読んでいるから管理者向けの情報が入ってないだけではあるかも。 でも経験上アジャイルを標榜する組織でリスクらしいものを管理してるのを見たことがない気もする。 開発手法が構造的にリスクを減らすといってもなくなるわけじゃないのできちんと向き合わないといけないということやろな。

2025-11-12, read count: 1, page: 215 ~ 238, pages read: 24