リスク管理表を「毎週使われる状態」にした事例

リスク管理表は、たいてい着手時に一度作られます。そして、そのまま更新されません。この事例のプロジェクトでも、3か月間で更新回数は0回、週次会議で話題になった回数も0回でした。

作り直して変えたのは1点だけです。各リスクに「毎週測る数字」と「引き金の値」を決めたこと。その結果、リスク管理表は毎週開かれる表になり、登録した23件のうち現実になったものは0件でした。会社名・数字はすべて架空ですが、記事の中で辻褄が合うように作っています。

■ 会社と案件の前提

建設の現場システムが難しいのは、使う人が本社にいないことです。現場所長は施工が本業で、システムの打ち合わせに出る時間が限られます。そして現場の運用は、現場ごとに違います。この構造が、いくつものリスクを生みました。

■ 2024年11月：リスク管理表がどうなっていたか

76%が「発生確率：中／影響：大」。これは、ほぼ全部が同じ評価ということです。全部が同じなら、優先順位はつきません。優先順位がつかない表は、見ても何も決まらないので、開かれなくなります。

実際に書かれていたリスクを、そのまま引用します。

• 「現場からの要望により、要件が膨らむリスク」（発生確率：中／影響：大／対応：注意して進める）

• 「タブレットの操作性が現場に受け入れられないリスク」（発生確率：中／影響：大／対応：適宜対応する）

• 「協力会社の入力が定着しないリスク」（発生確率：中／影響：大／対応：教育を徹底する）

読んでみると、どれも「そのとおり」です。しかし、この文からは、今週何をすればよいかが出てきません。「注意して進める」は、具体的な行動ではないからです。

■ リスク管理表を作り直した

2024年12月、次の6つのルールに変えました。

1. リスクは「○○が起きると、△△に□日（□万円）の影響が出る」の形で書く：影響は必ず数値にする

2. 各リスクに、毎週測れる数字を1つ決める：これを「監視する数字」と呼ぶ

3. その数字に「引き金の値」を設定する：超えたら対応に着手する、という線を先に引く

4. 対応は「誰が、何をするか」で書く：「注意する」「徹底する」は禁止

5. 発生確率は、過去の類似案件で何件中何件起きたかで書く：「中」ではなく「過去8案件中3件」

6. 週次会議で、監視する数字を測って読み上げる：所要5分

2つめの「監視する数字」を選ぶときのコツは、先に起きることを選ぶことです。

たとえば「要件が膨らむリスク」の場合、工数の実績を見ていては遅すぎます。工数に出るのは数か月あとだからです。そこで変更依頼票の月間起票件数を測ることにしました。これなら、その週のうちに分かります。

■ 42件を見直した結果

削除した6件について補足します。影響を数値にしようとすると、実は大したことがないリスクが見つかります。「中／大」と書いてあったものが、具体的に計算すると「最大2日の遅れ」だった、というケースです。これを管理対象から外すことで、残りの23件に集中できるようになりました。

■ 主なリスクと、監視する数字

23件のうち、特に重視した5件です。

「測り方」の列があることに注目してください。測り方が書いていない数字は、測られません。「誰が、どこを見て、いつ測るか」まで書いて、はじめて毎週回ります。5つのうち3つは、既存の表やログを数えるだけです。新しい作業をほとんど増やしていません。

■ 実際に引き金を引いた4件

4件とも、数字が引き金に触れた週のうちに動いています。ここが重要です。引き金の値を先に決めてあるので、「11件は多いのか少ないのか」を議論する必要がありません。決めた線を超えたから動く、それだけです。

もし測っていなかったら、どうなっていたか。変更依頼の件数は総合テストのころに工数超過として、タブレットの遅さは受入テストで現場所長の不満として表に出たはずです。どちらも、その段階では作り直す時間がありません。

残る19件は、引き金に触れないまま完了しました。たとえば協力会社の入力率は、試行期間を通じて78〜92%で推移し、70%を下回ることはありませんでした。監視して何も起きないのが、いちばん良い結果です。

■ 週次会議の5分をどう使ったか

作り直しで唯一増えた作業が、週次会議でのリスク確認です。やり方は単純で、監視する数字を読み上げるだけです。

「変更依頼票、今月ここまで4件。引き金8件に対して余裕あり」
「タブレット表示時間、2.6秒。引き金3.0秒に近づいています」
「未確定I/F項目、先週48件から今週44件。減っています」

議論はしません。数字を言うだけです。所要時間は5分です。

それでも効果があるのは、「近づいている」ことが全員に共有されるからです。上の例でいえば、タブレットの2.6秒を聞いた開発リーダーが、引き金に触れる前に自主的に調査を始めています。読み上げるだけの5分が、そういう動きを生みました。

■ 結果（QCD）

実績は270人月、計画262人月に対して8人月の超過です。内訳は、タブレット画面の作り直し（4人月）と、変更管理会議を毎週にしたことによる運営工数（2人月）、その他（2人月）です。

もし引き金を引かずに進んでいたら、タブレットの作り直しは稼働後になり、リスク表に書いてあったとおり20人月かかっていた見込みです。4人月で済んだのは、4月の時点で手を打てたからです。

稼働後3か月の利用状況も記録しておきます。

■ 管理帳票の実物

リスク管理表（作り直し後の様式）

課題管理表（リスクから移した7件を含む）

TODO（引き金を引いたあとの対応の実物）

■ 振り返りと、自分の現場で使うなら

まず反省点です。

• 着手から4か月、リスク管理表を開かなかった：作った時点で満足していた。最初の1か月で「これは使われない形だ」と気づけたはず

• 監視する数字を決めるのに3週間かかった：23件それぞれに「毎週測れる数字」を考えるのは、思ったより難しい作業だった

• 引き金の値に根拠がないものもあった：タブレットの3.0秒は現場ヒアリングから出たが、変更依頼の月8件は過去実績からの推測で、やや緩かった可能性がある

次に効いた点です。

• 影響を数値にした：数値にすると、管理しなくてよいリスク（6件）が見つかる

• 測る数字を「先に起きること」にした：工数ではなく起票件数、不満ではなく表示時間

• 引き金の値を先に決めた：触れた週に議論なしで動ける

• 測り方まで書いた：「誰がどこを見ていつ測るか」がないと、毎週は回らない

• 週次会議では読み上げるだけにした：5分で済むので続く。議論を始めると15分かかり、やがてやらなくなる

最後に、明日から使える形にまとめます。リスク管理表を作り直すのが大変なら、まず1件だけやってみてください。いま一番気になっているリスクを1つ選び、次の3つを書き足します。

1. それが起きると、何日・何万円の影響が出るか：数値にできなければ、管理する必要がないかもしれません

2. そのリスクが近づいていると分かる数字は何か：毎週測れるものを1つだけ。ログや既存の表から数えられるものが理想です

3. その数字がいくつになったら動くか：先に線を引いておきます

そして、いちばん大事なことを最後に書きます。リスク管理は、予知することではありません。何が起きるかを当てる必要はなく、起きかけていることに早く気づける仕掛けを作っておくことです。予知はできませんが、測ることはできます。