|
プロジェクトには、有期性と独自性の2つの特徴がある。有期性とは、始まりと終わりがあり、期限が定まっていることである。独自性とは、毎回違う仕事を行うということである。後者の独自性が、プロジェクトにリスクをもたらす大きな原因となる。
人間は同じ仕事をしていれば、だんだんと工夫することを覚えるため、失敗するリスクはほとんどなくなる。これに対して、プロジェクトは毎回、何かしら新しい要素が入り込んでくるため、どうしても予期できない事象が発生し、リスクが発生する。
別のいい方をすれば、プロジェクトは「失敗して当たり前」という要素を含んでいるといえる。リスクマネジメントとは、プロジェクトという非常にハイリスクな仕事を、失敗なく遂行するための仕組みである。従って、プロジェクトにおいて、リスクマネジメントは必須の機能である。ところが、リスクマネジメントを難しいものだと考え、公式な形では取り組んでいない企業が、実際のところは多いのだ。
リスクマネジメントを行う手順は、PMBOKでは次のように定めている（図1）。
| リスク・マネジメント計画 |
| ↓ |
| リスク識別 |
| ↓ |
| 定性的リスク分析 |
| ↓ |
| 定量的リスク分析 |
| ↓ |
| リスク対応計画 |
| ↓ |
| リスクの監視・コントロール |
リスクマネジメントを行うには、まず、手順と具体的な内容を把握する必要がある。
| ポイント1 過去の問題からリスクをリストアップするリスク識別 | |||
リスクマネジメントを適切に行うためには、まずは、リスク識別を漏れなく行うことが重要である。ここで重大なリスクを洗い出せていないと、当然適切なリスク対応はできなくなる。
リスク識別の代表的なツールと技法は、ブレーンストーミングとチェックリストである。システム開発では、過去と類似の問題が発生することがよくある。過去に同じような失敗をしたにもかかわらず、また同じことを繰り返してしまうことが多い。リスク識別においては、まず、これらの過去の失敗をリストアップし、同じような失敗を繰り返さないよう、チェックリストに整理することが大切だ。このチェックリストを使用して、過去と同じような問題が発生する可能性をチェックすれば、かなり失敗を減らすことができる。
しかし、チェックリストには、重大な欠点がある。それは、過去に経験したことがないリスクに対しては、まったく役に立たないという点である。これをカバーするためには、専門家の助けが必要である。あまり経験がない分野のプロジェクトを行う場合は、その分野の専門家の助けを借りてブレーンストーミングを行い、想定されるリスクを漏れなく洗い出す努力をするとよい。
| ポイント2 各リスクに優先順位を付ける リスク分析 | |||
リスク識別でリスクを洗い出した後は、各リスクを分析し、それぞれのリスクの大きさを推定する必要がある。各リスクの優先順位を決めるのがその目的だ。すべてのリスクに対して、完璧な対応をするのはコスト的にもスケジュール的にも不可能である。リスクが大きい場合には厳重な対策を取る必要があるが、リスクが小さい場合には簡便な対策で済ませたり、対策を取らないこともある。
一般的にリスクの大きさは、発生確率と影響額の積で表される。従って、リスク分析は、各リスクについて発生確率と影響額を推定すればよい。しかし、この両者を定量的に推定することは難しい。そこで、発生確率と影響額を3段階または5段階で評価することが多い。この各段階に評点を付けて、各評点を乗じた結果で優先順位を決める。これを表にしたものが、下記のリスク等級マトリクスである（表1）。
| 影響度 → | 0.8 | 0.4 | 0.2 | 0.1 | 0.05 |
| ↓ 発生確率 | |||||
| 0.9 | 0.72 | 0.36 | 0.18 | 0.09 | 0.05 |
| 0.7 | 0.56 | 0.28 | 0.14 | 0.07 | 0.04 |
| 0.5 | 0.40 | 0.20 | 0.10 | 0.05 | 0.03 |
| 0.3 | 0.24 | 0.12 | 0.06 | 0.03 | 0.02 |
| 0.1 | 0.08 | 0.04 | 0.02 | 0.01 | 0.01 |
| ポイント3 各リスクへ対応する、4つのリスク対応計画 | |||
リスク分析が終わったら、各リスクについて対応策を考えることになる。マイナスのリスクの対応策には以下の4種類がある。これらは状況によって使い分ける必要がある。
（1）回避
「回避」とは、脅威を取り除いてリスクが発生しないようにすることである。最も有効な対策だが、実際には脅威を取り除ける場合が少ないので、どんなリスクでも選択できるわけではない。
（2）軽減
「軽減」とは、発生確率または影響度を下げることである。ほとんどのリスクに対して有効な方法だが、完全にリスクを取り除くことはできないので、許容レベルまでリスクが軽減できているのかを評価する必要がある。
（3）転嫁
「転嫁」とは、脅威を第三者に移転することである。具体的には、保険を掛けること、リスクのある作業を外注することが主な方法である。
（4）受容
「受容」とは、リスクを受け入れることである。リスクが小さくて受け入れても大きな被害が出ない場合や、ほかの方策を取ることが難しい場合に、取られる方法である。ほかの対策を取ることが難しいリスクの代表は、地震やテロである。この場合、事前の対策を取らない代わりに、リスクが発生した際、どのような対応を取るかを決めておくことが多い。この計画をコンティンジェンシー計画という。コンティンジェンシー計画を持つ受容を能動的受容、持たない受容を受動的受容という。
| ポイント4 リスクをジャンル分けするリスク区分 | |||
リスクの分類をリスク区分という。リスク識別で使用するチェックリストは、このリスク区分に従って作成される。このリスク区分は、いろいろな考え方があり、統一はされていない。だが、1つの基準としてPMBOKの9つのマネジメント対象領域をベースにする方法がある。具体的には、9つのマネジメント対象領域から統合とリスクの2つを外した7つの領域でリスク区分を考えることになる。
しかし、これだけでは不十分だ。PMBOKでは対象領域とはされていないが、大きなリスクとなるものに、顧客関連のリスクがある。顧客の体制が十分でないとか、顧客の意思決定者が明確でないなどの状態があると、プロジェクトは非常に大きなリスクを抱えてしまうことになる。
もう1つの大きなリスクとして技術面のリスクも指摘できる。これは、品質リスクの一部と考えることもできるが、システム開発においては、この技術面に関連するリスクが生じる可能性が非常に高い。そのため、この分野を別の区分にしておくことは、リスクマネジメントを適切に行ううえで有効と考えられる。
これらを総合して、リスク区分をまとめると次のようになる（表2）。
| 区分 | リスク例 |
| 顧客 | 顧客の情報リテラシーが低いため、システムが使いこなせない |
| スコープ | 顧客の要望が明確でないため、スコープが定まらない |
| タイム | 無理なスケジュールの要求がなされる |
| コスト | 必要な資金の手当てが付かない |
| 品質 | 品質基準が明確になっていない |
| 技術 | 新技術に対応できる人材がいない |
| 人的資源 | 健康状態が優れない人材がいる |
| コミュニケーション | モラルが低く報告ルールが守られない |
| 調達 | 技術水準を満たす調達先が見つからない |
この中で、技術リスクはさらにサブ区分にしておいた方が、より漏れなくリスクを洗い出すことができる。この区分の仕方を例示する（表3）。
| 区分 | リスク例 |
| 開発技術 | 採用した開発手法では、開発できないモジュールがある |
| 基盤技術 | 新たに採用したネットワーク基盤上で動かない機器がある |
| セキュリティ | セキュリティ対策が十分でないために、脆弱性が露呈する |
| インターフェイス | モジュール間のインターフェイスが明確になっていない |
| 性能と信頼性 | データベースへのアクセスが多く、レスポンスが悪くなる |
| ポイント5 新しい脅威への対応を求められるセキュリティリスク | |||
技術リスクの中でも、最近特に留意しなければならないのが、セキュリティリスクである。セキュリティへの考慮が不十分なシステムを構築してしまうと、運用後に重大なセキュリティ事故が発生し、多大な損害が発生しかねない。
セキュリティリスクについては次々と脅威が出てくることから、過去の経験だけに頼った対応では不十分なことが多い。従って、自社で作成したチェックリストだけでリスク識別を行うことは危険である。
そこでチェックリストとして候補に挙がるのが、「情報セキュリティ管理基準」や「ISO27001」などのセキュリティ標準である。ただし、これらの標準に規定されている項目数はかなり多いので、すべてをチェックすることは困難だ。プロジェクトマネジメントの観点では、セキュリティ標準の中からプロジェクトに該当しそうな項目のみをピックアップして使用する方が現実的であろう。
また、セキュリティ対策は、開発段階からシステムに組み込んでおかないといけないものと、運用段階で対応すればよいものの両方があるので、開発を対象にしたプロジェクトであれば前者を中心に対応すればよい。
| リスクマネジメントは難しくない | |||
リスクマネジメントは難しいものだと思っている人がまだまだ多いが、定量的リスク分析を行わなければ、難しいことは何もなく、すぐに実行できる。準備作業として必要なことは、リスク登録簿のフォーマットを決めることとチェックリストの準備ぐらいである。チェックリストの作成も、有識者を集めて1日議論すれば、ほとんどのリスク項目を洗い出すことができるはずである。
プロジェクトマネジメントで役に立つツールと技法は、フォーマットの決定や標準の設定などの作業にかなりの労力を必要とするものが多いが、リスクマネジメントに関するツールと技法はすぐに実行できるものがほとんどである。リスクマネジメントの考え方を学習していただき、それをすぐに実務に役立てて欲しい。それにより、間違いなくプロジェクトの失敗をかなり減らせるはずである。
提供：NECラーニング株式会社
産業技術大学院大学
情報セキュリティ大学院大学
企画：アイティメディア株式会社
制作：＠IT自分戦略研究所編集部
掲載内容有効期限：2008年12月31日
