自治体向けシステムの調達を担う情報政策部門の担当者にとって、もっとも頭を悩ませるのが「RFP（提案依頼書）や要件定義書に、何をどこまで書けばよいのか」という点ではないでしょうか。公共調達は仕様書の記載がすべての土台になります。機能要件はもちろん、可用性やセキュリティといった非機能要件、複数ベンダーが関わる際の責任分界とSLA、標準化・ガバメントクラウド移行に伴うデータ移行や過渡期連携の要件、さらに補助金の交付要件まで、盛り込むべき論点は多岐にわたります。書き漏らせば追加開発や手戻り、調達後のトラブルに直結します。だからこそ、自治体システムのRFP・要件定義書に何を盛り込むべきかを体系的に押さえておくことが、調達の成否を分けます。
本記事は、自治体向けシステムのRFP・要件定義書・提案依頼書の作り方を、発注する自治体の視点から体系的に解説する「要件定義特化」の解説です。機能要件と非機能要件の整理、マルチベンダー環境での責任分界とSLAの定め方、データ移行と過渡期連携の要件、そして補助金・調達方式を見据えた仕様の組み立て方まで、一次データや実例とあわせて具体的に解説します。読み終えるころには、自庁のRFPで押さえるべき骨子が見えてくるはずです。なお、自治体向けシステムの全体像をまだ把握していない方は、まず自治体向けシステムの完全ガイドから読むことをおすすめします。
▼全体ガイドの記事
・自治体向けシステムの完全ガイド
機能要件と非機能要件をRFPで整理する
RFP・要件定義書の骨格を成すのが、機能要件と非機能要件の整理です。機能要件は「システムが何をするか」、非機能要件は「どのくらいの品質・性能・安全性で動くか」を定めます。自治体システムでは、標準仕様書という強力な拠り所がある一方で、自治体固有の運用をどう扱うかを切り分ける作業が要件定義の中心になります。機能だけに目が行きがちですが、可用性やセキュリティといった非機能要件こそ、住民の個人情報を扱う公共システムでは死活的に重要です。
標準仕様書を起点に機能要件を列挙する
機能要件を書くときは、国の標準仕様書を起点にするのが定石です。標準仕様書は各業務で備えるべき機能を細かく規定しており、RFPではこれに準拠することを前提に、自庁固有の運用で追加が必要な機能を明記します。ただし、標準仕様書の要件数は従来比で平均1.2倍、業務によっては3倍以上に増えています。すべてを盛り込めば運用経費が膨らむため、機能要件は「標準で満たす範囲」と「自治体独自で必要な範囲」を明確に区別して記載することが重要です。
機能要件の記載で陥りやすいのが、現行システムの機能をそのまま列挙してしまうことです。これでは、現行業務の非効率までシステムに引き継いでしまいます。RFPを作る前に、現状（AsIs）の業務フローを可視化し、あるべき姿（ToBe）を描いたうえで必要機能を導く。この一手間が、調達後に「現場が使わないシステム」になる失敗を防ぎます。機能要件は現行踏襲ではなく、業務改善の目標から逆算して定義することが、要件定義の質を決めます。
可用性・性能・セキュリティの非機能要件
非機能要件では、可用性（システムがどれだけ止まらないか）、性能（処理速度や同時利用者数）、セキュリティ（情報保護のレベル）、運用・保守の体制などを定量的に定めます。たとえば「平日の業務時間帯に稼働率99.9%以上」「ピーク時に何人が同時利用しても規定の応答時間内」といった形で、数値で測定できる基準を書くことが肝心です。曖昧な表現にすると、提案各社の解釈がばらつき、評価も困難になります。
セキュリティ要件は、住民の個人情報を扱う公共システムでは特に重要です。設定ミスにより個人情報が外部から閲覧可能になった失敗事例も報告されており、権限管理、監査ログ、通信の暗号化、不正アクセス対策などを非機能要件として明記する必要があります。また、システム停止時の業務継続（BCP）も非機能要件の一部として扱うべき論点です。サイバー攻撃やシステム障害を前提に、停止時の代替運用フローまで要件に織り込むことで、調達後に慌てずに済みます。非機能要件は、平時には見えにくいものの、有事に自治体を守る要件です。
マルチベンダー環境の責任分界とSLAを定める
ガバメントクラウド時代の自治体システムでもっとも見落とされやすく、かつトラブルの火種になるのが、マルチベンダー環境における責任分界とSLA（サービス品質保証）の取り決めです。標準化により、住民情報システムは複数のベンダーが提供する業務システムを共通のクラウド基盤上で組み合わせて動かす形が一般的になりました。この構造では、障害が起きたときに「どのベンダーの、どのレイヤーの問題か」を切り分ける必要があり、ここを要件で詰めておかないと、トラブルのたびに自治体が板挟みになります。
障害切り分けと責任分界点をRFPで明確にする
マルチベンダー環境では、ガバクラへの接続エラーが起きるたびに、自治体側が原因の切り分けを強いられる実態があります。アプリケーションの問題なのか、ネットワークの問題なのか、クラウド基盤の問題なのか。これを各ベンダーが互いに「うちの責任ではない」と主張し合うと、復旧が遅れ、住民サービスが止まります。RFP・要件定義書では、各システムの責任範囲（責任分界点）を明文化し、障害発生時に誰が一次切り分けを行い、誰が最終的に責任を負うのかを定めておく必要があります。
責任分界を明確にするうえで有効なのが、複数ベンダーをまとめる運用管理の役割を別途調達することです。大阪市は、ガバメントクラウドの運用管理補助者を総合評価一般競争入札で単独調達しました。障害時の一次対応や切り分けを担う専門の役割を置くことで、自治体が直接ベンダー間の調整に追われる事態を避けられます。RFPでは、こうした運用管理の役割をどう位置づけ、各ベンダーとの関係をどう整理するかまで含めて要件化することが、移行後の安定運用につながります。
SLAで稼働率・復旧時間・対応窓口を定義する
SLAは、ベンダーが保証するサービス品質を数値で定めた合意です。稼働率（例：月間99.9%以上）、障害発生時の一次対応時間、復旧目標時間、問い合わせ窓口の対応時間帯などを具体的に規定します。SLAを締結しておくことで、品質が基準を下回った場合の対応や、責任の所在が明確になります。マルチベンダー環境では、各ベンダーのSLAが整合しているか、システム間連携部分の品質を誰が保証するのかまで確認することが欠かせません。
SLAを定義する際の注意点は、数値を厳しくしすぎてもコストが跳ね上がる点です。たとえば稼働率を限界まで高く設定すれば、冗長構成のための費用が増します。業務の重要度に応じて、どの業務にどこまでの品質を求めるかをメリハリをつけて定めることが、コストと品質のバランスをとる鍵です。標準化移行で運用経費が中核市59市で平均2.3倍に膨らんだ現実を踏まえると、過剰なSLAは経費高騰の一因にもなり得ます。SLAは「高ければよい」ではなく、業務の重要度に見合った水準を、根拠とともにRFPに記載することが大切です。
データ移行と過渡期連携の要件を盛り込む
システムの刷新で、もっとも泥臭く、かつ事故が起きやすいのがデータ移行です。長年使ってきた現行システムから、新システムへ住民データを正確に移す作業は、機能開発以上に慎重さが求められます。RFP・要件定義書では、移行対象データの範囲、移行方式、データクレンジング（不整合データの整理）、移行後の検証方法、そして新旧システムが並行稼働する過渡期の連携要件まで、明確に定義しておく必要があります。ここを曖昧にすると、移行時に住民データの誤表示や欠落といった重大事故を招きます。
データクレンジングと移行検証を要件化する
データ移行で見落とされがちなのが、クレンジングの要件です。現行システムには、長年の運用で蓄積した重複データや表記ゆれ、不整合な情報が含まれていることが少なくありません。これをそのまま移行すると、新システムでデータが正しく扱えず、たとえば未納データが誤って表示されるといったトラブルが起きます。RFPでは、移行前にどの範囲のデータをクレンジングし、誰がその作業を担うのかを明記する必要があります。クレンジングを軽視した移行は、新システム稼働後の信頼を損ねます。
移行後の検証要件も欠かせません。移行したデータが現行と一致しているか、件数・金額・関連付けに齟齬がないかを確認する検証の方法と責任分担を定めます。検証なしに本番稼働すると、誤りに気づかないまま住民対応に使ってしまうリスクがあります。要件定義書には、移行リハーサルの実施、検証データの突合方法、不一致が見つかった場合の対応手順までを盛り込むことが、安全な移行の前提です。データ移行は「移せばよい」のではなく、移したデータが正しいことを保証する検証までを一体で要件化することが重要です。
新旧混在期の過渡期連携を設計する
大規模な刷新では、すべての業務を一斉に切り替えるのではなく、業務ごとに段階的に移行することが多く、その間は新旧システムが並行して動く過渡期が生じます。この過渡期に、新旧システム間でデータをどう連携させるかは、要件定義の難所です。たとえば、住民記録は新システムに移ったが税はまだ旧システムという状態で、両者がどう宛名情報を共有するか。この連携を設計しないと、過渡期に業務が止まったり、データの二重管理が発生したりします。
過渡期連携の要件は、移行スケジュールと一体で設計する必要があります。どの業務をいつ移行し、その間どのシステム間でどう連携を維持するのかを、時系列で整理します。新旧混在期は調整が難しく、ここでの不備が移行全体のスケジュール遅延につながります。RFP・要件定義書では、移行スケジュールと過渡期の連携方式をセットで提案各社に求め、現実的な移行計画を持つベンダーを見極めることが、調達の重要な評価ポイントになります。データ移行と過渡期連携は、機能要件の陰に隠れがちですが、刷新の成否を左右する核心です。
補助金・調達方式を見据えて要件を組み立てる
RFP・要件定義書は、技術的な要件だけでなく、補助金の交付要件や調達方式とも整合させる必要があります。自治体システムの導入には、デジタル基盤改革支援補助金や地域未来交付金など、国や都道府県の補助制度が活用できる場合があります。これらの交付要件を満たすように仕様を組み立てなければ、せっかくの補助が受けられません。また、一般競争入札にするかプロポーザル方式にするかという調達方式の選択も、RFPの記載内容を左右します。
補助制度の交付要件を仕様に織り込む
補助金を活用する場合、交付要件で求められる成果指標や対象経費の範囲を、要件定義の段階で仕様に織り込む必要があります。たとえば大阪府のデジタル人材シェアリングは1プラン120万円のうち府が2分の1の60万円を補助し、福井県のCO-FUKUIは最大300万円を補助します。こうした制度は、補助対象になる経費や求められる要件が制度ごとに異なります。仕様を固めた後に補助制度を当てはめようとすると、対象から外れる経費が出てしまうことがあります。
補助金を前提とするなら、企画の初期から財政部門と情報政策部門が連携し、どの制度を使い、どの要件を満たす必要があるかを整理してからRFPを作ることが肝心です。補助制度は単なる費用負担の軽減ではなく、事業設計の前提として早期に組み込むべき要素です。要件定義書には、補助対象となる範囲を明確にし、補助申請に必要な成果指標を要件として記載しておくことで、調達と補助申請の整合をとることができます。
一般競争入札とプロポーザルを使い分ける
調達方式の選択も、RFPの設計に直結します。価格を主に競う一般競争入札は、要件が明確で品質差が出にくいものに向きます。一方、提案内容の質を評価する公募型プロポーザルや総合評価方式は、技術提案や運用設計が成果を左右する領域に適しています。北九州市は観光AIチャットボットを公募型プロポーザルで、大阪市はガバクラ運用管理補助者を総合評価一般競争入札で調達しており、対象の性質に応じて方式を使い分けています。
プロポーザル方式を採る場合、RFPには評価項目とその配点を明示し、何を重視して提案を求めるのかを伝える必要があります。価格だけでなく、ToBe設計の妥当性、移行計画の現実性、運用・定着支援の体制などを評価軸に据えることで、安さだけで選んで失敗するリスクを避けられます。共同調達という選択肢もあり、近隣自治体と連携して調達することでコストを抑える動きもあります。調達方式は、システムの性質と自庁の体制に合わせて選び、その選択に沿ってRFPの記載粒度や評価設計を組み立てることが、要件定義の総仕上げになります。
まとめ
自治体向けシステムのRFP・要件定義書を組み立てるうえで核になるのは、標準仕様書を起点にした機能要件と定量的な非機能要件、マルチベンダー環境での責任分界とSLA、データ移行・過渡期連携の要件、そして補助金・調達方式との整合の4点です。とくにマルチベンダーの責任分界とデータ移行・過渡期連携は、競合の解説で抜けやすく、かつ移行後のトラブルに直結する論点です。標準仕様書の要件数が従来比で平均1.2倍に増え、運用経費が中核市59市で平均2.3倍に膨らんだ現実を踏まえれば、SLAや非機能要件は業務の重要度に見合った水準で定めることが欠かせません。
要件定義で大切なのは、現行システムの機能を踏襲することではなく、業務のあるべき姿から逆算して必要な要件を導くことです。自庁の業務と体制に照らし、機能・非機能・移行・調達を一体で設計したRFPを組み立ててください。riplaはフルスクラッチ受託と国内開発を組み合わせ、業務の棚卸しから要件定義書の整理、責任分界やデータ移行の設計までを一貫して支援します。全体像の確認には、あらためて完全ガイドをご活用ください。
株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。
また、弊社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。