官公庁のシステムのRFP/要件定義書/提案依頼書について

官公庁のシステムを発注するとき、成否の大半を決めるのがRFP（提案依頼書）と要件定義書の質です。行政の調達は、公平性・透明性を担保するために仕様書を起点に進むため、要件があいまいなままRFPを出すと、ベンダーごとに提案の前提がバラバラになり、評価も比較もできません。さらに、標準化・ガバメントクラウド移行という制度変更や、マルチベンダー環境での責任分界、過渡期のデータ移行といった行政特有の論点を要件に織り込めるかどうかが、後のトラブルを左右します。

本記事は、官公庁のシステムのRFP・要件定義書・提案依頼書の作り方を、発注する行政側の視点で体系的に整理する「要件定義特化」の解説です。機能要件と非機能要件の整理、マルチベンダーでのSLA・責任分界点の設定、データ移行・過渡期連携の要件、そして補助金・調達方式と紐づく要件まで、一次データとあわせて具体的に解説します。読み終えるころには、自組織のRFPに「何を、どの粒度で書くべきか」の指針が持てるはずです。なお、官公庁システムの全体像をまだ把握していない方は、まず官公庁のシステムの完全ガイドから読むことをおすすめします。

▼全体ガイドの記事
・官公庁のシステムの完全ガイド

機能要件と非機能要件の整理

RFPと要件定義書の骨格をなすのが、機能要件と非機能要件の整理です。機能要件は「システムが何をするか」、非機能要件は「どのくらいの性能・品質で動くか」を定めます。官公庁では、標準仕様書に沿った機能の網羅性と、行政に求められる高い非機能水準の両方を、漏れなく記述する必要があります。

機能要件は、住民記録・税・福祉といった業務ごとに、必要な処理を具体的に列挙します。標準化の流れの中で、国の標準仕様書が機能の土台になりますが、標準仕様書の要件数は平均1.2倍、一部の業務では3倍以上に膨らんでいます。この膨大な要件をそのまま転記するのではなく、自組織の業務に必要な機能を取捨選択し、独自運用が必要な部分との差分を明確にすることが、Fit&Gap分析を踏まえた機能要件の出発点です。

機能要件を書く際に有効なのが、必須要件と任意要件の区別です。「必ず満たすべき機能」と「あれば望ましい機能」を分けて記述すると、ベンダーの提案を評価しやすくなります。あわせて、自組織の業務フローを可視化し、現状（AsIs）とあるべき姿（ToBe）を描いたうえで機能要件に落とし込むと、現場で本当に使われる要件になります。要件が現場の業務から乖離していると、導入後に利用率が伸びない原因になります。

非機能要件は、応答速度などの性能、システムの稼働率を示す可用性、個人情報を守るセキュリティ、障害時の復旧目標などを定めます。行政は住民の重要情報を扱うため、民間以上に高い水準が求められます。たとえば、窓口の繁忙期にも処理が滞らない性能、長時間の停止を許さない可用性、不正アクセスを防ぐセキュリティといった要件を、定量的な基準で記述する必要があります。

非機能要件を曖昧にすると、提案価格や品質に大きなばらつきが生じます。たとえば「高い可用性を確保すること」とだけ書くと、ベンダーによって解釈が分かれます。稼働率の目標値、許容される停止時間、障害発生時の復旧目標時間といった数値を明示することで、提案を公平に比較でき、運用フェーズの認識ずれも防げます。非機能要件は、後述するSLA（サービス品質保証）の前提にもなるため、RFPの段階でしっかり書き込むことが重要です。

機能要件を実効性あるものにするには、現場の業務から逆算して要件を組み立てることが欠かせません。窓口担当者や内部事務の担当者に「実際にどう業務を処理しているか」「どこに無駄や手戻りがあるか」を細かくヒアリングし、現状（AsIs）の業務フローを可視化します。そのうえで、あるべき業務の姿（ToBe）を描き、システムでどう実現するかを要件に落とし込みます。この手順を踏まないと、現場で使われない要件になりがちです。

現場不在のまま要件を固めると、導入後に「現場の実態と合わない」というギャップが生じ、利用率の低迷を招きます。要件定義は技術的な作業である以前に、業務改革の設計そのものです。現場の声を起点にToBeを描くことが、機能要件の質を決定づけます。発注側が現場との橋渡し役を担い、要件に現場の知見を反映させる体制を整えることが、使われるシステムへの第一歩になります。

マルチベンダーSLAと責任分界点の設定

官公庁のシステムRFPで、競合の解説が手薄になりがちでありながら、実務でもっとも重要なのが、マルチベンダー環境におけるSLAと責任分界点の設定です。行政システムは複数のベンダーの製品が連携して動くため、障害が起きたときに「どこの責任か」を切り分けられる枠組みを、要件の段階で定めておく必要があります。

マルチベンダー環境では、ガバメントクラウドへの接続でエラーが起きるたびに、市側が原因の切り分けを強いられる実態が報告されています。あるベンダーは「自社の範囲は正常」と主張し、別のベンダーも同様に応じ、結局は発注側が板挟みになるという構図です。これを防ぐには、RFPの段階で各ベンダーの責任範囲を線引きする責任分界点を明文化することが不可欠です。

具体的には、ネットワーク、クラウド基盤、各業務システム、連携部分といった領域ごとに、どのベンダーが何に責任を負うかを図と表で示します。あわせて、障害発生時に最初に連絡する一次窓口を定め、切り分けの主体を明確にしておくと、トラブル時の混乱を最小化できます。責任分界点の設計は、要件定義の中でもっとも見落とされやすく、かつもっとも後から効いてくる論点です。

SLAは、ベンダーが提供するサービスの品質を発注側と合意する取り決めです。稼働率、障害発生時の一次対応までの時間、復旧目標時間、問い合わせへの応答時間といった指標を数値で定め、達成できなかった場合の取り扱いも含めて記述します。前述の非機能要件で定めた水準を、SLAという形で運用フェーズの約束に落とし込むイメージです。

SLAを要件に組み込むときは、複数ベンダーをまたぐ連携部分の品質をどう保証するかが論点になります。個々のベンダーが自社範囲のSLAを守っても、連携部分で問題が起きれば住民サービスは止まります。連携を含めた全体の品質をどの主体が保証するのかを、RFPで問う設計が望まれます。SLAと責任分界点をセットで定めることが、マルチベンダー環境の行政システムを安定運用させる前提になります。

データ移行・過渡期連携の要件

標準化・ガバメントクラウド移行を伴う官公庁のシステム刷新では、データ移行の要件が成否を分けます。長年蓄積された台帳データを、品質を保ったまま新システムへ移し、移行期間中も業務を止めない設計が求められます。ここはRFPで軽視されやすい一方、実務でもっとも泥臭いトラブルが起きる領域です。

データ移行で最初に問題になるのが、旧システムのデータ品質です。クレンジング（不整合の修正）を行わないまま移行すると、未納データが誤って表示されるといったトラブルが発生し、住民の信頼を損ないます。RFPでは、移行対象データの範囲、クレンジングの責任分担、移行後の検証方法を明確に定める必要があります。誰がどこまでデータを整えるのかが曖昧だと、移行直前に作業が破綻します。

移行検証の要件も欠かせません。移行したデータが旧システムと一致しているかを、件数照合や抽出比較で確認する手順を要件に含めます。移行は一度きりではなく、本番移行前にリハーサルを複数回行うのが定石です。リハーサルの回数や合否基準を要件に書き込んでおくことで、移行の安全性が担保されます。データ移行は「移し替える作業」ではなく「品質を保証する工程」として要件化する視点が重要です。

大規模な行政システムは、すべてを一斉に切り替えるのが難しく、新旧のシステムが一定期間混在することがあります。この過渡期に、新旧のシステム間でデータを連携させ、業務を止めずに移行を進める要件が必要になります。どの業務をいつ切り替え、その間どうデータをやり取りするのかを、移行スケジュールと一体で設計します。

過渡期連携は、平常時にはない一時的な仕組みであるため、要件から漏れやすい領域です。しかし、ここを設計しないまま移行に突入すると、新旧のデータが食い違い、住民への対応が混乱します。RFPでは、過渡期の連携方式、連携期間、連携を終えるタイミングまでを要件に含めることで、移行の現実的な進め方を担保できます。データ移行と過渡期連携は、行政システム刷新の隠れた最大リスクであり、要件定義で最優先に詰めるべき論点です。

データ移行の要件と一体で定めるべきなのが、移行スケジュールと推進体制です。標準化・ガバメントクラウド移行は国の期限が定められているため、いつまでに何を完了させるかを逆算した工程を要件に盛り込む必要があります。Fit&Gap分析、データクレンジング、移行リハーサル、本番移行という各工程に、現実的な期間を確保できているかが、移行の成否を左右します。

あわせて、発注側の体制も要件設計に含めて考えます。移行は職員の業務見直しを伴うため、現場の関与なしには進みません。誰が意思決定し、誰が現場との橋渡しをするのかを明確にしておかないと、ベンダー任せの丸投げになり、現場に合わないシステムができあがります。スケジュールと体制を要件の段階で固めておくことが、移行を計画どおりに進める前提になります。

補助金・調達方式と紐づく要件

官公庁のシステム調達は、民間と違い、調達方式と補助金制度が要件と密接に絡みます。どの調達方式を選ぶか、どの補助金を適用するかによって、RFPに盛り込むべき条件や評価基準が変わります。要件定義の段階から、調達と財源の枠組みを意識しておくことが重要です。

行政の調達方式には、価格と技術提案を総合的に評価する総合評価一般競争入札や、提案内容を重視する公募型プロポーザルなどがあります。大阪市はガバメントクラウドの運用管理補助者を総合評価一般競争入札で単独調達し、北九州市は観光AIチャットボットを公募型プロポーザルで調達しました。要件の性質に応じて、適切な調達方式を選ぶことが、良い提案を引き出す前提になります。

調達方式によって、RFPに書くべき評価基準が変わります。価格重視なら明確な仕様の固定が、提案重視なら課題と目指す姿の提示が求められます。あわせて、共同調達という選択肢もあります。複数の自治体が共同で調達することで、調達コストを抑え、ベンダーとの交渉力を高められる場合があります。自組織だけで抱えるか、近隣自治体と組むかも、要件設計の早い段階で検討する価値があります。

補助金を活用する場合、補助対象となる要件を満たすようにRFPを設計する必要があります。デジタル基盤改革支援補助金や地域未来交付金、福井県のCO-FUKUI（最大300万円）といった制度には、それぞれ補助対象の条件があります。大阪府のデジタル人材シェアリングのように、1プラン120万円のうち府が2分の1にあたる60万円を補助する仕組みもあり、要件が補助条件に合致しているかを事前に確認することが、財政負担を抑える鍵になります。

補助金は申請時期や対象経費が制度ごとに決まっているため、要件定義のスケジュールと補助金の申請スケジュールを連動させる必要があります。要件が固まってから補助金を探すのではなく、利用したい補助金を見据えて要件と調達計画を組み立てると、制度を取りこぼさずに済みます。補助金・調達方式・要件は一体で設計することで、限られた予算で最大の成果を引き出せます。

運用・保守・定着支援の要件

RFPで見落とされがちでありながら、導入後の成果を大きく左右するのが、運用・保守・定着支援の要件です。システムは構築して終わりではなく、運用フェーズで使われ続けてはじめて投資が回収されます。要件定義の段階で、納品後の支援まで明確に定めておくことが、利用率の低迷を防ぐ鍵になります。

保守の要件では、障害対応、定期的なアップデート、法改正への対応といった範囲を明確に定めます。とくに行政システムは制度改正が頻繁にあるため、改正への追従をどこまで保守費用に含めるかを曖昧にすると、後から追加費用が発生します。保守範囲を要件で線引きしておくことで、運用フェーズの想定外コストを抑えられます。

あわせて、クラウドを利用する場合は、運用経費が膨らむリスクを見据えたコスト管理（FinOps）の要件も重要です。中核市59市で運用経費が平均2.3倍に膨らんだ現実を踏まえれば、初期費用だけでなく、運用・保守・クラウド利用料を含めたTCO（総保有コスト）で評価する要件設計が欠かせません。利用状況の可視化やコスト最適化を支える仕組みを要件に含めることで、経費膨張に歯止めをかけられます。

導入後の定着を要件化するには、納品時の操作研修だけでなく、継続的なオンボーディングを盛り込むことが有効です。月次での利用ログ分析、現場ヒアリング、UI改善といった定着プロセスを要件に含めることで、利用率が低迷する悪循環を防げます。納品で関係が終わるベンダーに任せると利用率が伸びにくいため、運用伴走の体制を要件で求める設計が望まれます。

定着支援の要件では、成果を測る指標も定めておくと効果的です。利用率の目標値、窓口待ち時間30%短縮といった定量KPIを設定し、達成状況を定期的に確認する仕組みを要件に含めます。あわせて、システム停止時の紙運用フローや、BCP（業務継続計画）に関わる要件も検討しておくと、非常時にも住民サービスを止めない備えになります。運用・保守・定着支援を要件として明文化することが、導入後に「使われるシステム」を実現する土台です。

まとめ

官公庁のシステムのRFP・要件定義書を整理すると、押さえるべき論点は四つに集約されます。標準仕様書を踏まえた機能要件と定量的な非機能要件の整理、マルチベンダー環境でのSLAと責任分界点の明文化、データクレンジング・移行検証・過渡期連携を含むデータ移行の要件、そして総合評価入札やプロポーザルといった調達方式と補助金に紐づく要件です。とくに責任分界点と過渡期連携は、競合の解説が手薄でありながら実務で最大のトラブル源となるため、要件定義で最優先に詰める価値があります。

RFPを書くときに大切なのは、ベンダーに丸投げできる範囲と、発注側が責任をもって決めるべき範囲を切り分けることです。現場の業務から逆算した機能要件、障害時の責任の線引き、移行の品質保証、そして調達と財源の整合——これらを要件で固めておけば、提案を公平に比較でき、導入後のトラブルも大きく減らせます。riplaはフルスクラッチ受託と国内開発の立場から、行政の業務に即した要件整理と、移行・定着まで見据えた支援を一貫して行います。全体像の確認には、あらためて完全ガイドをご活用ください。

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

また、弊社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。