リスクについて
今回はプロジェクトマネジメントにおいて最も経験がものを言う領域、リスクについて考えていきたいと思います。リスクはプロジェクトが炎上する可能性を軽減するために非常に重要です。ですが、慣れていないとおざなりにしてしまう領域でもあります。
かく言う私もある程度プロジェクトの数をこなすまでは苦手な領域でした。私の経験も踏まえつつ分かりやすい形で解説するよう頑張りますので、最後まで読んでいただければと思います。
サンプルプロジェクトに対して、PMBOKの5つのプロセスに沿った形で解説していきます。今回は（３）計画｜リスクです。
リスク・マネジメントの計画
「リスク・マネジメント」という文字面から難しそうな印象を受けますが、やるべきことはそこまで難しくはありません。リスク・マネジメント計画は以下のような事柄を計画しておけばいいと思います。
- リスクを管理するフローの可視化
- リスクカテゴリの定義
- リスク評価基準の定義
- リスクの管理方法の定義
それぞれを詳しく見ていきましょう。
1. リスクを管理するフローの可視化
リスク管理の全体像を定義しておきます。例えばこんな感じです。
ここで明らかにしたリスクはプロジェクトリリース前に最終確認することをお勧めします。
2. リスクカテゴリの定義
リスクカテゴリは会社で統一的な基準を定義しているケースもあります。その場合は定義されている基準を用いるといいでしょう。今回のサンプルプロジェクトに合わせて以下のようなリスクカテゴリを定義しました。
- 財務リスク
- オペレーショナルリスク
- リーガルリスク
- レピテーション（風評被害）リスク
- システムリスク
- 内部システムリスク
- 外部システムリスク
- データ連携リスク
- その他システムリスク
3. リスク評価基準の定義
社内基準がある場合は利用します。サンプルプロジェクト用に発生頻度、影響度、継続期間を軸に基準を定義しました。参考にしてみてください。
| カテゴリ | 基準値 | 内容 | 判断基準 |
|---|---|---|---|
| 発生頻度 | 5 | 1年で48回以上（週に1回以上） | 13.15% |
| 4 | 1年で12回以上（月に1回以上） | 3.29% | |
| 3 | 1年で6回程度（2ヶ月に1回程度） | 1.64% | |
| 2 | 1年で1回以上2回未満（半年に1回程度） | 0.55% | |
| 1 | 1年で1回未満（年に1回未満） | 0.27% | |
| 影響度（影響を受けるユーザー） | 5 | 全ユーザー（ログイン・未ログイン問わず） | 50万人 |
| 4 | ログインユーザーの50%以上100%未満 | 25万人〜50万人未満 | |
| 3 | ログインユーザーの30%以上50%未満 | 15万人〜25万人未満 | |
| 2 | ログインユーザーの10%以上30%未満 | 5万人〜15万人未満 | |
| 1 | ログインユーザーの10%未満 | 5万人未満 | |
| 発生継続期間（復旧に必要な時間） | 5 | 復旧に24時間以上必要 | 24時間以上 |
| 4 | 復旧に8時間以上24時間未満が必要 | 8〜24時間未満 | |
| 3 | 復旧に3時間以上8時間未満が必要 | 3〜8時間未満 | |
| 2 | 復旧に1時間以上3時間未満が必要 | 1〜3時間未満 | |
| 1 | 復旧に1時間未満が必要 | 1時間未満 |
これを元に以下の計算式でリスクを定量化します。リスク評価は以下の式で定量化します。
リスク評価 = （発生頻度 x 発生継続期間）x 影響度
定量化した数値を更に判定して以下のような基準を定義することもあります。
- リスク評価値が10以下のものは無条件で受容することとする。
- リスク評価値が10以上15未満のものはプロジェクトオーナーの判断により受容することを可とする。
- プロジェクトオーナーが受容判断で否とした場合、リスク対策を必須とする。
- リスク評価値が15以上のものは対応方針を定義し、リスク評価値が15未満になるまで対策を検討する。
4. リスクの管理方法の定義
リスクを管理する方針は以下の4つしかありません。それぞれ確認しましょう。
軽減
基本的に取られるリスク管理の方針がこれです。見えているリスクの量を減らしたり、影響度合いを引き下げたりするために、何らかの対策を取ります。例えばこんな感じです。
- レコメンドAPIがエラーを返してきた場合、以下の対策を行う。
- レコメンドは表示しないようにし、UI崩れによるUXの低下を防ぐ。
- slackにalert情報をPOSTし、運営チームがこれをモニタリングする。
- 運営チームはalertが10分間連続でPOSTされたらマーケティングチームリーダーに電話連絡を入れる。
- マーケティングチームリーダーは連絡を受けたら相手先に問い合わせの一報を連絡する。
- 以上の対策によりレコメンドAPIのエラーリスクを軽減する。
回避
あまり取られる方針ではありませんが、単純に表現すればこんな感じです。
- 調査の結果、このビジネスモデルはリーガルリスク（違法性）が高い
- このプロジェクトを中止ししてリスクを回避する
- 自社の企画に対して、大手競合他社が同じようなビジネスモデルで近々参入予定と判明した
- このプロジェクトを中止してリスクを回避する
転嫁
これは軽減の次に取られることが多い方針です。リスクを転嫁する場合は基本的にコストを払う必要があります。例えばこんな感じです。
- 自社でのサーバー運用において現状の管理だけで手一杯なので、このプロジェクトで利用するサーバーの管理ができない
- クラウドを用いてサーバー運用をクラウドサービス提供者にリスク転嫁してしまう
- 自社のリソースが不足しているため、運用フェーズでの適切な運用に不安がある
- 外部委託業者で専門性がある業者に依頼して運用を任せることにより、リスクを転嫁する
受容
影響や可能性が軽微と思われるリスクに対して取られる方針が受容です。例えばこんな感じです。
- 実装期間が短期間であることにより、技術負債が発生するリスク
- 現状の体制（コードレビューや自動テスト、QA）によってある程度カバー可能と考える。よって受容する
リスクの特定
この3つは実際にサンプルを見てもらった方がわかりやすいと思いますので、まとめて紹介します。これらももちろんプロジェクトマネージャーが作成するのではなく、プロジェクトメンバーを巻き込んで作成するのが良いでしょう。
収集した要求事項を元にリスクを洗い出していきます。その際に「リスクをピックアップしてください」と言われても具体的にどうすればいいのかをイメージすることは難しいと思います。なので「このプロジェクトを進めるにあたって心配な点や気になってる点を挙げてください」といった形でプロジェクトメンバー全員でリストアップしていくやり方が良いと思います。
その際にリスクカテゴリなどが明確に決まっていると書きやすくなります。リスクカテゴリの定義やリスク評価基準の定義がしっかりとなされていればプロジェクトメンバーも参加しやすくなります。
リスクの定性・定量的分析
リスクの定性・定量的分析については主幹となる部門の方にヒアリングしながらプロジェクトマネージャーが記載する方法と、リスクを記載したプロジェクトメンバーに記載してもらう方法が考えられます。リスク評価基準がある程度わかりやすく明確に定義されている場合はプロジェクトメンバーに記載してもらう方法が良いと思います。
リスク対策の計画
リスク対策に関しては各部門の専門性がリスク対策の記載に必要なケースが多いため、主幹部門のメンバーに記載してもらう方が良いと思います。また、対策を記載した後にその対策によってどの程度リスクが減ったかを再評価しておくと尚良いと思います。
最後に
いかがだったでしょうか。リスクと聞くとあたかも悪いことであるかのように聞こえるかもしれませんが、リスクを洗い出し、マネジメントすることは必ずあなたの助けになると思います。プロジェクトの終盤で思いもよらぬ手戻りになる一番の原因は考慮していなかったリスクの顕在化だからです。
私がお手本にしたプロジェクトマネージャーの方が、以前「リスクを制するものはプロジェクトを制すッ！」と冗談混じりに言っていました。当時は「ふーん。そうなんだ」くらいにしか思いませんでしが、いつくものプロジェクトを経験するにつれ本質をついた言葉だったんだなと感じるようになりました。
宣伝
株式会社WAPでは「日本企業が世界と戦うための伴走型リーダー育成」をミッションに掲げています。この困難なミッションに共に立ち向かってくれるプロジェクトマネージャーを募集しています。ちょっと気になったので話を聞いてみたい！という方も大歓迎です。Meetyにてお気軽にお申し込みください。
