こんにちはエンジニアリングマネージャーをしております植田です。4月18日にグロースプランの提供が開始されました。今回この開発プロジェクトにて「リスク管理」に取り組んでみたのでそのお話をします。
Index
- リスク管理に取り組んだ背景
- そもそもリスク管理とは
- 具体的なリスク管理の進め方
- リスク管理はどのようなプロジェクトで実行すべきか
- 実際にどのように取り組んだか
- 取り組んで良かったことと、今後発展させたいこと
リスク管理に取り組んだ背景
まず今回なぜリスク管理に取り組んだかをお話します。BASEでは現在大小様々な開発プロジェクトが同時進行していますが、日に日にその複雑性は増しています。年月を追うごとに積み重なる仕様、日に日に拡大していくリポジトリ（ソースコード群）…と、複雑性・難易度は増す一方です。その中で、開発プロジェクトもいわゆる「不確実性が高い」と言われることが当たり前の状況になっています。不確実性とはつまりリスクのことです。この不確実性・リスクに立ち向かうにはリスク管理を行っていくことが有効な手段であると自身の経験から考えました。冒頭に触れたグロースプランプロジェクトは 「ミッションクリティカルなプロジェクト」 であったこと、「複数のチームからメンバーが集まり横断的に開発するタスクフォース型のプロジェクト」 であったこと、という点でリスク管理をするにはもってこいのプロジェクトであると考え、関係者に呼びかけリスク管理に取り組んでみることとなりました。 なお、私自身はPMBOKをベースとしてリスク管理を学びましたので、もしご興味がある方はPMBOKの書籍等もあわせてご覧いただけると嬉しいです。
そもそもリスク管理とは
リスク管理とは、プロジェクトにおける潜在的なリスクを洗い出し、リスクが顕在化しないように先手を打つプロジェクト管理手法の1つです。また、仮にリスクが顕在化してしまった時のためにあらかじめ対処を決めておくことで問題の影響を最小限に抑える行為です。リスク管理を行うことで、問題を防ぐことができ、また問題に発展した場合も即座の対応が先回りしてできるため、言わば転ばぬ先の杖として機能することができます。プロジェクトマネジメントの格言として 「リスクを制する者はプロジェクトを制す」 といった言葉があるほどリスク管理は重要なプロセスですのでぜひご参考いただきたいです。
具体的なリスク管理の進め方
具体的なリスク管理表を見て頂いたほうが理解しやすいので下記のサンプル表をご覧ください。
※サンプルのためグロースプランプロジェクトの内容とは関連ありません
このようなリスク管理簿を作成し運用していきます。サンプルのためシンプル化していますが、実際には、起票者、起票日、備考欄など管理上必要だと思う項目は適宜追加ください。
続いて実際の進め方、サイクルについて解説します。
こちらの図のように1週間程度のサイクルで「リスクの特定→対策の立案→対策の実行→モニタリング」を繰り返すのが基本です。
①リスクの特定と優先順位付け
プロジェクトのキックオフが開始されたあとはできるだけ早期にリスク特定のための会議を開きましょう。リスクはプロジェクトが開始された時点から潜在的に存在するものでプロジェクトの脅威となるものです。1日でも早くリスクを特定し対策を実行することでプロジェクトの成功確度が高まります。1〜2時間ほど関係者にてリストアップを行いましょう。
リスクが洗い出せたあとは、リスクに対して優先順位を決めていきます。仮にリスクの洗い出しを行って20件のリスクがリストアップされたとしても、愚直にリストの上から順番にすべて対処をするのは効率的ではありません。発生確率と影響度合いを決定し、それらをかけ合わせた上で優先度を決定し、優先度が高いものから対処を検討していきましょう。なお、発生確率と影響度合いは3段階で決定しますが、こちらは当事者で相談して決定すればある程度感覚値であっても問題ありません。優先度が決まればよいので、この数値に厳密性は必要ありません。
②リスクへの対応戦略（対策の立案）
リスクには「リスクが顕在化しないようにする事前対策」を実行しモニタリングすることが有効な手段です。リスクへの対応戦略は以下の4種類に大別されます。
| 種類 | 説明 |
|---|---|
| 回避 | リスクを避けたり、リスクの発生原因を取り除いたり、リスクの影響を避ける為にプロジェクトの計画を変更すること |
| 転嫁 | リスクの影響を責任とともに第三者へ移転すること |
| 軽減 | リスクの発生確率および影響度をプロジェクトが許容できる程度まで低減すること |
| 受容 | 事前対策を講じないと決めること、リスクの除去が困難な場合や、万が一リスクが顕在化しても大きな影響を及ぼさないときに採択される |
これらをリスクごとの基本方針としプロジェクトメンバーと共に検討し、対応策を決定していきます。優先度の高いリスクへの対策に関しては第三者や上位層へレビューしてもらうことでより有効な対応策にブラッシュアップしていくこともできます。リスク管理を繰り返していくことで、対策を考えるコツも掴めてきますので、当事者でどんどんアイデアを出し合ってよりよい対策を立案していけるといいですね。
③対策の実行
リスクのリストアップ、優先順位付け、対策が決まれば、優先順位の高いリスクから1つずつ対策を実行していきましょう。担当者（担当チーム）、対応期日を決めきちんと対応していくことでプロジェクトが実を結びます。
④モニタリング
実行プランができあがり対策が順次開始されたあとは ”モニタリング” が重要となってきます。新たなリスクが生まれていないか、既存リスクが問題となって顕在化してこないか、リスクが顕在化した場合はすぐに課題の対策を実行する、といった動き出しが必要です。なお、プロジェクトが終了する時期にリスクをすべて解消・解決している必要はありません。優先度が低いもの、リリースに特段の影響を及ぼさないものは無理に解消する必要はありませんので、現実とも向き合いながらモニタリングしていきましょう。
リスク管理はどのようなプロジェクトで実行すべきか
リスク管理が有効だからといって、動いているすべてのプロジェクトで実行する必要はないでしょう。ではどんなプロジェクトで活用すればよいかですが、例えば以下のような項目にあてはまるプロジェクトではリスク管理の適用を検討してみると良いと考えていますのでご参考ください。
- 期間的：3ヶ月以上かかるようなプロジェクト
- 技術的：技術的に難しい、新しい技術を導入するなど
- 人的：リソースが不安定、新規の顔ぶれ、ステークホルダーが多いなど
- その他：イレギュラー要素があるなど
実際にどのように取り組んだか
今回はトライアルでグロースプランプロジェクトにて取り組んでみたので、まずは関係するマネージャー数名で始めてみました。以下は具体的な経過です。
- 1回目（1時間）：初回はまず想定されるリスクをみんなでリストアップし、結果20件ほどのリスクが洗い出されました。この日は発生確率と影響度合まで相談し優先度を決定しました。
- 2回目（1時間）：翌週の2回目は優先度9〜6までのものに対してリスクの対策を検討しました。時間があればすべての対策を考えてもよいのですが限られた時間を有効活用し優先度の高いものにフォーカスして対策を決定しました。
- 3回目（1時間）：さらに翌週の3回目は優先度9〜6までのリスクの対策の進捗確認と、優先度6未満の対策を検討しました。
- 4回目以降は基本的にリスクの対策の進捗確認がメインとなり、プロジェクトがリリースされるまで毎週30分程度集まりました。
大事なことはリスクの対策が進むに従い、それぞれのリスクのステータスを未着手→対応中→モニタリング→クローズ、と変更していくことだと思っています。こうすることで、プロジェクトにおけるリスク管理が進捗していることがステータスの遷移と共に把握できます。 今回は1週間に1度の頻度でリスク管理定例を開催しましたが、開催頻度は現場で相談の上決定いただければよいかと思います。また、今回のプロジェクトは3ヶ月程度の期間でしたので、リスク管理定例も合計10回程度開かれたのが実績となります。
取り組んで良かったことと、今後発展させたいこと
取り組んで良かったこと
- 20件程度のリスクがリストアップされ、リスク顕在化の抑制が出来たり、リスクが顕在化したときにあらかじめ想定した通りの対処が実行されたこと
- リスク管理が実施されていなければ、問題が発生してから慌てて解決に動いていたであろう事象が複数あったこと
- ステークホルダーに対してプロジェクトにおけるリスクの件数を定量的にレポートできたこと
- 今回初めて取り組んだマネージャーからリスク管理終盤に「やってよかったですね」と率直な感想をもらえたこと
今後発展させたいこと
- 開発チームメンバーとともにリスク管理に取り組みたい
- 今回はトライアルだったこともありまずマネージャーのみでリスク管理に取り組みましたが、開発プロジェクトのリスクを一番知っているのは開発に向き合っているメンバーだと思いますので、ぜひ今後はマネージャーとメンバーが一緒になってリスク管理をやっていけたらと思っています。
- リスク管理の横展開
- 今後少しずつ社内で横展開を行いリスク管理をしているプロジェクトを増やしていきたいと考えています。
以上がBASEでリスク管理に取り組んだお話です。ぜひ皆様もリスク管理に挑戦いただけると嬉しいです。
