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