熊とワルツを

システムの仕事をしていると「リスク」という概念とは
切っても切り離せないのですが、体系的に学びたかったので
この本を読んでみることにしました。

ソフトウェア業界では有名なトム・デマルコの著で
「リスクのないプロジェクトには手をつけるな」という
強烈なイントロダクションから始まります。

熊とワルツを - リスクを愉しむプロジェクト管理/トム・デマルコ

￥2,310

Amazon.co.jp

ここで気がつかれた人もいると思いますが、この本は
一般的なシステム開発プロジェクトにおけるリスクを
扱った本であり、運用保守などシステムが絡む一般的な
状況やその他に企業におけるリスクの考え方などは
一切出ていません。

私としてもそういう個所については特に関心があったので
ちょっと残念。

ただ、リスクに関しては以下のように定義しています。
「将来起こりうる出来事で望まない結果を生むもの。
もしくは望まない結果そのもの」

そして冒頭の言葉はリスクを積極的に取りに行くことで
競争に打ち勝ち、自身の成長機会を得ると出ており
全般的なポリシーとしてはすごく共鳴できる個所が
あるのでそういう意味では面白い本と言えます。

この本は一般的な管理者がなぜリスクを管理しないのか
ということについて分かりやすい事例を用いて説明しており
不確定でコントロールできないことから考えないようにする
という悪循環を厳しく罰しています。

また、リスクの管理方法や定量化する方法についても
いくつか手法を載せており（デマルコの会社のRISKOLOGY
を推奨しているのにはちょっと閉口）私も実際にこの
ツールを使っていろいろ試しに遊んでみました。
ここでやろうとしているのはプロジェクトが完結する最初の
見込みのある日・ナノパーセント日からほぼ確実に納品できる
日の中で最も可能性のある日をプロジェクト終了予定日と
しなさいということのようです。

そのためにモンテカルロ・サンプリング法で500回もシミュレート
するというツールのようですが中身はなんてことのないExcelの
ワークブックです。ご興味ある方はこちらどうぞ。

http://www.systemsguild.com/riskology/

プロジェクトにおいては管理者はそこで得られる価値に対する
説明責任を負うべきという至極まっとうな話があります。また、
それに対し開発マネージャはそこにかかるコストへの説明責任を
負うべしということと不確定性のある問題（我々の業界用語？で
バッファと言ってますが）を考慮に入れよということ。こういった
ことは正論でありながらなかなかできないことですね。とはいっても

とはいってもこの辺に関しては説明するためのアイデア（引き出し）
をいろいろ身につけておきたいものです。事業プランを考案する
立場の人には避けて通れない道でしょう。

プロジェクトはインクリメンタル手法でプロジェクトを意味のある単位に
分割したうえで現在稼得価値（EVR)を算出して行けばプロジェクトの価値を
最大化して、リスクを相殺する賢明な方法と後半は締めています。
そのためにもプロジェクトは早く始めることが（仮にプロジェクトが
失敗に終わった場合でも）肝要ですという話でこの辺納得。いろんな前置き
が長くてなかなかプロジェクトの開始にたどりつけないケースもありますが
「すぐやる」という姿勢はいろんな意味でメリットがあるということなんですね。

ところで、自分が一番知りたかったことの一つに「何をリスクとして扱うのか」
というレベル感があります。開発の最中に地震が起きるかもしれないとかは
考慮に値しないのはわかりますが、たとえば当社のサービスでクチコミや
演出・エピソードという投稿系のものがあります。こういったサービスを
考案するたびに監視体制を増強しますが、「チェック負荷の増加」という
項目を本当にリスクとして挙げるべきなのか悩んでしまったりします。

ここではリスクの洗い出し（リスク・リストと言ってますが）は過去の案件
で問題になったことから出していくことについては記載があるものの、
そのレベル感については特には言及してません。これはつまり問題と認識
できたものはリスクとしておけということなのかもしれません。

そのリスクの対処は
避ける
抑制する
軽減する
かわす
となっており、まあ経験則からいっても妥当な内容です。

こういうことでリスクは管理できるという自信を持たせてくれる、
そんなお話でした。リスクって何だ？と思ったら読んでみる価値は
ありそうです。