熊とワルツを 〜 信じる権利があるものだけを信じること

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

デマルコ＆リスターの名著。リスクマネジメントとは、を解説する一冊。名著なんで、中身のきちんとした解説は適当な書評を探して下さい。

「上司に聞かせたかった」と言われたとき、私のメッセージがきちんと正しい相手に届いたと思うようになった。このメッセージを聞いてなにも行動する必要を感じなければ、抵抗すべきものもないはずだ。上の階層に責任を転嫁したいと最も強く願う人こそが、自分が変化を起こせることを知っているひとなのだ。（訳者あとがきより、デマルコのメッセージとして）

そう言いたくなる聴衆側の気持ちも、「だから君がやるんだよ」というデマルコの気持ちも分かる。本書はそういう心構えで読み、「何をするべきか、何をできるか」を考えるための一冊である。

上との付き合い方という点から本書を読んでいて、こんなことを考えた。
まず、リスク対策は避けがたいコストとして現れる。だから「幸運を期待する」マネジメント（本来、そんなものはマネジメントではないが）をする上司は、リスク・マネジメントは嫌がるだろう。そのとき何ができるだろうか。

こんなリスクに対しては運命論者になって、当たったらおしまいだから用心してもしかたがないと言いたくなるかもしれない。自分の力ではどうにもならないのだから、気を楽に持って、どうにかなりそうな問題だけに対応していればいい。この論理には重大な間違いがある。たとえば、自分が組織の中で2階級昇格したらどうなるか想像して欲しい。このリスクに強い関心を持つのではないだろうか。このれらのリスクを抱えるのはプロジェクトチームではなく、プロジェクトを発案した人間なのだとわかるはずだ。プロジェクトをやめることができるのは、プロジェクトを始めた人間だ。プロジェクトの仮定条件が間違っていた場合にどうするかは、その人が決めるしかない。
原則として、上の階層の人間が負担するリスクは、下の階層の人間にとっては仮定である。下の階層でもそのリスクを監視する必要はあるため、リスクリストには載せるが、それがプロジェクトの仮定条件であることを注記しておく必要がある。それは自分が管理するリスクではなく、上司か、上司の上司が管理すべきものであるということだ。このリスクを上層部に引き渡すときには、ちょっとした儀式を行うといい。リスク管理計画を提出するときに、幾つかのリスクの管理を、正式に上の階層の人間に託すのである。このためには、残りのリスクは自分が責任を持ってきちんと管理する必要がある。(pp.80-81)

上司に託すところまでが自分の仕事であり、そのために自分の仕事はきちんとやらなければならない、というわけ。
具体的にどういう心構えで、どういうことをすればよいか、その具体例とヒントは本書にたっぷりと説明されている。以下に、幾つか抜き書きをするので、「あ！」と思った人は素直に本書をどうぞ。

不確定要素を明確に宣言していない場合、思いつく限り最高の結果を達成できなければ失敗である。リスク管理をしなければ、高めの目標と妥当な期待を区別できない。そのため高めの目標をもとにスケジュールを立てるが、そのような目標はふつうぎりぎり届くか届かないかの所にあるため、達成に失敗する。(p.36)

無茶なスケジュールで失敗する理由。

間違えるのはかまわないが、不確かなのはだめだ。
このルールが自分の会社にあてはまったら、おしまいである。(p.48)

リスクとは不確かなもの。

Nに完成すると約束するのはばかげているが、それでもこの日は重要な日である。この日に関して何らかの直感が働くからだ。我々は過去に予測を立てた経験からNを予想する方法を知っているが、次に誤ってNを納期として扱ってしまう。(p.65)

Nは「ナノパーセント日」のこと。累積完成確率が０でなくなる日のことで、「すべてがうまくいった場合の完成日」。その見積もりをいつのまにか「納期」にすり替えられた経験の無い人はいないだろう。
すべてがうまくいくと信じる「根拠はない」、すなわち「信じてはいけない」のである。

きのうの問題は今日のリスクである。
誰にでも、この法則に納得のいかないところはある。「今日の問題はきのうのリスクである」とか「今日のリスクは明日の問題であるに「訂正したくなる」。(p.71)

一度起きたことは、しばしばもう一度起きる。対策を取らなければ当然だし、対策をとってすらしばしば再発する。リスク候補リストの第一番には、きのうの問題を記載するべきなのである。

いつものことですが、ソフトウェア開発のプロセスには不確定要素があります。これが今回のプロジェクトの不確定範囲です。(p.98)

これを認めないといけない。

コストと効果は同じ精度で表す必要がある。
「どうしてもいるのだ」としか効果を言い表せないのなら、コストも「相当かかるだろう」とするべきである。(p.174)

市場機会という壮大な幻想は、丹念に効果を予測しないことに対する最も安全な言い訳としてよく使われている。発注者は、市場機会が失われる前に開発者がシステムを完成さえなければ効果は実現しないといったことを、自信満々に語ることがある。さらに合わせ技として、殆ど間に合うはずのない期日を「市場機会が失われる日」と主張するため、効果の数値は実はどうでもよくなる。こうして、プロジェクトは失敗するように仕組まれるが、発注者はいっさいの説明責任を回避する。(p.182)

スケジュールの根拠と効果は言い出した側にきちんと説明させなければならない、ということ。ここから優先度付けなどが始まる。スケジュールが最優先なら、スコープやコストを調整するべきなのである。それらのバランスが必要なら、各項目は同程度の粒度・精度を持っていなくてはならない。