自治体向けシステムのRFP・要件定義書は、標準仕様を踏まえて機能・非機能要件と移行計画を整理し、業務改善につながる形で組み立てます。書き漏らしは、追加開発や手戻り、調達後のトラブルに直結します。
発注担当者の視点で、機能要件、責任分界、データ移行、調達方式を解説します。詳しくは関連記事もご覧ください。
▼全体ガイドの記事
・自治体向けシステムの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
RFPにおける機能要件と非機能要件の整理
機能要件はシステムが行うことを、非機能要件は品質・性能・安全性の基準を定めるものです。自治体では、標準仕様書を拠り所にしながら、固有の運用をどう扱うかを切り分けることが要件定義の中心になります。
住民の個人情報を扱う公共システムでは、可用性やセキュリティも重要です。そのため、機能要件だけでなく、非機能要件もRFPの骨格として整理しておく必要があります。
標準仕様を起点にした機能要件の列挙
発注側は、国の標準仕様書を起点に機能要件を整理します。RFPでは標準への準拠を前提に、自庁固有の運用で追加する機能を定めます。
- 標準で満たす範囲：標準仕様書で定められた機能が対象。
- 自治体独自で必要な範囲：固有の運用に必要な機能の明記。
標準仕様書の要件数は従来比で平均1.2倍となり、業務によっては3倍以上に増えています。すべてを盛り込むと運用経費が膨らむため、標準の範囲と自治体独自の範囲を分けて記載します。
現行システムの機能をそのまま並べると、業務の非効率まで引き継ぐおそれがあります。そのため、RFP作成の前に現状（AsIs）の業務フローを書き出し、あるべき姿（ToBe）を描きます。
必要な機能は、業務改善の目標から導きます。現行の踏襲を避けると、調達後に現場で使われないシステムになるのを防ぎ、要件定義の質も高まります。
可用性・性能・セキュリティの非機能要件
非機能要件は、運用・保守を含めて測定できる基準で定めます。稼働の継続性から運用体制まで、RFPに書く観点をそろえておくと、提案各社を同じ物差しで比べられます。
- 可用性：平日の業務時間帯に稼働率99.9%以上など。
- 性能：ピーク時の同時利用者数と応答時間。
- セキュリティ：情報保護の水準とアクセス対策。
- 運用・保守：担当体制と業務継続の方法。
性能は、平常時ではなく混み合う時間帯を前提に定める必要があります。基準が曖昧だと、提案各社の解釈が分かれ、評価も難しくなります。そのため、数値で測れる形にして、比較できる要件にします。
個人情報を扱う公共システムでは、セキュリティ要件が特に重要です。実際に、個人情報の設定ミスで外部から閲覧可能になった失敗事例も報告されています。そのため、RFPでは権限管理と監査ログを要件に明記し、通信の暗号化や不正アクセス対策も盛り込みます。
システムが停止した場合の業務継続（BCP）も、要件に含めます。特に、サイバー攻撃や障害を想定し、停止時の代替運用フローまで定めておくと、有事の対応に備えられます。
マルチベンダー環境の責任分界とSLAの定義
ガバメントクラウドの時代には、責任分界とSLA（サービス品質保証）が見落とされやすく、トラブルの火種になりがちです。
複数ベンダーの業務システムを、共通基盤上で組み合わせる形が一般的です。そのため、障害時は原因となったベンダーとレイヤーを切り分ける必要があります。要件が曖昧なままだと、自治体がベンダー間の板挟みになります。
障害の切り分けと責任分界点の明確化
障害時の切り分けで自治体側が負担を抱えないよう、RFPで役割を明確にしておきます。
- 責任範囲：各システムの責任分界点。
- 一次切り分け：障害発生時に最初に調査する担当。
- 最終責任：原因に応じて責任を負う担当。
ガバクラへの接続エラーでは、自治体側が原因を切り分ける実態があります。原因は、アプリケーション、ネットワーク、クラウド基盤などに分かれます。さらに、各社が責任を否定し合うと、復旧が遅れて住民サービスが止まるおそれもあります。
たとえば、大阪市は、ガバメントクラウドの運用管理補助者を総合評価一般競争入札で単独調達しました。こうした専門の役割が一次対応や切り分けを担えば、自治体の調整負担を避けやすくなります。
RFPでは、運用管理の役割と各ベンダーとの関係も定めておきます。自治体が直接の調整に追われない体制が、移行後の安定運用につながります。
SLAで定める稼働率・復旧時間・対応窓口
SLA（サービス品質保証）は、ベンダーが保証する品質を数値で定めた合意です。業務の重要度を踏まえ、項目ごとに具体的な水準を決めます。
- 稼働率：月間99.9%以上などの水準。
- 障害対応：一次対応時間と復旧目標時間。
- 問い合わせ：窓口の対応時間帯。
SLAを定めておくと、品質が基準を下回った場合の対応や責任の所在も明確になります。加えて、各ベンダーのSLAが整合しているかを確かめ、システム間連携部分の品質を誰が保証するかも決めておきます。
稼働率を限界まで高めると、冗長構成の費用が増える場合があります。そのため、発注側は業務ごとに必要な品質を定め、コストとのバランスを取ります。
標準化移行では、運用経費が中核市59市で平均2.3倍に膨らみました。過剰なSLAは経費高騰の一因になり得るため、根拠を添えて適切な水準をRFPに記載します。
データ移行と過渡期連携の要件
住民データを現行システムから正確に移すには、機能開発以上の慎重さが要ります。そのため、発注側はRFP・要件定義書で、移行作業と新旧システムが並行する期間の連携を明確にします。
- 移行対象と方式：移すデータの範囲と方法。
- データクレンジング：不整合データの整理。
- 移行後の検証：正確性の確認方法と責任分担。
- 過渡期連携：新旧システム間の連携要件。
要件が曖昧だと、移行時に住民データの誤表示や欠落といった重大事故を招くおそれがあります。
データクレンジングと移行検証の要件化
RFPでは、移行前の整理から本番稼働前の確認まで、作業ごとの担当と方法を定めます。
- クレンジング：対象範囲と作業担当。
- 移行リハーサル：本番前の実施方法。
- データ突合：検証データを照合する方法。
- 不一致時の対応：誤りを見つけた後の手順。
長年の運用で蓄積した重複データや表記ゆれ、不整合な情報をそのまま移すと、新システムで正しく扱えない場合があります。実際に、未納データが誤表示される例もあります。クレンジングを軽視した移行は、新システム稼働後の信頼を損ねます。
移行後は、現行データとの件数、金額、関連付けに食い違いがないかを確認します。検証せずに本番稼働すると、誤りに気づかないまま住民対応に使うリスクがあります。
データを移すだけでなく、正しさを確かめる工程まで一体で要件に含めることが、安全な移行の前提になります。
新旧混在期の過渡期連携の設計
業務ごとに段階的に移行すると、新旧システムが並行稼働する期間が生じます。そのため、移行の時系列と連携の組み合わせを整理しておきます。
- 移行時期：業務ごとの切り替え時期。
- 連携先：混在期に連携するシステムの組み合わせ。
- 連携方式：新旧間で情報共有を保つ方法。
たとえば、住民記録が新システムに移り、税は旧システムに残る場合は、両者で宛名情報を共有する方法が必要です。この連携を設計しないと、業務停止やデータの二重管理につながります。
RFPでは、移行スケジュールと過渡期の連携方式をセットで提案各社に求めます。混在期の調整が不十分だと移行全体が遅れるため、現実的な計画を持つベンダーかどうかを見極めることが、調達の評価点になります。
データ移行と過渡期連携は、機能要件の陰に隠れがちです。一方で、刷新の成否を左右する部分でもあります。
補助金と調達方式を見据えた要件の組み立て
技術要件に加えて、補助金の交付要件と調達方式もRFP・要件定義書に反映します。国や都道府県の制度には、デジタル基盤改革支援補助金や地域未来交付金などがあり、活用できる場合があります。
交付要件を満たさなければ、補助を受けられないことがあります。また、一般競争入札かプロポーザル方式かという選択も、RFPの記載内容を左右します。
補助制度の交付要件の仕様への織り込み
補助制度ごとに、対象経費や要件は異なります。そのため、仕様を固める前に、利用する制度ごとに次の項目を確認しておきます。
- 成果指標：交付要件で求められる指標。
- 対象経費：補助対象に含まれる費用の範囲。
- 必要要件：制度ごとに満たすべき条件。
たとえば、大阪府のデジタル人材シェアリングは1プラン120万円で、府が2分の1の60万円を補助します。福井県のCO-FUKUIは最大300万円を補助します。
仕様を固めた後に制度を当てはめると、対象外の経費が出ることがあります。このため、企画の初期から財政部門と情報政策部門が連携し、利用する制度と要件を整理します。
要件定義書には、補助対象の範囲と申請に必要な成果指標を記載します。補助制度を早い段階で事業設計の前提に組み込み、調達との整合を取ります。
一般競争入札とプロポーザルの使い分け
発注側は、システムの性質に合わせて調達方式を選び、RFPの評価内容を設計します。
- 一般競争入札：要件が明確で品質差が出にくく、価格を主に競う場合。
- 公募型プロポーザル・総合評価方式：技術提案や運用設計の質が成果を左右する場合。
たとえば、北九州市は観光AIチャットボットを公募型プロポーザルで、大阪市はガバクラ運用管理補助者を総合評価一般競争入札で調達しました。対象の性質に応じて、方式を使い分けています。
プロポーザルでは、評価項目と配点を明示して、どの提案を重視するかを伝えます。また、ToBe設計の妥当性、移行計画の現実性、運用・定着支援の体制も評価軸になります。
価格だけで選ぶ失敗を避けるため、技術や運用の評価を組み込みます。さらに、近隣自治体との共同調達でコストを抑える選択肢もあります。
自庁の体制とシステムの性質に応じて方式を選びます。そのうえで、選んだ方式に沿って、RFPの記載粒度（どこまで細かく書くか）と評価設計を組み立てます。
まとめ
自治体向けシステムのRFPでは、標準仕様を踏まえた機能要件と、数値で測れる非機能要件を整理します。そのうえで、責任分界、SLA、データ移行、過渡期連携も含めて設計します。
特に責任分界と、データ移行・過渡期連携は、競合の解説で抜けやすく、移行後のトラブルに直結する論点です。
標準仕様書の要件数は従来比で平均1.2倍に増え、運用経費は中核市59市で平均2.3倍に膨らみました。そのため、SLAや非機能要件は業務の重要度に見合う水準にします。
要件は、業務のあるべき姿から導きます。現行機能をなぞると、業務の非効率まで引き継ぐおそれがあるためです。自庁の業務と体制に照らして、機能・非機能・移行・調達を一体で設計します。
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を創業。