リスク感度分析

	プロセス１３：プロジェクトマネジメントノベルアクティビティ１４：リスク感度分析
◆前回までのあらすじ　３１５プロジェクトチームでは、リスクの洗い出しを終え、それぞれのリスクをリスクマトリクスを使って定性的に評価する作業を終えた。次の会議では、リスクの詳細を確定し、リスク対策を検討することになっている。 ◆船田からの指令　次の会議は翌日開催された。この日は船田は所用のため出席できず、とりあえず、曽田が肩書きのとおり、プロジェクトマネージャーの代行をすることになっている。曽田は、船田から、感度分析が勝負なので、徹底的に行うように言われていた。その代わりに、アステックからは木村が参加していた。ＲＴ－ＸＰプロジェクトのプロジェクトマネージャーである。 ◆上司がいないと議論が活性化する！？　船田がいないせいか、会議はこれまでより少しリラックスした雰囲気だったが、その雰囲気を破るように、冒頭から曽田は、「みなさん如何でしょうか？昨日、船田ＰＭの方からの宿題になったリスクの詳細記述書はできましたでしょうか」と切り出した。全員、下を向いた。仕方ないといった顔で、曽田は個別に指名を始めた。「青柳さん、如何でしょうか」「ええ、昨日、あの後で、リスクマトリクスの中で、重要だと認識されたリスクについては分析をして、詳細記述書を作ってきましたが、すべてはちょっと時間の関係もあったので、できていません」青柳をフォローするように、これまでの会議であまりしゃべらなかった守村が発言をした。「私もすべては作っていません。私も昨日の最後に船田さんがリスクマトリクスを作られたのは、重要なリスクのみを抽出するためだと思っていました。しかし、よく考えてみると、重要なリスクって何なんでしょうね。私はダメージが大きいリスクについてのリスク記述票を作ってきましたが、青柳さんの発言を聞いていて、これでいいのかと、ふと、疑問に感じました。青柳さんはどのようなものを重要なリスクだと考えましたか」 ◆どのようなリスクが重要なのか「私の場合にはダメージが大きくて、なおかつ、発生頻度が高いものを重要なリスクだと考えました。その結果、　・アステック社の十分な協力が得られない　・ＯＳの機能・性能が不十分　・自動車側の操縦性のコンセプトが技術的に実現できない　・自動車側の操縦性のコンセプトが途中で変更になるといったようなリスクを取り上げて、リスク記述書を作成しました」と青柳が答える。守村はうなづきながら青柳の発言を聞いていた。木村は、苦笑いしながら、最初のリスクは発生確率は０に近いと力説した。そこに、杉本がよく分からないという顔で話に首を突っ込んできた。「よくわからないんだけど、影響が大きいものが重要なリスクなんでしょうか？船田さんがいればすぐに分かるかもしれないけどね。例えば、関東に大地震が起こって、ホンダが新車開発を見合わせるというのはリスクだと思うんですが、こんなリスクなんて考え出すときりがないし、そもそも、考える必要がないじゃないですか」「そもそも、影響が大きいとか、小さいとかいうけど、おそらく、今回は納期が最優先のプロジェクトで、コストはある程度のブレが許されることになると思うけど、同じ影響と言っても、納期に影響があるのと、コストに影響があるのではぜんぜん、意味が違うんじゃないかな」と野村も参入。船田がいないと議論も盛り上がるようである。曽田は船田から「リスクの議論はフリーディスカッションをさせて、リスクについて身にしみて分かるようにしよう」というアドバイスを受けており、口をださないようにしていた。逆に議論を発散させるように、発生確率というのはリスク事象にかかわるものだが、影響度というのは結果にかかわるものではないかと指摘した。 ◆リスクの大きさを測る近藤も負けじと発言した。「賭け事にオッズってあるだろ。あれと同じなんじゃないか。重要という言葉はあいまいだけど、結局、期待値としてどれだけの影響が期待できるかというのを考えれば、はっきりするんじゃない」といって、ホワイトボードに　リスクの大きさ＝発生確率×影響の大きさと書き、「結局、このように考えたときに、リスクの大きさというのを影響度の指標にすればいいんじゃないかな」と続けた。守村は手を大きく肯き「私も近藤さんの言われるのが分かりやすいと思います。とすれば、結局、影響度と発生頻度の両方が大きいものが重要だということになりますね。つまり、「発生頻度は大きいけど、影響が極端に小さいもの」や、「壊滅的な影響があるけど、万に一つも発生確率がないもの」はあまり重要なリスクではないことになります。また、発生頻度も、影響度もそれなりに大きいものが、リスクの大きさも大きく、重要性も高いということになりますね」なんとなく議論が決着した感じになり、曽田が、進行を試みた。「では、一応、近藤さんの定義で、みなさんの書いてきたリスク記述票を発表して貰えますか、まず、青柳さん、いいでしょうか」と青柳を指名した。「じゃあ、ご指名にお答えして。木村さんがアステックは十分な支援をしてくださるということなので、これはないとして、「ＯＳの機能・性能が不十分」というリスクのリスク票をかいていますので、発表します。プロジェクターに移していいですか」とマイＰＣをプロジェクタに接続して映し出した。 ◆リスク詳細記述書リスク詳細記述書 ■リスクカテゴリー：調達リスク ■リスク事象：ＯＳの機能・性能が不十分 ■リスクの根本原因：・リアルタイムＯＳの調査不足・アプリケーション側のアーキテクチャー設計に問題がある・リアルタイムＯＳの機能を十分に活用できない ■リスク発生の結果：・当初計画していた性能が出ない ■リスク発生の兆候・アプリケーションの基本設計がうまくできない・詳細設計がうまくできない・ＯＳの特性が理解できない ■リスク発生の予想タイミング・システムテストとなっていた。以下、同じように、それぞれのリーダーが主要リスクについて発表をした。一通り終わったところで、曽田が全員に対して「今のところ、そんなところでしょうか。これからリスクの感度分析をしたいと思いますので、それを踏まえて、改めて考えてもらうといいんじゃないかと思います」 ◆リスク感度分析　リスク感度分析というのは、リスクの原因になっていることが、コスト、品質などに対してどのような影響を与えるかを定量的に評価する手法である。今回のリーダーのほとんどは、はじめての経験であるので、曽田は一つの例をとって説明を始めた。「青柳さんのＯＳの機能・性能が不十分というリスクを例にとって考えましょうか。このリスクの原因だと指摘されているのは・リアルタイムＯＳの調査不足・アプリケーション側のアーキテクチャー設計に問題がある・リアルタイムＯＳの機能を十分に活用できないの３つです。それぞれについて、コスト、タイム、品質などのプロジェクトのマネジメント対象（パラメータ）に対して、どのような影響を与えるかを議論してみます。最終的には影響を数字にしたいわけですが、いきなり数字にするとエイヤーになるので、最初に影響を言葉で書いてみましょう。青柳さん、私が書きますので、言って貰えますか。この３つの中でもっとも可能性が大きいのはどれでしょうか」とホワイトボードに向かった。「リアルタイムＯＳの機能を十分に活用できないという問題について考えて見ますね」・コスト　（空欄）・タイム　プロジェクトスケジュールに盛り込まれていない作業の発生・品質　制御系の性能不足・スコープ　プロジェクト全体のスコープとの整合性が無くなる・人的資源　調整作業に余計な手間をとられる・調達　代替の調達を考えなくてはならなくなる・コミュニケーション　（空欄）と書いていき、曽田に、影響があるかどうかが分からない部分があるのだがどうすればよいかと尋ねた。曽田は、青柳の質問の答えをみんなに向けていった。「いいですよ、当然、すべての原因が、すべてのマネジメント対象に影響を与えるということはないわけですから、青柳さんのように空欄のままでいいわけです。じゃあ、ここに数字を書いてみてもらえますか、青柳さん」・タイム　作業時間３０％増・品質　性能２０％不足・スコープ　－・人的資源　要員数１５％増・調達　調達準備時間４０％増と書いて「こんなところですかね」といった。「みなさん、だいたい、要領は分かりましたか？分かったら、各自、先ほどの大きいリスクに対して、感度分析をしてみてもらえますか？よく分からない方はもう一度、個別に説明しますので、私に遠慮なく言ってくださいね」（次回に続く）（２００４．９．１６号より抜粋）
購入はこちら