官公庁システムのRFP（提案依頼書）と要件定義書は、現場の業務を押さえ、要件と責任を線引きし、移行と運用を詰める順に進めると、記載する内容と粒度が定まります。
行政側のRFPでは、機能要件、SLA、データ移行、調達と運用の要件が中心です。全体像は官公庁のシステムの完全ガイドもご覧ください。
▼全体ガイドの記事
・官公庁のシステムの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
機能要件と非機能要件の整理
RFPと要件定義書の骨格は、機能要件と非機能要件の二つです。機能要件はシステムが行う処理を定め、非機能要件は性能や品質の水準を定めます。さらに、官公庁では、標準仕様書に沿う機能と行政に必要な品質を、漏れなく記述します。
標準仕様書を踏まえた機能要件の記述
機能要件は、住民記録・税・福祉などの業務ごとに必要な処理を列挙します。その土台になるのが、国の標準仕様書です。
- 必須要件：必ず満たすべき機能
- 任意要件：あれば望ましい機能
標準仕様書の要件数は平均で1.2倍、一部業務では3倍以上に膨らんでいます。そのため、すべてを転記するのではなく、自組織に必要な機能を選びます。必須要件と任意要件を分けて示しておくと、ベンダーの提案を評価しやすくなります。
一方で、独自運用が必要な部分は、標準仕様との差分を明確にします。この取捨選択が、Fit&Gap分析を踏まえた機能要件の出発点になります。
自組織の業務の流れを書き出し、現状（AsIs）とあるべき姿（ToBe）を描いて、要件に落とし込みます。業務と要件がずれたままだと、導入後に利用が伸びない原因になります。
性能・可用性・セキュリティの非機能要件
非機能要件では、性能、可用性、セキュリティ、障害時の復旧目標などを定めます。行政は住民の重要情報を扱うため、これらには高い水準が求められます。
- 性能：窓口の繁忙期にも処理が滞らない基準
- 可用性：長時間の停止を許さない稼働基準
- セキュリティ：不正アクセスを防ぐ基準
各基準は定量的に書きます。「高い可用性を確保すること」とだけ書くと、ベンダーごとに解釈が分かれ、提案価格や品質にばらつきが生じます。
稼働率の目標値、許容停止時間、障害時の復旧目標時間を明示すれば、提案を公平に比べることや、運用時の認識合わせにつながります。
非機能要件は、後述するSLA（サービス品質保証）の前提になります。そのため、RFPの段階で具体的に定めておきます。
現場ヒアリングとToBe設計を踏まえた要件化
機能要件は、現場の業務から逆算して組み立てます。窓口や内部事務の担当者には、業務のやり方を聞き取ります。
- 現状把握：処理の方法や無駄、手戻りを聞き取り、AsIsを洗い出す
- 要件化：ToBeを描き、システムでの実現方法を要件として定める
現場の業務から離れた要件は、導入後の利用率低迷を招きます。要件定義は技術作業である以前に、業務改革の設計です。
このため、発注側が現場との橋渡しを担い、現場の知見を要件に反映させる体制を整えます。
マルチベンダーSLAと責任分界点の設定
複数のベンダーが連携する行政システムでは、障害時の責任を分けるSLAと責任分界点の設定が欠かせません。他社の解説では扱いが手薄になりがちですが、実務では重要な論点です。
障害切り分けと責任分界点の明文化
ガバメントクラウドへの接続でエラーが起きたとき、市の側が原因を切り分ける実態が報告されています。各ベンダーは自社の範囲は正常だと主張し、発注側が板挟みになる構図です。
これを防ぐには、RFPで各ベンダーの責任範囲を線引きしておきます。領域ごとの担当と責任は、図や表で示します。
- 対象領域：ネットワーク、クラウド基盤、各業務システム、連携部分
- 障害時の窓口：最初に連絡する一次窓口と切り分けの主体
責任分界点は見落とされやすい一方、障害対応に長く影響します。そのため、要件定義で明文化しておくことが欠かせません。また、一次窓口と切り分けの主体を決めておけば、トラブル時の混乱も抑えられます。
SLAに盛り込むべき品質指標
SLAは、提供サービスの品質について発注側とベンダーが合意する取り決めです。品質指標は数値で定め、未達のときの扱いも書いておきます。
- 稼働率：サービスの稼働に関する指標
- 障害対応：一次対応までの時間と復旧目標時間
- 問い合わせ：問い合わせへの応答時間
非機能要件で定めた水準は、SLAで運用時の約束にします。また、複数のベンダーにまたがる連携部分の品質保証も論点になります。
各社が自社範囲のSLAを守っても、連携部分に問題があれば住民サービスは止まります。そのため、全体の品質を保証する主体を、RFPで問います。
SLAと責任分界点はセットで定めておくことが、行政システムを安定して運用する前提になります。
データ移行・過渡期連携の要件
標準化やガバメントクラウド移行を伴う刷新では、データ移行が成否を分けます。蓄積した台帳データの品質を保ちながら、移行中も業務を止めない設計が必要です。RFPでは軽視されやすい一方、実務では手間のかかるトラブルが起きやすい領域です。
データクレンジングと移行検証の要件
移行では、旧システムのデータ品質が問われます。クレンジング（不整合の修正）をせずに移すと、未納データの誤表示などが起き、住民の信頼を損ないます。
- 対象範囲：移行するデータの範囲
- 責任分担：誰がどこまでデータを整えるか
- 検証方法：件数照合や抽出比較による確認手順
責任が曖昧だと、移行直前に作業が破綻します。そのため、RFPの段階で誰が何を担うかを決め、検証の進め方も定めておきます。
移行は、本番前に複数回のリハーサルを重ねるのが定石です。そのうえで、回数と合否基準を要件に含め、移行後のデータが旧システムと一致するかを確かめます。データ移行は、品質を保証する工程として要件に組み込みます。
新旧混在期の過渡期連携要件
大規模な行政システムは一斉に切り替えるのが難しく、新旧システムが一定期間混在することがあります。その間も業務を止めない連携要件が必要です。
業務ごとの切り替え時期とデータ連携の方法は、移行スケジュールと一体で設計します。過渡期連携は平常時にはない一時的な仕組みのため、要件から漏れやすい領域です。設計がないまま移行すると、新旧のデータが食い違い、住民対応が混乱します。
- 移行の前提：新旧混在中も業務を止めない連携
- RFPで定めること：方式、連携期間、終了時期
移行計画の不備は、刷新時の大きなリスクになります。そのため、現実的な進め方を要件定義の段階で詰めておきます。
移行スケジュールと体制の要件
移行の要件と一体でスケジュールを定め、発注側の推進体制も要件設計に含めます。標準化やガバメントクラウド移行には国の期限があるため、完了時期から工程を逆算します。
- Fit&Gap分析：現行と標準仕様の差を確認
- データクレンジング：移行データを整える
- 移行リハーサル：本番前に、移行を複数回試す
- 本番移行：計画に沿って切り替える
各工程に現実的な期間を確保できるかが、成否を左右します。職員の業務見直しを伴うため、移行には現場の関与も欠かせません。
誰が意思決定し、誰が現場と橋渡しするかを明確にします。体制が曖昧だと、ベンダー任せになり、現場に合わないシステムになりかねません。
スケジュールと体制は要件の段階で決めておくことが、計画どおりに移行するための前提になります。
補助金・調達方式と紐づく要件
官公庁の調達では、調達方式と補助金制度が要件に関わります。選ぶ方式や補助金によって、RFPの条件と評価基準が変わります。そのため、要件定義の段階から、調達と財源の枠組みを意識します。
総合評価入札とプロポーザルの使い分け
行政の調達では、価格と技術提案を評価する総合評価一般競争入札や、提案を重視する公募型プロポーザルなどを使います。
たとえば、大阪市はガバメントクラウドの運用管理補助者を総合評価一般競争入札で単独調達しました。北九州市は観光AIチャットボットを公募型プロポーザルで調達しました。
要件の性質に応じて方式を選ぶことが、良い提案を引き出す前提になります。方式に応じて評価基準も変わります。
- 価格重視：仕様を明確に固定する
- 提案重視：課題と目指す姿を示す
- 共同調達：複数自治体で調達する
共同調達は、調達コストを抑え、ベンダーとの交渉力を高められる場合があります。そのうえで、自組織で進めるか近隣自治体と組むかを、要件設計の早い段階で検討します。
補助金適用を見据えた要件設計
補助金を使う場合は、補助対象の条件を満たすようにRFPを設計します。制度ごとに対象条件が異なるため、事前の確認が必要です。
- デジタル基盤改革支援補助金：補助対象の条件を確認
- 地域未来交付金：制度の対象になるかを確かめる
- 福井県のCO-FUKUI：最大300万円
- 大阪府のデジタル人材シェアリング：1プラン120万円のうち府が2分の1の60万円を補助
要件が補助条件に合うかを先に確認すると、財政負担を抑える判断につながります。
申請時期と対象経費は制度ごとに決まっているため、要件定義と申請のスケジュールを連動させます。要件が確定してから補助金を探すのではなく、補助金を見据えて要件と調達計画を組み立てます。
補助金、調達方式、要件を一体で設計することで、限られた予算でも成果を引き出せます。
運用・保守・定着支援の要件
導入後の成果を左右するのは、運用・保守・定着支援の要件です。システムは、運用の中で使われ続けてはじめて投資を回収できます。そのため、納品後の支援を要件定義で明確にしておくと、利用率の低迷を防ぐ助けになります。
保守範囲とFinOpsを見据えたコスト要件
保守要件では、どこまでを保守の対象にするかを明確にします。制度改正の多い行政では、範囲が曖昧だと追加費用が発生します。
- 保守範囲：障害対応、定期更新、法改正対応
- コスト評価：運用・保守・クラウド料を含むTCO
- コスト管理：利用状況を見ながら費用を最適に保つ（FinOps）
保守の範囲を決めておくと、想定外のコストを抑えやすくなります。クラウドを使う場合は、運用経費が膨らむ点にも注意します。
中核市59市では、運用経費が平均2.3倍に膨らみました。そのため、初期費用だけで判断しないことが大切です。
オンボーディング・定着支援の要件
定着支援には、操作研修に加えて、継続的なオンボーディングを盛り込みます。
- 利用状況の確認：月次の利用ログ分析
- 現場改善：ヒアリングとUI改善
- 成果確認：利用率や窓口待ち時間30%短縮の定量KPI
納品で関係が終わるベンダーでは利用率が伸びにくいため、運用を伴走する体制を求めます。KPIの達成状況も、定期的に確認します。
システムが止まったときの紙運用フローや、BCP（業務継続計画）に関わる要件も検討します。非常時にも住民サービスを止めないための備えになります。
運用・保守・定着支援を明文化しておくことが、導入後に使われるシステムの土台になります。
まとめ
官公庁システムのRFPと要件定義で押さえる論点は四つあり、まず機能要件と非機能要件、次にSLAと責任分界点です。残りの二つは、データ移行と過渡期連携（データクレンジングと移行検証を含む）、調達方式（総合評価入札やプロポーザルなど）と補助金になります。
他社の解説では手薄になりがちですが、特に責任分界点と過渡期連携は、実務で大きなトラブル源になりやすい論点です。要件定義の段階で最優先に詰める価値があります。
また、RFPでは、ベンダーに任せる範囲と発注側が決める範囲を分けておきます。現場業務から機能要件を組み立て、障害時の責任を線引きすることも欠かせません。
移行の品質保証と、調達・財源を揃えておくことも要件に含めます。そうすることで、提案を公平に比べられ、導入後のトラブルを減らすことにつながります。
riplaは、フルスクラッチ受託と国内開発の立場から、行政業務に即した要件整理と、移行・定着までの支援を一貫して行っています。全体像は完全ガイドをご覧ください。
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。