公共システム開発を外注する流れは、業務要件の整理から始まり、仕様書、評価基準、契約、検収へと段階的に進みます。公共調達の原則と手続きを踏まえ、この順で一つずつ進めることが重要です。
- 業務、利用者、調達方式、仕様、予算の整理
- RFI、公告、資格審査、提案評価の条件の決定
- 契約、開発、検収、移行、運用の計画
▼全体ガイドの記事
・公共システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
公共システム開発の外注・発注の全体像
公共システムの開発を外注する流れは、大きく4つのステップに分かれます。最初が「計画・要件整理フェーズ（業務分析・RFI・仕様書作成）」、次が「調達・入札フェーズ（公告・入札・審査・契約）」です。続いて「開発フェーズ（要件定義〜テスト〜リリース）」があり、最後に「運用フェーズ（保守・法改正対応・改善）」があります。
公共調達特有の手続きとして、この流れに一連のプロセスが加わります。具体的には、RFI（情報提供依頼書）の活用、入札仕様書（調達仕様書）の公告、入札参加者の資格審査があり、そのあとに開札・落札者決定と契約締結が続きます。
このため、発注側は各フェーズで自分たちがすべきことを理解し、準備と意思決定を適切に行うことが、プロジェクトを成功させる鍵です。
調達方式の種類と選択基準
公共システムの調達方式には、主に「一般競争入札」「指名競争入札」「随意契約」の3種類があります。一般競争入札は、最も透明性・公平性が高い方式で、一定金額以上の調達では原則として採用が義務づけられています。この方式では、入札資格要件を満たすすべての事業者が参加でき、競争性が確保される一方で、入札仕様書の作成や審査に時間がかかります。
指名競争入札は、発注機関が信頼できる事業者を指名して競争させる方式で、実績・信頼性のある業者に絞った入札が可能です。ただし、指名の公平性を確保することが課題です。
随意契約は、特定の事業者と直接契約する方式で、緊急対応・特許技術・少額案件などに限定されます。そのうえで、公共システム開発では、金額や緊急性・特殊性に応じて、適切な調達方式を選ぶことが大切です。
総合評価落札方式の活用
公共システムの調達では、価格だけで落札者を決める「最低価格落札方式」より、技術力・実績・体制・セキュリティ対応力も価格とともに評価する「総合評価落札方式」の活用を強くおすすめします。一方、最低価格落札方式では、価格競争の結果として技術力の低いベンダーが落札し、システム品質の低下・納期遅延・追加費用の発生につながるリスクがあります。
総合評価落札方式では、技術提案書の審査・プレゼンテーション評価・類似実績の確認などを通じて、価格と品質・技術力のバランスを考慮した落札者選定が可能です。また、評価基準（価格評価点・技術評価点の配点比率）は、案件の特性に応じて設定することをおすすめします。
発注前の準備：RFIの活用と仕様書作成
公共システムの開発発注を成功させるには、入札公告の前に十分な準備を行うことが最も大切です。準備が不十分なまま入札を公告すると、仕様書の解釈が曖昧になり、参加者から質問や問い合わせが殺到するおそれがあります。さらに、入札後に仕様変更が生じると、追加費用や納期遅延につながりかねません。
特に、公共システムの仕様書には、セキュリティ要件・標準化要件・法令対応要件など多岐にわたる専門的な内容が求められます。そのため、時間をかけて準備することが欠かせません。
RFI（情報提供依頼書）の作成と活用方法
RFI（Request For Information：情報提供依頼書）は、入札仕様書を作成する前に、市場の最新動向や技術、費用感、対応できるベンダーを把握するためのツールです。
RFIを使うと、ガバメントクラウド上で実装できるかどうかや、標準仕様書への準拠方法を事前に知ることができます。さらに、セキュリティ要件の実現コストや、複数のベンダーの対応能力も把握できます。そうして得た回答を入札仕様書の作成に生かすことで、実現可能性が高く、競争性も確保された調達が可能になります。
RFIに記載する主な内容は、システムの目的と概要、業務要件の概要、セキュリティ要件の概要です。加えて、ガバメントクラウド・標準化対応の方針とスケジュールの目安を書き、回答を求める情報として、対応可能な技術、費用概算、実績を挙げます。
入札仕様書（調達仕様書）の作成ポイント
入札仕様書（調達仕様書）は、複数のベンダーが同一条件で入札・提案できるよう、要件を詳細かつ明確に記述した文書です。主な内容は、プロジェクトの目的と背景、現状の業務フローと課題、新システムで実現すべき機能要件（必須要件・推奨要件に分類）です。
非機能要件（性能・可用性・拡張性・セキュリティ・標準準拠性）も、あわせて盛り込みます。公共システムでは、LGWAN接続・マイナンバー連携、ガバメントクラウド対応、地方公共団体情報システム標準化対応の要件を記載します。また、データ移行や研修・導入支援、保守・運用（SLA・法改正対応・バージョンアップ）の要件も定めます。
最後に、納品物の一覧（ソースコード・設計書・テスト仕様書・操作マニュアル）と、評価基準（総合評価落札方式の場合は技術評価点の基準）を記載します。仕様書の品質が提案の品質と競争性に直結するため、できる限り詳細かつ客観的に書くことをおすすめします。
ベンダー評価と審査のポイント
入札仕様書を公告したら、参加表明と入札書の受付を行います。総合評価落札方式では、技術提案書の審査とプレゼンテーション評価も行います。評価にあたっては、担当職員だけでなく、情報システム・セキュリティ・業務の専門知識を持つ内部・外部委員で構成する評価委員会を置くことをおすすめします。
公平性と透明性を保ちながら、技術力・実績・セキュリティ対応力を適切に評価することが大切です。
ベンダー評価の基準
公共分野の実績では、同種・同規模の公共システム開発実績の有無や、自治体・政府機関への納入実績を見ます。セキュリティ対応力では、ISMS認証やプライバシーマークの取得、LGWAN接続システムの構築実績、マイナンバー法対応システムの実績を確認します。
標準化・ガバメントクラウド対応力は、標準準拠システムの開発実績と、ISMAP登録クラウドサービスの活用経験で判断します。プロジェクト管理体制では、PM専任かどうか、公共システムのプロジェクト管理経験、再委託の管理体制を見ます。
保守・長期運用体制では、法改正対応の実績とスピード、SLA設定の妥当性、担当者の継続性の確保を押さえます。また、財務状況の安定性（倒産リスク）や、情報セキュリティ事故の有無・対応実績も、評価の観点として欠かせません。
契約時の注意点
契約形態では、請負型は完成まで責任を負いますが、要件変更の費用は別途発生しやすくなります。一方、準委任型は要件変更に柔軟に対応できる反面、費用管理が難しくなります。また、納品物では、ソースコードの所有権と著作権の帰属、ドキュメント一式（仕様書・設計書・テスト仕様書・操作マニュアルなど）を定めます。
追加費用の発生条件と変更管理のプロセス、バグ対応の保証期間と範囲は、契約に含めます。法改正・制度改正対応の費用負担の考え方に加えて、セキュリティインシデント発生時の対応責任と損害賠償の条件を決めておきます。さらに、情報セキュリティ管理体制の確認と監査権限、再委託（下請け・孫請け）の可否と範囲・管理体制も押さえます。
公共調達では契約の適正性が特に重要で、法務担当や会計検査にも耐えられる契約書の内容を確認したうえで締結することをおすすめします。
開発中の管理と発注機関の役割
開発が始まったら、ベンダー任せにせず、自治体や公共機関などの発注機関も積極的にプロジェクトに関わることが欠かせません。具体的には、週次や隔週の進捗確認ミーティングに参加し、マイルストーン（要件定義完了・基本設計完了・開発完了など）ごとに納品内容を確認して承認します。
さらに、業務担当部署（住民課・税務課・福祉課など）に定期的なデモを見てもらい、早期にフィードバックを受けます。こうした関わりを続けることで、完成後に現場で使えないシステムになるリスクを大幅に減らせます。
特に、公共システムは複数の部署や担当者が利用するため、各部署の業務担当者が実際の業務シナリオで動作を確かめる機会を、開発中から設けることが大切です。
セキュリティ審査と脆弱性診断
公共システムでは、リリース前にセキュリティ審査と脆弱性診断を行うことが強く求められます。
特に、住民の個人情報やマイナンバー情報、税務情報を扱うシステムでは、外部の専門機関によるペネトレーションテスト（侵入テスト）、ソースコードレビュー、脆弱性スキャンを行うことが必要です。そのうえで、セキュリティ上の問題がないことを確かめてからリリースすることが望ましいです。
発注側は、発注仕様書にセキュリティ審査の実施と報告書の提出を義務づけ、審査費用も契約に含めておくと、後から費用が発生する事態を防げます。
検収・納品基準の設定と受け入れテスト
開発完了後の受け入れテスト（UAT：User Acceptance Testing）と検収手続きは、公共システムの発注でも重要な工程です。検収基準、つまり何をもって納品完了と判定するかは、事前に仕様書と契約書で明確に定めておきます。それが、後のトラブルを防ぐうえで大切なポイントです。
業務担当職員は、住民からの申請受付・審査・通知・データ連携などの業務シナリオで動作を確かめ、機能要件・非機能要件・セキュリティ要件をすべて満たしているかを見ます。検収で見つかったバグや仕様の乖離は、契約範囲内に入るか、追加費用が発生するかをベンダーと照らし合わせながら、対応を進めます。
操作マニュアル・設計書・テスト仕様書などのドキュメント納品も、検収の対象に含めておきます。
まとめ
公共システムの開発発注を成功させるには、RFIを活用した市場調査と、入札仕様書の詳細な作成が土台になります。そのうえで、適切な調達方式を選び（総合評価落札方式の活用を推奨）、セキュリティ審査を組み込み、契約内容を精査します。さらに、開発中も発注側が積極的に関わることが欠かせません。
特に、発注機関側の準備不足は、入札後の仕様変更・追加費用・納期遅延の主な原因になります。そのため、業務フローの整理、セキュリティ要件の明確化、標準化対応の方針の決定に、十分な時間をかけることをおすすめします。
公共調達では透明性・公平性・説明責任が求められるため、発注側は評価基準を明確にし、評価のプロセスを記録に残すことが重要です。
十分な準備と優れたパートナーの選定により、公共システムの開発は住民サービスの向上と行政事務の効率化に大きく貢献します。
▼全体ガイドの記事
・公共システム開発の完全ガイド
▼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を創業。