リスク管理表のテンプレート
リスク管理表は、着手時に一度作られて、そのまま引き出しにしまわれることが多い帳票です。ある案件では、登録した42件が3か月間まったく更新されず、週次会議で話題になった回数も0回でした。
このページでは、毎週使われる状態を保つためのリスク管理表のテンプレートと、記入例、運用のしかたをまとめます。記入例は、事例集の「北斗建設（架空）の施工管理・原価管理システム刷新」に当てはめたものです。
■ この帳票が要る場面（背景・よくある課題）
よくある症状 | 本当の原因 |
|---|---|
着手時に作って以来、更新していない | 毎週見る理由がない（測る数字がない） |
ほとんどのリスクが「発生確率：中／影響：大」 | 影響を数値にしていないので、差がつかない |
対応欄が「注意して進める」「適宜対応する」 | 具体的な行動になっていない |
リスクが現実になってから慌てて動く | 近づいていることに気づく仕掛けがない |
リスクが抽象的で、誰の問題か分からない | 「品質が低下するリスク」のような書き方をしている |
■ このテンプレートの目的
リスクが近づいていることに、早く気づけるようにする：毎週測れる数字を1つ決めます
動き出す線を、先に決めておく：引き金（トリガー）の値を設定します
対応を、自分たちで実行できる行動にする：「注意する」ではなく「誰が何をするか」を書きます
リスク管理は、予知することではありません。何が起きるかを当てる必要はなく、起きかけていることに早く気づける仕掛けを作っておくことです。予知はできませんが、測ることはできます。
■ テンプレートの全体像
リスクを登録したら、まず発生確率と影響で位置を決めます。位置が決まれば、打つ手の種類も決まります。
対応の種類 | 内容 | 使う場面 | 例 |
|---|---|---|---|
回避 | そもそも起きない計画に組み替える | 発生確率 高 × 影響 大 | 依存している外部連携を、クリティカルパスから外す |
軽減 | 発生確率か影響のどちらかを下げる | 最も多く使う | 試行現場を5か所に絞り、全社展開前に問題を洗い出す |
転嫁 | 契約や保険で他者に移す | 発生確率 低 × 影響 大 | ベンダーとの契約で、性能要件を成果物の受入基準に含める |
受容 | 起きても受け入れ、監視だけする | 影響が小さいもの | 端末の初期不良（代替機で対応可能） |
■ 各項目の説明
列 | 何を書くか | 書き方のコツ |
|---|---|---|
ID | R-01、R-02… | クローズしても番号は再利用しない |
リスクの内容 | 「○○が起きると、△△に□日（□万円）の影響が出る」 | 影響は必ず数値。「品質が低下するリスク」では動けません |
発生確率 | 過去の類似案件で何件中何件起きたか | 「中」ではなく「過去8案件中3件」。根拠が残ります |
影響の大きさ | 日数と金額 | ここを数値にすると、管理しなくてよいリスクが見つかります |
監視する数字 | 毎週測れる、先に動く数字 | 工数の実績ではなく変更依頼の件数。結果ではなく兆候を測る |
測り方 | 誰が、どこを見て、いつ測るか | ここがないと、毎週は回りません。既存の表やログから数えられるものが理想 |
引き金（トリガー） | いくつになったら動くか | 先に線を引いておく。触れた週に議論なしで動けます |
対応（発動時） | 誰が、何をするか | 「注意する」「徹底する」は禁止。自分たちで実行できる行動に |
対応の種類 | 回避／軽減／転嫁／受容 | 図の位置から決める |
状態 | 監視中／発動／収束／クローズ | 発動した日と、収束した日を記録する |
監視する数字を選ぶコツは、「先に起きること」を選ぶことです。
リスク | △ 遅れて分かる数字 | ○ 先に分かる数字 |
|---|---|---|
要望で機能が膨らむ | 工数の実績（数か月後に出る） | 変更依頼票の月間起票件数（その週に分かる） |
動作が遅くて使われない | 稼働後の利用率（手遅れ） | 検証機での主要画面の表示時間（毎週測れる） |
受入テストに人が集まらない | 受入テスト当日の出席者数（手遅れ） | 参加確定した人数（4週前に分かる） |
連携仕様が固まらない | 結合テストの遅れ（数か月後） | 未確定のI/F項目数（毎週数えられる） |
■ 記入例：北斗建設 施工管理・原価管理システム刷新
3工場ではなく58現場で使うシステムです。42件のリスクを見直し、23件に絞りました。
ID | リスク（影響を数値で） | 発生確率 | 監視する数字 | 引き金 | 対応 |
|---|---|---|---|---|---|
R-01 | 現場からの要望で機能が膨らみ、開発が15人月増える | 過去8案件中3件 | 変更依頼票の月間起票件数 | 月8件を超えたら | PMが変更管理会議を隔週から毎週に切り替える |
R-04 | タブレットの動作が遅く、稼働後の作り直しで20人月 | 過去4案件中2件 | 検証機での主要3画面の平均表示時間 | 3.0秒を超えたら | 開発リーダーが画面の表示項目を削る検討に入る |
R-07 | 連携仕様が固まらず、結合テストが3週間遅れる | 過去8案件中4件 | 未確定のI/F項目数（全164項目） | 3週連続で減らなかったら | PMが経理部長を入れた確定会議を設定する |
R-12 | 受入テストに現場所長が集まらず、テストが2週間延びる | 過去6案件中4件 | 参加確定した所長の人数（目標24名） | 4週前時点で18名未満 | PMが支店長3名に依頼文を出す |
R-16 | 協力会社の入力が定着せず、原価が正しく集まらない | 過去3案件中1件 | 試行5現場の日次入力率 | 70%を下回ったら | 業務リーダーが入力項目を削るか、代行入力の運用を作る |
実際に引き金を引いた4件
時期 | 数字 | 打った手 | その後 |
|---|---|---|---|
2025年2月 | 変更依頼票が月11件（引き金8件） | 変更管理会議を隔週から毎週へ | 3月以降は月6件以下に収束 |
2025年4月 | 平均表示時間3.4秒（引き金3.0秒） | 一覧の初期表示を50件から20件へ変更 | 1.8秒に改善 |
2025年7月 | 未確定I/F項目が3週連続で42件 | 経理部長を入れた確定会議を2回開催 | 2週間で0件に |
2025年8月 | 4週前時点で15名（引き金18名未満） | 支店長3名から現場へ依頼文を発出 | 最終的に26名が参加（目標24名） |
4件とも、数字が引き金に触れた週のうちに動いています。引き金の値を先に決めてあるので、「11件は多いのか少ないのか」を議論する必要がありません。決めた線を超えたから動く、それだけです。
残る19件は、引き金に触れないまま完了しました。監視して何も起きないのが、いちばん良い結果です。
■ 運用ルール
リスクは「○○が起きると、△△に□日（□万円）の影響が出る」の形で書く。影響は必ず数値
各リスクに、毎週測れる数字を1つ決める。ログや既存の表から数えられるものが理想
引き金の値を先に決める。触れたらその週のうちに対応に着手します
対応は「誰が、何をするか」で書く。「注意する」「徹底する」は禁止
週次会議で、監視する数字を読み上げる。議論はしません。所要5分
登録は20〜25件まで。40件を超えると、監視が回りません
影響を数値にして、管理対象外にできるものを外す。全部を同じ重さで扱わないこと
5番目の「読み上げるだけ」が、続けるためのコツです。議論を始めると15分かかり、やがてやらなくなります。読み上げるだけの5分でも、「近づいている」ことが全員に共有される効果があります。ある案件では、引き金の手前の値を聞いた開発リーダーが、触れる前に自主的に調査を始めました。
■ 活用シーン
場面 | 使い方 |
|---|---|
計画の立ち上げ | 過去の類似案件で起きたことを、リスクとして登録する |
週次の進捗会議 | 監視する数字を読み上げる（5分） |
引き金に触れたとき | あらかじめ決めた対応を、その週のうちに実行する |
経営層への報告 | 「23件を監視中、うち4件が発動し収束」と状況を1行で示せる |
契約交渉 | 転嫁するリスクを、契約条項や受入基準に反映する |
プロジェクト完了時 | 発動した／しなかったリスクを整理し、次の案件の登録候補にする |
■ よくある失敗と直し方
失敗 | 何が起きるか | 直し方 |
|---|---|---|
リスクが抽象的（「品質が低下するリスク」） | 誰の問題か分からず、誰も動かない | 「○○が起きると、△△に□日の影響」の形で書く |
影響を「大・中・小」で書く | ほとんどが「大」になり、優先順位がつかない | 日数と金額で書く。数値にすると受容でよいものが見つかる |
監視する数字がない | 毎週見る理由がなく、引き出しにしまわれる | 各リスクに1つ、毎週測れる数字を決める |
監視する数字が「遅れて分かる数字」 | 気づいたときには手遅れ | 結果ではなく兆候を測る（工数ではなく起票件数） |
引き金を決めない | 「まだ大丈夫では」という議論が毎週続く | 先に線を引く。触れたら議論なしで動く |
対応が「注意して進める」 | 具体的な行動がなく、何も変わらない | 「誰が、何をするか」で書く |
40件以上登録する | 監視が回らず、全部が放置される | 影響を数値にして絞る（20〜25件） |
■ 導入効果
項目 | 作り直し前（4か月） | 作り直し後（10か月） |
|---|---|---|
リスク管理表の更新回数 | 0回 | 46回（毎週） |
週次会議でリスクを確認した回数 | 0回 | 45回（毎回5分） |
登録リスク件数 | 42件 | 23件 |
監視する数字が書かれているもの | 0件 | 23件（全件） |
引き金を引いた件数 | ― | 4件 |
リスクが現実になった件数 | ― | 0件 |
この案件では、タブレットの表示速度のリスク（R-04）に4月の時点で手を打てたことで、作り直しが4人月で済みました。リスク表には「稼働後の作り直しで20人月」と書いてありましたから、16人月ぶんを回避できたことになります。
最後に1つ。リスク管理表を作り直すのが大変なら、まず1件だけやってみてください。いま一番気になっているリスクを選び、「それが起きると何日・何万円の影響が出るか」「近づいていると分かる数字は何か」「いくつになったら動くか」の3つを書き足す。それだけで、そのリスクは監視できる状態になります。