はじめに
リスク管理（リスクマネジメント）は難しいです。
「リスクを見逃す」、「リスクをチームで共有していない」等の原因で、リスクに対する対応が遅れる・できないことが、しばしばありました。
自分達がやっていて「いいな」「続ける価値ありそうだな」と思った手法を整理しておきます。定量的に効果を明らかにできているわけではありません。
我々が取り入れたリスク特定の方法
オニオンモデル風の図の活用
オニオンモデルを応用して、自分のプロジェクトを中心に、ステークホルダを配置した図を描く。
この図の中に、各ステークホルダの状況の変化や発生した事件を毎週記入する（追記していく）。
各ステークホルダの状況の変化を見ながら、リスクを抽出する。
参考文献
独立行政法人情報処理推進機構 技術本部 ソフトウェア・エンジニアリング・センター，「要求工学知識体系(REBOK)概説」，p.24
https://www.ipa.go.jp/files/000005375.pdf
プロセス図の活用
金子龍三さんが提案されている「プロセスネットワーク分析法（PNA）」で使用される「プロセス図」を応用して、インプット・アウトプットの関係を示した図を描く。
図に登場する要素についての想定外（=リスク）を抽出する。
想定外を抽出するときにHAZOPのガイドワードが活用できる。
参考文献
金子龍三，「原因分析「プロセスネットワーク分析法（PNA）」の勘所 品質マネジメントシステムの原則に基づく原因分析法」，Quality One Vol.8 2009年11月号，2009
http://www.juse-sqip.jp/archives/vol8/qualityone_01.html
未来予想図の活用
水野昇幸さん・安達賢二さんが提案されている「未来予想図」を作成しながら、リスクを抽出する。ここでのリスクは、「起きてほしくないこと」と捉える。
我々のプロジェクトでの、「未来予想図」の作成のステップを以下に示す。
- 各自一人で、付箋にリスクを書き出す ※ブラストではなく個人作業
- 同じリスクの付箋は重ねて、まとめる
- 因果関係を示すように付箋を線で繋ぐ
- 因果関係が成り立たたないところは、”新たなリスクを追加する”または”表現を修正する”ことで、因果関係が成り立つようにする
- 要因が不足している場合（「他にもこんな要因でこれ起きるね」がわかった場合）、新たなリスクの付箋を追加する。
「未来予想図」の上部には、リスク抽出対象のプロジェクトのリリース日を記載する。
「未来予想図」は、左から右に時系列に付箋を並べる。左にある付箋のほうが、先に顕在化する可能性高いリスクとする。
「未来予想図」は毎週見直す。対策を実施したリスクの付箋、発生確率がかなり低くなったリスクの付箋には、上から「解消済み」と書かれた付箋を張り付ける。
我々のプロジェクトでは、オンラインホワイトボード「Miro（ https://miro.com ）」を使用して、「未来予想図」を作成した。
参考文献
水野昇幸，安達賢二，「リスク構造化を用いたリスクマネジメント手法の提案と効果分析 ～「未来予想図」を用いたリスクマネジメントPDCAサイクル～」，ソフトウェア・シンポジウム 2018，2018
https://www.sea.jp/ss2018/download/4-3-DM_sea-ss2018_mizuno.pdf
3つの手法の組み合わせ方
- 時間がないときは、最低限「未来予想図」の活用のみメンバ全員（マネージャー、リーダー含む）で実施するとよい。
- 3つの手法は、基本的にはメンバ全員で実施するとよい。ただし、メンバ全員で実施することが難しければ、最低限「未来予想図」の活用のみメンバ全員（マネージャー、リーダー含む）で実施するとよい。
- プロセス図とオニオンモデル風の図から特定したリスクは、「未来予想図」に反映し、毎週監視するとよい。
- オニオンモデル風の図に、ステークホルダの状況を記入することは、情報が掴めるマネージャーでなければ難しい。
- 3つの手法（図）は、それぞれ以下のタイミング・頻度・人で活用するとよい。
| 手法 | 利用タイミング | 利用頻度 | （主な）利用者 |
|---|---|---|---|
| オニオンモデル風の図 | 開発中 | 毎週 | マネージャー |
| プロセス図 | 計画立案・変更時 | 1回 | リーダー |
| 未来予想図 | 開発中 | 毎週 | マネージャー、リーダー、メンバ |
ちなみに、リスクチェックシートのようなものも使ってみようとしたこともありましたが、うまく使えませんでした。うまく使えなかった理由については、まだ明らかにできていません。
リスク管理について参考になる論文・書籍・記事
FRIモデルとリスク管理表について
安達賢二さんが、「FRI(Factor-Risk-Influence)モデル」という手法を以下の論文で提案をされています。「FRIモデル」は、「未来予想図」が応用されていると思われます。「FRIモデル」と「リスク管理表」の違い・関係などについても論文で言及されています。
「FRIモデル」については、私達のプロジェクトでは、まだ導入していません。
安達賢二，「リスク構造を読み解いてアプローチするFRI(Factor-Risk-Influence)モデルによるリスク構造の見える化」，ソフトウェア・シンポジウム 2020，2020
https://www.sea.jp/ss2020/download/SS2020-10.pdf
https://www.sea.jp/ss2020/download/SS2020-10(slide).pdf
トム・デマルコ「ゆとりの法則」で述べられているリスク管理の難しさ
トム・デマルコ「ゆとりの法則 － 誰も書かなかったプロジェクト管理の誤解」の「第29章 常識の誤り」に、以下の記載があります。
「できる」型思考は、現代の企業に定着している。
ところが、「できる」型思考はリスク管理とは正反対のものである。リスク管理は、「できない」可能性を素直に認める必要がある。完璧な「できる」型でありながら、リスク管理も実践するということはありえない。
人ならありえないが、企業には両方を実践できない理由はない。個々の管理者は「できる」か「できないか」どちらかの態度をとる必要があり，両方の態度はとれない。しかし、企業には、完全な「できる」型管理者と少数の「できない」型管理者が混在することが可能である。
「できる」型管理者は、今回紹介した3つの手法などを利用し、むりやり意図的に「できない」型の思考をする時間を設ける必要がありそうです。
ただそれでも、どうしても「できる」型の思考になると思いますので、チーム内の複数人で、「できる」型と「できない」型の思考を分担する必要がありそうです。リスクの特定は、視点・視野・視座が異なる複数人で実施するということが大切な気がします。
標準的なリスク管理について説明している資料
-
MS&ADインシュアランスグループ，「リスクマネージメント入門＜JISQ31000 準拠＞」
https://www.ms-ins.com/pdf/business/rm/rmguide.pdf -
独立行政法人情報処理推進機構 技術本部 ソフトウェア・エンジニアリング・センター，「ITプロジェクトのリスク予防への実践的アプローチ」，2019
https://www.ipa.go.jp/sec/softwareengineering/reports/20130327_3.html -
村上治，「リスクとインシデント」，経営・情報研究 多摩大学研究紀要 No.20，2016
https://tama.repo.nii.ac.jp/?action=pages_view_main&active_action=repository_view_main_item_detail&item_id=300&item_no=1&page_id=32&block_id=88
Qiitaの中でリスクについて言及している記事