前置き

社内勉強会で使った資料を転換しました。
IPA的なプロジェクト管理でのリスク管理についてまとめています。

できるだけ一般的な用語を使って、実現できる範囲での方法論に抑えたつもりです。

IPA的なプロジェクトマネジメント

プロジェクトとは

独自の製品やサービスを創造するために実施される有期性の業務
(繰り返し行う定常業務とは区別されます)

プロジェクトの目的とプロジェクト管理の関係

プロジェクトの目的	プロジェクト管理
要求された品質の	品質管理
成果物を	スコープ管理(変更管理など)
予算内で	コスト管理
定められた期間までに	タイム管理
完成させること	リスク管理

ざっくりいえば、 QCDS が決まっている、管理するということです。
Quality (品質)
Cost (コスト)
Delivery (納期)
Scope(スコープ)

上記以外にも、ステークホルダや複数メンバがいることから、以下も管理対象となります。

人的資源管理
コミュニケーション管理
ステークホルダ管理
調達管理

今回はこれらの中で「リスク管理」について深掘りします。

リスク管理

リスクとは

もし発生したらプロジェクト目標にプラスもしくはマイナスの影響をもたらす不確定な事象または状態です。
不確定つまりまだ起こっていないというのがミソです。

	顕現していない	顕現している
原因・要因が分かる	リスク	課題(対処可能)
原因・要因が分からない	未知	問題(対処方法が不明)

リスクへの向き合い方として、基本的な方針は以下になります。

未知の領域を減らしたい
起こり得るマイナスの影響を減らしたい
起こり得るプラスの影響を増やしたい

リスクは、プラスの影響も含みますが、リスク管理においては対象外とするのが基本です。
(マイナスをゼロに近づける方が重要なので)

リスク管理の大まかな流れ

プロジェクトの始めに、どんなリスクがあるか、どんな対策ができるかを考えます。

リスクの特定
リスク分析
リスク対応計画
リスクのモニタリング、コントロール

PM試験では各工程の手法も出てきますが、リスク管理専任でもないとそこまで習熟して取り扱えない(し私も試験勉強でしか知らない)ため、ここでは取り上げません。
代わりに、項目と例を記載していきます。

1. リスクの特定

下記のような情報をもとに洗い出します。

プロジェクトの特性
- 未確定な要件が多い
- 納期を変えられない
関わる人(ステークホルダー、メンバ)の特性
- 承認者が多い
- 複数案件を担当しており、ミーティングを設定しづらい
プロジェクト全体で蓄積した知見
- 失敗しやすい観点などをまとめたもの(いわゆるチェックリスト)
- (陳腐化・形骸化していることもままある)
観点となるキーワードや各自の知識・経験
- 有識者への協力・レビュー依頼
- (スキルとも言えるし、属人的とも言える)

たいていの場合、リスク管理表(後述)で一覧化します。
問題や課題、タスクについては、管理したい項目が違うので別の表にすることが多いです。

2. リスク分析

洗い出したリスクを分類します。
優先度決めなどで使うので概算でOKです。

発生タイミング
- ウォーターフォールの場合は、工程を書くことが多い
- 同じ事象でもタイミングが違うなら別リスクとして扱った方が管理しやすいこともある
- 予防対策期限の目安にもなる
発生率
- 高中低くらいでざっくり出す
影響度
- 大中小くらいでざっくり出す
- QCDのどこに影響あるのかも考えたりする

3. リスク対応計画

分析したリスクを、発生率と影響度から優先度をつけ、戦略を考えます。
リソースは有限なので、どのリスクに対応すべきか取捨選択をします。

	影響度: 小	影響度: 大
発生率: 高	予防対策	予防対策発生時対策
発生率: 低	受容	発生時対策

予防対策: そもそも起こらないようにする対策
発生時対策: 起こったときの対策
受容: 対策しない

マイナスのリスクへの戦略としては、以下の4種類があります。

回避：要因を取り除く(0にする)
- 不安定な技術を採用しない
- 特定機能の開発をスコープ外にする
- 他社サービスを利用する
軽減：発生率を低くする
- メンバに教育をする
- 小さく始める
転嫁：第三者へ移転する
- 外部委託する
- 開発以外の例だと、保険に入ることがこれ
受容：なにもしない
- 消極的受容：リスク発生時の対策もしない
- 積極的受容：リスク発生したら事後対応する(コンティジェンシー計画を立てる)

プラスのリスクへの戦略の場合は、以下の4種類があります。

活用：確実にとらえられるようにする
- 納期を早めるために有能な人員を投入する
強化：発生率を高くする
- 有識者をメンバに加える
共有：第三者に委ねる
- 外部委託する
- コンペをする
受容：なにもしない

4. リスクのモニタリング、コントロール

これまで検討してきたことをまとめます。

1. リスク特定
- 発生タイミング
- 発生率
- 影響度
1. リスク分析
- 優先順位
- 戦略
1. リスク対応計画
- 予防対策
- 予防対策の期限
- 発生とみなす条件
- 発生時対策

これをリスク管理表で一覧化するとこのようになります。
発生頻度と影響度を選んだら、優先度が勝手に決まる数式が入っていたりしますね。

あとはこれを適宜、確認・更新していくことになります。

見直しタイミング

定期
- 日次や週次など決めておく
- フェーズの変わり目など
不定期
- リスクが顕在化したとき
- 問題(リスクとして管理していなかった事象)が生じたとき
- プロジェクト環境(体制、予算、納期、要件 etc)が変わったとき

見直し対象

顕在化したリスクや生じた問題、プロジェクト進行による分かったことをもとに見直します。

他にリスク、問題がないか
リスク顕在化の兆候がないか
影響度や発生率が変わっていないか
予防対策は実施されているか、効果があるか
発生時対策は実現可能か
- メンバなど環境が変わった場合に不可能になってしまうことがある

プロダクト全体で考えるリスク

これまで、プロジェクトとしてのリスクを考えてきました。
ひとまわり大きい範囲であるプロダクトでリスクを考えてみます。

プロダクトにとってのリスク
- プロダクトが存続、拡大していけない
- 使ってもらえない、売れない
- 利用者が増えない、減る
- 顧客満足度の低下
プロダクトへのリスクが生じる理由 ¹
- 必要な機能がない
- 競合他社と比べて機能が劣っている
- 魅力的な機能がない
- 利用できない、不安定

改修しなければ障害も起きないという意味で「動いているシステムは触るな」だった時代もありました²。
しかしWEBサービスでは、競合も多いですし乗り換えも比較的簡単なため、サービスが変わらないことは満足度低下へとつながります。
また改修しないままでいると、ライブラリのバージョンアップやOSバージョンアップによる利用制限がかかるなど、具体的な障害につながることもあります³。

リスクとうまく付き合うために

リスクは常にありますし、ゼロにはできませんが、減らすことはできます。

改修するリスクと改修しないリスクを考え、どのくらいのリソースをリスク管理、対策に使うのかなど、プロダクト全体で考えていくべきなんだなと最近感じます。

とはいえ、リスクについて考えることは、実装時やリリース、仕様検討など様々な場面でも役に立つと思います。
この記事がリスクを考えるきっかけになったら嬉しいです。

参考書籍

2016 プロジェクトマネージャ「専門知識+午後問題」の重点対策 ※リンク先は2020版
ポケットスタディプロジェクトマネージャ ※リンク先は第2版
日経ITエンジニアスクールシステムエンジニア　最強の指南書
ソフトウェアテストの教科書―品質を決定づけるテスト工程の基本と実践