公共システムのフルスクラッチ開発は、標準化しにくい固有の要件がある場合に選ばれる方式です。
費用と期間は規模や要件の複雑さで変わります。制御系との連携やロックインの回避、調達の進め方も、計画の段階で確認しておきたい点です。
▼全体ガイドの記事
・公共システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
公共システムにおけるフルスクラッチ・オーダーメイド開発の位置づけ
フルスクラッチ開発は、既製品に頼らず要件に合わせてシステムを設計・構築する方式です。業務や制度に合わせやすい一方で、工数が大きくなり、費用と期間もかさみます。
標準化された業務には、パッケージやSaaSを使い、固有の要件には個別開発を選ぶのが基本です。行政情報システムの標準化・共通化も進んでいます。
公共インフラや独自サービスには、24時間365日の高可用性やリアルタイム性など、標準では吸収しきれない要件が残ります。
フルスクラッチが選ばれる場面
フルスクラッチが選ばれるのは、標準化できない固有の要件がある場合です。
- 複雑な連携：制御系やIoT機器、MaaSを連携させる必要がある
- 独自の業務要件：条例や独自の内部処理フローに合わせる必要がある
- 制度変更への対応：頻繁な法改正などに合わせた柔軟な改修が求められる
- 独自料金・高い即時性：固有の料金体系や高いリアルタイム性への対応が要る
ある市では交通・環境データが企業・部局間で分断され、単一パッケージでは対応できませんでした。そこで、産官学で国際標準の基盤を独自に構築し、MaaS・自動運転・IoTをAPIで横断連携しました。
別の市は、2,800種類の行政手続きをオンライン化するため、独自フォームを開発しました。スマートフォンから申請して、内部処理までを一気通貫させた事例です。
ある自治体の施設予約仕様書は、国の法改正に伴う機能改修を標準仕様とし、追加経費なしで提供すると定めています。また、公共特有のリスク配分に応える柔軟な作り込みも求められます。
パッケージ・SaaSとの使い分けの判断軸
パッケージやSaaSと個別開発の使い分けは、四つの観点で判断します。
- 共通性：一般的な業務ならパッケージやSaaSが向く
- 独自性：事業固有の要件が核心にあるなら、個別開発が候補
- 変更頻度：制度や料金が頻繁に変わるなら、自組織で改修を制御しやすい
- 長期コスト：長く使う基幹システムでは、初期投資を回収しやすい
共通性の高い業務では、初期費用と期間を抑えつつ、他団体の改善も取り込めます。一方で、独自要件を妥協すると導入の意義が失われる場合には、フルスクラッチが正当化されます。
料金体系や制度がめまぐるしく変わる領域では、フルスクラッチが有利な場合があります。改修を自組織で制御できる反面、保守コストも自組織が負担します。
全体を一つの方式で揃えず、標準機能はパッケージ・SaaSに、独自の中核部分はフルスクラッチにする構成もあります。作り込む価値のある範囲を見極めることが、選定の鍵です。
フルスクラッチ開発の費用・期間の目安
費用と期間は、規模や要件の複雑さで変わります。公共分野の事例からは、規模別の目安と、要件定義や財源の関係が読み取れます。
規模別の費用・期間感
公共システムのフルスクラッチ開発費用は、数千万円から数億円まで幅があります。
- コンパクトな独自システム：施設予約や住民向けサービスなら数千万円、期間は約10ヶ月が目安
- 複数組織をまたぐ基盤：数年がかりで、費用は1億円から数億円規模
- 設備連携を伴う基幹系：大規模になりやすい
導入委託業務の事例では、スマートロックとキャッシュレス決済を連携しました。仕様書の提示から本稼働まで、約10ヶ月の構築期間が見込まれていました。
都市全体の交通・環境データ基盤は、実証実験を含めて数年かかることがあります。また、上下水道や公共交通の基幹系も、膨大なデータや現場設備との連携があるため、大規模になります。
作り込む範囲が広いほど、費用と期間は比例して増えます。そこで、必要なコアを見極め、周辺には既製品を組み合わせる設計にすると、全体のコストを抑えられます。
要件定義の精緻化と財源（交付金・補助金）
費用と期間のぶれを抑えるには、要件定義の精度と財源の見通しが欠かせません。
- 要件定義：見積もりの前に、作る内容を明確にしておく
- 関係者との合意：料金や条例のルール、部署・事業者の要望を漏れなく整理し、優先順位を付ける
- 財源を確認：国の交付金や補助金を使える場合がある
ゼロから作るため、何をどう作るかは発注側の要求に委ねられます。要件が曖昧なまま開発を進めると、仕様変更や手戻りが頻発し、費用と期間が膨らみます。
反対に、要件を丁寧に詰めておけば、見積もりの精度が上がり、開発中の混乱も抑えられます。
ある自治体は施設予約システムの整備に、デジタル実装関連の交付金を使いました。スマートシティ基盤も、国庫補助金や交付金を前提に予算化されることがあります。
高い初期費用を賄うには、まず補助制度を早めに調べます。そのうえで、その要件に沿って事業を設計すると、実現可能性を高められます。
制御系（OT）・レガシー資産との連携の難しさ
公共システムのフルスクラッチ開発では、現場の制御設備（OT）や既存システム（レガシー資産）との連携が難所です。新システムだけを見ていると見落としやすく、プロジェクトで最も厄介な部分になることもあります。そのため、制御系と移行の両面を、早い段階から確認しておく必要があります。
制御系・IoT・現場設備との連携
インフラ系では、業務ソフトが現場の制御設備やIoT機器とつながって機能します。
- 上下水道・電気・ガス：メーター、ポンプ、浄水設備の制御装置
- 公共交通：券売機、改札機、運行管理装置
- 公共施設：スマートロック、キオスク端末
制御系（OT）は、情報系（IT）と設計思想や更新周期が異なります。安定稼働を優先して古い技術が使われ続けることもあり、専用の接続や変換が必要になります。
制御系は停止が現場運用に直結するため、本番環境で自由に連携テストできません。そのため、連携方式は早い段階で設計・検証し、機器メーカーや現場部門と進める必要があります。ソフトウェアだけで計画すると、連携の難しさを見落として手戻りを招きます。
レガシー個別開発システムの「移行困難」問題とマルチベンダー連携
個別開発システムの移行と、複数事業者が関わる連携には、特有の難しさがあります。
- 移行の難しさ：標準化の際に「移行困難システム」となる場合がある
- データ抽出：長年の独自開発で構造が特殊化し、仕様書も散逸していることが多く、移行の負担になる
- 複数事業者の連携：役割分担や過渡期の対応が複雑になる
個別開発は当初要件に適合しても、年月を経て移行困難になるリスクがあります。たとえば、ある政令市の基幹系も、標準化の際に移行困難システムに分類されました。同市は現行ベンダーに所定形式でのデータ出力を依頼し、抽出と移行に調整と費用を要しました。
標準準拠システムを既存環境や外部システムにつなぐ場面では、複数の事業者が関わります。ある政令市は、役割分担や過渡期の対応に備えて、多数の連携パターンを整理しました。
目先の適合性だけでなく、将来の移行や連携も見据える必要があります。特に、データを当初から取り出しやすく持つ設計は、長期のコストを左右します。
ベンダーロックインを回避する設計
フルスクラッチで警戒すべきなのは、特定ベンダーしか保守・改修できないロックインです。保守費が高止まりし、更改時の選択肢も狭まるため、仕様書の段階から対策しておく必要があります。
公共システムでは、公費を長期にわたり適正に使う責任もあります。
データ引継ぎ・無償出力の義務化
契約終了時のデータ引継ぎを仕様で義務づけると、移行の選択肢を確保できます。
- 全データの引継ぎ：契約終了時に無償で返す
- 標準的な形式：データ形式はCSVを基本とする
- 技術情報の開示：設計書やソースコード、保守情報を契約で定める
ある自治体の施設予約仕様書は、契約終了時に全データを無償で引き継ぐこと、CSVを基本形式とすることを定めています。さらに、移行時の抽出費用も請求させない定めになっています。
データをベンダーが握ったままだと、移行時に高額な抽出費を請求され、乗り換えが難しくなるおそれがあります。逆に、契約で形式や費用を定めておけば、後継事業者への移行に備えられます。ロックイン対策は、発注前の仕様設計の段階で定めておくと、移行の進め方も円滑になります。
オープン標準の採用と長期運用を見据えた設計
独自規格を避け、オープン標準やAPIを採用することも、ロックイン対策になります。
- 標準に準拠：データ連携には国際標準を使う
- APIを前提に設計：他システムと接続しやすくする
- 部品ごとに交換可能：標準的な接続で柔軟性を持たせる
県の共同データ基盤や都市データ基盤では、国際標準やAPIを前提にした設計が使われました。こうした接続は、ベンダーの交代や別システムとの連携を進める助けになります。
独自規格による密結合は、対応できる事業者を限ってしまいます。一方で、疎結合にしておけば、部品を交換・追加しやすくなります。
十年以上使うこともあるため、制度変更や技術進化、更改を見据えた設計が必要です。外部との接続は標準に合わせ、独自性が必要なコアに作り込みを集中させます。この方針は、適正なコストで長く維持するための前提になります。
公共調達（入札・プロポーザル）との関係
複雑な開発やシステム統合では、価格だけでなく技術力や提案を評価する方式が選ばれることがあります。公共分野の調達方式と、事業者への依存を避ける方法についても触れます。
公募型プロポーザル方式の活用
要件が複雑で提案の質が成否を左右する場合、公募型プロポーザルが適しています。
- 具体案を募る：事業者による実現方法と体制の提案
- 総合的に審査：価格と技術・提案内容を合わせて評価し、受注者を決める
- 評価基準を示す：観点と配点を明確にした、公正な審査
ある市は観光案内AIチャットボットの調達で、この方式を採用しました。多言語対応の仕組みや、週次の情報更新体制を評価するためです。
作り方に幅があり、技術力が成果を左右する案件では、最低価格だけで選ぶより、提案の質で相手を選ぶ方が、良いシステムを得られる可能性が高まります。
役務の切り離しとマルチベンダー化による依存回避
大規模システムを一社に任せると、依存が強まり、競争性が低下するおそれがあります。
- 役割ごとに分割：機能や役務を分けて発注する
- 別事業者に委託：インフラとアプリなどを分ける
- 統括体制を用意：連携や障害時の責任分界を管理する
ある政令市は基盤移行で、ネットワーク接続設定とクラウドアカウント管理の補助を、アプリ構築から分離しました。そのうえで、別事業者へ総合評価一般競争入札で発注し、特定ベンダーへの依存を防ぎました。
分割すると依存を分散できますが、事業者間の連携や障害時の責任管理は複雑になります。そのため、発注側が統括体制とルールを整え、依存回避と調整コストを踏まえて分割を判断する必要があります。
適切なマルチベンダー体制は、競争環境を保ち、長期的なコストと品質に影響します。
まとめ
独自料金や条例、制御連携、高可用性・即時性が求められる場合には、フルスクラッチが有力です。ここまで、選定の考え方や費用、連携を中心に、ロックインや調達についても整理しました。
小規模な予約・住民向けシステムは、数千万円・約10ヶ月が目安です。大規模な基盤は数億円・数年に及び、コアを絞り込むと費用を抑えられます。
長期運用では、契約終了時のデータ無償引継ぎとオープン標準が役立ちます。また、提案評価や役務の分割で競争性を保ち、ロックインを避けられます。
制御系連携とレガシー移行も、早い段階で計画に組み込んでおきたい点です。そのうえで、要件に合う方式を検討します。
公共システムの開発方式に迷う場合は、独自性と長期コストを踏まえ、実績のある開発パートナーと一緒に検討するとよいでしょう。
▼全体ガイドの記事
・公共システム開発の完全ガイド
▼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を創業。