リスク管理表のテンプレートと書き方 リスク一覧60例と評価基準

リスク管理表とは、「まだ起きていないが、起きると計画に影響する出来事」を一覧にし、発生確率・影響度・対応策・担当を決めておく表です。 起きてから考えるのではなく、起きる前に手を打つ順番を決めるために使います。

この記事では、システム開発を題材に、工程別のリスク一覧60例、確率と影響度の5段階判定基準、5×5マトリクス、スコアと優先度を出すExcel数式、4つの対応方針の記入例、期待金額（EMV）の計算例をまとめました。60例はタブ区切りの表でも載せているので、表計算ソフトに貼ってそのまま自分の表の下書きにできます。

確認環境：Excel の数式は LibreOffice Calc 24.2.7 で計算して結果を確かめました（Excel と共通の関数だけを使用）。期待金額の計算例は Python 3.11 で実行しました。

リスク管理表の早見表（列と書くこと）

リスク管理表の書き方：1行を「原因・出来事・影響」で書く

リスクの欄は、次の型に当てはめると具体的になります。

（原因）のため、（出来事）が起きる可能性があり、起きると（影響）になる。

表の列が多くなるときは、リスクの欄に「出来事」、兆候の欄に「原因から見える合図」、影響度の判定メモに「影響」を分けて書きます。この記事の60例はこの分け方です。

兆候（トリガー）の欄があると、定例の場で「合図が出ているか」を確かめるだけで見直しが進みます。 兆候は「〜が増える」「〜が決まっていない」のように、見ればわかる事実で書きます。

リスクと課題の違い

発生確率と影響度の5段階判定基準

人によって点数がばらつかないよう、数値の目安を先に決めておきます。次の表は目安の例です。規模に合わせて数値を書き換えて使います。

発生確率の判定基準

影響度の判定基準

納期・費用・品質と範囲の3つの観点で判定し、最も点数の高い観点を影響度として採用します。

5×5リスクマトリクスの早見表

スコアは「確率×影響度」、優先度は A（15以上）・B（10〜14）・C（5〜9）・D（4以下）の4段階です。

3×3 のマトリクスに比べて、5×5 は「中」に集まりがちな評価を分けられます。一方で判定に迷いやすくなるので、上の判定基準の表とセットで使うのがポイントです。

スコアと優先度を出すExcel数式

列の並びは早見表のとおり（E列：確率、F列：影響度、G列：スコア、H列：優先度）です。2行目に次の式を入れ、最後の行までコピーします。

G2 : =E2*F2
H2 : =IFS(G2>=15,"A",G2>=10,"B",G2>=5,"C",TRUE,"D")

IFS は条件を上から順に調べ、最初に当てはまったものの値を返します。最後の TRUE,"D" は「どれにも当てはまらないとき」の指定です。Microsoft のサポートページによると、IFS は Excel 2019 以降と Microsoft 365 で使え、当てはまる条件が1つもないと #N/A になります。IFS のない版では、次の IF の入れ子で同じ結果になります。

H2 : =IF(G2>=15,"A",IF(G2>=10,"B",IF(G2>=5,"C","D")))

「確率は低いが、起きたら影響が非常に大きい」リスクを埋もれさせたくない場合は、影響度5を B 以上に引き上げる形にします。

H2 : =IF(AND(F2=5,G2<10),"B",IFS(G2>=15,"A",G2>=10,"B",G2>=5,"C",TRUE,"D"))

計算結果

IFS の式と IF の入れ子の式は、後述の60例すべてで同じ優先度になりました。

優先度で行に色を付ける（条件付き書式）

表の範囲（A2:M61）を選び、数式を使うルールを3つ登録します。

$H2 と列だけを固定すると、行のどのセルから見ても H列の優先度を参照します。

件数を集計する式

回避・軽減・転嫁・受容：4つの対応方針と記入例

対応方針は、広く使われている次の4つに分けると選びやすくなります。

4方針の記入例

転嫁は「リスクがなくなる」わけではなく、影響の受け持ち方を決める方針です。 委託した作業の進み具合は、中間の成果物で確かめ続けます。受容も「何もしない」ではなく、「起きたときの動きと予備を決めたうえで見守る」 と書いておくと、表の読み手に意図が伝わります。

方針を選ぶ判断表

開発工程別のリスク一覧60例

要件・設計・実装・テスト・移行・体制・外部依存の7分類で、合わせて60例です。確率と影響度は一般的な目安として入れてあります。自分の計画に当てはめるときは、判定基準の表を見ながら点数を付け直してください。スコアと優先度は、前の章の数式で計算した結果です。

要件のリスク（9例）

設計のリスク（9例）

実装のリスク（9例）

テストのリスク（9例）

移行のリスク（8例）

体制のリスク（8例）

外部依存のリスク（8例）

60例の集計結果

前の章の集計の式を使って、60例を数えた結果です。

マトリクスの各マスに入る件数（COUNTIFS の結果）は次のとおりです。

優先度Aは6件（R-001・R-004・R-011・R-028・R-037・R-038）です。 要件の範囲、非機能要件、外部とのインターフェース、テスト期間、移行データ、移行時間と、上流と終盤に集まっています。60件すべてに同じ力をかけるのではなく、まずこの6件の対応策・担当・期限を決めるところから始めると、表が動き出します。

貼り付け用テンプレート（タブ区切り・60例入り）

次のブロックをコピーして、表計算ソフトの A1 に貼り付けます。G列（スコア）と H列（優先度）は空にしてあるので、貼り付けたあとで G2・H2 に前の章の式を入れ、最後の行までコピーします。当てはまらない行は消し、自分の計画に固有のリスクを足して使います。

No  工程  リスク 兆候  確率  影響度 スコア 優先度 対応方針    対応策 担当  期限  状態
R-001   要件  要件の範囲が開発の途中で増える 打ち合わせのたびに新しい要望が出る   4   4           軽減  変更管理の手順を決め、追加の要望は影響を見積もってから採否を決める           未対応
R-002   要件  利用部門ごとに要望が食い違う  部門によって回答が異なり、決定が持ち越される  3   4           軽減  決定権者を1人決め、論点と決定を一覧にして週次で確定する            未対応
R-003   要件  業務ルールの例外が後から見つかる    「この場合は別」という発言が増える   4   3           軽減  例外パターンを洗い出す会を早めに設け、業務フローに分岐として書く            未対応
R-004   要件  性能や可用性などの非機能要件が決まらない    目標値の欄が空のまま設計に入ろうとしている   3   5           軽減  項目一覧を使って目標値を仮置きし、期限を切って合意する         未対応
R-005   要件  要件の承認が予定日に取れない  レビューの日程が決まらない、指摘への回答が遅い 3   4           軽減  承認の手順と期限を計画書に書き、まとまった単位ごとに部分承認を取る           未対応
R-006   要件  現行システムの仕様書がなく挙動がわからない   質問に答えられる人が限られている    3   4           軽減  現行の画面とデータを調べる期間を計画に入れ、調査結果を文書にする            未対応
R-007   要件  法令や社内規程の改定で要件が変わる   改定の予告や検討の通知が出る  2   4           受容  改定の時期を定期的に確かめ、発生時は変更として扱えるよう予備日を持つ          未対応
R-008   要件  画面のイメージが合意できていない    文章の説明だけで話が進んでいる 3   3           軽減  早い段階で画面の試作を見せ、操作の流れを確かめてもらう         未対応
R-009   要件  優先度が決まらずすべてが必須になる   要望一覧の優先度がすべて「高」になっている   4   3           回避  初回リリースの範囲を必須の機能に絞り、残りは次の段階に回す合意を取る          未対応
R-010   設計  採用する技術が要件を満たせない 試作で想定どおりの性能や機能が出ない  2   5           回避  設計の前に小さな検証を行い、満たせない場合は別の技術に切り替える            未対応
R-011   設計  外部システムとのインターフェース仕様が確定しない    相手側の仕様書の版が頻繁に変わる    4   4           軽減  仕様を合意する期限を決め、変換処理を1か所にまとめて変更の影響を小さくする           未対応
R-012   設計  データモデルの変更が後工程で発生する  レビューで項目の追加が続く   3   4           軽減  主要な画面と帳票で必要な項目を突き合わせてから確定する         未対応
R-013   設計  性能の見積もりが甘く応答が遅くなる   データ件数の想定が決まっていない    3   4           軽減  想定件数と目標の応答時間を決め、早い段階で負荷をかけて測る           未対応
R-014   設計  設計書の粒度が人によってばらつく    レビューの指摘が書き方に集中する    4   2           軽減  記入例つきのひな形とレビューの観点表を用意する         未対応
R-015   設計  セキュリティの要件が設計に反映されない 認証や権限の設計が後回しになっている  2   5           軽減  設計レビューにセキュリティのチェックリストを組み込む          未対応
R-016   設計  共通部品の設計が遅れて各機能が待たされる    共通部品の担当者が他の作業と掛け持ちしている  3   4           軽減  共通部品に先行して着手し、仮のインターフェースを先に公開する          未対応
R-017   設計  画面数や帳票数が見積もりより増える   設計中に画面一覧の行が増え続ける    3   3           軽減  一覧の件数を毎週記録し、増えた分は変更管理に載せる           未対応
R-018   設計  設計レビューの指摘が収束しない 同じ箇所に繰り返し指摘が出る  3   3           軽減  指摘を分類して根本の原因を直し、レビューの完了条件を決める           未対応
R-019   実装  担当者のスキルと作業の難しさが合わない 見積もりより時間がかかる作業が続く   3   3           軽減  ペア作業や事前の学習時間を計画に入れ、難しい箇所は経験者が受け持つ           未対応
R-020   実装  利用しているライブラリに不具合や脆弱性が見つかる    公開元から修正版や注意喚起が出る    3   3           軽減  依存ライブラリを一覧にし、更新の有無を定期的に確かめる         未対応
R-021   実装  開発環境の構築に時間がかかる  新しく入った人が着手できるまで数日かかる    4   2           軽減  環境構築の手順をスクリプトにし、手順書を最新に保つ           未対応
R-022   実装  コードの品質がばらつき手戻りが増える  レビューで同じ種類の指摘が繰り返される 3   3           軽減  コーディング規約と自動チェックを導入し、レビューの観点をそろえる            未対応
R-023   実装  作業の進み具合が見えにくい   「あと少し」という報告が続く  4   3           軽減  作業を小さく分け、完了の条件で進捗を判定する          未対応
R-024   実装  ブランチの統合で競合が多発する 統合に半日以上かかることがある 3   2           軽減  短い周期で統合し、自動ビルドで早く気づけるようにする          未対応
R-025   実装  仕様の解釈違いで作り直しになる 質問が出ないまま実装が進んでいる    3   4           軽減  着手前に受け入れ条件を確かめ、途中で動くものを見せる          未対応
R-026   実装  生成AIが出力したコードに誤りが混ざる レビューを通さずに取り込まれるコードが増える  3   3           軽減  人によるレビューと自動テストを必ず通す決まりにする           未対応
R-027   実装  ライセンス条件に合わない部品を使ってしまう   出どころのわからないコードが見つかる  2   4           回避  利用できるライセンスを決め、導入の前に確かめる手順を置く            未対応
R-028   テスト 前工程の遅れでテスト期間が短くなる   実装の完了日が後ろにずれている 5   4           軽減  優先度の高いテストから実施し、範囲を縮める判断基準を先に決める         未対応
R-029   テスト テストデータが用意できない   本番に近いデータの提供元が決まらない  3   3           軽減  データの作成方法と担当を計画に入れ、個人情報は加工して使う           未対応
R-030   テスト テスト環境が本番と異なり不具合を見落とす    環境ごとの設定の違いが一覧になっていない    3   4           軽減  環境の差分を一覧にし、構成をコードで管理する          未対応
R-031   テスト 不具合の件数が想定を上回る   検出件数が日ごとに増え続ける  3   4           軽減  件数の推移を毎日見て、原因の多い箇所を集中的に見直す          未対応
R-032   テスト 修正によって別の箇所が動かなくなる   修正後に、以前通ったテストが通らなくなる    3   3           軽減  回帰テストを自動化し、修正のたびに実行する           未対応
R-033   テスト 性能テストで目標値に届かない  少量のデータでも応答が遅い画面がある  3   4           軽減  早い時期に一度測り、調整の期間を計画に入れる          未対応
R-034   テスト 受け入れテストの担当者の時間が取れない 日程の調整に返事がない 3   4           軽減  早めに日程を押さえ、テストの手順と期待結果を先に渡す          未対応
R-035   テスト テストケースに抜けがある    要件とテストケースの対応が取れていない 3   3           軽減  要件とテストケースの対応表を作り、レビューで確かめる          未対応
R-036   テスト 不具合の修正版の確認が滞る   「修正済み・確認待ち」の件数が増えている    3   2           軽減  確認の担当と期限を決め、滞留日数を毎週確かめる         未対応
R-037   移行  移行データに想定外の値や欠けがある   調査で形式の異なるデータが見つかる   4   4           軽減  早期に全件を調べ、変換ルールと例外の扱いを決める            未対応
R-038   移行  移行にかかる時間が切り替えの時間枠に収まらない リハーサルの所要時間が見込みを超える  3   5           軽減  リハーサルで時間を測り、分割移行や事前移行を検討する          未対応
R-039   移行  切り替え後に元へ戻す手順がない 切り戻しの条件が計画に書かれていない  2   5           軽減  切り戻しの判断基準と手順を決め、リハーサルで試す            未対応
R-040   移行  利用者への周知や教育が間に合わない   説明会の日程が決まっていない  3   3           軽減  操作マニュアルと説明会を計画に入れ、問い合わせ窓口を用意する          未対応
R-041   移行  現行システムとの並行稼働の期間が延びる 切り替えの判定条件があいまいになっている    3   3           軽減  並行稼働を終える条件を数値で決める           未対応
R-042   移行  本番環境の作業で手順の誤りが起きる   手順書が作業者以外に確認されていない  2   5           軽減  手順書を2人で読み合わせ、リハーサルと同じ手順で行う          未対応
R-043   移行  移行後のデータの件数や合計が合わない  照合の方法が決まっていない   3   4           軽減  件数と合計値の照合項目を決め、照合の仕組みを用意する          未対応
R-044   移行  切り替え日が利用部門の繁忙期と重なる  業務の予定表との照合がされていない   2   4           回避  業務の予定を確かめ、繁忙期を外して日程を組む          未対応
R-045   体制  中心となるメンバーが離任する  特定の人にしかわからない作業がある   2   5           軽減  作業を2人以上で受け持ち、設計の経緯を文書に残す            未対応
R-046   体制  要員の確保が予定より遅れる   参加の予定日が確定していない  3   4           軽減  必要な時期とスキルを早めに伝え、着手の順序を入れ替えられるようにする          未対応
R-047   体制  体調不良や休暇で作業が止まる  代わりに作業できる人がいない  4   2           受容  日程に予備日を持ち、発生時は優先度の低い作業を後ろに回す            未対応
R-048   体制  役割と責任の分担があいまい   「誰が決めるのか」がたびたび話題になる 3   3           軽減  役割分担表を作り、決定する人と相談を受ける人を明記する         未対応
R-049   体制  情報共有が不足して認識がずれる 同じ質問が繰り返される 3   3           軽減  定例の会議と議事録の共有先を決め、決定事項を1か所にまとめる          未対応
R-050   体制  複数の作業を掛け持ちして時間が取れない 予定した作業時間に届かない週が続く   4   3           軽減  割り当ての割合を合意し、毎週の作業時間を確かめる            未対応
R-051   体制  長時間の作業が続き生産性が下がる    作業時間の長い週が続いている  3   4           軽減  作業時間を毎週確かめ、範囲と日程を早めに見直す         未対応
R-052   体制  意思決定に時間がかかる 承認待ちの課題が増えている   3   4           軽減  判断の期限と、期限を過ぎた場合に上位へ相談する経路を決める           未対応
R-053   外部依存    委託先の納品が遅れる  中間報告が遅れる、進捗の数値が変わらない    3   4           転嫁  納期と品質の基準、遅れた場合の扱いを契約に明記し、中間の成果物で確かめる            未対応
R-054   外部依存    外部サービスの仕様や料金体系が変わる  提供元から変更の予告が出る   2   3           受容  変更の通知を受け取る設定にし、発生時は変更として扱う          未対応
R-055   外部依存    クラウドサービスの障害で作業が止まる  提供元の稼働状況のページに障害の情報が出る   2   3           受容  復旧を待つ間に進められる作業を決めておく            未対応
R-056   外部依存    機器やライセンスの納期が遅れる 見積もりの回答に時間がかかっている   3   4           回避  納期の長いものを先に手配し、代わりの構成も用意する           未対応
R-057   外部依存    連携先システムのテスト環境が使えない  利用の申請に時間がかかっている 3   4           軽減  利用の日程を早めに調整し、代わりに応答を返す模擬サーバーを用意する           未対応
R-058   外部依存    製品のサポート終了が稼働期間中に来る  提供元がサポート期限を公表している   1   4           回避  サポート期限が稼働期間を満たす版を選ぶ         未対応
R-059   外部依存    運用を担う部門への引き継ぎが間に合わない    運用の担当者が決まっていない  3   4           軽減  運用の担当を早めに決め、手順書の作成とリハーサルを計画に入れる         未対応
R-060   外部依存    専門性の高い作業を社内で担えない    経験者がおらず調査に時間がかかっている 3   4           転嫁  専門の会社に作業を委託し、責任の範囲と成果物を契約で決める           未対応

期待金額（EMV）と予備費の計算例

期待金額（EMV：Expected Monetary Value）は、「発生確率×起きたときの影響金額」 で求める金額です。リスクごとの期待金額を合計すると、リスクに備える予備費の目安になります。

一覧から選んだ代表的な5件に、確率と影響金額を当てはめた例です。確率は5段階の判定基準の範囲から代表値を選んでいます（確率4→60％、確率3→40％、確率2→20％）。金額は説明用の数値です。

risks = [
    ("R-037 移行データに想定外の値や欠けがある", 0.6, 120),
    ("R-001 要件の範囲が開発の途中で増える", 0.6, 200),
    ("R-038 移行時間が時間枠に収まらない", 0.4, 150),
    ("R-053 委託先の納品が遅れる", 0.4, 100),
    ("R-045 中心となるメンバーが離任する", 0.2, 300),
]

total_impact = 0
total_emv = 0.0
for name, prob, impact in risks:
    emv = prob * impact
    total_impact += impact
    total_emv += emv
    print(f"{name}: {prob:.0%} × {impact}万円 = {emv:.0f}万円")

print(f"影響金額の合計: {total_impact}万円")
print(f"期待金額（EMV）の合計: {total_emv:.0f}万円")

budget = 3000
print(f"予算{budget}万円に対する割合: {total_emv / budget:.1%}")

# 対応策を打った後（軽減で確率を下げ、対応費用を足す）
after = [
    ("R-037", 0.3, 120, 20),
    ("R-001", 0.3, 200, 10),
    ("R-038", 0.2, 150, 15),
    ("R-053", 0.4, 100, 0),
    ("R-045", 0.2, 300, 0),
]
emv_after = sum(p * i for _, p, i, _ in after)
cost = sum(c for *_, c in after)
print(f"対応後のEMV: {emv_after:.0f}万円 / 対応費用: {cost}万円 / 合計: {emv_after + cost:.0f}万円")
print(f"対応前との差: {total_emv - (emv_after + cost):.0f}万円")

実行結果：

R-037 移行データに想定外の値や欠けがある: 60% × 120万円 = 72万円
R-001 要件の範囲が開発の途中で増える: 60% × 200万円 = 120万円
R-038 移行時間が時間枠に収まらない: 40% × 150万円 = 60万円
R-053 委託先の納品が遅れる: 40% × 100万円 = 40万円
R-045 中心となるメンバーが離任する: 20% × 300万円 = 60万円
影響金額の合計: 870万円
期待金額（EMV）の合計: 352万円
予算3000万円に対する割合: 11.7%
対応後のEMV: 226万円 / 対応費用: 45万円 / 合計: 271万円
対応前との差: 81万円

読み取れることは3つです。

• 5件すべてが起きた場合の影響は870万円、期待金額の合計は352万円。全部が同時に起きる前提で予備を積むと過大になり、ゼロでは足りません。期待金額の合計が、その間の目安になります
• 予算3,000万円に対して11.7％。予備費を「予算の一律10％」と決める前に、主要なリスクから積み上げた値と比べると根拠を説明しやすくなります
• 対応策に45万円かけて確率を下げると、期待金額との合計は271万円。対応前の352万円より81万円小さいので、この対応策は費用に見合うと判断できます

Excel では、確率を B2:B6、影響金額を C2:C6 に入れて次の式で同じ合計が出ます。

=SUMPRODUCT(B2:B6,C2:C6)

上の5件を入れて計算した結果は 352 で、Python の結果と一致しました。

期待金額を使うときの注意点

リスク管理表の運用：いつ・誰が・何を見るか

表は作ったあとの見直しで価値が出ます。次の流れを定例に組み込みます。

状態の列は、次の5つに決めておくと集計しやすくなります。

よくある質問

Q. リスクは何件くらい挙げればよいですか？ A. 件数の決まりはありません。最初は工程別の一覧から当てはまるものを20〜30件選び、優先度A・Bに絞って対応策を決めると進めやすくなります。件数を増やすことより、毎週見直せる量に保つことを優先します。

Q. 確率と影響度の点数が人によって違うときはどうしますか？ A. 判定基準の表を見ながら、それぞれが点数を付けた理由を出し合います。違いが出た行は「前提の見方が違う」ことが多いので、兆候の欄や影響の見積もりを具体的に書き直すと点数がそろいます。

Q. 3×3 と 5×5 のどちらを使うとよいですか？ A. 件数が少なく短期間の作業なら 3×3 で十分です。件数が30件を超える、または「中」に評価が集まって順番が付けにくいときは 5×5 にすると差が見えます。途中で切り替えるときは、判定基準の表も一緒に作り直します。

Q. スコアが同じリスクはどちらを先に対応しますか？ A. 影響度の高いほうを先にします。確率は対応策で下げやすい一方、影響度は起きてからでは変えにくいためです。並べ替えのキーを「スコアの降順、影響度の降順」にしておくと、表の上から順に見ていけます。

まとめ

• リスク管理表は「まだ起きていない出来事」に、確率・影響度・対応策・担当を決めておく表。起きたら課題管理表に移す
• 1行は「原因・出来事・影響」で書き、兆候の欄を設けると、定例で合図を確かめるだけで見直しが進む
• 確率と影響度は5段階の判定基準を先に決める。影響度は納期・費用・品質と範囲のうち最も高い点数を採用する
• スコアは =E2*F2、優先度は =IFS(G2>=15,"A",G2>=10,"B",G2>=5,"C",TRUE,"D") で出し、条件付き書式で行に色を付ける
• 対応方針は回避・軽減・転嫁・受容の4つ。受容も「起きたときの動きと予備」を書いておく
• 工程別の60例を計算すると、優先度Aは6件。まずその対応策・担当・期限を決める
• 期待金額（EMV）は確率×影響金額。合計を予備費の目安にし、対応策の費用と比べて判断する

参考

• Microsoft サポート「IFS 関数」 https://support.microsoft.com/ja-jp/office/ifs-関数-36329a26-37b2-467c-972b-4a39bd951d45

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。