「熊とワルツを」
古典的名著である「熊とワルツを」を読みました。
そこから学んだことを僕なりにまとめていきたいと思います。
不思議なタイトルについて
「熊とワルツを」という一見ソフトウェア開発に関する本とは思えないタイトルですが、どういう意味なのでしょうか。
僕がこの本を開く（kindleですが）時にまず気になったことです。
読んでいくうちにわかりましたが、筆者たちは
熊＝リスク
と例えています。
つまりソフトウェア開発とは、熊のような獰猛なリスクと楽しい時間をいかに過ごせるか、というのが重要だと言っているのです。
なんというか、多面的な見方ができるタイトルだな、と感じます。
森のくまさんと楽しく踊ろうという牧歌的なイメージも湧きます。
しかし、ふと気づけば熊はこちらをにらみつけて歯をむき出しているかもしれません。
そして次の瞬間には頭から噛みつかれるかもしれません。
そんなリスクと向き合いつつ（＝一緒にワルツを踊る）、ソフトウェア開発を最後までやりきる方法を、具体例を交えながら教えてくれる本です。
リスクとは
人は信じたいものを信じてしまう
まず、人間の性として、人は真実よりも自分が信じたいものを信じやすい傾向にあります。
そして、それが集団の同調圧力や上層部からの納期の催促があるような状況では、より顕著な特徴となります。
その結果、後から見ればどう考えても無理な計画だったのに、その当事者でいる間は視野がとても狭くなり、信じるべきでないものを信じてしまうのです。
その信じるべきでないもの、それこそがリスクの温床です。
ソフトウェア開発におけるリスクの定義とは
ソフトウェア開発の計画を阻害する要因となりうるもの、そのすべてがリスクであると言えます。
それは
- 技術的な障害であったり
- スケジュールの急な変更であったり
- 仕様が途中で変わるという根本的なものであったり
- 誰かキーパーソンが仕事を辞めてしまうかもしれない
ということであったりします。
リスク管理とは
リスク管理とは、”将来起こりうるできごとで、望まない結果を生むもの（＝リスク）を管理する”ことである。
リスク管理は、問題が実際に発生する前の、抽象概念の段階で対策を考えるプロセスです。
リスク管理の反対を「危機管理」といい、問題が発生したあとに何をするべきか考えることを意味します。
リスク管理と危機管理を混同してはいけません。
リスク管理を怠った実際の事例
デンバー国際空港の事例
アメリカで有名なソフトウェア開発の失敗として常にデンバー国際空港の事例が挙げられます。
コロラド州デンバー市は、1988年に新空港の建設に着手した。
新空港が完成すれば、コストを削減でき、環境汚染や航空便の遅れは軽減され、今後の成長も保証される。
新しい空港となるデンバー国際空港（DIA）は、1993年10月31日に開港する予定だった。
それが当初の計画である。
しかしけっきょくのところ、ソフトウェア開発者たちの遅れのせいで空港は開港できなかった。
最終的に開港できたのはなんと1995年になってからです。（しかもこれも部分開港）
それまでの間、莫大なお金はゴミ箱に捨てられていくことになったのです。
ことの顛末は以下のとおりです。
「自動手荷物処理システムが完成しないため開港できなかった」
以上。
新聞や雑誌がソフトウェア開発の失敗として書きたて、いまでも「DIAの自動手荷物処理システム」といえば、ろくでもないソフトウェア開発プロジェクトの象徴になっているそうです。
しかし、筆者たちは問題の別の側面を見ています。
それがリスク管理の問題です。
DIAのリスク管理
DIAのリスクマネージャーは、「もし自動手荷物処理システムが間に合わなかったら」というリスクを管理していなかった。
そのために自動手荷物処理システムの遅れが計画に致命的な影響を及ぼしました。
「もし自動手荷物処理システムが間に合わなかったら」どうするべきか、考えていればそれも計画の中に入ってきたはずです。
具体的には無人運転（有人でもいい）の荷物運搬できる車のとおるトンネルを用意しておくことができたはずです。
しかし現実には、自動手荷物処理システムが遅れるかもしれないというリスクを管理していなかったため、荷物運搬者がとおるトンネルを作ることは設計に考慮されていなかった。
そのため、自動手荷物処理システムが遅れるとわかってから、二の矢を放つことができず、ただ手をこまねいて遅れていくしかなかったのです。
リスクは避けられるものではない
リスクを避けようとするのは間違いです。
リスクを避けようとする行為は、リスクを目に見えないところに追いやるということを意味します。
目に見えないところに追いやったとしても、リスクは突如としてやってくるものです。
なのでリスク管理においては、リスクは避けようとするのではなく、いかに向き合って付き合っていくかが大切なのです。
リスクを避けようとするのは現実逃避に他なりません。
リスクと楽しく付き合っていくこと、それが「熊とワルツを」ということなんですね。
リスクと向き合うには
考えられるリスクをすべて検討する
- まずプロジェクトが始まるときに、開発にたずさわるソフトウェア開発者をみんな集めてリスクについて意見を出し合う
- 1時間以上の時間をかけて、お菓子を食べながらなど、気楽な空間を作りながらみんなで考えられるリスクをどんどん出し合う
- そしてそのリスクがどんな結果につながるかみんなで考えていく
- リスクの時間的、資金的な影響度を見積もる
- リスクが発生し始めた時の対応策を決めておく
これがリスク管理プロセスです。
僕も次のプロジェクト開始時にはこれをやろうと思います。
リスク管理を確実に履行する
けっきょくこれができなければ何の意味もありません。
リスクが実現したり終了したりしないか監視し、実現したときに危機対策計画を実行します。
また、あとから新しいリスクが生まれることも考えられます。
その時に備えてリスク発見プロセスは継続しましょう。
また、本の中にはリスクを踏まえた計画を定量的にグラフ化し、リスク図として表現したり、製品リリースまでのリスクを踏まえた見積もりの出し方を提示しています。
そちらも非常に参考になるのでぜひチェックしておくべきです。
ちなみに
本の最初に日本版の序文が書かれていますが、
みずほ銀行のシステム統合直後の障害で、社長がたびたび報道陣の前で頭を下げる光景はいまだに多くの人の記憶に新しい
ということが書かれています。
この序文が書かれたのはいつだろう、と確認してみたら2003年のことでした。
いまから18年前のことなんですね。
2021年現在もみずほ銀行はシステム障害を頻発して、信用を失いつつあります・・・。
ソフトウェア開発を軽く見てリスク管理してこなかったツケが回ってきている感じがあります。
おわりに
この本は18年前に書かれたものですが、いまのソフトウェア開発でも十分通じる内容ばかりです。
ソフトウェア開発におけるリスク管理というのはいつまでたっても大きな課題なのですね。
まだ読んでいない人は、ぜひこの機会に手に取ってリスク管理と向き合ってみてはいかがでしょうか。
