提案書のリスク管理の書き方 ― 本業務に固有のリスクを予防策と発生時対応のセットで示すリスク一覧表

リスク管理の項目で評価者が見ているのは、「この業務の難しさを事前に分かっているか」と「問題が起きたときに慌てずに対処できるか」です。リスクを書くことは弱みを見せることではなく、業務を深く理解している証拠になります。

評価者の視点：ここで点が分かれる理由

自治体の評価基準でリスク管理に相当する項目は、「危機管理」「トラブル発生時の対応」「業務継続性」「課題発生時の対応方針」など、名称がさまざまです。着眼点として多いのは、①本業務に固有のリスクが具体的に想定されているか、②予防策と発生時の対応が明確か、③発注者への報告・協議の手順が示されているか、④災害・感染症・要員離脱などの非常時に業務を継続できるか、の4点です。国の運用ガイドラインでも、技術提案の評価で「的確性」と「実現性」を見る考え方が示されており、リスク管理の記述も「この業務の条件に合っているか」「本当に実行できるか」で読まれます。

満点に近い答案は、仕様書や発注者の事情から導いた固有のリスクが4〜6件あり、1件ごとに予防策・発生時対応・責任者・発注者への報告がそろっています。中間の答案は、表の形は整っていても「遅延」「品質低下」など一般名詞のリスクが並び、どの業務にも使い回せる内容になっています。低得点の答案は、リスクを列挙するだけで対応が「適切に対応します」で終わる、あるいはリスク管理の記述自体がありません。評価者は複数の提案書を並べて読むため、使い回しの文章はすぐに見分けられます。

想定リスクを具体的に挙げる

悪い例： スケジュール遅延、品質低下、情報漏えいなどのリスクに対し、適切に対応します。

良い例： 本業務の想定リスクと対応を次の表に示します。

想定リスク	発生可能性	影響	予防策	発生時の対応
職員ヒアリングの日程が確保できず現状分析が遅れる	中	中	契約直後に全対象課の候補日を一括調整する	書面アンケートに切り替え、不足分を後日補完する
既存システムの仕様が想定と異なり改修範囲が増える	中	大	フェーズ1で既存システムの事業者に仕様を確認する	影響範囲を整理し、優先度と代替案を添えて協議する
研修日に参加できない職員が多い	高	小	研修を複数回開催し、録画を共有する	個別の質問窓口を研修後1か月設ける
担当者の急な離脱	低	大	作業内容を課題管理表で共有し、属人化を防ぐ	副担当が即日引き継ぎ、2週間以内に後任を配置する

予防策と発生時対応をセットで書く

予防策だけでは「起きたらどうするのか」が分かりません。発生時対応だけでは「なぜ事前に防がないのか」と思われます。両方をそろえ、可能であれば発注者への報告タイミングも書きます。災害や感染症の流行などで対面作業ができない場合の代替手段は、事業継続の記述として別にまとめます。

業務種別ごとの典型リスク一覧

本業務に固有のリスクを考える出発点として、業務種別ごとによく挙げられるリスクを示します。これをそのまま写すのではなく、仕様書の条件に照らして「本業務ではどれが特に当てはまるか」「どんな形で起きるか」を具体化してください。

事業継続（災害・感染症・システム障害）の書き方

災害や感染症の流行は、提案者にも発注者にも同時に起きるリスクです。評価者が知りたいのは「そのとき業務が止まらないか」「止まった場合にどう再開するか」です。次の4点を書くと、業務継続の記述として形が整います。

1. 代替手段：対面作業をオンラインに切り替える、紙の配布を電子配布に変える、など。
2. 代替拠点・代替要員：自社の別拠点や在宅での業務継続、副担当による代行。
3. データの保全：作業データのバックアップ先と頻度、復旧までの目標時間。
4. 発注者との連絡手段：平時の連絡先がつながらない場合の第二連絡先、安否と業務状況の報告期限。

悪い例： 災害時にはBCPに基づき対応します。

良い例： 大規模災害や感染症の流行で対面作業ができない場合、ヒアリングと定例会はオンラインに切り替え、工程への影響を1週間以内に貴課へ報告します。作業データは毎日、貴市の承認を得たバックアップ先（暗号化したクラウドストレージ）へ保存し、本社が使用できない場合は在宅勤務と支社拠点で業務を継続します。なお、貴市が災害対応で業務を一時停止する判断をされた場合は、再開時期と工程の組み直し案を速やかにご提示します。

なぜ良いか： 「BCP」という言葉で済ませず、代替手段・拠点・データ保全・連絡手段が具体的に書かれています。発注者側が停止を判断する場合まで想定しており、自治体の実情を理解していることが伝わります。

発注者側要因のリスクを責任転嫁にならずに書く

自治体業務の遅延原因としてよく挙げられるのは、発注者側の確認・決裁・庁内調整に時間がかかることです。これをリスクとして書くこと自体は問題ありませんが、「貴市の確認が遅れると納期を守れません」と読める書き方は反感を買います。コツは、①主語を「事象」にする、②自社が先回りしてできることを予防策に置く、③発生時は「協議して工程を組み直す」と書き、相手を責める表現を避ける、の3点です。

悪い例： 貴市側の承認が遅れた場合、スケジュールが遅延するリスクがあります。その場合の責任は貴市にあるものとします。

良い例： 設計書の承認に庁内の関係課照会が必要となり、確認期間が想定より長くなる可能性があります。予防策として、設計の中間段階で関係課向けの説明会を当社が開催し、承認前に論点を解消します。確認期間が2週間を超える見込みとなった場合は、後続工程の並行実施案を添えて貴課と協議し、納期への影響を最小化します。

なぜ良いか： 主語が「確認期間」という事象になり、提案者が自分でできる予防策（説明会の開催）を示したうえで、発生時は協議と並行実施で吸収する姿勢を見せています。責任の所在を論じていない点が、評価者の安心につながります。

この項目の標準構成（テンプレート）

リスク管理の項目は、「リスクの洗い出し方法（1〜2文）→リスク一覧表→事業継続の記述（1段落）→リスクの見直し時期（1文）」の順で構成します。中心となるリスク一覧表は、次の6列で作ると評価者が確認しやすくなります。

表の前の「リスクの洗い出し方法」と、表の後の「リスクの見直し時期（定例会で毎月更新など）」を添えると、リスク管理が一度きりではなく運用の仕組みになっていることが伝わります。

書き換え手順（チェックリスト）

• 仕様書・募集要項・発注者の公開資料から、本業務に固有のリスクを4〜6件抽出したか
• 各リスクが「原因＋結果」の一文になっているか（「遅延」などの一般名詞だけになっていないか）
• 発生可能性と影響を3段階で付け、影響の大きいものから並べたか
• 予防策に「いつ・誰が」が入っているか
• 発生時の対応に、発注者への報告期限と協議の手順が入っているか
• 責任者の役割名が体制表と一致しているか
• 災害・感染症・システム障害などの事業継続の記述があるか
• 発注者側要因のリスクが責任転嫁の表現になっていないか
• リスク一覧の見直し時期（定例会での更新など）を書いたか
• 「適切に対応します」「万全を期します」で終わる文が残っていないか

業務種別ごとの例文

IT導入

悪い例： データ移行については、細心の注意を払って実施し、トラブルのないよう努めます。

良い例： 現行システムからのデータ移行では、住所の表記ゆれや外字が原因で取り込みエラーが発生するリスクがあります（発生可能性：高、影響：中）。予防策として、フェーズ1で全件の事前クレンジングと外字の対応表作成を行い、移行リハーサルを2回実施します。本番移行でエラーが残った場合は、エラー一覧を当日中に貴課へ提出し、手修正と再取込を3営業日以内に完了します。責任者：移行担当C。

なぜ良いか： 「トラブル」を「表記ゆれ・外字による取り込みエラー」と特定し、リハーサル回数・報告期限・修正期限という数字で対応力を示しています。

イベント・広報

悪い例： 荒天の場合は、貴市と協議のうえ対応を決定します。

良い例： 屋外開催のため荒天による中止・延期のリスクがあります（発生可能性：中、影響：大）。予防策として、開催2週間前に予備日と屋内代替会場を貴課と確定し、前日正午の気象情報で開催可否を判断する基準（警報発表時は中止）を募集案内に明記します。中止の場合は、当日7時までに公式サイト・SNS・申込者へのメールで周知し、出演者と会場のキャンセル条件は契約時に取り決めておきます。責任者：運営責任者A。

なぜ良いか： 判断基準・判断時刻・周知手段が決まっており、「協議して決める」より前に判断の枠組みを提案者側が用意しています。キャンセル条件の事前取り決めは、費用面のリスクまで見ていることを示します。

調査・計画策定

悪い例： アンケートの回収率が低い場合は、回収率向上に努めます。

良い例： 住民アンケートの回収率が目標の40%に届かないリスクがあります（発生可能性：中、影響：中）。予防策として、郵送に加えてWeb回答を併用し、発送2週間後に未回答者へ督促はがきを送付します。発送3週間時点で回収率が30%未満の場合は、貴課と協議のうえ回答期間を1週間延長し、分析工程を圧縮して全体工程を維持します。責任者：調査担当B。

なぜ良いか： 目標値と判断時点、追加施策、工程での吸収方法が具体的で、回収率が低くても計画策定に支障が出ないことを評価者が確認できます。

よくある失敗パターンと処方箋

AIに書き直させるときの指示例

以下の「リスク管理」の下書きを、評価者が「本業務の難しさを分かっている」と判断できる内容に書き直してください。
条件：
1. 添付の仕様書の情報から、本業務に固有のリスクを4〜6件に絞る。「遅延」「品質低下」など一般名詞だけのリスクは書かない。
2. 各リスクを「リスク（原因＋結果）／発生可能性（高・中・低）／影響（大・中・小）／予防策（いつ・誰が）／発生時の対応（発注者への報告期限を含む）／責任者」の6列の表（Markdown表）にする。
3. 災害・感染症で対面作業ができない場合の事業継続（代替手段・拠点・データ保全・連絡手段）を1段落追加する。
4. 発注者側要因のリスクは主語を事象にし、責任転嫁の表現を避ける。
5. 「適切に対応します」「万全を期します」は使わない。
6. です・ます調。発注者は「貴市」、自社は「当社」と書く。
下書き：
（ここに貼り付け）
仕様書の条件（既存システム・対象者・時期など）：
（ここに貼り付け）

よくある質問