公共システムの要件定義は、現場の業務を把握することから始まります。ToBeとKPIを定めたうえで、仕様書、調達方式、運用・制度の要件へ進めると、実務に合うRFPにつながります。
自治体・官公庁の発注側に向けて、RFPや要件定義書の要点を説明します。全体像は公共システムの完全ガイドもあわせてご覧ください。
▼全体ガイドの記事
・公共システムの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
現場ヒアリングとToBeから始める要件定義の進め方
公共システムの要件定義は、機能の一覧を作るより先に、職員が業務をどう処理しているかを現場でヒアリングして可視化します。公共業務は法令・条例・要綱や、組織ごとの長年の取り決めで成り立っています。そのため、実態を無視して理想論で機能を決めると、現場に合わないシステムになります。
AsIsの業務フローを可視化するヒアリング
要件定義の第一歩は、現状（AsIs）の業務フローを可視化することです。関係者には、処理の実態と、無駄や手戻りが起きている場所を聞きます。
- 窓口担当：紙の申請書を一文字ずつ入力する作業の実態
- 税務・福祉部門：同じ情報を複数のシステムへ二重入力している業務
- 情報システム部門：現行業務と標準仕様との差
ボトルネックとして洗い出した作業は、後の機能要件を支える根拠になります。
標準化を進めるには、Fit&Gap分析が欠かせません。標準仕様書の要件数は、平均で従来の1.2倍、一部業務では3倍以上です。現状を把握していないと、標準に収まる業務と独自対応が要る業務の差を見誤り、移行後に業務が回らない事態にもつながります。
ヒアリングでは、複数の担当者から話を聞くことが大切です。同じ業務でも、ベテランと若手では手順の理解が異なる場合があるため、一人の話だけでは業務全体を見誤るおそれがあります。文書化されていない暗黙のルールや例外処理も、現場で確かめておく必要があります。
要件定義書には、通常の処理だけでなく例外時の分岐も記載します。例外まで含めて実務を捉えておけば、手戻りを防げます。
ToBeモデルとKPIの定義
AsIsを可視化したあとに、あるべき業務の姿（ToBe）を描きます。導入後に効果を測るKPI（評価指標）も、要件定義の段階で定めておきます。
- 窓口待ち時間：30%短縮を目標とする例があります。
- 特定業務の処理時間：年1,100時間の削減を目標とする例が見られます。
- 提案内容：KPIを達成する方法を、事業者に提案してもらいます。
数値目標があれば、導入後の効果を客観的に検証できます。また、議会や住民への説明責任にも役立ちます。
KPIは、調達後のROI評価にも直結します。実際に、長岡市は年18,603時間の削減、札幌市は児童手当の処理を20秒に短縮しており、いずれも削減効果を数値で捉えています。
RFPには、KPIと、その達成に必要な要件を明記します。達成方法も事業者に提案させると、提案同士を比べられます。
ToBeとKPIが曖昧なままだと、納品物が要件を満たしているかを判断できません。
公共調達仕様書に盛り込む機能要件・非機能要件
ToBeとKPIが固まったら、機能要件と非機能要件を仕様書に落とし込みます。公共調達では、入札や公募型プロポーザルの手続きに沿って進めます。
仕様書の記述によって、事業者が提案できる範囲が決まります。ただし、曖昧な記述は後の解釈違いやトラブルの原因になるため、要件は具体的かつ検証可能な形で書きます。
機能要件の書き方とFit&Gapの反映
機能要件には、ToBeで描いた機能を具体的に書きます。そのうえで、Fit&Gapの結果を反映し、標準で満たせる要件と独自対応が要る要件を分けます。
- 業務の自動化：RPA・AI-OCRの利用範囲
- 情報管理：マスタ・台帳の一元管理
- 住民接点：予約・チャットボットなどの受付機能
すべてを独自開発にすると、コストが膨らみます。一方で、標準だけに寄せると、現場に必須の業務が回らなくなるおそれがあります。
一部業務では、標準仕様の要件数が従来の3倍以上に増えています。この増加は、運用経費の膨張要因にもなっています。
独自対応が本当に必要かを慎重に見極めたうえで、RFPでは標準で代替できないかを検討します。さらに、機能はKPI達成に必要な範囲に絞ります。
要件ごとに「必須」「推奨」「任意」などの区分を設けます。必須は確実な対応を求め、推奨と任意は予算や提案内容に応じて取捨選択します。
すべてを必須にすると、コストが膨らむうえに、事業者の提案の幅も狭まります。一方で、優先度を明示しておけば、限られた予算で最大の効果を得られる要件構成を事業者と一緒に作り込めます。要件の優先順位付けは、コストと効果のバランスを取る実務的な工夫です。
非機能要件（セキュリティ・可用性・BCP）の明記
公共システムは、住民の個人情報や税・福祉の情報を扱います。そのため、機能要件と同じく、非機能要件も仕様書に明記します。
- セキュリティ：権限管理・監査ログ・暗号化の定め
- 可用性：稼働率など、停止を防ぐための水準
- BCP：停止時にも業務を続けるための方法
非機能要件を曖昧にしたために失敗した例も、実際に起きています。復旧時間なども定量的な指標で示し、目標値を明記しておけば、事業者と水準をそろえられます。
設定をベンダー任せにした結果、個人情報が外部から閲覧できてしまった事例もあります。だからこそ、権限管理の要件は仕様書で詰めておく必要があります。
サイバー攻撃や大規模障害でシステムが止まっても窓口を止めないよう、紙の代替フローと訓練を要件に含めます。有事の備えは、調達の段階から組み込めます。
調達方式に応じたRFPの書き分け
公共調達では、方式によってRFPの書き方を変えます。たとえば、価格を主な基準とする一般競争入札では、仕様を細かく確定させます。
- 一般競争入札：事業者が価格で競える仕様
- 公募型プロポーザル・総合評価方式：KPIや課題を示し、実現方法の提案余地を残す
住民が直接使うサービスや独自性の高い施策では、提案を重視する方式が質の高い提案を引き出せます。
実際の例として、大阪市はガバメントクラウドの運用管理補助者を総合評価一般競争入札で、北九州市は観光AIチャットボットを公募型プロポーザルで調達しました。
標準性の高い対象は入札、提案力で差がつく領域はプロポーザルにするのが、一つの目安です。
まず調達方式を決め、その方式に合う粒度で要件を書けば、適切な事業者選定につながります。方式と要件の書き方が合っていないと、評価がうまく機能しなくなります。
マルチベンダーのSLA・責任分界とデータ移行要件
公共システムでは、複数の事業者がレイヤーごとに関わる体制が一般的です。とくにガバメントクラウド移行などでは、障害の切り分けや移行の段取りが難しくなります。
SLA・責任分界とデータ移行を要件として詰めておくことが、運用時のトラブルを左右します。
SLAと責任分界点の要件化
マルチベンダー環境では、障害の原因がどの事業者のレイヤーにあるかを切り分ける必要があります。さらに、接続エラーのたびに組織側が切り分けを担う負担も報告されています。
- 担当範囲：各事業者が担うレイヤーの明確化
- 障害対応：一次受付窓口とエスカレーション手順の定め
- 復旧目標：復旧時間の目標値
RFPでは、SLA（サービス品質の保証水準）と責任分界点を定義します。そのうえで、誰がどの事象に対応するかを契約に落とし込みます。
運用管理を支援する人材も、調達の対象として検討できます。実際に、大阪市は運用管理補助者を総合評価一般競争入札で単独で調達しました。
運用体制まで要件に含めておくと、組織が切り分け作業に追われる事態を防げます。SLAは、障害が起きたときにこそ価値を発揮します。
データ移行と過渡期連携の要件
レガシーシステムからの移行では、データ移行の要件が重要になります。RFPには、移行範囲、クレンジングの責任、移行後の検証方法を記載します。
- データクレンジング：移行元データの不整合の修正
- 過渡期連携：並行稼働中の新旧システム間の連携ルール
- 移行検証：リハーサルと合格基準、修正責任の定め
クレンジングをしないと、誤ったデータがそのまま引き継がれます。実際に、未納情報が誤って表示された事例も報告されています。
段階的に移行する場合は、移行済みの業務と未移行の業務をつなぐ連携を定義しておきます。地味な調整ですが、詰めないまま進めると、移行中に業務が止まるおそれがあります。
データ移行と過渡期連携は、要件定義で特に丁寧に扱う領域です。本番の前に実データでリハーサルを行い、件数の一致と整合性を確かめます。
RFPには、リハーサルの実施回数、合格基準、問題発生時の修正責任も記載します。検証を重ねる前提で要件を作っておくと、本番移行時の誤表示やトラブルを防ぎやすくなります。
補助金・制度要件のRFPへの織り込み
公共システムのRFPでは、財源と制度に関する要件も扱います。補助金の適用要件や、診療報酬・加算に関する機能要件が、投資計画と運用収支を左右します。制度は年度ごとに変わるため、最新の公募要領や改定内容を確認してから、要件に反映します。
補助金適用を前提とした要件設計
公共システムの調達では、補助金を前提に投資計画を組み立てるのが定石です。国の制度のほかにも、地域独自の支援制度があります。
- 国の制度：デジタル基盤改革支援補助金や地域未来交付金があります。
- 福井県：CO-FUKUIは最大300万円です。
- 大阪府：1プラン120万円のうち、府が2分の1の60万円を補助します。
制度の適用要件に沿ってRFPを設計すれば、自己負担を抑えながら必要な機能を確保できます。
補助金は年度ごとに条件が変わるため、要件を決める前に最新の公募要領を確認します。補助対象の経費や機能が限られる場合、RFPの要件が対象範囲の外にあると補助を受けられません。そこで、財政部門や所管部署と、要件定義の段階から連携します。
診療報酬・加算に対応する機能要件
医療分野の公共性の高いシステムでは、診療報酬や加算を機能要件に反映させます。要件にどこまで対応するかが、収支に関わります。制度の要件に合う機能を設計すると、投資負担を抑えながら制度的な評価も得られます。
- 加算1：令和8年度改定では15点
- 加算2：令和8年度改定では9点
- 加算3：令和8年度改定では4点
電子的診療情報連携体制整備加算が設けられました。なお、取得には、電子カルテや電子処方箋の連携機能が要件を満たしている必要があります。
電子処方箋の導入補助は最大194,000円です。さらに、東京や大阪などの上乗せを含めると、最大29.1万円程度の支援を受けられる場合があります。
また、介護分野でも、ICT導入支援が職員数に応じて最低100万円相当用意されています。制度の要件に合う機能を設計すれば、投資の負担を抑えつつ、制度上の評価も得られます。
制度は改定されるため、最新の点数と要件を確認してRFPに反映します。
導入後の定着・伴走の要件
RFPには、導入後の定着支援と伴走も記載します。納品のときにベンダーの関与が終わってしまうと、機能が使われず、利用率が下がることがあります。
- 運用支援：納品後の支援を役務に含める
- 利用状況の分析：利用ログをもとにした改善提案を求める
- UI改善：現場ヒアリングをもとにした改善
介護分野の関係者50名への調査では、ICTについて「知らない」が74%、「聞いたことがある」が20%、「理解がある」が6%でした。
現場がツールを理解していなければ、機能が優れていても使われません。そのため、導入時のオンボーディングと継続的な定着支援を、役務として記載します。
要件定義には、システムを作るための要件と、現場に根づかせるための要件の両方が必要です。
まとめ
公共システムの要件定義は、現場ヒアリングとToBe・KPIの定義から始めます。そのうえで、機能・非機能要件に加えて、SLAや責任分界、データ移行、制度要件も整理します。
標準化では、Fit&Gap分析が要件の精度を左右します。一部業務で3倍以上に増えた要件から、独自対応が要るものを見極めることが、運用経費の膨張を防ぎます。
SLA・責任分界とデータ移行のクレンジングは、運用時のトラブルを防ぐうえで重要な領域です。機能を増やすよりも、実務とKPIから必要な要件に絞り込みます。
公共特有の制度要件を早い段階で詰めておくと、移行後に運用経費だけが膨らむ事態を避けやすくなります。
riplaは、フルスクラッチ受託と国内開発を組み合わせ、業務を起点にした要件整理とRFP設計を、調達から運用まで支援しています。
全体像を確認するには、あらためて完全ガイドをご活用ください。
▼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を創業。