第3章 3.4 ← 3.0 計画の基本
リスク管理とは、全部に備えないことです
リスク管理表をつくると、たいてい30件くらい並びます。そして30件すべてに「注意する」と書かれます。これは管理しているように見えて、何もしていません。リスク管理の本質は、どれに備えないかを決めることです。
この記事の要点
- リスクは未発生、課題は発生済み。この線引きを守ると、打つ手の選び方が変わります。
- 洗い出しは「これが倍かかるとしたら、何が起きたときですか」と聞くだけで十分集まります。
- 起きやすさと影響の大きさで並べ、右上だけに手を打ちます。全部に備えると、どれにも備えられません。
- 打ち手は4つ——避ける・減らす・移す・受け入れる——だけです。「気をつける」は打ち手ではありません。
- 確率が低くても影響が致命的なものは、起きる前提で「起きたらこうする」を決めておきます。
リスクと課題は、分けて扱います
日本の現場ではこの2つが混ざりがちですが、実務上は分けたほうが動きやすくなります。
リスクはまだ起きていないことです。起きないかもしれません。だから打ち手は「起きにくくする」「起きても軽くする」になります。課題はすでに起きていることです。もう起きているので、打ち手は「解決する」しかありません。
この線引きを守ると、会議での扱いが変わります。リスクの一覧は月に1度見直せば足りますが、課題の一覧は毎週見ます。混ぜて1つの表にすると、毎週30件を眺めることになり、結局どれも見なくなります。
洗い出しは、一問で足ります
リスクの洗い出しに、特別な手法は要りません。2.2でも触れた一問を、関係者それぞれに聞くだけです。
「これが倍かかるとしたら、何が起きたときですか」
この問いには、みんな正直に答えます。自分の能力の話ではなく、世の中の話だからです。「先方のデータが前回みたいに汚かったら」「田中さんが例の案件に呼ばれたら」「稟議が年度末にかかったら」。返ってきた答えを並べれば、それがリスク一覧です。
関係者3人に聞けば、だいたい15件くらい出ます。ここから絞ります。
右上だけに手を打つ
集まったリスクを、起きやすさと影響の大きさの2軸で置いてみます。厳密な数値は要りません。高いか低いか、大きいか小さいかの4つに分ければ十分です。
打ち手は4つしかありません
右上に入ったリスクには、次の4つのどれかを選んで書きます。「注意する」「気をつける」は選択肢に入っていません。
- 避ける。やり方を変えて、そもそも起きなくします。「移行対象を3年分に絞れば、データ品質の問題が起きる範囲が減る」。
- 減らす。起きる確率か影響を小さくします。「先方のデータを、いま1000件だけもらって確認しておく」。これがいちばんよく使う打ち手です。
- 移す。契約や保険で、他者に持たせます。「データ整備は先方の作業として契約に明記する」。
- 受け入れる。備えないと決めます。ただし「起きたらこうする」だけは決めておきます。
ここで大事なのは、打ち手には担当者と期日がつくということです。「先方データを1000件確認する／田中／2月10日まで」。これがないものは、打ち手ではなく願望です。リスク管理表が機能していない現場は、ほぼ例外なくこの欄が空白になっています。
日本の現場で、右上に入りやすい3つ
キーマンが別案件に呼ばれる。兼任が前提の職場では、確率がかなり高くなります。
承認が想定より長く止まる。年度末や役員の出張と重なると、2週間が1か月になります。決裁ルートを先に確認するだけで、確率も影響も下がります。
先方のデータが想定より汚い。移行を伴う案件では定番です。サンプルを早めにもらうだけで、多くが「減らす」で処理できます。
確率は低いが、致命的なもの
図の右下——起きにくいが、起きたら致命的——は、扱いを間違えやすい箱です。確率が低いので後回しにされ、そして起きてから考えることになります。
この箱に対しては、確率を下げようとするより「起きたらこうする」を決めておくほうが現実的です。本番切替の当日に不具合が出たら、何時までに判断して、誰が切り戻しを決めて、誰が業務部門に連絡するのか。これを紙に1枚書いておくだけで、当日の混乱がまったく違います。
切り戻しの手順を用意しておくのは、失敗を前提にしているからではありません。失敗したときに戻れる状態にしておくと、判断が速くなるからです。戻れないと思っていると、人は判断を先延ばしにします。
見直しは、月に一度で足ります
リスク一覧は、作って終わりではありません。ただし毎週見る必要もありません。月に一度、次の3つを確認すれば十分です。
- 起きたものはないか。起きたら、それはリスクではなく課題です。課題の一覧へ移します。
- 消えたものはないか。その工程を通過したなら、もう起きません。消して構いません。
- 新しく増えたものはないか。前提が変わると、新しいリスクが生まれます。
この3つだけなら10分で終わります。逆に、30件すべてについて状況を説明する会議にすると、誰も出たくなくなり、翌月から開かれなくなります。
ABではこう見えます
AB Projectsでは、リスクの打ち手をタスクとして登録するのがいちばん確実です。「先方データを1000件確認する」を担当と期日つきで置けば、他の作業と同じように期日が来ます。リスク管理表の中に閉じ込めておくと、表を開いた人しか見ません。
リスクそのものの一覧は、プロジェクトWikiに1ページ持って月に一度更新する形が扱いやすくなります。起きたものを課題に移すとき、元がリスクだったと分かるようにしておくと、ふりかえりのときに「見えていたのに手を打てなかったもの」が拾えます。これは次回の見積りの精度に直結します。
このページで使った言葉
- リスク
- まだ起きていないが、起きると困ることです。「危険」とは訳しません。また危機管理とは別の概念です。くわしく →
- 課題
- すでに起きていて、対処しないと進まない事柄です。リスクが現実になったものも、ここに移ります。くわしく →
- バッファ
- 想定外に備えて計画に持たせておく余裕です。リスクへの「受け入れる」を、日程の側で支える仕組みでもあります。くわしく →
- 属人化
- 特定の人しか分からない・できない状態です。多くのプロジェクトで、右上に入る最大のリスクです。くわしく →
- 稟議・決裁
- やるかどうかを組織として決める仕組みです。止まる期間の読みにくさが、そのままリスクになります。くわしく →
- エスカレーション
- 自分の権限で決められないことを、決められる人に上げることです。リスクが現実になったときの初動です。くわしく →
あわせて読みたい
6.2 課題と変更の管理
リスクが現実になったあと、どう扱うか。
3.3 体制と要員
最大のリスクである属人化を、どう見えるようにするか。
4.0 チームと関係者
人にまつわる問題を、正面から扱う章。