システム開発が予定通りに進むことはまずないので、プロジェクトのリスク管理はとても重要です。
リスク管理ができているプロジェクトは円滑に進みやすいですし、できていないプロジェクトはちょっとしたトラブルがダイレクトに進捗遅れや品質悪化につながります。
リスク管理は簡単なコツさえつかめば難しいものではありません。
今回はリスク管理の基本的な考え方についてご紹介します。
「リスク」って何だ？
そもそも、「リスク」とはなんでしょうか？
リスクとは不確実性のことです。
「宝くじがあたる"かもしれない"」「交通事故に遭う"かもしれない"」というのは、どちらもリスクになります。
予想よりも良い結果になることを「上振れリスク」、悪い結果になることを「下振れリスク」と言います。
プロジェクト管理では、基本的にスケジュールの遅れや品質悪化を招く「下振れリスク」を扱います。
確実に起こる未来は「リスク」ではない
ここで注意が一つあります。
確実に起こると予測できる未来は、どんなに悪い内容であってもリスクではありません。
例えば「高層ビルの屋上から落ちたら死ぬ」というのは誰もが想定する結果です。
「高層ビルの屋上から落ちたら死ぬ"かもしれない"」とは普通は考えません。
このようなものはリスク管理の対象にはなりません。
結果が分かっているのですから「屋上に近づかない」など、事前に対策を講じておけば良いのです。
リスク管理のやり方
それでは、プロジェクトにおけるリスク管理について説明します。
リスク管理は次の手順で進めます。
- リスクを洗い出す
- 発生確率とプロジェクトへの影響度を検討する
- 対策を検討する
- トリガーポイントを決める
1. リスクを洗い出す
まずプロジェクトにはどんなリスクが潜んでいるかを洗い出します。
今までどういう要因で進捗遅れが出たか、などを思い返しながら書き出しましょう。
ただし、どうにもならない要因は無視する
過去の経験から探るといっても、どうにもできない出来事があります。
例えば東日本大震災は多くの方が影響を受けた事例ですが、「大規模地震が発生しプロジェクトの継続が困難になる」というのは管理すべきリスクでしょうか？
無視できない課題ですが、これはプロジェクト以前に会社の存亡に関わる問題です。
プロジェクトリーダーの裁量でどうにかできるレベルを超えているため、こういう課題はプロジェクトで扱うべきではありません。
それは会社のリスク管理（防災戦略）として取り組んでもらいましょう。
部課長レベルで解決可能なレベルが適切
管理対象とするリスクは、自分でどうにかできるか、または直属の上司に相談して解決できるレベルあたりが適切です。
具体例を紹介します。
- 顧客からの仕様変更依頼が多く、要件が固まらない
- メンバーの病欠で機能の実装が遅れる
- メンバーのスキルが想定よりも低く、進捗が遅れる
- メンバーのスキルが想定よりも低く、不具合が多発する
- 初めて使う技術の理解に時間がかかり、進捗が遅れる
- 初めて使う技術の理解不足で、想定外の作業が多く発生する
- 委託先の成果物の品質が悪く、デバッグに時間がかかる
リスクの多くは品質と時間の課題です。
どのようなリスクが発生すると品質が悪くなるか、時間が足りなくなるかといった観点で考えてみるのがおすすめです。
2. 発生確率とプロジェクトへの影響度を検討する
多くのリスクが洗い出せたら、リスクに優先順位をつけ、重点的に監視するリスクを決めていきます。
そのための作業が、発生確率とプロジェクト影響度の検討です。
リスクの内容によりますが、基本的には大・中・小の3段階で分類すれば十分です。
発生確率とプロジェクト影響度の組み合わせて、対策の優先度を決めていきます。
発生確率が低くても発生時の影響が大きいのであれば、優先度「高」。
発生確率、プロジェクト影響度ともに小さいものであれば無視できるので優先度「低」のように設定します。
以下が早見表です。
| 発生確率 | 影響度 | 優先度 |
|---|---|---|
| 大 | 大 | 高 |
| 大 | 中 | 高 |
| 大 | 小 | 中 |
| 中 | 大 | 高 |
| 中 | 中 | 中 |
| 中 | 小 | 中 |
| 小 | 大 | 高 |
| 小 | 中 | 中 |
| 小 | 小 | 小 |
3. 対策を検討する
優先度が決まったら、「予防策」と「発生時対策」を検討します。
予防策はリスクを発生させない施策、発生時対策はリスクが発生してしまった場合の対応方針です。
決定した優先度によって、以下の通り対策検討します。
- 優先度「高」：予防策と発生時対策を検討する
- 優先度「中」：発生時対策を検討する
- 優先度「小」：無視
4. トリガーポイントを決める
優先度「中」以上のリスクについて、発生時対策の実行タイミング（トリガーポイント）を設定します。
進捗会議などでこのトリガーポイントを定期的にチェックし、トリガーが引かれていたら対応策を実施するわけです。
トリガーポイントは具体的な数値で設定しましょう。
タイミングを間違えずに対策を打てます。
リスクを共有する
リスク管理シートが完成したら、プロジェクトメンバーや上司、クライアントなどの関係者に共有しましょう。
「このプロジェクトにはこういうリスクがあるから気をつけようね」ということを周知し、協力体制を作ります。
リスクの予防に全員が気をつけてくれるようになりますし、発生した場合も対応策を実行しやすくなります。
クライアントまで巻き込めると完璧ですね。
リスクは定期的にチェックすること
プロジェクトが始まったら、リスク管理シートを定期的にチェックします。
最低でも月一くらいで見直すと良いと思います。
トリガーが発火してないか確認すると合わせ、新たなリスクが発生していないかもチェックします。
新たなリスクは上述の手順に従い、予防策、対応策、トリガーポイントを記載します。
リスク管理はプロジェクトを円滑に進めるための有効な手段
出来る限り分かりやすく、具体的に書いてみたつもりですが、いかがでしたでしょうか？
リスク管理を行うことで適切なリスクコントロールができるようになり、マネジメントがやりやすくなります。
なによりリスク管理シートの作成は、プロマネする上での思考整理に役立ちます。
私が使っているリスク管理シートを置いておきますので、よろしければご活用ください。