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

公共システムを開発・導入するうえで、プロジェクトの成否をもっとも大きく左右するのがRFP（提案依頼書）と要件定義です。公共調達は、民間と違って入札やプロポーザルといった手続きのルールが厳格で、しかも標準化・ガバメントクラウド移行やマルチベンダー体制といった公共特有の論点を抱えます。これらを正確に要件として整理し、RFPや仕様書に落とし込めるかどうかが、現場に使われるシステムになるか、運用経費だけが膨らむシステムになるかの分かれ目になります。実際、要件を詰めきれないまま調達したことで、移行後に運用経費が平均2.3倍に膨張したという報告もあります。

本記事は、公共システムのRFP・要件定義書・提案依頼書を、発注する側である自治体・官公庁の視点から具体的に解説する「要件定義特化」の記事です。現場ヒアリングとAsIs/ToBeの描き方、公共調達仕様書に盛り込む機能要件と非機能要件、マルチベンダーのSLA・責任分界、データ移行と過渡期連携の要件、そして補助金・診療報酬といった制度要件まで、公共調達の実務に即して掘り下げます。読み終えるころには、事業者に渡すRFPの骨子が描けるはずです。なお、公共システム全体の進め方や費用感をまだ把握していない方は、まず公共システムの完全ガイドから読むことをおすすめします。

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

現場ヒアリングとToBeから始める要件定義の進め方

公共システムの要件定義は、「どんな機能が欲しいか」のリストアップから始めてはいけません。出発点は、現場の職員が今どのように業務を処理しているかを徹底的にヒアリングし、可視化することです。公共の業務は、法令・条例・要綱や、組織ごとの長年の取り決めの積み重ねでできています。これを無視して理想論で機能を決めると、現場の実態と噛み合わないシステムができあがります。

要件定義の第一歩は、現状（AsIs）の業務フローを可視化することです。窓口担当・税務・福祉・情報システム部門といった関係者に、「実際にどう処理しているか」「どこに無駄や手戻りがあるか」を細かくヒアリングします。たとえば、紙の申請書を職員が一文字ずつ入力している、同じ情報を複数システムに二重入力している、といった具体的なボトルネックを洗い出すことが、後の機能要件の根拠になります。

標準化への移行では、既存業務と標準仕様の差を埋めるFit&Gap分析が欠かせません。標準仕様書の要件数は平均で従来の1.2倍、一部の業務では3倍以上に増えており、現状の業務がどこまで標準に収まり、どこに独自対応が必要かを丁寧に突き合わせる必要があります。AsIsの可視化を怠ると、このGap分析が表面的になり、移行後に「想定外の業務が回らない」という事態を招きます。現場の実務を起点にすることが、すべての要件定義の土台です。

ヒアリングの際は、複数の担当者から話を聞くことが大切です。同じ業務でも、ベテランと若手では手順の理解が異なることがあり、一人の話だけを聞くと業務の全体像を見誤ります。また、文書化されていない暗黙のルールや、例外的な処理ほど、現場でしか把握できません。要件定義書に「通常はこう処理するが、こういう場合は例外的にこう対応する」という分岐まで書き込めるかどうかが、後の手戻りを防ぐ精度を決めます。AsIsの可視化は、表面的なフロー図ではなく、例外まで含めた実務の実態を捉えることが目的です。

AsIsを可視化したら、次にあるべき業務の姿（ToBe）を描きます。ここで重要なのは、ToBeに到達したかどうかを測るKPI（評価指標）を、要件定義の段階で定義しておくことです。たとえば「窓口待ち時間を30%短縮する」「特定業務の処理時間を年1,100時間削減する」といった具体的な数値目標を掲げれば、導入後に効果を客観的に検証でき、議会や住民への説明責任も果たせます。

KPIを定めておくことは、調達後のROI評価にも直結します。前述の長岡市の年18,603時間削減や、札幌市の児童手当を20秒へ短縮した事例も、削減効果を数値で捉えているからこそ、投資の妥当性を示せています。RFPには、こうしたKPIと、それを達成するための要件を明記し、事業者に「どうやって達成するか」を提案させる構成にすると、提案の質を比較しやすくなります。ToBeとKPIを曖昧にしたまま調達すると、納品物が要件を満たしているかの判断基準そのものが持てなくなります。

公共調達仕様書に盛り込む機能要件・非機能要件

ToBeとKPIが固まったら、それを公共調達仕様書の機能要件・非機能要件に落とし込みます。公共調達は、入札や公募型プロポーザルといった手続きのルールに沿って進めるため、仕様書の記述が事業者の提案範囲をそのまま規定します。曖昧な記述は、後の解釈違いやトラブルの温床になるため、要件は具体的かつ検証可能な形で書く必要があります。

機能要件には、RPA・AI-OCRによる自動化、マスタ・台帳の一元管理、予約・チャットボットといった住民接点など、ToBeで描いた機能を具体的に記述します。重要なのは、Fit&Gap分析の結果を反映し、「標準パッケージで満たせる要件」と「独自対応が必要な要件」を切り分けて書くことです。すべてを独自開発で要求するとコストが膨らみ、逆に標準のみに寄せると現場の必須業務が回らなくなります。

独自対応が本当に必要かは、慎重に見極める必要があります。標準仕様の要件数が一部で3倍以上に増えている背景には、各組織が独自要件を積み増した経緯があり、これが運用経費の膨張要因にもなっています。RFPの段階で「この独自要件は本当に必要か、標準で代替できないか」を問い直すことが、後のコスト肥大を防ぎます。機能要件は、多く盛り込むほど良いのではなく、KPI達成に必要な範囲に絞ることが肝心です。

機能要件を記述する際は、要件ごとに優先度を付けておくと、提案や予算の調整がしやすくなります。「必須」「推奨」「任意」といった区分を設け、必須要件は確実に満たすことを求め、推奨・任意は予算や提案内容に応じて取捨選択できるようにします。すべてを必須にすると、コストが膨らむうえに、事業者の提案の幅も狭まります。優先度を明示することで、限られた予算のなかで最大の効果を得る要件構成を、事業者と一緒に作り込めます。要件の優先順位付けは、コストと効果のバランスを取るための実務的な工夫です。

公共システムでは、非機能要件を仕様書に明確に書くことが、機能要件と同じくらい重要です。住民の個人情報や税・福祉情報を扱うため、権限管理・監査ログ・暗号化といったセキュリティ要件と、可用性（止まらないこと）、BCP（止まったときに業務を継続できること）を、定量的な水準で示します。たとえば、稼働率の目標値や、障害発生時の復旧時間といった指標を明記します。

非機能要件を曖昧にした結果の失敗も現実に起きています。設定をベンダー任せにした結果、個人情報が外部から閲覧できる状態になっていた事例は、権限管理の要件が仕様書で詰めきれていなかったことを示します。また、システム停止に備えた紙運用のBCPも、非機能要件として明記しておくべき項目です。サイバー攻撃や大規模障害でシステムが使えなくなっても窓口を止めないために、紙での代替フローと訓練の要件まで盛り込むことで、有事の備えが調達段階から組み込まれます。

公共調達では、選ぶ調達方式によってRFPの書き方を変える必要があります。価格を主たる基準とする一般競争入札では、仕様を細かく確定させ、事業者が価格で競える形にします。一方、提案内容を重視する公募型プロポーザルや総合評価方式では、達成すべきKPIや課題を示し、その実現方法を事業者に提案させる余地を残します。住民が直接使うサービスや、独自性の高い施策では、後者のほうが質の高い提案を引き出せます。

実際、大阪市はガバメントクラウドの運用管理補助者を総合評価一般競争入札で、北九州市は観光AIチャットボットを公募型プロポーザルで調達しています。調達対象の標準性が高ければ入札、提案力で差がつく領域ならプロポーザル、という使い分けが一つの目安です。RFPを書く際は、まずどの調達方式を採るかを決め、その方式に合った粒度で要件を記述することが、適切な事業者選定につながります。方式と要件の書き方がちぐはぐだと、評価そのものが機能しなくなります。

マルチベンダーのSLA・責任分界とデータ移行要件

公共システムの要件定義で、競合の解説が手薄になりがちなのが、マルチベンダー体制のSLA・責任分界と、データ移行の要件です。ガバメントクラウド移行をはじめ、近年の公共システムは複数事業者がレイヤーごとに関与する構造が一般的で、障害の切り分けや移行の段取りが難しくなっています。ここを要件として詰めておくことが、運用フェーズのトラブルを大きく左右します。

マルチベンダー環境では、障害が起きるたびに、原因がどの事業者のレイヤーにあるのかを切り分ける必要があります。ガバメントクラウドへの接続エラーが起きるたびに、組織側が原因の切り分けを強いられる、という負担が実際に報告されています。これを避けるには、RFPの段階でSLA（サービス品質の保証水準）と責任分界点を明確に定義し、どの事象を誰が責任を持って対応するかを契約に落とし込むことが不可欠です。

具体的には、各事業者の担当範囲、障害発生時の一次受付窓口、エスカレーションの手順、復旧時間の目標値を要件として書きます。あわせて、運用管理を支援する人材の調達も検討に値します。大阪市はガバメントクラウドの運用管理補助者を総合評価一般競争入札で単独調達しており、こうした運用体制の確保まで含めて要件定義に織り込むことで、組織が切り分け作業に忙殺される事態を防げます。SLAは、平時よりも障害時にこそ価値を発揮する要件です。

レガシーシステムからの移行では、データ移行の要件が極めて重要です。移行元データのクレンジング（不整合の修正）を要件に含めておかないと、誤ったデータがそのまま新システムに引き継がれます。実際、クレンジングを実施しなかったために、未納情報が誤って表示されてしまった事例が報告されています。RFPには、データ移行の範囲・クレンジングの責任・移行後の検証方法を明記しておく必要があります。

あわせて見落とされがちなのが、新旧システムが並行稼働する過渡期の連携要件です。一斉に切り替えるのではなく段階的に移行する場合、移行済みの業務と未移行の業務の間でデータをどう連携させるかを、あらかじめ要件として定義しておく必要があります。この過渡期連携は泥臭く地味な作業ですが、ここを詰めておかないと、移行期間中に業務が回らなくなります。データ移行と過渡期連携は、要件定義で最も丁寧に扱うべき領域です。

データ移行の要件には、移行のリハーサルと検証の手順も含めておくべきです。本番移行の前に、実データを使ったリハーサルを行い、件数の一致やデータの整合性を確認しておけば、本番での事故を大幅に減らせます。RFPには、移行リハーサルの実施回数、検証の合格基準、問題が見つかった場合の修正責任といった項目まで明記することが望まれます。データ移行は「一度きりの本番勝負」にせず、検証を重ねて確実性を高める前提で要件を組み立ててください。これが、移行後の誤表示やトラブルを防ぐ最も確実な備えになります。

補助金・制度要件をRFPに織り込む

公共システムのRFPでは、財源と制度の要件を織り込むことが、民間調達との大きな違いです。補助金の適用要件や、診療報酬・加算の対象となる機能要件を満たすかどうかが、投資計画と運用収支を左右します。制度は年度ごとに変わるため、最新の公募要領や改定内容を確認したうえで要件に反映する必要があります。

公共システムの調達では、補助金を前提に投資計画を組み立てるのが定石です。デジタル基盤改革支援補助金や地域未来交付金といった国の制度に加え、福井県のCO-FUKUI（最大300万円）や、大阪府のデジタル人材シェアリング（1プラン120万円のうち府が2分の1の60万円を補助）といった地域独自の支援もあります。これらの適用要件を満たす形でRFPを設計すれば、自己負担を抑えながら必要な機能を確保できます。

補助金を活用する際は、要件と補助対象の整合を取ることが重要です。補助の対象となる経費や機能が限定されている場合、RFPの要件がその範囲を外れていると補助を受けられません。要件定義の段階で、財政部門や補助金の所管部署と連携し、補助対象に沿った要件構成にしておくことが、確実な財源確保につながります。補助金は年度ごとに条件が変わるため、必ず最新の公募要領を確認してください。

医療分野の公共性の高いシステムでは、診療報酬や加算の要件を機能要件に反映することが収支に直結します。令和8年度改定では、電子的診療情報連携体制整備加算が設けられ、加算1が15点、加算2が9点、加算3が4点と評価されています。これらの加算を取得するには、電子カルテや電子処方箋の連携機能が要件を満たしている必要があり、RFPにその対応を明記しておくことが求められます。

導入支援の制度も要件設計に組み込めます。電子処方箋の導入には最大194,000円の補助があり、東京や大阪などの上乗せを含めると最大29.1万円程度の支援を受けられる場合があります。介護分野でも、ICT導入支援が職員数に応じて最低100万円相当用意されています。これらの制度要件を満たす形で機能要件を設計することで、投資負担を抑えつつ、制度的な評価も得られます。制度は改定されるため、最新の点数と要件を必ず確認したうえでRFPに反映してください。

RFPで見落とされがちなのが、導入後の定着支援と伴走を要件に明記することです。公共システムは、納品時点でベンダーの関与が終わると、利用ログを誰も見なくなり、使われない機能が放置されて利用率が下がる悪循環に陥りがちです。これを防ぐには、調達の段階で「納品後の運用支援」「利用ログの分析と改善提案」「現場ヒアリングに基づくUI改善」といった伴走の役務を要件に含めておく必要があります。

定着支援を要件に入れる重要性は、介護分野の調査が裏づけています。関係者50名への調査では、ICTを「知らない」が74%、「聞いたことがある」が20%、「理解がある」はわずか6%でした。つまり、現場がツールを理解していなければ、どれだけ優れた機能も使われません。RFPには、導入時の手厚いオンボーディングと、その後の継続的な定着支援を、明確な役務として記述することが求められます。要件定義は、システムを作る要件だけでなく、現場に根づかせる要件まで含めて初めて完成します。

まとめ

公共システムのRFP・要件定義を振り返ると、(1)現場ヒアリングとToBe・KPIの定義、(2)機能要件と非機能要件の具体化、(3)マルチベンダーのSLA・責任分界とデータ移行・過渡期連携、(4)補助金・診療報酬といった制度要件、という四つの柱に整理できます。標準化ではFit&Gap分析が要件の精度を左右し、要件数が一部3倍以上に増える独自要件の見極めが運用経費の膨張を防ぎます。SLAと責任分界、データ移行のクレンジングは、運用フェーズの泥臭いトラブルを未然に防ぐ最重要領域です。

要件定義で大切なのは、機能を多く盛り込むことではなく、現場の実務とKPIから逆算して、必要な要件に絞り込むことです。公共特有のSLA・責任分界・データ移行・制度要件を早期に詰めておくことで、移行後に運用経費だけが膨らむ事態を避けられます。riplaはフルスクラッチ受託と国内開発を組み合わせ、現場の業務から逆算した要件整理と、調達から運用までを見据えたRFP設計を一貫して支援します。全体像の確認には、あらためて完全ガイドをご活用ください。

株式会社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を創業。