リスク管理に取り組もう

(98/10/17 全面改訂)

▲▽ リスクとは ▽▲

 リスクとは、「問題」として発症する前の状態、あるいは発症の可能性のある事象ということができます。つまりこのまま放っておくと「問題」になる可能性のある事象です。「可能性」にはランクがあります。「確率」といってもいいでしょう。また「可能性」は時間と共に変化します。「ゴミ焼却場から出るダイオキシンが周囲の環境を汚染する」という事象は、すでに「問題」のレベルになってしまいました。つまり実際に起きてしまったわけです。これにたいして「環境ホルモンの影響で、将来国の人口が半減する」というのは、現時点では「リスク」の段階です。もちろん、これに対して何らの「事前の対応策」も講じなければ、何年かの後には「問題」となる可能性があります。そして「問題」となった場合は確実に「事後の対応」をしなければならないわけですが、その時は、取り返しがつかない事態に陥っていることも考えられます。

 この国は、世界から「危機管理能力」が問われる場面がしばしば起きています。日本海でのロシアのタンカー座礁による重油の漂着事故や、北朝鮮による「ミサイル事件」、エイズをまき散らす結果となった厚生省の血液製剤の事件などは、国のレベルでの「リスク」意識の欠如を物語っています。もっと身近な例では、遊園地のコースターの事故だとか、児童公園の滑り台の破損事故、学校の電動シャッターの事故などでも、リスク管理が行なわれていなかったことが伺えます。

 国の最高の「リスク管理」は「国防」です。残念ながら、この国では「国防」については殆ど議論されません。起きてはならないことについて、それが起きたときのことを議論できないのです。マスコミも含めてそこを避けて通っています。その副作用として一般的な「リスク管理」についても議論されることがありません。国家レベルの問題だけでなく、事業のレベルにおいても、リスク管理が殆どできていません。

 このような「リスク」に対する感覚は、企業のレベルだけでなく、ソフトウェアの開発組織のレベルにおいても伝染するのは避けられないことです。実際、ソフトウェアの開発組織のプロジェクトリーダーが、自分の管轄する範囲でプロジェクトのリスク・リストを作成したとしても、おそらく周囲から「何もそこまで考えなくても・・・」という反応が返ってくることは想像に難くありません。その前に、とのようなリストが作れないかもしれません。

▲▽ リスクはどこにあるか? ▽▲

 どうやらこの国では、リスクというものが分かっていないのではないかと思われます。リスクが「どこ」にあるのか分かっていない。その証拠に、リスク・リストを作るように指示すると、リスクを一生懸命?に探そうとします。そうして書かれたリストには、的外れなものや強引にリスクに仕立て上げたものなどが半分以上混じってきます。

 リスクは、「約束」や「基準」というものがあって、それを守ろうとする意識があれば見えてきます。リスクが見つからないとすれば、それは強く「約束」しているものが無い証拠です。“実現すればいいけど”という意識では、リスクは見えてこないのです。納期を約束しようとするから、それが達成できない危険(リスク)を探すわけです。評価部門に対してバグの件数を何件以内と約束しているからこそ、それを妨げる事象(リスク)を探すわけです。

 “まともな設計書を書いている時間がないから”といって設計書を書くプロセスを省いたり、“どこを修正したか記録している時間がない”“それをレビューしている時間がない”ということで、いわゆる変更制御を省くしかないという時に、品質に関する強い「約束」が無ければ、実現しない可能性に対して何の歯止めも存在しないことになります。

 約束は、このように顧客に対するものだけではありません。例えば、今回のプロジェクトに合わせてドキュメントを整備しようとか、チームとしてレビューの技術を身に付けようというような内的な「約束」も同じです。実現に対して強く意識することで、その約束を実現しない危険(リスク)というものが見えてくるわけです。逆に、約束、基準、目標などが存在しないところでは、リスク管理は成立しないのです。

▲▽ スケジュールから見えるもの ▽▲

 たとえば、ソフトウェアの開発組織のマネージャーとして約束しているものは何かということです。その約束していることを表現するものがあれば、そこから簡単にリスクを見つけることができます。

 納期や期日に対するリスクを見つけたいと思えば、期日が明確に表現されたスケジュールを書くことです。「このモジュールをいつまでに結合テスト可能な状態に仕上げる」という目標が明確に示され、さらに、そのための具体的な取り組み(作業)が明示されているようなスケジュールを見れば、予定の日に仕上げられない可能性は簡単に見えてきます。そこで「Bさんの作業」の遅延が直接影響することが分かれば、そこに「リスクの要因」が見えてきます。もちろん、この場合「Bさんが予定に日に完成しない」という要因は、さらに別の要因、例えば「C++が初めて」という要因、の結果という事も考えられますが、それは比較的簡単に気づくことです。

 一方、コストや見積金額に対するリスクを見つけたいと思えば、積算の根拠が具体的に細かく示されたものを書くことで、その中で、予定を外しそうな項目が見えてきます。さらに、その項目が予定を外す際の要因、例えば、IC相場がひっ迫しているという、も見えてきます。

 「リスクリスト」が書けないのは、多くの場合、このような「リスク」をイメージさせてくれる「もの」が書かれていないことが原因です。その「もの」が、約束を強く意識したものであればあるほど、リスクは見えやすくなります。PERT図も、それに替わるようなスケジュールも書かないで、納期に関するリスクを考えようとすることじたい、適当ではないのです。

▲▽ 「role」と「commitment」 ▽▲ 

 「約束」を見出しやすくするために、もう少し別の角度からみることにします。

 人には、それぞれ「役割」というものがあります。会社の中には、「社長」や「部長」「プロジェクト.リーダー」「開発エンジニア」などという役割があります。国という単位にも「首相」「・・大臣」「厚生省の課長」などが、その役割を現す名称です。家庭の中にも、「父親」「母親」という役割があります。

 「役割」は「role」ですが、「role」には「commitment」がセットで付いています。「commitment」を伴わない「role」というのは、舞台などの演技の中にしかありません。舞台や映画の「役割」としての「首相」には、「首相」としての「role 」は存在しても、「首相」としての「commitment」は存在しません。そこにあるのは「役者」「演技者」としての「commitment」です。このように、自分の「役割」に付随している「commitment」を意識すれば、「約束」は見えてきます。

 「社長」には、株主に対する「commitment」だけでなく、社員や顧客、更には社会や環境に対する「commitment」が存在します。だからこそその「commitment」を果せない可能性を「リスク」として抽出し、その要因がリスクに作用しないように対応策を講じ、監視するのです。ソフトウェアのエンジニアにも、その「役割」に応じた「commitment」が存在します。自分の担当部分を、求められる品質とコストを実現しながら、所定の期日までに仕上げることです。この「commitment」の障害になる要素を「リスク要因」として認識しなければなりません。

 リーダーぐらいになると、今までと違った「commitment」が付いてきます。それは「人を育てる」という「commitment」です。組織は継続を前提としています。自分が出来るだけでなく、次の人も出来るように育てるか、その仕組みを作らなければなりません。この種の「commitment」は、殆どの組織において忘れられています。だから、日本の組織は、年々その機能を低下させているのです。企業のトップは、部下がそのように後継者を育てない可能性をリスクとして追跡しなければなりません。この「commitment」も忘れられているのです。

 一国の「首相」には、国民の生命財産を守るという最高の「commitment」の他に、諸外国に対して自国の地位をおとしめないという「commitment」もあります。同じ役割であっても、「commitment」は時代と共に変化します。あるいはその実現方法が変化します。明治維新の時の、国民の生命財産を守るという「commitment」は、産業を育成し国力を高めることで実現したのですが、今日では、その方法では必ずしも不十分であり、時には弊害さえ生じてしまいます。

 今日、我が国では、多くの人は「role」を演じているだけのように思います。毎日、「社長」という「role」、「部長」という「role」、学校の「先生」という「role」、「父親」という「role」を演じているだけで、それぞれの「role」に付随している「commitment」は、何処かに置き忘れているのではないでしょうか。そうでなければ、今日の状態の説明が付かないのです。全く「commitment」を忘れているということはないとしても、それを実現することに対して、わずかな障害を前にして引き下がってしまうような「commitment」なら、意識していないのと同じです。

 「commitment」を明確に、そして正しく意識しない限り、適確な「リスク管理」は実現しませんし、懸念される事態は、全て「発症」してしまいます。起きると分かっていて防げないほど、馬鹿げたことはありません。そこには「人間としての叡知」が感じられないからです。

▲▽ 事後処理 ▽▲

 リスク管理の裏側にあるのが「事後処理」です。つまり、リスクとして適切に対応されなかったために問題として発症した後の対応です。もちろん、リスク管理の中で、事前に表面化(問題化)した際の対応方法を考えておく必要があります。いわゆる「最悪の場合」というもので、幾つかの発症パターンが想定され、それぞれに対してどのように対応するかということを予め定めておくわけです。もちろん、その最悪のケースが現実のものとならないための手立ては尽くさなければなりません。

 神戸の地震の後で「危機管理」という言葉が氾濫しました。しかしながら相手が地震だけに、これを発生(表面化)させない方法というのはありませんので、事が起きたときの対応しか想定できません。そのようなところに「危機管理」という言葉を充てたということは、この国には、「リスク」の概念が存在していないことの証でもあります。今後も、「危機管理」という日本語が、「リスク管理」という意味で使われるとすれば、正しい意味での「リスク管理」は、この国では望めない可能性があります。

 事後処理にはコストが掛かってしまいます。エラーのコストは、その発見段階によって100倍ものコストが掛かってしまうというIBMの調査結果が公表されています。今の作業を中断したり、リワークが発生するわけですから時間も取られてしまいます。そして中断された方のプロジェクトの納期にも影響します。場合によってはそれだけでは済みません。企業イメージを損ねたり、時には1回の失敗で事業から撤退せざるを得なくなります。

 数年前に、大和銀行米国支店で債権の不正取引が発覚し、しかも監督機関への報告が遅れたことで、大和銀行は目の飛び出るような賠償金を払わされ、その上米国から追い出されてしまいました。これは完全なリスク管理の不備が招いた結果です。この場合の事後処理というのは、まさに撤退作業になってしまった分けです。これでもまだ、「リスク管理」が分かったかどうか

 ソフトウェアの開発組織での事後処理というのは、評価部門で発見されたバグの対応や、納期を延長したあとの対応などに相当します。中には運用段階に入ってのバグもあるでしょうが、ある程度、謝罪や保証などを絡めて対応しているのが現状でしょうが、そのような「事後処理」に慣れてしまった人がマネージメントの立場に立ったとき、一体何が起きるか想像してみて下さい。適切な事前の判断が為されない状態で、メンバー全員が事後処理に振り回される様子は、容易に想像できるところです。これなどは確実に経営レベルでの「リスク管理」の項目です。

▲▽ 開発組織におけるリスクの種類 ▽▲

 こにように、リスクは強い「約束」の存在するところに必ず存在します。経営者には、顧客(全体)に対する約束、株主に対する約束、従業員に対する約束、ときには社会に対する約束などがあります。管理者には、そこからブレークダウンされた事業目標に対する約束、個々の顧客に対する約束、従業員(の成長)に対する約束などがあるはずです。

 またそれぞれの職種に応じて「リスク」はあるはずです。営業部門にも、約束を違える危険(リスク)が考えられます。今の御時世ですから、外注先の業者が突然消滅してしまうリスクもあるでしょう。その危険性を感じれば、信用調査など必要な手を講じなければなりません。危険が高いとなれば、早めに業者を入れ換えるか、信用調査会社と契約してリアルタイムの情報収集で対応することも考えられます。もちろんそれに掛かるコストも無視するわけにはいきません。「仕事は約束」である以上、職種を問わずリスクは存在するはずです。

 ちなみに、ソフトウェア開発の世界におけるリスクには大きく分けて、「プロジェクト・リスク」と「ソフトウェア・リスク」の2つがあります。前者は主に、プロジェクトの管理者(マネージャー)の立場で考えるリスクで、後者は、実際に開発するエンジニアの立場で考えるリスクです。もちろん、一緒に考えてもいいのですが、リスクを管理する際に、20も30もリスクの状況変化を追跡しているわけには行きません。実際に追跡できるのはせいぜい10個程度です。特に、個々のエンジニアには、その人の能力や経験などで一人ひとり違ったリスクが存在します。このようにソフトウェア開発の世界にはリスクが多く存在しますので、そうなると全体で10個では、リスクの発症を防げないのです。

 そこでソフトウェア開発にかかるリスクを、それを分担するであろう立場にあわせて「プロジェクト・リスク」と「ソフトウェア・リスク」(担当者別)に分けることによって、それぞれ10個の範囲でカバーしようというわけです。

▲▽ プロジェクト・リスク ▽▲

 プロジェクトレベルのリスクというのは、一つのプロジェクト単位のリスクです。その中で個々のエンジニアの分担が、途中のマイルストーンに対してどの程度の遅れが発生しようと、プロジェクト全体としての約束に対してどのようなリスクがあるかということです。いいかえれば、マネージャーのレベルでのリスクアイテムです。

 例えば、人の遣り繰りが当初の目論見どおりに行かないために納期が間に合わないリスク、途中で人事異動によってチームの編成が変わってしまい、品質の統制がとれなくなってしまうリスク、チームのメンバーが自己を主張しあってチームプレーができず、テスト期間が延びてしまうリスク、ツールが上手く使えず予算を途中で使い果たしてしまう危険、メンバーのスキルの不足に気付かすに不適切にアサインしてしまい、納期を外すリスクなどが考えられます。

 また、新しくCMMに取り組むことになったプロジェクトであったり、今回のプロジェクトで作業フローや標準を変更した場合や、新しい分析・設計手法を取り入れた場合なども、それによって組織に混乱が生じるリスクがあるわけです。これらは全て、納期や品質、性能などの約束を違えるリスクのある項目で、個々のエンジニアの管理範囲を超えるものです。

▲▽ ソフトウェア・リスク ▽▲

 これに対して、個々のエンジニアのレベルでも約束していることがある以上、そのレベルにおいてもリスクは存在します。自分の担当する範囲が初めてのテーマであったり、使用する言語や搭載されるOSが初めてであったり、そこで求められているアルゴリズムが十分理解できていなかったり、そのような短い期間で開発に取り掛かるのが初めてという場合など、各自のレベルでの納期、あるいは設定されているマイルストーンに間に合わない事態が発生する可能性が、ここでの対象となります。

 この領域のリスクは、ほとんどの場合、「初めて」というところから発生しますので、むしろ「新規性」という視点から捉えたほうが分かり易いものです。この点については別のページに触れていますので、そちらに譲ります(CMMとリスク管理)。

▲▽ マネージャーとリスク管理 ▽▲

 マネージャーにとって適切なリスク管理能力を備えていることが不可欠であるという理由は沢山あります。たとえばAさんはこの4月の人事異動でソフトウェアを開発する立場からマネージャーに変わったとします。そこでプロジェクト全体の仕上がりに対して責任(約束)を負うことになりますが、彼にとって今までと違って自分が開発しないこと自体が、すでにリスクアイテムになる可能性があります。全てのマネージャーにとって必ずしもそうではありませんが、ほとんどの場合、自分が直接作らないことはリスクになるはずです。また、相手がコンピュータから人間に変わる事もリスクアイテムになります。そのことによって、自分に課せられた「約束」を違える危険があるわけです。

 また、マネージャーとしての責任範囲が広くなるにつれて、自分の専門領域外の部分が増えてきます。かっては、ソフトウェア・モジュールの完成に責任をもって対応すればよかったのに、今は、ハードの領域やマーケティングの領域まで、責任範囲が広がっています。自分は「ソフトェア出身」だからといって、それ以外の領域は得意ではないというわけには行きません。かといって、今からその分野の専門家になるには制約が多すぎます。そのような状況に合って、自分に課せられた「commitment」を果たすためには、「リスク管理」は欠かせません

 言い換えれば、マネージャーの仕事は、その責任範囲が広くなるほどリスク管理に尽きる言っても過言ではありません。マネージャーがプロジェクト・リスクを適切に管理し、問題として顕在化させないような事前の対応をすることによって、はじめて「約束」が果せるのです。また、そのために適切なマネージメント技術を習得するのです。

▲▽ リスク管理の不在 ▽▲

 しかしながら、現実にはこのようなリスク管理が殆ど行なわれていません。個々のエンジニアのレベルはもちろん、マネージャーのレベルにおいても、全くといって言いほど、リスク管理は存在していません。そんなことを考えている時間が惜しいとでも言うように、リスク管理は脇に追いやられています。その結果何が起きるかは言うまでもありません。手配をミスしたり、追加の要求を考えずに作業を進めたために、大きくリワークを招いてしまったり、初めてのテーマが重くて、ある担当者の分担が仕上がってこなかったりするのです。当然、そのあとは“やっつけ仕事”になり、皆でプログラムの切り張り作業が始まります。こうしてプログラムはいじり回され、どこが何の理由で修正されたのか、その記録はどこにも残っていないという状態になるのです。そしてこのことがさらに、次回の保守開発時に、予定通りに作業を進行させることに対するリスク要因となります。

 そのような組織には、工程管理も変更制御もスケジュール管理も存在しません。ただ、動かしてみてバグが見えなくなる迄作業が繰り返されるだけです。あとどれだけの時間で終わるのか全く予想がつかないわけで、まるでプログラムに聞いてくれ、という状態になります。

 これらはリスク管理という「プロセス」を省いたために起きた事態なのですが、関係者は、そのことに気付くよりも「現象」を叩くことに精一杯なのです。もちろん、最初の約束は守れません。おそらく約束した殆どの項目において約束は守れないでしょう。それが「部品」であったり、OEM開発であったりすれば、致命的な結果を招きかねません。これからは場合によっては訴訟にまで発展する可能性があります。

▲▽ 経営者の能力が問われる ▽▲

 最近、日本の経営者の能力が問われるような場面がしばしば起きています。世界の経済がグローバル化することは、90年の初めには予想できた筈です。つまり、その時点で「グローバル化することで・・・」というキーワードで幾つかのリスクアイテムが考えられたはずです。さらには、そこから派生して経済が停滞するリスクも、銀行が金貸し業に行き詰まるリスクも、たとえ高い確率で予想できなかったとしても、リスクアイテムとして考慮されなければならないものです。経営者なら、多くの株主の資金を預かっている以上、そのようなリスクの中で、株主に利益を還元するという約束は課せられているのですから。

 「6シグマ」も、90年には確立していたわけで、世界を相手にビジネスをしているのなら、その動向には十分注意し、状況に応じて適切な行動を取れるように備えておかなければなりません。でも日本の企業はどこも本気で対応しませんした。三菱重工が96年ごろからことごとく「ABB社」に入札で負けるようになったが、それは「ABB社」が1993年にシックスシグマの2人の教祖を招聘した時から始まっているのです。その結果、「ABB社」は94年から4年連続で「欧州No.1の優良企業」という認定を受けています。少なくとも重工はこの時点で気付かなければならなかったのです。

 この問題は、何も三菱重工に限ったことではありません。No.1 になろうという約束や、投資家に対する約束などがなければ、あるいはそれを達成しようという意思がなければ、競争相手の動きをチェックする事もないでしょう。ましてや、No.1 になることを妨げる要因など、考えることもないでしょう。でも、これでは経営者としての資質がとわれることは言うまでもありません。

 98年に入って、ソニーがようやく本格的にシックスシグマに取り掛かったところですが、他の企業は、まだ様子見の状態です。いったい、これらの企業の経営者は、何に対して約束し、責任を負っているというのでしょうか。

▲▽ 将来への危惧 ▽▲

 このような風潮は、意外と早く組織の末端まで行き渡るものです。トップが経営上のリスクを考慮していないということは、それぞれの部署の責任者が、そのレベルでリスクを考えないことを許すことに繋がります。そしてこの構図がそのまま末端まで同時並行で行き渡るわけです。こうして、誰もリスクについて考えていない組織が簡単に出来上がってしまいます。そこでは、すべてが事後処理で対応されることになります。もちろんコストは高く付くわけです。日本では上場企業といえども営業利益が数%に止まっている背景に、意外とこのような高コスト体質があるのではないかと思われます。

 そしてこの問題は、もっと大きな問題へと発展する可能性が高いのです。組織の中では、入社以来、1度も「リスク管理」というものに取り組んだことのない人が「管理職」に就いている可能性があります。それも決して少なくないし、結構「上」の方にも居るのではないかと思われます。

 最近の不景気で、企業のリストラの対象になっている年代層が2層あります。1層は20代の若者で、彼らは十分な技術を持ちあわせていないため、今から教育するよりは経験者、熟練者を採用する、あるいは残すという選択肢のなかで職を失っているのです。

 もう1層は、40代以上の中高年層で、こちらの方はマネージャーとしてのスキルが問われているのです。すでに述べたように。「リスク管理」は、それを起点にしていろいろなマネージメント・スキルに繋がっています。見方を変えれば、工程管理も品質保証も、チーム・マネージメントも、全てが「リスク」を発症させないための手立てであるという捉え方もできるのです。逆にいうと、「リスク管理」について何も考えていない状態では、あらゆるマネージメント・スキルを手に入れる動機が失われることになります。

 今日、企業を取り巻く状況の変化が激しいことは言うまでもありません。ベンツとクライスラーが合併するなんて、正直言って誰も予想しなかった事が起きてしまうのです(三菱自工の経営幹部も蚊帳の外だったようです)。彼らは、21世紀に株主などに対する約束をどう果すかという観点から合併という選択肢を選んだのでしょう。もし何もしなければ競合他社に事業の機会を奪われ、経営者としての約束が果せないリスクを感じたのでしょう。これが世界の経営者なのです。

 これが出来る管理職がリストラにあうはずがないのです。よしんば社内の政治的な要因でリストラに遭ったとしても、拾う神は現れてくるものです。世間は盲ではありません。“これは!”と思う人は、どこかで見られているものです。だが残念ながらそのようなスキルを身に付けていないとすれば、21世紀の市場の要求に対して、いったいどのようにして応えるというのでしょうか。「接待が禁止されては営業がやりにくい」というようは次元が低すぎます。

 そしてこれは中高年だけの問題ではないのです。組織の中で誰もリスク管理が出来ないということは、その企業の将来が危険であるということになります。次々とビンチヒッターを繰り出しても、誰もリスク管理ができず、全ての施策が後手を踏むことになるでしょう。そのために膨大なコストがかかってしまい、事業は行き詰まるでしょう。組織をあげて「リスク管理」に取り組まなければ、早晩、このような状態に陥ることになるでしょう。

 残念ながら、このままでは、21世紀に日本の企業は総崩れです。社会主義の世界でもないかぎり、リスク管理も出来ないマネージャーや経営者が活躍できる「場」があるとは思えないのです。日本という場を世界に解放する以上、勝ち残れる要素は一体どこにあるというのでしょう。地方の企業と言えども、「6シグマ」で武装したアジアの企業と、その製品がまともに競合するのです。

 欧米の企業は、その生産拠点としてのアジアをしっかり掴んでいます。アジア経済の再度の揺さぶりで最もダメージを受けるのは日本です。そうしてもたついている間に、完成された「6シグマ」手法が欧米系の企業を中心に広がるでしょう。タイの動きを見ていると、そのしたたかさを感じざるを得ません。



「Index of Manager の為の講座」に戻る