Risk Breakdown Structureとは何か

米国のアポロ計画は、1961年5月に、ケネディ大統領が演説の中で、「60年代中に人類を月に送る」と宣言して始まった。じつは当時、宇宙技術の点で、米国は仮想敵国ソ連に大幅に遅れをとっていた。ケネディ演説の直前の4月、ソ連のガガーリン飛行士がボストーク1号に乗り、人類初の有人宇宙飛行を実現した。彼のセリフ「地球は青かった」は、名言として今も広く知れ渡っている。

ケネディ大統領が60年代中に（つまり、それから8年7ヶ月以内に）有人月面飛行をする、と宣言したとき、米国の多くの専門家は、「そんなこと不可能」と感じていたらしい。しかし、一見不可能に見える未来像を示して、大勢の人を引っ張るタイプの楽観的リーダーシップは、当時の米国社会ではうまく作用した。1969年7月、アポロ11号は3人の宇宙飛行士を乗せて、月に向かって旅立つ。

アポロ11号というプロジェクトに、費用を全部でいったいいくら使ったのか、正確にはよく分からない。とりあえず、アポロ宇宙船とサターンロケットのみの費用は、約830億ドル（現在価値）という数字は調べることができた。これだけで軽く10兆円である。まあ、冷戦下における国家の威信をかけたプロジェクトである。10兆円なら安いのかもしれない。

ところでプロジェクト・マネジメントの感覚でいうと、費用とスケジュールは、プロジェクトのパフォーマンスを測る二大指標である。受注型プロジェクトだったら、約束の納期を守り、受注金額を下回るコストで仕上げられれば、利益が出る。自発型プロジェクトだって、結果を早くだし、出費も抑えれば成功と言える。

では、費用とスケジュールが両立しないときは、どうすべきか？

端的な例は、発注先が2社あって、A社に発注すれば費用は安いが納期がかかり、B社ならば高いけれども納期が短い、という場合だ。プロジェクト・マネージャーは、どちらに発注すべきか、決断しなければならない。品質その他の条件は、同じだとする。あなたなら、どちらを選ぶか。

答えは、いろいろあり得るだろう。だが、もしこれがアポロ11号のプロジェクトだったら、答えは明白だ。費用がかかっても、納期が短い方を選ぶはずである。なぜなら、アポロ計画全体の目標が、「60年代中」という時間設定だからだ。打ち上げ予定は1969年7月。ケネディ大統領の公約までに、残されたフロート日数は5ヶ月を切る。だとしたら、納期が遅れるリスクの方が、費用が超過するリスクよりも重大だ。これが判断の基準である。

プロジェクトのリスクとは、プロジェクトが目標を達成できなくなる事象の可能性である。プロジェクト目標は、もしかしたら複数あるかもしれない。成果物の性能や、納期、あるいはコストなどだ。もちろん、ある種のプロジェクトでは、納期やコストが目標から外れる場合もある。もし仮に、金に糸目をつけないプロジェクトなら、コスト超過リスクなどというものは存在しなくなる。

アポロ計画に予算枠があったかどうかは知らない（たぶん国家予算だからあったのだろう）。だが、コストよりも時間的目標の方がはるかに重要だった。プロジェクトの目標設定は、何をリスクと考えるかに対して、基本的な指針、枠組みを与えるのである。言いかえるならば、「客観的なリスク」などというものは、ない。リスクとは、人びとが設定したプロジェクトの目標を元にして、洗い出すべきものなのだ。

Risk Breakdown Structure(RBS)とは、リスク洗い出しのために、リスク・アセスメント・セッションで利用されるツールの一つである。

RBSは、リスク源を階層的に表示した図である。WBS(Work Breakdown Structure)やOBS(Organization Breakdown Structure)などと同じく、一番上のレベル(Level-0)には、プロジェクト・リスクの全体をおく。そしてその下に、第一階層、第二階層、と分解された要素が並んでいく。例を示そう。

この図では、第一階層に、「外部リスク」「技術リスク」「組織リスク」「プロジェクト・マネジメント・リスク」が並んでいる。そしてその下に、たとえば外部リスクなら「市場環境変化」などの要素がぶら下がる。リスク・アセスメントの参加者は、この図を見ながら、たとえば市場環境変化に起因して生じる、リスク事象を考えていくのである。

もちろん、この図がいつも正とは限らない。客観的リスクというものが存在せず、リスクはプロジェクト実行主体の目標設定に従うのだから、RBSは本当は、プロジェクトごとに作成するべきである。とはいえ、まあプロジェクト種類毎に、組織内にテンプレートくらいは持っているのが望ましい。

ちなみにRBSは、PMBOK Guideでは、どう説明されているだろうか。

ためしに、手元にある最新版のPMBOK Guide 第7版（2021年7月発行）を見ると、こう書かれている：

「潜在的なリスク源（Potential sources of risks）を階層的に表示した図」（拙訳、英語版P.187）

この説明は、Section 4 - Models, Methods and Artifactsの下、4.6.4「階層図」のところに、WBSやOBSなどと一緒に並んでいる。ただし、上記のワンセンテンスの説明があるだけで、図はついていない。ずいぶんそっけない扱いである。これだけ読んでも、プロマネたる読者は、どうしたら良いか分からないだろう。

（なお、すでにご承知の方も多いと思うが、プロジェクト・マネジメント分野の事実上の世界標準であったPMBOK Guideは、今回の第7版で抜本的な変革を行っている。本のメイン部分は”The Standard for Project Management”となり、PMBOK Guideは後半に追いやられ、10個のマネジメント知識エリアも消失している。この変化についてはいずれ項を改めて論じたい）

ところで、わたしはPMBOK Guide 第2版（2000年発行）をまだ持っていて、ときどき参照のためひっくり返す。というのも、第2版はコンパクトながら、ある意味モダンPM論のエッセンスを凝縮していて、分かりやすいからだ。・・ということを、実はわたしの勤務先で昔、学んだのである。

で、そのPMBOK Guide 第2版には、RBSそれ自体は登場しない。かわりに、リスク分類（Risk categories）という用語がある。説明は、こうである：

「プロジェクトに良きにつけ悪しきにつけ影響を与えるリスクは、洗い出して分類整理することが可能である。リスク分類は明確に定義し、当該産業や応用分野において共通するリスク源を反映していなければならない。」（英語版P. 131）

具体的には、こんな説明が続く。

・技術上、品質上、性能上のリスク — 未検証の技術や複雑な技術、非現実的な性能のゴール、利用している技術や業界標準に対するプロジェクト中の変更など

・プロジェクト・マネジメント・リスク — 時間やリソースの割当が不十分なこと、プロジェクト・プランの品質が不適切なこと、プロジェクト・マネジメント技法の乏しさ

・組織リスク — お互いに矛盾するコスト・時間・スコープの目標、プロジェクト間の優先順位付けの欠如、予算が不十分だったり中断すること、組織内で他のプロジェクトとリソースの取り合いが生じること

・外部リスク — 法律や規制などの変化、労働問題、オーナー側の優先順位付けの変化、カントリー・リスク、気候など。とくに不可抗力リスクとは、地震、洪水、内乱などで、リスク・マネジメントよりも危機管理（Disaster recovery）を必要とする。

（以上、拙訳）

お分かりの通り、ここにあげられている4種類の分類は、ほぼそのまま、上の図の第一階層に対応している。というか、図はPMBOK Guide 第3版以降に登場するRBSを参考に、少し改変して作成したからだ。第3版のRBSは、第2版の上述の説明を継承し、敷衍して作ったものになっている。

わたしが変えた部分は、第2階層以下である。というのも、上の説明は（そして第3版以降のRBSも）、何だか奇妙だからだ。

プロジェクトのリスクが、外部リスクと内部リスクに分かれる、というのは良い。内部リスクが、さらに技術・組織・PMに分かれるのも、まあ良いとしよう。しかし、技術リスクの下にある性能リスクというのは、リスクの発生源だろうか？　むしろ影響の及ぶ結果＝目標値の方ではないか（ちょうど「納期遅延リスク」のように）。非現実的な性能のゴールは、技術に起因するリスクだろうか？　ゴールを設定したのは自分たちなのだから、それはむしろ計画設定の不適切さ（つまりPM）に起因するはずではないか。

繰り返すが、RBSは単なるリスク分類ではない。リスク源の階層分類なのだ。だから技術に起因する要素としては、むしろ「複雑さ」（これが増えると不整合が生じやすくなる）、「サイズ」（大きすぎたり小さすぎたりすると困難性が増す）、「新規性」（技術の未成熟さを表す）などを置いたのである。

他の項目も同様である。外部リスクの「外部」とは、プロマネの計画やコントロールが及ばない範囲を指すはずだ。だとしたら、その中に、自分で選ぶはずのサプライヤーや下請け業者によるリスクが来るのは奇妙だ。もちろん、外部リスクの中に「不可抗力リスク」を置くのもおかしい。これは契約条件に依存するからだ（だから第3版からはなくなっている）・・

お分かりだろうか。RBSはある意味、単純なツールだ。だが、その単純なツールでさえ、論理的に詰めていくと、いろいろと奇妙な点が出てくる。それはなぜかというと、

　・リスクの発生場所（発生源）と、リスクが発現する所（結果）を区別する

　・ある事象がリスクかどうかは、プロジェクトの目標設定に依存する

という原則が十分理解されないまま、自分のなれたデフォルトのビジネス感覚を当てはめがちになるからだ。

そういう意味で、リスク・アセスメントできちんとリスクを洗い出すには、それなりのトレーニングが必要だということになる。だからこそ、前々回の記事でも紹介したように、わたし達の研究部会でも研修プログラムに組み入れることにしたのである。

現代のプロジェクト・マネジメント技法は、60年代の米国アポロ計画を通じて、非常に発展した。PMの用語のほとんどがカタカナ英語なのは、それに依るところが大きい。そして、アポロ11号についてリスクを考えるなら、未経験の環境における機材の故障・トラブル、人間の誤操作、機材の誤設計・製造不良、離着陸時の気象不良、そして未知の事象との遭遇などなど、いくらでもあげられるだろう。

だが、プロジェクトはつねに、新しい挑戦の要素を含む。だからプロジェクトを進める事とリスクをテイクする事は、表裏一体の関係にある。そこが、安全や知財やセキュリティのリスク・マネジメントと異なる点なのだ。プロジェクト遂行における最大のリスクは、機材の故障でも未知との遭遇でもない。リスクという概念を良く理解せずに、なんとなくプロジェクト計画を進めることなのである。

＜関連エントリ＞

「危険予知：プロジェクト・リーダーに必須の能力として（11月16/23日・PMセミナーのお知らせ）」 (2021-10-10)

「危機なんて、ほんとに管理できるのか？」 (2020-03-08)