ソフトウェア開発のリスク管理を扱った古典『熊とワルツを』を読み終えた。
抽象度が高く、一度読んだだけでは消化しきれない部分も多かった。 特に確率の扱いや、モンテカルロシミュレーションなどを使ったリスクの数量化は、考え方こそ理解できるものの、実際のツールやExcelで手を動かしてみないと、どう運用するのかイメージが湧かない。これが正直なところだ。
それでも、これまで当たり前だと思っていた見積もりや納期の捉え方を、考え直すきっかけになった。
納期は「点」ではなく「確率」である
特に印象に残ったのが、納期をひとつの日付ではなく、達成確率で示すという視点だ。
開発の現場には、仕様変更、未知の技術的障害、キーマンの離脱など、不確定な要素がいくつもある。 それなのに「○月○日に完成します」と、ひとつの日付で約束することを求められる。 本来は、たとえば「この日までに終わる確率は60%」と示すほうが、不確実性を含んだ見積もりとして実態に近い。
理屈としては合理的だし、開発側としても納得感がある。 ただ、すぐに別の疑問が浮かぶ。
その60%という数字を顧客に提示して、受け入れてもらえるのか?
正論だからといって、そのまま実務に持ち込めるわけではない。 考え方には納得できるのに、実際に顧客とどう話すのかとなると難しい。この隔たりが、読んでいてずっと気になった。
見積もりに潜む「願望」と責任の所在
本書を通じて気づかされたのは、普段作っている計画に、どれだけ願望が入り込んでいるかということだ。
- 仕様変更は起きないだろう
- 重大なバグは出ないだろう
- メンバーは誰も辞めないだろう
こうした楽観的な前提をいくつも重ねた結果を、いつの間にか確定した未来として扱ってしまう。 見積もりは作業時間を合計すれば済むものではなく、いくつもの前提条件の上に成り立っている。その前提が崩れれば、見積もりも変わる。
リスクと発注・受注の関係についても、納得するところが多かった。 外注したからといって、リスクまで相手に転嫁できるわけではない。 遅延や品質低下の影響を受けるのはプロジェクト全体であり、発注側にもリスクを管理する責任がある。
それなのに、リスクのしわ寄せや納期の責任を受注側だけに背負わせる構造には、やはり強い違和感がある。
「悪い情報」を消してしまう組織文化
手法以上に根深いと感じたのが、組織文化の問題だ。
納期が遅れそうだとわかっていても、正直に言えない。 そんな組織では、どれだけ高度なリスク管理手法を取り入れても、形だけになってしまう。 「難しいです」と警鐘を鳴らす人より、「できます!」と引き受ける人が評価される環境では、不都合なリスクほど表に出てこなくなる。
「想定外」の一言で片付けているトラブルにも、事前に起こる可能性を考えられたものはあるはずだ。 その可能性を話せないままでは、確率を計算する以前のところでつまずいてしまう。
悪い予測を伝えても、伝えた人が不利益を受けないこと。 ツールを導入する以上に、安心して悪い情報を共有できる環境が必要なのだと感じた。
一度で消化しきれないから、また読み返したい
リスクのないプロジェクトには価値がない、といった主張には、やや極端さも感じた。 方法論を明日からそのまま職場に適用するのも、ハードルが高い。 顧客との契約慣行、社内の評価制度、従来の見積もりルール。考え方を理解しただけでは変えられないものが、いくつもある。
それでも、予定は確定した未来ではなく、見積もりには不確実性が含まれている。 そのことを改めて意識できただけでも、読んだ価値はあった。
理解しきれなかった定量化の手法も含めて、一度で全部を飲み込む本ではないのだろう。 今後、実際の現場で見積もりやリスクに頭を抱えたとき、辞書のように何度も読み返したい一冊だ。
購入したときのことは、7月31日の写真日記にも書いている。
本人の読後メモをもとに、GPT-6 が記事として編集しました。

