リスク管理についての一考察
▼ リスク管理に取り組もうプロジェクトを大きく崩すものとして、多くの場合、リスクへの対応のまずさ、あるいはリスクに適切に対応しなかったことが挙げられます。「リスク管理」という言葉自体は、すでに一般化して“日常的に”使われていますので、そこにいる人たちは、今更「リスクって、何をすることなの？」とは聞けないかも知れません。つまり、「リスク」や「リスク管理」という言葉は知っている、でも、それって何をすることかは知らない。言い換えれば、このような状態でプロジェクトが進められているのです。
日本の組織においては、その「任に必要なスキル」を持たない状態で、その役に就いているということは、日常茶飯事です。たとえば、「ソフトウェア・エンジニア（ＳＥ）」といっても、ソフトウェア・エンジニアリングにつてまともに勉強した人は少ないと思います。たしかに、ソースコードは書けます。そして顧客が要求する機能を、なんとか実現することもできます。でも、そこには品質は織り込まれていません。そうして作られたソフトウェアをベースに、企業は製品を展開しようというのです。この状態を、日本の組織は許しているのです。
こうした“不足”はＳＥだけの話しではありません。マネージメントについても、スキル不足のままに任に就く傾向は著しいものがあります。単に、その前のエンジニアの経験年数に依存していたり、中には年齢によって、“そろそろマネージャーの役に付いてもらわないと”という“もらわないと論法”で辞令がでたりすることも少なくないようです。
私は、これを「役所式人事」と読んでいます。確かに、年数を積み上げることで「管理」ができる職場もあります。でも私の知っているソフトウェア開発の世界は違います。マネージメントの仕事は、単にＳＥの仕事の延長線ではないのです。そのため、プロジェクトの計画書は書けないし、要求仕様の適否も判断できず、リスク管理もメンバーのスケジュール管理もできません。揚げ句は、「それはマネージャーの仕事ではない」と言い出す始末です。当然、この論法は、責任を部下に押し付ける方向に繋がっていきます。「権限の委譲」という便利な言葉を持ってくるマネージャーもいます。このような状況が起きているのに、会社存亡のリスクと認識できないトップが多いのです。
トップが「リスク」を認識していない以上、組織の誰もリスクを認識していなくても違和感は無いでしょう。たしかに、マネージャーとしては、立場上、「リスク管理ってどうすればいいの？」とは、周囲の人に気軽に聞けないのかも知れません。それなら独習すべきです。今や「リスク管理」のスキル抜きで、マネージメントは勤まらないのです。
「リスク管理」については、文献がないわけではありません。でも、そこではリスクの評価や、取り組みの優先度の判断などに重点が置かれていたり、リスクの事例は沢山かかれているものの、それはどのような観点で抽出すれば良いのかということには触れていなかったりします。第一、そこで挙げられている事例も、私に言わせれば、適切なものではありません。そのため、周囲の人でこの種の文献を読んだ人に聞いても、実際にはどうやってリスクを抽出すればよいのか、良く分からないという返事が返ってきます。もちろん、実際に取り組まれていません。
私の経験では、リスク管理にはもっと簡単に取り組むことができます。リスクの抽出も難しくありません。ここでは、「リスクの意味」をもう一度理解し直していただき、そこから、リスクの抽出の仕方や、軽減措置の考え方などを説明することにします。ただ、私の時間の都合から、一気に掲載するのではなく、何回かに分けて原稿が溜まったところで掲載するようにします。また、世の中で起きた社会問題で、リスク管理の不在が原因と思われるケースや、リスク管理で防ぐことが出来たのではないかと思われることがあれば、それも、ここに取り上げてみたいと思います。
なお、リスクの表現のテクニックには、私の「要求と要求仕様」の構成を持ち込みますので、手元に、「Software People vol.4」の特集記事『要求の仕様化入門』があれば、時々読み直して頂けると理解しやすいかと思います。
▼ 心配するだけでは意味がない何度か納期の期日を延長してもらって、７０余りの機能テストの方は何とか目処が付いたというので、いよいよ機能を連動させた性能の確認試験に入ったとたん、「何でこんなに反応が遅いのだ！、ということもしばしば起きています。大手銀行のシステム統合の失敗も、これに近いものがあるようです。
このような事態がまったく予想されていなかったのかと言うと、そうではありません。多くの場合、現場のリーダーは、早い段階でこういうことが起きる可能性があることに気付いています。でも、彼は、全体の一部を担当するチームのリーダーにすぎなかったり、その懸念を表現する仕組み（や場）が無かったりして、対策に必要な行動がとられなかったために、後で問題が表面化し、大きな損害を被るのです。私の知るかぎりでも、こうした事態は何度も繰り返されています。人が入れ替わっては、また同じ失敗を繰り返すのです。
多くのソフトウェアの開発現場では、「リスク」の存在を感じていながら、結局は、リスクを 問題化させないための有効な手が打たれることないまま、リスクの襲撃を受けてしまうのです。ある意味では「マーフィーの法則」にはまってしまうと言えるのかもしれません。わかっていたのに、防ぐことができないというのは、悲しいことです。それを繰り返しているというのは、情けないことです。
「今度は大丈夫だろうか」「この体制だと、また、前回と同じようなことが起きるのではないだろうか」と心配するだけでは、何も役に立ちません。心配は、それを防ぐための工夫に変えなければ意味がありません。その工夫のところに「リスク管理」を持ち込むのも、一つの方法です。
「リスク管理」を簡単に言ってしまえば、責任ある人にとって何が心配なのかを明らかにして（リスクの抽出と表現）、その心配をできるだけ早い段階で消滅させる方法（回避措置と軽減措置）を講じ、誰も知らないうちに心配の種を絶やしてしまう（リスクの消滅）ことです。最高のリスク管理が行われた時は、どのような危険があったのか、それを取り除くために誰がどのように動いたのかを、ほとんどの人は気付いていない状態なのです。これこそが、リスク管理の“快感”なのです。
その意味では「心配」は「リスク管理」のネタであり、心配することは「リスクのアンテナ」なのです。アンテナの感度が鈍い人には、リスク管理は無理かも知れません。「なんとかなるさ」の世界とは違うのです。
▼ リスクとは
最初に、「リスクとは何か」というところに触れておくことにします。リスクとは、「問題」（起きて欲しくないこと）として発症する前（直前と言う意味ではない）の状態、あるいは発症の可能性のある事柄ということができます。つまり、まだ「問題」にはなっていないが、問題に発展する要因が存在するので、このまま放っておくと「問題になる」可能性のある事象です。
「問題になる」ということは、その時点で予定外のリソースの投入を余儀なくされたり、またまた「ファイアーマン（火消し役）」の出動を要請したり、納期に間に合わせるために当初の機能をドロップ（直前トレードオフ）したり、納期の延期を求めて依頼者と交渉に入ったり、場合によっては補償問題になってしまったりすることを意味しています。エンジニアが過労で倒れてしまうことも考えられます。簡単にいってしまえばお金がかかってしまう状態になることです。
もちろん、このような事が起きれば、組織にとって大きなダメージとなります。後追いの費用はかかるでしょうし、顧客を失うかも知れません。市場からの撤退（追放？）もありえるでしょう。でも、初期のころには懸念される事象はあっても、結果として問題にならなければ、これらのコストはかからないし（軽減措置を講じるために僅かな費用はかかるかも知れませんが）、このことで組織も存亡の危機に直面することはありません。逆に、リスクを克服したことで、チャンスや大きな成果を手にする可能性もあるのです。
日本の組織においては「リスク」の感覚はマヒしているとしか言い様がありません。ブリジストンの工場火災や、先の、原発の配管の破裂事故など、相次ぐ企業の不祥事は、そのことを証明しています。９０年代以降、リスク管理を「体で覚えた人」がいなくなったことで、この傾向は顕著になっているようです。「２００７年問題」は、リスク管理の面からも、日本の企業組織にとって最大のリスク要因（一般には“危機”と用語が使われます）と言えるかも知れません。
中でも、ソフトウェアの開発組織においては、まったくと言っていいほど「リスク管理」とは無縁の状態です。実際、ソフトウェアの開発組織のプロジェクト・リーダーが、「リスク管理」について勉強して、自分の関係する範囲でプロジェクトの「リスクリスト」を作成したとしても、おそらく周囲から「何もそこまで考えなくても・・・」という反応が返ってくるのです。いや、それよりも、上司からは「弱気な奴」と受け止められたり、「最初から出来なかったときの言いわけをしている」と受け取られることの方が多いと思われます。
実際、プロジェクトのリーダーが、ほとんど成功しないと思われたプロジェクトで、「リスク管理」を取り入れたことで、いくつものの困難（危険）を表面化させることなくプロジェクトを完成させた例を発表しても、その組織の誰も（特に上級の管理者たち）、そこで見事に展開された「リスク管理」のことには興味を示さななかった例もあるのです。彼らの頭にあるのは、「出来て当たり前」なのです。「褒める文化」を持たない組織では、これがオチなのです。
このリーダーには、日本に於ても今に、あなたが手に入れた技術が必要になる時代が来るから、誰からも評価されなくても、黙って「リスク管理」の腕を磨くように、とアドバイスしたのです。
ところで、リスクが問題になる「可能性」にはランクがあります。発症の「確率」と言えるかも知れません。また発症の「可能性」は時間と共に変化します。
「アジアの製造業の台頭で部品市場がひっ迫して、来春からの生産開始に支障を来す可能性がある」
というリスクは、アジアのメーカーの動きや、部品メーカーの生産能力の変化、部品の市況の変化によって、このリスクの発症の可能性も変化します。部品メーカーの火災事故などがあると、一気に「調達できないリスク」の発症の可能性が高まります。したがって、リスク管理にはリスク要因の「追跡」が不可欠です。リスクには「期限」というものもあります。その「期限」を過ぎれば、問題になっているか、発症せずにリスクとしての「寿命」を迎えることになります。「試験機材の調達が遅れると、結合テストに入れない可能性がある」というリスクは、解消できてもできなくても「結合テスト」の時期が期限になります。そのため、リスクの「期限」は対応の優先度にも影響を与えます。
▼ “危機管理”との違い
リスク・マネージメントは、問題が発症しないようにするもので、事前の対応に価値があるのです。しかしながら、日本では「リスク・マネージメント」が「危機管理」と訳されたとき、事前対応から事後対応にすり替わったように思われます。
日本の「危機管理」が機能しない理由の一つは、「危機管理」という言葉を、阪神淡路の地震の際に使ったことです。あの地震の後、政府から日本中の企業に（従業員の数が一定数以上？）対して、地震に対する「危機管理マニュアル」の作成が求められました。そこでは、地震が発生したとき、あるいは発生の可能性を政府が宣言したときの行動をまとめることが求められています。つまり、「事後対応マニュアル」です。阪神淡路の地震の後のこうした政府の対応よって、日本では「危機管理」が「事後対応」として認識が定着したと考えています。同時に、ソフトウェアの開発現場においては、「危機管理」と言う言葉が「場違い」な響きを持つようになったのです。
大きな地震の発生が避けられない状況で、地震から「国民の生命と財産を守ろう」というのであれば、最高のリスク管理は、危険地域に住まないように誘導することです。“そんなアホな”と思うかも知れませんが、アメリカでは、フロリダ半島を襲った巨大なハリケーンに対して「危険地帯」が指定され、そこでの居住が禁止されました（現在、湿生公園になっているはず）。そこに住んでいた人たちは強制的に移住することとなったのです。この判断は、このような大規模のハリケーンの襲来が１００年に１回の確率で起きると言う研究結果を受けたものです。見事なリスク管理です。これは「事後対応」ではないのです。
ソフトウェアの開発組織での事後対応というのは、客先や評価部門で発見されたバグの対応や、納期を延長したあとの対応などに相当します。中には運用段階に入ってのバグもあるでしょう。「ファイアーマン」の登場も事後対応です。そこでは、ある程度、謝罪や保証などを絡めて対応しているのが現状でしょうが、そのような「事後対応」に慣れてしまった人がマネージメントの立場に立ったとき、いったい何が起きるか想像してみて下さい。適切な事前の対応が為されない状態で、メンバー全員が事後対応に振り回される様子は、容易に想像できるところです。そして、これが「現実」なのです。
この「現実」が常態化していることは、確実に経営レベルでの「リスク」です。つまり、そのような人がマネージメントに就いていることが、組織存亡のリスクであり、企業のトップの責任なのです。
ところで、そのような企業に投資している株主は、そこにあるリスクを認識しているかどうか。先頃、三菱自動車の経営再建に絡んで株式を７億４０００万株取得したフェニックス・キャピタルが、即日、ＪＰモルガンに貸し出したのは、この株を保有し続けることのリスクに対応したものと思われる。（もっとも、ェニックス・キャピタルが三菱に７００億円余りを出資する際には、保有し続けることと必要な資金を自己資金で賄うことを公言していたと思うので、今後、この対応が問題になるかも知れません）
▼ 危機管理の３つの要素前節で、日本の「危機管理」が「リスク管理」と違っていることに触れましたが、もう少し詳しく説明します。
日本で使われている「危機管理」の中には、次の３つの“危機”が含まれています。
１）Risk Management
２）Crisis Management
３）Emergency Management
これらは、問題の発生の状況がことなります。「Risk Management」は、問題が発症する前に、その要因を消してしまうことです。そのため、そのような問題があったことは、一部の人しか認識していないかも知れません。これに対して「Crisis Management」とは、問題の発症を中心にした「前後」の範囲での対応に当たります（Crisis には峠の意味がある）。リスクの対応として事前に消してしまうことが無理な段階に入ったとこから、問題が発症したことに伴う「初期対応」のところまでが、その範囲です。９月１日の「防災会議」は「Crisis」すなわち、大規模地震の発生が避けることができない状況での「meeting」です。
これに対して、「Emergency Management」は、問題が発生した後の対応になります。ホテルなどの「避難口」は、「Emergency Exit」です。したがって、単に、“火災の危険がある”というだけで、この扉を開けることは禁じられています。政府の「危機管理対策室」は、通常は鍵がかかっているはずで、大災害などの事態の発生を受けて電源が入るようになっていますので、「Emergency」に相当します。
実際、政府のＨＰを覗いてみて下さい。そこにある「危機管理」という用語をサーチしてみればわかります。いろんな場面で「危機管理」という言葉が出てきます。そのほとんどが、「Risk」ではなく「Emergency」の場面で使われています。中には、年末の中小企業向けの資金繰りを円滑にするための金融機関への指示にも、「危機管理」という言葉が使われています。これは「Crisis」と思われます。「Emergency」では、すでに倒産状態になっていますので、意味はありませんから。
このように、日本では政府の曖昧な使い方から、「リスク管理」が「危機管理」にすり替わってしまい、しかも「危機管理」＝「事後対応」として認識されているのです。このままでは、まともな「リスク管理」が為されない可能性が高くなりますので、私としては、「危機管理」という言葉は、少なくともソフトウェア開発の現場には持ち込まないように注意しているところです。
「Index of Manager の為の講座」に戻る