官公庁のシステム開発では、住民記録システムや税務システムをはじめとする大規模な基幹系を、既製のパッケージソフトではなくゼロから設計・構築するフルスクラッチ・オーダーメイド開発が採用される場面が数多くあります。中央省庁・地方自治体・独立行政法人が扱う情報は、住民の個人情報や税情報、医療・社会保険といった極めて機微なデータであり、法制度や条例に細かく紐づいた独自要件を正確に反映する必要があるためです。民間企業のシステム開発とは異なり、官公庁の調達には一般競争入札や総合評価落札方式、公募型プロポーザル方式といった公平性・透明性を担保する制度が介在し、予算も単年度主義を原則としています。そのため「フルスクラッチにはどれくらいの費用と期間がかかるのか」「パッケージやガバメントクラウドの標準サービスとどう使い分ければよいのか」といった疑問を抱える調達担当者やベンダー担当者が少なくありません。
本記事では、官公庁におけるフルスクラッチ・オーダーメイド開発の位置づけを、地方公共団体情報システムの標準化・ガバメントクラウド移行という近年の大きな政策動向を踏まえて整理します。あわせて、システム規模別の費用感や要件定義が費用・スケジュールに与える影響、一般競争入札・総合評価落札方式・プロポーザル方式の違い、複数年度契約（債務負担行為）の設計、そして官公庁調達で長年課題とされてきたベンダーロックインの回避策までを、具体的な数字や制度の背景とともに解説します。標準準拠が求められる20業務とそうでない独自業務を切り分けながら、フルスクラッチという選択肢を適切に活用するための判断材料をお示しします。
本テーマに関する全体ガイドは、以下の記事をご覧ください。
▼全体ガイドの記事
・官公庁のシステム開発の完全ガイド
官公庁システム開発におけるフルスクラッチ・オーダーメイド開発の位置づけ
官公庁のシステムは、民間の情報システムが一般に3〜5年で刷新されるのに対し、10〜20年という長期にわたって運用されることが多く、長期的な保守性・可用性・拡張性を前提とした設計が求められます。フルスクラッチ・オーダーメイド開発は、こうした長期運用と独自要件への適合を両立させる手段として位置づけられます。一方で、地方公共団体情報システムの標準化やガバメントクラウド移行の進展により、すべての業務をゼロから作るのではなく、標準準拠が求められる領域と独自開発が許容される領域を切り分ける発想が重要になっています。ここでは、フルスクラッチが選ばれる典型的な場面と、標準サービス・パッケージとの使い分けの考え方を整理します。
フルスクラッチが選ばれる場面（大規模基幹系・独自要件）
フルスクラッチ開発が選ばれる最も典型的な場面は、住民基本台帳や固定資産税、個人住民税といった大規模基幹系のうち、既製パッケージや標準サービスでは吸収しきれない独自要件を抱えるケースです。たとえば、独自の減免制度や地域固有の福祉給付、他システムとの複雑な連携要件などは、自治体ごとに運用ルールが異なるため、標準化された機能だけでは業務が回らないことがあります。こうした場合、業務プロセスに合わせて画面遷移やチェックロジック、帳票様式を細かく作り込めるフルスクラッチが有力な選択肢となります。
また、府省庁が所管する許認可システムや統計処理システム、補助金交付の審査システムなど、そもそも市販パッケージが存在しない専門性の高い領域でも、フルスクラッチ・オーダーメイド開発が中心になります。これらのシステムは、法改正のたびに処理ロジックを改修する必要があり、制度の細部まで正確に実装できる自由度が不可欠です。加えて、住民の個人情報や税情報といった機微なデータを扱うため、デジタル庁が2024年1月に公表した「セキュリティ・バイ・デザインガイドライン（DS-200）」に沿って、設計段階からセキュリティを組み込むことが求められます。要件が固有かつ長期に変化し続けるほど、パッケージの制約から自由になれるフルスクラッチの価値が高まります。
ガバメントクラウド標準サービス・パッケージ開発との使い分け
近年の官公庁システムでは、フルスクラッチ一辺倒ではなく、標準準拠システムやパッケージと組み合わせる使い分けが前提になっています。とりわけ地方公共団体では、住民基本台帳、戸籍、印鑑登録、固定資産税、個人住民税、介護保険、国民健康保険など基幹業務20業務について、国が示す標準仕様書に準拠したシステムへ移行することが求められています。デジタル・ガバメント実行計画では、2025年度中に約1,700の地方公共団体すべてがガバメントクラウド上の標準準拠システムへ移行することが目標とされており、これらの領域で独自のフルスクラッチを維持することは原則として認められません。
そのため、使い分けの基本は「標準化対象の20業務は標準仕様書に準拠したサービス・パッケージを採用し、標準化の対象外である独自業務や周辺システムにフルスクラッチを充てる」という切り分けになります。たとえば、標準準拠システムでは対応できない独自の申請受付・審査ワークフロー、庁内の他システムとのデータ連携基盤、住民向けのオンライン手続き画面などは、フルスクラッチで柔軟に構築する価値があります。デジタル庁が示す標準仕様書は自治体の規模や特性を細かく考慮していないため、実務ではどうしても調整が必要になりますが、その調整を標準準拠の枠内で行うのか、独自システム側で吸収するのかを見極めることが、費用と保守負担を最適化する鍵となります。
フルスクラッチ開発の費用・期間の目安
フルスクラッチ・オーダーメイド開発は、自由度の高さと引き換えに、数千万円から数億円規模の初期費用と年単位の開発期間を要します。官公庁システムの場合、この費用は人件費が大半を占め、エンジニアの人月単価は平均で80万円〜120万円、高度なスキルを持つ技術者では120万円〜200万円に達することもあります。ここでは、システム規模別のおおまかな費用感と、要件定義の精緻化が費用・期間に与える影響を、発注側が予算要求を組み立てる際の目安として整理します。
システム規模別の費用感（自治体窓口システム／府省庁基幹系）
比較的小規模な自治体の窓口支援システムや、特定部門向けの申請受付システムであれば、フルスクラッチでも数百万円から2,000万円程度で構築できるケースがあります。一方、基幹システムを一新するような大規模開発になると、一般的に2,000万円〜3,000万円程度が目安となり、システム連携が多い場合や対象業務が広い場合には数千万円以上、ときには数億円規模に達することも珍しくありません。府省庁の基幹系や全国規模で利用される共通システムでは、開発と初期構築だけで億単位、運用保守を含めた総額では数十億円規模になる例もあります。
期間についても、小規模な窓口システムであれば要件定義から稼働まで半年〜1年程度で収まることがありますが、大規模基幹系のフルスクラッチでは要件定義に半年以上、設計・開発・テストを含めると2〜3年、大規模な移行を伴う場合はそれ以上かかることもあります。官公庁の場合は、住民サービスを止められないため、旧システムとの並行稼働やデータ移行のリハーサルにも相応の期間を確保する必要があり、この移行期間を短く見積もると、稼働直前に費用と工数が膨らむ原因になります。予算要求の段階では、初期開発費だけでなく、移行・研修・運用保守を含めたライフサイクル全体の費用を見込むことが重要です。
要件定義の精緻化が費用・期間に与える影響
フルスクラッチ開発はゼロから設計・構築するため、要件定義の精度が費用と期間を大きく左右します。要件定義をベースに以降の設計・開発が進むため、この工程が曖昧なまま契約を締結すると、開発途中での仕様変更や手戻りが頻発し、結果として当初見積もりを大きく上回る費用が発生します。官公庁のシステムは法制度や条例に紐づく処理が多く、制度変更が見込まれる部分をどこまで柔軟に作り込むかによって、開発規模が数割単位で変動することもあります。要件を早期に固めきることが、費用と期間を安定させる最大のポイントです。
もっとも、官公庁の調達では、契約後に要件を大きく変更することが手続き上も難しいため、契約前の要件定義や仕様書作成の段階に十分な時間と体制を投じることが欠かせません。実務では、本格的な開発契約に先立って要件定義を独立した工程として発注したり、複数の事業者から情報提供を受けるRFI（情報提供要求）を実施したりすることで、精度の高い仕様書を整える手法がとられます。要件定義を丁寧に行うほど初期の調査費用はかさみますが、開発フェーズでの手戻りや追加契約を抑えられるため、プロジェクト全体で見れば費用対効果は高くなります。逆に、要件定義を軽視して価格の安さだけで発注すると、稼働遅延や品質不良を招き、最終的な総コストはかえって増大します。
官公庁特有の調達方式と発注プロセス
官公庁のシステム開発は、税金を原資とするため、公平性・透明性・経済性を確保する調達制度に沿って発注されます。民間のように特定の業者へ随意に発注できる場面は限られており、原則として競争性のある入札やプロポーザルを経て事業者を選定します。フルスクラッチ開発のように技術力や提案内容が成果を大きく左右する案件では、価格だけでなく提案の質を評価する方式が選ばれる傾向にあります。ここでは、代表的な調達方式の違いと、発注プロセスの流れを整理します。
一般競争入札・総合評価落札方式・プロポーザル方式の違い
一般競争入札は、参加資格を満たす事業者を広く募り、最も条件のよい入札者を選定する方式で、主に最低価格落札方式が採用されます。要件と仕様が明確に固まっており、価格競争によって調達すべき案件には適していますが、価格が最優先されるため、技術的な提案の巧拙が成果を左右するフルスクラッチ開発には必ずしも向きません。そこで用いられるのが総合評価落札方式です。これは一般競争入札の枠組みの中で、価格に加えて技術力や実施体制、提案内容を点数化し、総合得点で落札者を決める方式で、品質と価格のバランスを重視する大規模システム開発で広く採用されています。
公募型プロポーザル方式は、参加条件を満たすすべての事業者に平等に提案の機会を開いたうえで、提案内容そのものを中心に評価して事業者を選ぶ方式です。総合評価落札方式が一般競争入札・指名競争入札における選定手法であるのに対し、プロポーザル方式は随意契約における事業者選定の手法である点が制度上の大きな違いです。プロポーザル方式では、価格の優劣よりも「どのような体制と方法で課題を解決するか」という提案の質が重視されるため、要件がまだ固まりきっていない構想段階の案件や、業務改革を伴う難易度の高いフルスクラッチ開発に適しています。案件の性質、すなわち仕様の確定度合いと提案の重要度に応じて、これらの方式を使い分けることが求められます。
発注プロセスの流れ（情報提供要求から契約締結まで）
官公庁のフルスクラッチ開発の発注プロセスは、まず調達の企画・構想から始まります。担当部門は、業務課題や実現したい機能を整理し、必要に応じてRFI（情報提供要求）を実施して、複数の事業者から仕様書作成に必要な情報や技術動向の提供を受けます。このRFIは、後述するベンダーロックインの回避や、特定業者に有利とならない中立的な仕様書づくりのうえでも重要な役割を果たします。集めた情報をもとに、調達仕様書、評価基準、予算額を確定し、入札公告やプロポーザル募集を行う流れです。
公告後は、事業者からの提案書や入札書の提出を受け、総合評価落札方式であれば技術評価と価格評価を合算した総合得点で、プロポーザル方式であれば審査委員会による提案評価で受注者を選定します。選定後は契約を締結し、要件定義、設計、開発、テスト、移行、稼働という工程へ進みます。官公庁の場合、これらの各段階で議会や上位機関の承認、監査への対応、成果物の検査といった手続きが加わるため、民間よりも意思決定に時間を要します。発注側としては、公告から契約締結までのリードタイムや、契約後の要件変更が原則として難しい点を踏まえ、スケジュールに余裕を持たせた計画を立てることが欠かせません。
複数年度契約（債務負担行為）とスケジュール設計
官公庁の予算は単年度主義を原則とするため、複数年度にわたるフルスクラッチ開発では、年度をまたいで契約を結ぶための仕組みが必要になります。その中心的な制度が債務負担行為です。ここでは、単年度主義と債務負担行為の関係、そして複数年度契約における費用・スケジュール管理の留意点を整理し、年度をまたぐ大規模開発をどう設計すべきかを解説します。
単年度主義と債務負担行為の関係
財政法や地方自治法では、予算は当該年度内に執行することを原則とする単年度主義がとられています。しかし、フルスクラッチによる大規模システム開発は数年にわたることが一般的であり、単年度の枠内だけでは契約できません。この制約を緩和する仕組みとして、繰越明許費、継続費、そして債務負担行為の3つが用意されています。このうち、システム開発で最も広く使われるのが債務負担行為で、あらかじめ議会や国会の議決を経ることで、複数年度（一般に5年以内が目安）にわたって支出を約束する権限を得られます。
ただし、債務負担行為はあくまで「将来にわたって債務を負担してよい」という権限であり、実際に支出する権限（歳出予算）は各年度の予算で別途計上する必要がある点に注意が必要です。つまり、複数年度契約を締結するには、初年度の予算に加えて、翌年度以降の債務負担行為の設定が求められます。この仕組みによって、単年度の予算に縛られることなく、複数年にわたる開発を計画的かつ安定的に発注でき、事業者にとっても長期の体制を確保しやすくなるため、効率・品質の向上とコスト低減につながります。フルスクラッチ開発を発注する際は、開発期間全体を見据えた債務負担行為の設定を、予算要求の初期段階から財政部門と調整しておくことが不可欠です。
複数年度契約における費用・スケジュール管理の留意点
複数年度契約を前提とするフルスクラッチ開発では、各年度に成果物と支払いをどう配分するかを設計することが重要になります。要件定義と設計を初年度、開発とテストを次年度、移行と稼働を最終年度に割り当てるといった工程分割を行い、年度ごとに検収可能な成果物を定義しておくと、進捗管理と予算執行が明確になります。年度末をまたぐ工程では、作業や支払いが年度をまたいで滞らないよう、契約書上の履行期限や検査時期をあらかじめ調整しておく必要があります。
費用面では、当初の債務負担行為で設定した限度額を超える追加開発が発生した場合、改めて議会の議決や補正予算の手続きが必要になり、稼働スケジュールに影響を及ぼすおそれがあります。したがって、要件定義の段階で将来の制度変更や機能追加の可能性をできるだけ織り込み、限度額に一定の余裕を持たせておくことが実務的なリスク対策となります。また、複数年度にわたる開発では、途中で担当者が異動することも多いため、仕様や進捗の記録を組織として引き継げるよう、ドキュメントの整備と共有を徹底することが、プロジェクトの継続性を守るうえで欠かせません。
ベンダーロックインを回避するためのポイント
官公庁のフルスクラッチ開発で長年課題とされてきたのが、特定の事業者に依存してしまうベンダーロックインです。公正取引委員会が2022年2月に公表した「官公庁における情報システム調達に関する実態調査報告書」によれば、98.9％の官公庁が既存ベンダーと再度契約した経験があり、既存ベンダーしかシステムの内容を把握できない状況が競争を妨げていると指摘されています。フルスクラッチは自由度が高い反面、作り込みが特定業者のノウハウに閉じてしまうと、更改や機能追加のたびに同じ業者に頼らざるを得なくなります。ここでは、その回避策を解説します。
オープンな標準・仕様書設計の重要性
ベンダーロックインを回避する基本は、オープンな仕様を設計することです。特定のベンダー独自の製品や技術に依存せず、汎用性の高い技術や標準的な仕様、オープンソースソフトウェアを採用することで、多様なベンダーが参入しやすくなり、特定業者のみに有利となる仕様の設計を避けられます。データ形式やインターフェースを標準的な仕様で定義し、他システムとの連携を独自プロトコルに閉じないようにすることも、将来の乗り換えやすさを大きく左右します。デジタル庁も情報システム調達改革検討会の最終報告書（2023年3月）などを通じて、オープンな仕様設計と調達の透明化を推進しています。
また、発注者自身が仕様を十分に理解し、記述できる状態を保つことも重要です。既存ベンダーだけが仕様を把握している状況を防ぐため、RFI（情報提供要求）を活用して複数の事業者から情報提供を受けたり、発注支援業務を担う中立的な事業者を活用したりして、特定業者に偏らない仕様書を整える手法が有効です。あわせて、成果物としてソースコードや設計書、データベース定義などのドキュメントを発注者が確実に受領し、知的財産権の帰属を契約で明確にしておくことで、次回の更改時に別のベンダーが参入できる余地を残せます。仕様と成果物をオープンに保つことが、健全な競争環境と保守コストの適正化につながります。
標準化方針への対応と将来の刷新を見据えた設計
ベンダーロックインの回避は、国が進める地方公共団体情報システムの標準化方針とも密接に結びついています。基幹業務20業務を標準仕様書に準拠させ、ガバメントクラウド上で運用する取り組みは、自治体ごとにばらばらだったシステムを共通の土台に載せ替えることで、特定ベンダーへの依存を構造的に減らす狙いを持っています。フルスクラッチで独自業務を構築する際も、標準準拠システムとのデータ連携を標準仕様に沿って設計しておけば、将来標準化の対象範囲が広がった場合でも、比較的スムーズに移行できます。
将来の刷新を見据えるうえでは、システムを疎結合なモジュール構造で設計し、機能単位で入れ替えやすくしておくことが有効です。全体を一枚岩のフルスクラッチで作り込むのではなく、標準サービスやパッケージを活用できる部分は活用し、独自性が本当に必要な部分だけをオーダーメイドで構築するという切り分けが、10〜20年という長期運用を前提とする官公庁システムでは特に重要になります。こうした設計思想を調達仕様書の段階から明確に示しておくことで、初期構築だけでなく、その後の更改・機能追加まで含めた総保有コストを抑えつつ、健全な競争環境を維持することが可能になります。
まとめ
官公庁のフルスクラッチ・オーダーメイド開発は、住民記録や税務をはじめとする大規模基幹系や、市販パッケージが存在しない専門性の高い業務において、独自要件を正確に反映し、10〜20年という長期運用に耐える手段として重要な役割を果たします。一方で、地方公共団体情報システムの標準化・ガバメントクラウド移行が進むなか、基幹業務20業務のように標準準拠が求められる領域では独自のフルスクラッチを維持できないため、標準サービス・パッケージを採用する領域と、フルスクラッチで作り込む独自領域とを的確に切り分けることが、費用と保守負担を最適化する出発点となります。
費用は小規模な窓口システムの数百万円から、大規模基幹系の数千万円〜数億円規模まで幅があり、要件定義の精度がその振れ幅を大きく左右します。調達にあたっては、一般競争入札・総合評価落札方式・公募型プロポーザル方式を案件の性質に応じて使い分け、複数年度にわたる開発は債務負担行為を活用して計画的に発注することが求められます。さらに、RFIの活用やオープンな仕様設計、成果物と知的財産権の確保によってベンダーロックインを回避し、疎結合で刷新しやすい設計を志向することが、健全な競争環境と適正な総保有コストの両立につながります。フルスクラッチという選択肢を、標準化時代の文脈のなかで賢く活用していくことが、これからの官公庁システム調達に求められる姿勢といえるでしょう。
▼全体ガイドの記事
・官公庁のシステム開発の完全ガイド
株式会社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を創業。