公共システム開発のフルスクラッチ・オーダーメイド開発について

公共システムの開発方式を検討する際、市販のパッケージやクラウドサービス（SaaS）を利用するか、要件に合わせてゼロから作り込むフルスクラッチ（オーダーメイド）開発を選ぶかは、プロジェクトの成否を左右する重要な判断です。公共交通の運行管理・料金精算、上下水道・電気・ガスといったライフラインの検針・料金計算・設備保全、公共施設の予約管理、公共工事の入札・積算・管理、独立行政法人・公社・第三セクターの業務など、公共システムが対象とする領域には、独自の料金体系や条例に基づくルール、現場の制御設備との複雑な連携、24時間365日の高可用性やリアルタイム性といった、パッケージでは吸収しきれない固有要件が数多く存在します。こうした要件に応えるためにフルスクラッチが選ばれる一方で、開発費用や期間が大きくなりやすく、特定のベンダーしか保守できなくなる「ベンダーロックイン」のリスクも抱えます。「どんなときにフルスクラッチを選ぶべきか」「費用や期間はどれくらいか」「長く使えるシステムにするには何に気をつければよいか」という疑問を持つ担当者は多いはずです。

本記事では、公共インフラ・公共サービスを支えるシステムのフルスクラッチ・オーダーメイド開発に焦点を当て、それが選ばれる場面とパッケージ・SaaSとの使い分け、費用・期間の目安、制御系（OT）やレガシー資産との連携の難しさ、ベンダーロックインを回避する設計、そして公共調達（入札・プロポーザル）との関係までを、公共分野の具体的な事例とともに体系的に解説します。公共施設や交通・ライフラインのシステムを所管する自治体・事業者の担当者はもちろん、公共分野へシステムを提供するベンダー担当者にとっても、開発方式を適切に選び、長期にわたって使えるシステムを実現するための判断軸が身に付く内容です。

本テーマに関する全体ガイドは、以下の記事をご覧ください。

▼全体ガイドの記事
・公共システム開発の完全ガイド

公共システムにおけるフルスクラッチ・オーダーメイド開発の位置づけ

フルスクラッチ開発とは、既製のパッケージやSaaSに頼らず、要件に合わせてシステムをゼロから設計・構築する方式です。オーダーメイドで作り込むため、業務や制度に完全に適合したシステムを実現できる一方、開発の工数が大きく、費用と期間がかさむという特性があります。公共システムでは、標準化された業務にはパッケージやSaaSを活用しつつ、標準では吸収しきれない固有要件を持つ領域についてはフルスクラッチや個別開発を選ぶ、という使い分けが基本になります。近年は行政の情報システム全般で標準化・共通化が進められていますが、それでもなお公共インフラや独自サービスの領域には、作り込みが避けられない部分が残ります。ここでは、どのような場面でフルスクラッチが選ばれるのか、そしてパッケージ・SaaSとどう使い分けるべきかを整理します。

公共インフラ・サービス分野でパッケージではなくフルスクラッチや個別開発が選ばれるのは、「標準化できない固有要件」が存在する場合です。第一に、制御系（OT）やIoT機器、MaaSとの複雑なデータ連携が必要なケースです。ある市では、交通や環境などの都市データが企業・部局間で分断されていた課題に対し、既存の単一パッケージでは対応できず、国際標準に準拠したデータ連携基盤を産官学協働で独自構築し、MaaSや自動運転、IoTセンサーをAPI連携させる横串のシステムを作り上げました。第二に、条例や独自の内部処理フローに基づく要件があるケースです。ある市では、2,800種類にも及ぶ行政手続きをオンライン化するため、パッケージ導入ではなく独自フォーム開発により、スマートフォンからの申請から内部処理まで一気通貫するシステムを構築しました。第三に、頻繁な法改正・制度改正への対応が求められるケースです。ある自治体の公共施設予約システムの調達仕様書では、国の法改正等により対応すべき機能改修を標準仕様として追加経費の請求なく提供することが規定されており、こうした公共特有のリスク配分に応えられる柔軟な作り込みが求められています。独自の料金体系や高いリアルタイム性が必要な場合も、フルスクラッチが有力な選択肢になります。

フルスクラッチとパッケージ・SaaSのどちらを選ぶかは、要件の独自性・変更頻度・コストの三つの軸で判断するのが基本です。要件が一般的で他の団体と共通性が高い業務は、パッケージやSaaSを活用したほうが初期費用も期間も抑えられ、他団体の改善が反映される恩恵も受けられます。逆に、その団体や事業にしかない独自要件が核心にあり、それを妥協するとシステムを導入する意味が失われる場合は、フルスクラッチが正当化されます。変更頻度の観点では、料金体系や制度がめまぐるしく変わる領域は、自組織で改修をコントロールできるフルスクラッチが有利な場合がありますが、その分保守コストも自組織で負担することになります。コストの観点では、フルスクラッチは初期費用が高くなりがちなため、長期にわたって使い続けることで投資を回収できる基幹的なシステムに向いています。実務的には、システム全体を一律にどちらかで作るのではなく、標準的な機能はパッケージ・SaaSを活用し、独自性の高いコア部分だけをフルスクラッチで作り込むハイブリッドな構成を採ることも多く、どの部分に作り込みの価値があるかを見極めることが賢明な使い分けの鍵になります。

フルスクラッチ開発の費用・期間の目安

フルスクラッチ開発の費用と期間は、システムの規模と要件の複雑さによって大きく変動します。ここでは公共分野の実例をもとに、規模別のおおよその費用・期間感と、それを左右する要件定義の精度、そして公共システムならではの財源について整理します。

公共システムのフルスクラッチ開発は、規模によって数千万円から数億円まで幅があります。比較的コンパクトな公共施設予約や住民向けサービス系の独自システムであれば、開発期間はおおむね10ヶ月程度、費用は数千万円規模が一つの目安です。実際、スマートロックとキャッシュレス決済の連携を含む公共施設予約システムの導入委託業務では、仕様書が示された時点から本稼働まで約10ヶ月程度の構築期間が見込まれていました。一方、都市全体の交通・環境データを連携させる基盤のように、複数の事業者・部局をまたぐ大規模なプロジェクトになると、実証実験を含めて数年がかりとなり、費用も1億円から数億円規模へと膨らみます。上下水道や公共交通の基幹システムのように、扱うデータ量が膨大で現場設備との連携が不可欠な領域も、大規模な部類に入ります。フルスクラッチは作り込む範囲が広いほど費用も期間も比例して増えるため、本当に作り込む必要のあるコア部分を見極め、周辺機能は既製品を組み合わせることで、全体のコストを抑える設計が重要になります。

フルスクラッチ開発では、費用と期間のブレを決めるのが要件定義の精度です。ゼロから作り込む以上、何をどう作るかがすべて発注側の要求に委ねられるため、要件が曖昧なまま開発に入ると、途中での仕様変更や手戻りが頻発し、費用も期間も膨らみます。逆に、要件定義を丁寧に精緻化しておけば、見積もりの精度が上がり、開発中の混乱を最小化できます。公共システムでは、料金体系や条例に基づくルール、関係部署・関係事業者の要望を漏れなく洗い出し、優先順位を付けて合意しておくことが、結果的にコストを抑える最善策になります。また、公共システムの財源としては、国の交付金や補助金を活用できる場合が多い点も特徴です。ある自治体は公共施設予約システムの整備にあたり、デジタル実装に関する交付金を活用しており、スマートシティ関連の基盤整備なども含めて、国庫補助金や交付金を前提とした予算規模で計画されることが少なくありません。フルスクラッチの高い初期費用をどう賄うかを検討する際は、活用可能な補助制度を早い段階で調べ、その要件に沿った事業設計をしておくことが、実現可能性を高めるうえで重要です。

制御系（OT）・レガシー資産との連携の難しさ

公共システムのフルスクラッチ開発で難易度が高いのが、現場の制御設備（OT）や、過去に作られた既存システム（レガシー資産）との連携です。新しく作るシステムだけを見ていては見落としがちなこの領域が、しばしばプロジェクトの最大の難所になります。ここでは、その難しさの正体を二つの観点から見ていきます。

上下水道や電気・ガスといったライフライン、公共交通などのインフラ系システムでは、業務ソフトウェアが現場の制御設備やIoT機器とつながることで初めて機能します。上下水道であればメーターやポンプ・浄水設備の制御装置、公共交通であれば券売機・改札機・運行管理装置、公共施設であればスマートロックやキオスク端末などがその例です。これらの制御系（OT）は、情報系（IT）とは設計思想も更新サイクルも異なり、安定稼働を最優先するために古い技術がそのまま使われ続けていることも多く、新しいシステムと連携させるには専用のインターフェースや変換の仕組みが必要になります。また、制御系は止めると現場の運用に直結するため、連携のテストを本番環境で自由に行えないという制約もあります。フルスクラッチでインフラ系システムを開発する際は、制御系との連携方式を早い段階で設計・検証し、機器メーカーや現場の運用部門と密に連携しながら進めることが不可欠です。ソフトウェアの開発だけを見て計画を立てると、制御系連携の難しさを見落として大きな手戻りを招くことになります。

フルスクラッチで作り込んだシステムは、その時点では要件に完璧に適合していても、年月が経つと将来の「移行困難システム」に転じるリスクをはらんでいます。ある政令市の事例では、現行システムがパッケージではなく個別開発で運用されている基幹系システムが、標準化対応の際に「移行困難システム」に分類され、現行ベンダーに移行データを所定の形式で出力するよう依頼するなど、データの抽出と移行に多大な調整とコストを要しました。長年独自に作り込んできたシステムは、データ構造が特殊で仕様書が散逸していることも多く、新システムへの移行時に想定外の負担が生じるのです。また、新しい標準準拠システムと既存のオンプレミス環境・別クラウド・外部システムを連携させる際には、複数の事業者が絡むマルチベンダー環境となり、役割分担や過渡期の対応が大きな壁になります。ある政令市では、こうした連携について想定される多数のパターンを網羅的に整理する必要に迫られています。フルスクラッチを選ぶ際は、目先の適合性だけでなく、将来の移行・連携まで見据えて、データを取り出しやすい形で持つ設計を最初から意識しておくことが、長期的なコストを左右します。

ベンダーロックインを回避する設計

フルスクラッチ・オーダーメイド開発で最も警戒すべきなのが、特定のベンダーしか保守・改修できなくなる「ベンダーロックイン」です。いったんロックインに陥ると、保守費が高止まりし、システム更改の際にも足元を見られて選択肢が狭まります。公共システムでは公費を長期にわたって適正に使う責任があるため、調達の仕様書段階からロックインを避ける工夫を組み込んでおくことが定石になっています。

ベンダーロックインを回避する具体策として、契約終了時のデータ引継ぎを仕様であらかじめ義務づけておく方法があります。システムに蓄積されたデータをベンダーが握ってしまうと、次のベンダーへの移行時にデータ抽出費用を高額に請求され、実質的に乗り換えができなくなってしまいます。これを防ぐため、ある自治体の公共施設予約システムの仕様書では、契約期間終了時に蓄積された全てのデータを無償で引き継ぐこと、データ形式はCSV形式を基本とすることを明記し、ベンダー移行時のデータ抽出費用を請求させないよう事前にロックをかけています。このように、契約終了時にどのような形式でデータを返してもらえるかを調達段階で取り決めておくことは、将来の選択肢を確保するうえで極めて有効です。加えて、システムの設計書やソースコードの取り扱い、保守に必要な技術情報の開示についても契約に盛り込んでおくと、万一ベンダーを変更する必要が生じた際にも、後継のベンダーがスムーズに引き継げます。ロックイン回避は開発が終わってから考えるのではなく、発注前の仕様設計の段階で手を打っておくべき事項です。

もう一つの有効なロックイン回避策が、特定企業独自の規格ではなく、オープンな標準やAPIを採用することです。ある県の共同データ連携基盤や、前述の都市データ連携基盤の事例のように、国際標準に準拠したデータ連携の仕組みや、API化を前提とした拡張設計を採ることで、将来的なベンダー交代や別システムとの接続が容易になります。独自規格で密結合に作り込んでしまうと、その部分を理解しているベンダーしか手を出せなくなりますが、標準的なインターフェースで疎結合に設計しておけば、システムを部品ごとに交換・追加できる柔軟性が生まれます。公共システムは十年以上にわたって使われることも珍しくないため、開発当初の要件だけでなく、将来の制度変更・技術進化・システム更改まで見据えて、拡張しやすく交換しやすいアーキテクチャを選ぶことが重要です。フルスクラッチだからといってすべてを独自に作り込むのではなく、外部と接する部分は標準に準拠させ、独自性が本当に必要なコア部分に作り込みを集中させる。この設計方針が、長期にわたって適正なコストで公共システムを維持し続けるための土台になります。

公共調達（入札・プロポーザル）との関係

フルスクラッチやシステム統合を伴う公共システムの調達では、価格だけで決まる一般的な入札ではなく、技術力や提案内容を評価する調達方式が選ばれる傾向があります。ここでは、公共分野で用いられる代表的な調達方式と、依存を避けるための工夫を紹介します。

フルスクラッチ開発のように機能要件が複雑で、技術的な提案の質がプロジェクトの成否を左右する場合は、価格の安さだけで受注者を決める一般競争入札ではなく、提案内容を総合的に評価する公募型プロポーザル方式が適しています。ある市が本格運用する観光案内向けのAIチャットボットの調達では、多言語対応の仕組みや週次での情報更新体制といった運用・技術面の提案内容を評価するため、公募型プロポーザル方式が採用されました。この方式では、参加事業者が具体的な実現方法や体制を提案し、発注側が価格と技術・提案内容を総合的に審査して受注者を選びます。フルスクラッチのように「どう作るか」に幅があり、ベンダーの技術力や創意工夫が成果を大きく左右する案件では、最低価格の事業者を機械的に選ぶよりも、提案の質を評価して最適なパートナーを選ぶプロポーザル方式のほうが、結果的に良いシステムを得られる可能性が高まります。発注側は、評価の観点と配点を事前に明確にし、公正かつ透明性のある審査を行うことが求められます。

大規模な公共システムでは、すべてを一社に任せてしまうと、その事業者への依存が過度に強まり、ロックインや競争性の低下を招きます。これを避けるため、調達の範囲を機能や役割ごとに分割し、それぞれを別の事業者に発注するマルチベンダー化が有効です。ある政令市の基盤移行の事例では、アプリケーションを構築する事業者とは別に、ネットワーク接続の設定やクラウド環境のアカウント管理を担う運用管理補助の役務を切り離し、それを単独で総合評価一般競争入札により調達しています。これにより、インフラとアプリケーションを別々のベンダーに発注し、特定ベンダーへの過度な依存を防ぐ工夫がなされています。ただし、マルチベンダー化は依存を分散できる反面、事業者間の連携や障害時の責任分界点の管理が複雑になるため、発注側が全体を統括する体制やルールを整えておくことが前提となります。役務をどう分割し、どこを別発注にするかは、依存回避のメリットと調整コストの増加を天秤にかけて設計する必要があります。適切に設計されたマルチベンダー体制は、長期にわたって健全な競争環境を保ち、公共システムのコストと品質の双方に良い影響をもたらします。

まとめ

本記事では、公共インフラ・公共サービスを支えるシステムのフルスクラッチ・オーダーメイド開発について、それが選ばれる場面とパッケージ・SaaSとの使い分け、費用・期間の目安、制御系（OT）やレガシー資産との連携の難しさ、ベンダーロックインを回避する設計、そして公共調達との関係までを解説しました。フルスクラッチは、独自の料金体系や条例に基づく要件、制御系との複雑な連携、高い可用性・リアルタイム性といった、パッケージでは吸収できない固有要件に応えられる強力な選択肢です。一方で、コンパクトなシステムでも数千万円・約10ヶ月、大規模な基盤では数億円・数年規模と費用と期間がかさむため、本当に作り込む価値のあるコア部分を見極める姿勢が欠かせません。長く使えるシステムにするには、契約終了時のデータ無償引継ぎを義務づけ、オープンな標準を採用してベンダーロックインを避け、プロポーザル方式や役務の分割によって健全な競争環境を保つことが重要です。制御系連携やレガシー移行の難しさも早期に織り込んでおくことで、想定外の手戻りを防げます。公共システムの開発方式にお悩みの方は、要件の独自性と長期的なコストの両面から、実績のある開発パートナーとともに最適な方式を検討することをお勧めします。

▼全体ガイドの記事
・公共システム開発の完全ガイド

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。