リスク管理表の作り方：発生確率・影響度の項目と課題管理表との違い、更新の運用

リスク管理表は、プロジェクトでまだ起きていない問題を一覧にし、発生確率と影響度で順位を付け、予兆・対応策・責任者を決めて見張るための表です。この記事では、リスク管理表に最初から入れる14列と記入例、5段階で評価する基準の作り方、確率と影響度を掛け算したスコアで見落としが出る理由をまとめました。後半では、回避・軽減・移転・受容の決め方と予備日程の積み方、リスクが顕在化したときに課題管理表へ移す手順、Excelで作るときの数式まで、システム開発のプロジェクトを例に整理します。

まとめ：リスク管理表は予兆の列と課題管理表へ移す線引きで機能する

リスク管理表に必要な列は、内容・発生確率・影響度・ランク・予兆・対応戦略・予防策・発生時の対応・オーナー・次回見直し日・状態などの14列で足ります。競合のテンプレートとの差が出るのは「予兆（トリガー）」の列です。何が起きたら発生時の対応に切り替えるかを決めていない表は、リスクが顕在化しても誰も気づかず、課題として後から見つかります。

評価は発生確率と影響度をそれぞれ5段階にし、段階ごとの判定材料を文章で定義します。確率×影響度の掛け算だけで順位を付けると、確率は低いが稼働日を動かすリスクが下位に沈むので、影響度が最大のものは確率に関係なく上位に置くルールを足してください。

運用は、週次の定例で上位リスクの予兆を確認し、工程の区切りで全件を見直します。予兆が出たら、リスク管理表の行を「顕在化」に変え、課題管理表に起票して番号を相互に書き込みます。この往復が決まっていれば、2つの表を分けても二重管理になりません。

リスク管理表とは：課題管理表との違いとシステム開発で載せるリスクの範囲

リスク管理表の定義とデジタル庁DS-100がリスク管理に求める記載事項

リスクとは、まだ起きていないが、起きればプロジェクトの目標・期日・費用・品質のどれかに影響する不確かな事象です。リスク管理表は、その事象を洗い出して評価し、手を打つ順番と責任者を決めて追いかける一覧を指します。英語ではリスクレジスター（リスク登録簿）と呼ばれます。

政府情報システムの整備ルールであるDS-100 デジタル・ガバメント推進標準ガイドライン（2026年6月12日決定）は、第3編第2章でプロジェクト管理要領に書く事項として「リスク管理」を挙げ、プロジェクトの遂行を阻害する可能性のあるリスクについて「リスク顕在時の報告先、報告内容、リスクの管理手法等を記載する」と定めています。第7章の設計・開発実施要領では、記載事項が「リスク認識の手法、リスクの管理手法、顕在時の対応手順等」になっています。

民間の案件に適用される規程ではありません。ただ、どちらの章も「顕在時」の扱いを書かせている点は参考になります。リスク管理表は、洗い出して点数を付けた時点では半分しかできていません。

課題管理表との違いを「まだ起きていないか」と持つ列で分ける比較表

リスク管理表と課題管理表の違いは、対象の事象がもう起きたかどうかです。起きていなければリスク、起きていれば課題になります。この違いから、持つべき列も変わります。

DS-100 も、リスク管理を「遂行を阻害する可能性のあるリスク」、課題管理を「遂行上発生する解決すべき課題」と書き分けています。課題管理表の列設計やステータスの決め方は、兄弟記事の課題管理表の作り方：必要な項目とステータス設計、Excelで破綻する条件で扱っています。

システム開発でリスク管理表に載せる代表例と載せなくてよい一般的な懸念

受託開発のプロジェクトで、リスク管理表の上位に繰り返し出てくるのは次のような事象です。

• 要件定義の終了時点で、帳票や外部連携の仕様が決まっていない
• 既存システムのデータに重複や欠損があり、移行で手戻りが出る
• 連携先の他社システムがAPI仕様やテスト環境を期日までに出さない
• 発注者側のレビュー担当が兼務で、設計書の承認が遅れる
• 特定の技術者に作業が集中し、その人が抜けると工程が止まる

1つ目について DS-100 第6章は、未確定な要件が「リスク要因となり得ることに厳に留意し」、その旨を要件定義書で明らかにするよう求めています。未確定の要件は、要件定義書の中で終わらせずリスク管理表に行として移すと、誰がいつまでに決めるかを追うことが可能です。要件定義で決めておく範囲は要件定義の目的・進め方・成果物と失敗を防ぐ方法で整理しています。

逆に、「品質が下がるかもしれない」「スケジュールが遅れるかもしれない」のような、どのプロジェクトにも当てはまる懸念は載せません。原因が書けない懸念には予防策も予兆も決められず、表の行数だけが増えます。

リスク管理表の項目：発生確率・影響度と予兆を含む14列の設計と記入例

最初から入れる14列の一覧と課題管理表にはない予兆と発生時の対応

テンプレートを比べると、列は8〜12列程度のものが多く見られます。システム開発のリスク管理なら、次の14列で始めると、評価から顕在化後の移管までを1行で追えます。

市販のテンプレートに無いことが多いのは、予兆・発生時の対応・関連課題番号の3列です。予防策だけを書いた表は、予防が効かなかったときの動きが決まっていないので、顕在化した日に対応方針の議論から始めることになります。

リスク内容の書き方：原因と事象と影響を一文で書く記入例と悪い例

悪い例は「データ移行」「ベンダーの体制」のような名詞だけの書き方です。何が原因で何が起きるのかが分からないため、確率も影響度も人によって違う点数が付きます。

良い例は「旧販売管理システムの得意先マスタに重複があるため（原因）、移行リハーサルでデータ投入が失敗し（事象）、本番切替日を2週間延ばすことになる（影響）」です。原因が書けていれば予防策（事前のデータ調査）が決まり、事象が書けていれば予兆（リハーサル前の件数照合で差が出る）が決まります。

1行には1つの原因だけを書きます。「要件の未確定と担当者の兼務で遅れる」のように原因を2つ並べると、片方の手を打った時点で確率をいくつに下げればよいか判断できなくなります。

オーナーと対応担当を分ける理由と発注者側が持つべきリスクの判断基準

オーナーは、予兆を見張り、発生時の対応に切り替える判断をする人です。予防策の作業をする担当者と同じ人である必要はありません。設計書の承認遅れのリスクなら、作業をするのは受託側のPMでも、承認の段取りを動かせるのは発注者側の責任者なので、オーナーは発注者側に置きます。

受託側が作ったリスク管理表では、オーナー欄が受託側の名前で埋まりがちです。発注者側の決裁・レビュー・現場部門の調整・既存システムのデータ提供に関わるリスクは、発注者側の人をオーナーにしないと、予兆に気づいても動ける人がいません。

発生確率と影響度の評価基準：5段階の判定材料と掛け算スコアの落とし穴

発生確率をパーセントでなく判定材料つきの5段階で定義する基準表

発生確率を「30%」「60%」と数字で書かせると、根拠のない数字が並びます。段階ごとに、何を見てその段階と判断するかを文章で決めておく方が、人によるぶれが減ります。

米国立標準技術研究所のNIST SP 800-30 Rev.1（リスクアセスメントの実施ガイド、2012年9月）も、評価尺度を Very High から Very Low までの5段階にし、それぞれに0〜100と0〜10の半定量値と説明文を付けています。同書の付録は、これらの尺度を組織の事情に合わせて調整する出発点として使えると書いています。上の表も出発点であり、自社の過去案件に合わせて言葉を書き換えてください。

影響度を遅延日数・追加費用・業務への影響の3軸で決める定義例

影響度は、軸を決めずに付けると「大きい」「小さい」の感覚になります。システム開発では、遅延・費用・業務の3つの軸で段階を定義し、いちばん高い軸の段階を採ります。

数字はプロジェクトの規模で変えて構いません。決めておくべきなのは、表をプロジェクト計画の段階で発注者と受託側の双方が合意しておくことです。合意がないと、同じリスクに発注者は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つに分けるのが一般的です。システム開発のリスクに当てはめると、次のように使い分けます。

実務で選ばれるのは軽減と受容がほとんどです。回避はスコープや技術の変更を伴うため、要件定義より前でないと選びにくくなります。移転は契約で決める事項なので、契約後に気づいたリスクには使えません。

受容を選んだリスクに発動条件と予備日程・予備費を紐づける手順

受容は「何もしない」ではありません。予兆を決めて見張り、起きたときに使う予備日程と予備費を先に確保しておく戦略です。予備が無いまま受容と書いたリスクは、実際には放置と変わりません。

1. 受容したリスクごとに、起きたときの遅延日数と追加費用を影響度の表から見積もる
2. 発生確率の段階に応じて、その一部をプロジェクト全体の予備日程・予備費として積む
3. 予兆と、予備を使ってよいと判断する人（オーナー）を表に書く
4. 予備を使ったら、残りの予備と使った理由を定例で報告する

予備を個々の作業の見積もりに上乗せすると、どの作業にどれだけ余裕があるかが見えなくなり、余裕から先に使われます。予備はプロジェクト全体でまとめて持ち、使うたびに理由を記録してください。見積もりの段階で予備をどう分けるかは見積もり精度の測り方と予備の決め方、精度が上がらない原因で詳しく扱っています。

リスク管理表の更新運用：見直しの頻度・顕在化時の移管とExcelでの作り方

週次・工程の区切り・変更発生時の3つのタイミングで見直す項目

リスク管理表は、作った日がいちばん正確で、更新しなければ日ごとに外れていきます。見直しは、深さの違う3つのタイミングで行います。

週次の定例では、ランク高のリスクについて予兆が出ていないかだけを確認します。確認に必要な時間の目安は1件1分です。工程の区切り（要件定義・設計・テストの完了判定）では全件を見直し、終わった工程に紐づくリスクをクローズし、次の工程のリスクを洗い出します。仕様変更や体制変更が起きたときは、その変更が関わるリスクを臨時で評価し直します。

見直したら、対応後の発生確率と影響度に書き換えます。予防策を打っても残る分が残存リスクで、ここが下がらない行は予防策が効いていない状態です。プロジェクト管理の中でリスク管理をどの会議体に載せるかは、システム開発のプロジェクト管理の進め方と品質・課題・リスク管理で全体像を示しています。

リスクが顕在化したときに課題管理表へ移す手順と管理番号の紐づけ

予兆が出たか、事象そのものが起きたら、リスク管理表から課題管理表へ移します。移す手順を決めていないと、両方の表に同じ問題が別の書き方で残ります。

1. オーナーがリスク管理表の状態を「顕在化」に変え、発生時の対応を実行に移す
2. 課題管理表に起票し、件名の先頭か専用列に元のリスク番号（R-012など）を書く
3. リスク管理表の関連課題番号の列に、起票した課題番号を書く
4. 以後の経緯は課題管理表だけに書き、リスク管理表の行は課題が完了した時点でクローズにする

予兆が出たが、まだ事象は起きていない段階で移すかどうかは迷うところです。発生時の対応に人や予備を使い始めた時点で移す、と決めておくと判断がそろいます。

Excelでリスク管理表を作るときのランク判定の数式と条件付き書式

14列の見出しを入れてテーブル化し、テーブル名を「リスク」に変えたうえで、ランク列と見直し超過列に次の数式を入れます。発生確率・影響度・状態の列には、データの入力規則でリストを設定して表記の揺れを止めます。

ランク列（影響度5は確率にかかわらず高）：
=IF(OR([@影響度]=5,[@発生確率]*[@影響度]>=15),"高",IF([@発生確率]*[@影響度]>=6,"中","低"))

見直し超過列（次回見直し日を過ぎた監視中の行）：
=IF(AND([@状態]="監視中",[@次回見直し日]<TODAY()),"超過","")

ランク高で監視中の件数（定例の報告用）：
=COUNTIFS(リスク[ランク],"高",リスク[状態],"監視中")

条件付き書式（行全体を色付け・数式を使用）：
=$F2="高"

条件付き書式の例は、F列がランク列の場合です。列の位置に合わせて書き換えてください。しきい値の15と6は、5段階×5段階で高・中・低がおおむね3分の1ずつになる値の例で、自社の過去案件に合わせて調整します。複数案件の進捗表やガントチャートとあわせて1つのブックで管理する方法は、関連記事の「エクセルでプロジェクト管理する方法」を参照してください。

発注者と受託側でリスク管理表を共有するときの持ち方と更新の分担

システム開発を外注すると、受託側がリスク管理表を作り、定例で発注者に報告する形が多くなります。この形だけでは、受託側が書きにくいリスクが表から抜けます。発注者側のレビュー遅れ、現場部門の協力不足、予算の追加承認の見通しといった、発注者自身が原因になるリスクです。

決めておくべきなのは3点です。発注者側にもリスクを起票できる人を置く。発注者側が原因のリスクは発注者側の人をオーナーにする。評価基準の表はプロジェクト計画の段階で双方が合意し、途中で変えるときは定例の議事録に残す。

受託側の表に乗るだけでは、発注者側が見るべきリスクを自分で拾えないこともあります。一創の要件定義・RFP作成・PMO支援では、開発を請けない前提で発注者の側に立ち、リスクの洗い出しや評価基準の合意、定例でのリスク管理表の読み解きを支援しています。

よくある質問：リスク管理表のテンプレート・頻度と全社リスク管理との関係

リスク管理表を作るときによく寄せられる質問に、本文の内容を踏まえて答えます。

リスク管理表と課題管理表は1つの表にまとめてもよいですか？

関係者が少ない3か月程度の案件なら、「種別」列でリスクと課題を分けて1つの表にしても回ります。ただ、リスクは発生確率・影響度・予兆を持ち、課題は期限・完了日・確認者を持つため、1つにすると空欄の列が増える構造です。半年以上の案件や社外の受託先が入る案件では表を分け、顕在化したリスクを課題管理表へ移して番号で紐づける運用にした方が、どちらの表も読みやすく保てます。

リスク管理表の無料テンプレートはそのまま使えますか？

使えますが、確かめたい点が3つあります。予兆（トリガー）の列があるか、発生時の対応が予防策と別の列になっているか、発生確率と影響度の段階ごとの定義がシートに書かれているかです。この3つが無いテンプレートは、評価が人によってぶれ、顕在化に気づくのも遅れます。足りない列を足し、評価基準の表を別シートに置いてから使い始めてください。

リスク管理表はどのくらいの頻度で更新すればよいですか？

週次の定例でランク高のリスクの予兆を確認し、工程の区切りで全件を見直すのが基本です。仕様変更や体制変更があったときは、その都度関係するリスクを評価し直します。1か月以上、どの行も書き換えられていない表は、プロジェクトの実態から外れていると考えてください。更新日を列に持っておくと、放置されている行をフィルタで抜き出せます。

リスクの洗い出しはどう進めればよいですか？

WBSの作業ごとに「この作業が止まる原因は何か」を問う方法が、漏れが少なく進めやすい形です。発注者と受託側の両方から人を集め、過去の同種案件で起きた問題を持ち寄ってください。分類（要件・技術・体制・外部・発注者側）ごとに1件以上出ているかを最後に確かめると、受託側だけでは出にくい発注者側のリスクも拾えます。作業の分解はWBSの作り方の手順が下敷きになります。

プロジェクトのリスク管理表と全社のリスクマネジメントは何が違いますか？

プロジェクトのリスク管理表は、そのプロジェクトの期日・費用・品質への影響を扱い、プロジェクトが終われば閉じます。全社のリスクマネジメントは、災害・情報漏えい・法令違反など、事業の継続に関わるリスクを継続的に扱います。プロジェクトで見つけたリスクのうち、システム稼働後も残るもの（障害時の業務停止など）は、全社のリスク管理や事業継続計画へ引き継いでください。

関連記事

• 課題管理表の作り方：必要な項目とステータス設計、Excelで破綻する条件：顕在化したリスクの移し先になる課題管理表の列とステータス
• WBSとは？書き方・作り方の5ステップとシステム開発の例、ガントチャートとの違い：リスクの洗い出しの下敷きになる作業分解
• PMOとは？役割・種類とPMとの違い｜システム開発でPMOを外部に任せる判断：リスクと課題の管理を横断して担うPMOの役割
• エクセルでプロジェクト管理する方法｜管理表・ガントチャートの数式と複数案件の一元管理、無料テンプレートの注意点：リスク管理表と同じブックで扱う進捗管理表とガントチャート
• クライシスマネジメントとは？リスクマネジメント・BCPとの違いと危機対応の手順、事例：プロジェクトの外側にある全社の危機対応