--- title: "リスク管理表の作り方：発生確率・影響度の項目と課題管理表との違い、更新の運用" url: "https://www.issoh.co.jp/column/details/19780/" published: 2026-11-14 updated: 2026-11-14 categories: ["DX"] publisher: "株式会社一創" --- # リスク管理表の作り方：発生確率・影響度の項目と課題管理表との違い、更新の運用 リスク管理表は、プロジェクトでまだ起きていない問題を一覧にし、発生確率と影響度で順位を付け、予兆・対応策・責任者を決めて見張るための表です。この記事では、リスク管理表に最初から入れる14列と記入例、5段階で評価する基準の作り方、確率と影響度を掛け算したスコアで見落としが出る理由をまとめました。後半では、回避・軽減・移転・受容の決め方と予備日程の積み方、リスクが顕在化したときに課題管理表へ移す手順、Excelで作るときの数式まで、システム開発のプロジェクトを例に整理します。 ## まとめ：リスク管理表は予兆の列と課題管理表へ移す線引きで機能する リスク管理表に必要な列は、内容・発生確率・影響度・ランク・予兆・対応戦略・予防策・発生時の対応・オーナー・次回見直し日・状態などの14列で足ります。競合のテンプレートとの差が出るのは「予兆（トリガー）」の列です。何が起きたら発生時の対応に切り替えるかを決めていない表は、リスクが顕在化しても誰も気づかず、課題として後から見つかります。 評価は発生確率と影響度をそれぞれ5段階にし、段階ごとの判定材料を文章で定義します。確率×影響度の掛け算だけで順位を付けると、確率は低いが稼働日を動かすリスクが下位に沈むので、影響度が最大のものは確率に関係なく上位に置くルールを足してください。 運用は、週次の定例で上位リスクの予兆を確認し、工程の区切りで全件を見直します。予兆が出たら、リスク管理表の行を「顕在化」に変え、課題管理表に起票して番号を相互に書き込みます。この往復が決まっていれば、2つの表を分けても二重管理になりません。 ## リスク管理表とは：課題管理表との違いとシステム開発で載せるリスクの範囲 ### リスク管理表の定義とデジタル庁DS-100がリスク管理に求める記載事項 リスクとは、まだ起きていないが、起きればプロジェクトの目標・期日・費用・品質のどれかに影響する不確かな事象です。リスク管理表は、その事象を洗い出して評価し、手を打つ順番と責任者を決めて追いかける一覧を指します。英語ではリスクレジスター（リスク登録簿）と呼ばれます。 政府情報システムの整備ルールである[DS-100 デジタル・ガバメント推進標準ガイドライン（2026年6月12日決定）](https://www.digital.go.jp/assets/contents/node/basic%5Fpage/field%5Fref%5Fresources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/54d8725e/20260715%5Fresources%5Fstandard%5Fguidelines%5Fguideline%5F01.pdf)は、第3編第2章でプロジェクト管理要領に書く事項として「リスク管理」を挙げ、プロジェクトの遂行を阻害する可能性のあるリスクについて「リスク顕在時の報告先、報告内容、リスクの管理手法等を記載する」と定めています。第7章の設計・開発実施要領では、記載事項が「リスク認識の手法、リスクの管理手法、顕在時の対応手順等」になっています。 民間の案件に適用される規程ではありません。ただ、どちらの章も「顕在時」の扱いを書かせている点は参考になります。リスク管理表は、洗い出して点数を付けた時点では半分しかできていません。 ### 課題管理表との違いを「まだ起きていないか」と持つ列で分ける比較表 リスク管理表と課題管理表の違いは、対象の事象がもう起きたかどうかです。起きていなければリスク、起きていれば課題になります。この違いから、持つべき列も変わります。 | 観点 | リスク管理表 | 課題管理表 | | ------- | ------------------ | ------------- | | 対象 | まだ起きていない事象 | すでに起きている問題 | | 固有の列 | 発生確率・影響度・予兆 | 期限・完了日・確認者 | | 打つ手 | 予防策と発生時の対応を用意する | 原因を調べて解決策を決める | | 行を閉じる条件 | 発生しなくなった・顕在化して移管した | 起票者が解決を確認した | | 見直しの頻度 | 週次で上位、工程の区切りで全件 | 定例ごとに未完了の全件 | DS-100 も、リスク管理を「遂行を阻害する可能性のあるリスク」、課題管理を「遂行上発生する解決すべき課題」と書き分けています。課題管理表の列設計やステータスの決め方は、兄弟記事の[課題管理表の作り方：必要な項目とステータス設計、Excelで破綻する条件](https://www.issoh.co.jp/column/details/19764/)で扱っています。 ### システム開発でリスク管理表に載せる代表例と載せなくてよい一般的な懸念 受託開発のプロジェクトで、リスク管理表の上位に繰り返し出てくるのは次のような事象です。 - 要件定義の終了時点で、帳票や外部連携の仕様が決まっていない - 既存システムのデータに重複や欠損があり、移行で手戻りが出る - 連携先の他社システムがAPI仕様やテスト環境を期日までに出さない - 発注者側のレビュー担当が兼務で、設計書の承認が遅れる - 特定の技術者に作業が集中し、その人が抜けると工程が止まる 1つ目について DS-100 第6章は、未確定な要件が「リスク要因となり得ることに厳に留意し」、その旨を要件定義書で明らかにするよう求めています。未確定の要件は、要件定義書の中で終わらせずリスク管理表に行として移すと、誰がいつまでに決めるかを追うことが可能です。要件定義で決めておく範囲は[要件定義の目的・進め方・成果物と失敗を防ぐ方法](https://www.issoh.co.jp/column/details/12848/)で整理しています。 逆に、「品質が下がるかもしれない」「スケジュールが遅れるかもしれない」のような、どのプロジェクトにも当てはまる懸念は載せません。原因が書けない懸念には予防策も予兆も決められず、表の行数だけが増えます。 ## リスク管理表の項目：発生確率・影響度と予兆を含む14列の設計と記入例 ### 最初から入れる14列の一覧と課題管理表にはない予兆と発生時の対応 テンプレートを比べると、列は8〜12列程度のものが多く見られます。システム開発のリスク管理なら、次の14列で始めると、評価から顕在化後の移管までを1行で追えます。 | 列 | 書く内容 | | -------- | --------------------- | | 番号 | R-001のように課題と別の接頭辞を付ける | | リスク内容 | 原因・事象・影響を一文で | | 分類 | 要件・技術・体制・外部・発注者側など | | 発生確率 | 1〜5 | | 影響度 | 1〜5 | | ランク | 高・中・低（数式で算出） | | 予兆（トリガー） | 発生時の対応に切り替える合図 | | 対応戦略 | 回避・軽減・移転・受容 | | 予防策 | 確率か影響度を下げるために今やること | | 発生時の対応 | 顕在化したら実行する手順 | | オーナー | 予兆を見張り、判断する1人 | | 次回見直し日 | ランクに応じて1〜4週間後 | | 状態 | 監視中・対応中・顕在化・クローズ | | 関連課題番号 | 顕在化して起票した課題の番号 | 市販のテンプレートに無いことが多いのは、予兆・発生時の対応・関連課題番号の3列です。予防策だけを書いた表は、予防が効かなかったときの動きが決まっていないので、顕在化した日に対応方針の議論から始めることになります。 ### リスク内容の書き方：原因と事象と影響を一文で書く記入例と悪い例 悪い例は「データ移行」「ベンダーの体制」のような名詞だけの書き方です。何が原因で何が起きるのかが分からないため、確率も影響度も人によって違う点数が付きます。 良い例は「旧販売管理システムの得意先マスタに重複があるため（原因）、移行リハーサルでデータ投入が失敗し（事象）、本番切替日を2週間延ばすことになる（影響）」です。原因が書けていれば予防策（事前のデータ調査）が決まり、事象が書けていれば予兆（リハーサル前の件数照合で差が出る）が決まります。 1行には1つの原因だけを書きます。「要件の未確定と担当者の兼務で遅れる」のように原因を2つ並べると、片方の手を打った時点で確率をいくつに下げればよいか判断できなくなります。 ### オーナーと対応担当を分ける理由と発注者側が持つべきリスクの判断基準 オーナーは、予兆を見張り、発生時の対応に切り替える判断をする人です。予防策の作業をする担当者と同じ人である必要はありません。設計書の承認遅れのリスクなら、作業をするのは受託側のPMでも、承認の段取りを動かせるのは発注者側の責任者なので、オーナーは発注者側に置きます。 受託側が作ったリスク管理表では、オーナー欄が受託側の名前で埋まりがちです。発注者側の決裁・レビュー・現場部門の調整・既存システムのデータ提供に関わるリスクは、発注者側の人をオーナーにしないと、予兆に気づいても動ける人がいません。 ## 発生確率と影響度の評価基準：5段階の判定材料と掛け算スコアの落とし穴 ### 発生確率をパーセントでなく判定材料つきの5段階で定義する基準表 発生確率を「30%」「60%」と数字で書かせると、根拠のない数字が並びます。段階ごとに、何を見てその段階と判断するかを文章で決めておく方が、人によるぶれが減ります。 | 段階 | 判定材料の例 | | -- | ----------------- | | 5 | 予兆がすでに出始めている | | 4 | 同種の過去案件の半数以上で起きた | | 3 | 同種の過去案件で起きたことがある | | 2 | 社内外で起きた例を聞いたことがある | | 1 | 想定はできるが、起きた例を知らない | 米国立標準技術研究所の[NIST SP 800-30 Rev.1（リスクアセスメントの実施ガイド、2012年9月）](https://csrc.nist.gov/pubs/sp/800/30/r1/final)も、評価尺度を Very High から Very Low までの5段階にし、それぞれに0〜100と0〜10の半定量値と説明文を付けています。同書の付録は、これらの尺度を組織の事情に合わせて調整する出発点として使えると書いています。上の表も出発点であり、自社の過去案件に合わせて言葉を書き換えてください。 ### 影響度を遅延日数・追加費用・業務への影響の3軸で決める定義例 影響度は、軸を決めずに付けると「大きい」「小さい」の感覚になります。システム開発では、遅延・費用・業務の3つの軸で段階を定義し、いちばん高い軸の段階を採ります。 | 段階 | 遅延 | 追加費用 | 業務への影響 | | -- | ----------- | -------- | --------- | | 5 | 稼働日が動く | 予算の10%超 | 本番で業務が止まる | | 4 | 工程が2週間以上遅れる | 予算の5〜10% | 主要機能が使えない | | 3 | 工程が1〜2週間遅れる | 予算の1〜5% | 回避策のある不具合 | | 2 | 数日の遅れ | 予算の1%未満 | 一部の画面だけ | | 1 | 予備日程で吸収できる | なし | なし | 数字はプロジェクトの規模で変えて構いません。決めておくべきなのは、表をプロジェクト計画の段階で発注者と受託側の双方が合意しておくことです。合意がないと、同じリスクに発注者は5、受託側は3を付ける、という点数の綱引きが定例で始まります。 ### 確率と影響度の掛け算が低確率で致命的なリスクを下位に沈める理由 多くのテンプレートは、発生確率×影響度を「スコア」として計算し、点数順に並べます。この方法では、確率1・影響度5のリスクが5点になり、確率3・影響度2の6点より下に並びます。稼働日が動くかもしれないリスクが、数日遅れるリスクより後回しになるわけです。 NIST SP 800-30 Rev.1 の Table I-2 は、掛け算ではなく5×5の判定表でリスクの水準を決めています。この表では、発生可能性が Very High でも影響が Very Low なら水準は Very Low のままで、影響が Very High なら発生可能性が Low でも Moderate になります。影響の大きさを掛け算より重く見る設計です。 稼働日が契約や法令で決まっているシステム開発では、さらに一歩進めて「影響度5は確率にかかわらずランク高」と決めることを勧めます。確率が低いと判断した根拠は外れることがあり、外れたときの損失が取り返せないからです。逆に、社内向けツールのように稼働日を後ろにずらせる案件なら、掛け算のスコアのままで困りません。 ## 対応策の決め方：回避・軽減・移転・受容の4戦略と予備日程・予備費の積み方 ### 4つの対応戦略をシステム開発のリスクに当てはめた具体例と判断表 対応戦略は回避・軽減・移転・受容の4つに分けるのが一般的です。システム開発のリスクに当てはめると、次のように使い分けます。 | 戦略 | やること | システム開発での例 | | -- | -------------- | ------------------------- | | 回避 | 原因ごと取り除く | 実績のない新技術をやめ、実績のある構成にする | | 軽減 | 確率か影響度を下げる | 移行データを先行して調査し、リハーサルを2回にする | | 移転 | 損失を他者に負わせる | 連携先の遅延時の費用負担を契約で決める | | 受容 | 手を打たず、起きたら対応する | 予備日程を積んで見張るだけにする | 実務で選ばれるのは軽減と受容がほとんどです。回避はスコープや技術の変更を伴うため、要件定義より前でないと選びにくくなります。移転は契約で決める事項なので、契約後に気づいたリスクには使えません。 ### 受容を選んだリスクに発動条件と予備日程・予備費を紐づける手順 受容は「何もしない」ではありません。予兆を決めて見張り、起きたときに使う予備日程と予備費を先に確保しておく戦略です。予備が無いまま受容と書いたリスクは、実際には放置と変わりません。 1. 受容したリスクごとに、起きたときの遅延日数と追加費用を影響度の表から見積もる 2. 発生確率の段階に応じて、その一部をプロジェクト全体の予備日程・予備費として積む 3. 予兆と、予備を使ってよいと判断する人（オーナー）を表に書く 4. 予備を使ったら、残りの予備と使った理由を定例で報告する 予備を個々の作業の見積もりに上乗せすると、どの作業にどれだけ余裕があるかが見えなくなり、余裕から先に使われます。予備はプロジェクト全体でまとめて持ち、使うたびに理由を記録してください。見積もりの段階で予備をどう分けるかは[見積もり精度の測り方と予備の決め方、精度が上がらない原因](https://www.issoh.co.jp/column/details/11003/)で詳しく扱っています。 ## リスク管理表の更新運用：見直しの頻度・顕在化時の移管とExcelでの作り方 ### 週次・工程の区切り・変更発生時の3つのタイミングで見直す項目 リスク管理表は、作った日がいちばん正確で、更新しなければ日ごとに外れていきます。見直しは、深さの違う3つのタイミングで行います。 週次の定例では、ランク高のリスクについて予兆が出ていないかだけを確認します。確認に必要な時間の目安は1件1分です。工程の区切り（要件定義・設計・テストの完了判定）では全件を見直し、終わった工程に紐づくリスクをクローズし、次の工程のリスクを洗い出します。仕様変更や体制変更が起きたときは、その変更が関わるリスクを臨時で評価し直します。 見直したら、対応後の発生確率と影響度に書き換えます。予防策を打っても残る分が残存リスクで、ここが下がらない行は予防策が効いていない状態です。プロジェクト管理の中でリスク管理をどの会議体に載せるかは、[システム開発のプロジェクト管理の進め方と品質・課題・リスク管理](https://www.issoh.co.jp/column/details/15670/)で全体像を示しています。 ### リスクが顕在化したときに課題管理表へ移す手順と管理番号の紐づけ 予兆が出たか、事象そのものが起きたら、リスク管理表から課題管理表へ移します。移す手順を決めていないと、両方の表に同じ問題が別の書き方で残ります。 1. オーナーがリスク管理表の状態を「顕在化」に変え、発生時の対応を実行に移す 2. 課題管理表に起票し、件名の先頭か専用列に元のリスク番号（R-012など）を書く 3. リスク管理表の関連課題番号の列に、起票した課題番号を書く 4. 以後の経緯は課題管理表だけに書き、リスク管理表の行は課題が完了した時点でクローズにする 予兆が出たが、まだ事象は起きていない段階で移すかどうかは迷うところです。発生時の対応に人や予備を使い始めた時点で移す、と決めておくと判断がそろいます。 ### Excelでリスク管理表を作るときのランク判定の数式と条件付き書式 14列の見出しを入れてテーブル化し、テーブル名を「リスク」に変えたうえで、ランク列と見直し超過列に次の数式を入れます。発生確率・影響度・状態の列には、データの入力規則でリストを設定して表記の揺れを止めます。 ``` ランク列（影響度5は確率にかかわらず高）： =IF(OR([@影響度]=5,[@発生確率]*[@影響度]>=15),"高",IF([@発生確率]*[@影響度]>=6,"中","低")) 見直し超過列（次回見直し日を過ぎた監視中の行）： =IF(AND([@状態]="監視中",[@次回見直し日])（株式会社一創）