自治体向けシステム開発のフルスクラッチ・オーダーメイド開発について

自治体の独自開発(フルスクラッチ)は、標準化の対象範囲、独自施策の必要性、移行の見通しを照らし合わせて、独自に作る領域を決めると、制度と業務に沿って進めやすくなります。

独自開発が選ばれる場面、契約と移行での備え、費用・財源・共同利用との関係を、順に見ていきます。

▼全体ガイドの記事
・自治体向けシステム開発の完全ガイド

標準化時代に自治体でフルスクラッチが選ばれる意味と隣接分野との違い

標準化による共通化の圧力が強まるなかで、自治体システムにおける独自開発の位置づけは大きく変わりました。標準に合わせることが原則となったため、独自開発には明確な理由が求められます。

標準化でパッケージ化が進む中の独自開発の位置づけ

地方公共団体情報システムの標準化では、基幹二十業務を国の標準仕様に準拠させます。そのため、自治体独自のカスタマイズは原則として認められません。

現行システムと標準仕様との差を洗い出す工程が、フィット&ギャップ分析です。差への対応には、業務改革、外部ツール、独自開発という方法があります。

  • 業務改革(BPR):業務フローを標準仕様に合わせる
  • 外部ツール:RPAソフトやマクロ機能で独自要件を代替する
  • 独自開発:標準準拠システムで満たせない要件に限る

岐阜市や国分寺市では、標準仕様との差への対応が実務上の課題になっています。基幹二十業務については、独自に作り込む余地が原則としてなくなります。

一方で、標準化の対象外となる住民向けサービスや都市基盤、独自施策などには、独自開発の余地があります。ただし、独自開発を選ぶには、「なぜ標準では対応できないか」という合理的な理由が欠かせません。

官公庁・公共システムのフルスクラッチとの違い

自治体向けシステムでは、官公庁や公共システムとは独自開発を判断する観点が異なります。主な違いは、技術上の複雑さだけでなく、標準化との関係が問われる点です。

  • 官公庁:大規模な府省庁基幹系など既製品で対応できない業務や、調達方式の選択が論点
  • 公共システム:制御機器、IoT、現場設備との複雑な連携が主な理由
  • 自治体:標準化対象か、移行困難か、独自施策・条例対応かを判断

官公庁では、一般競争入札、総合評価落札方式、プロポーザルの使い分けも論点です。一方で、公共インフラでは、二十四時間稼働を支える作り込みが問われます。

基幹二十業務は、標準準拠システムへ寄せるのが原則です。独自開発は、標準化の枠外、移行困難システム、独自施策・条例の実現に絞られます。

標準化方針に反した開発は、将来の共通化を妨げる場合があります。制度の全体像を踏まえて、独自に作る範囲を線引きします。

ポイント

独自開発を選ぶのは、標準準拠システムで満たせない要件に限ります。なぜ標準では対応できないかを説明できない要件は、独自開発の対象から外すのが目安です。

フルスクラッチ・独自開発が選ばれる具体的な場面

標準化が進むなかでも、自治体が独自にシステムを構築・維持するケースはあります。独自施策・条例に基づく処理や都市基盤、データ連携、移行困難なシステムの場合に分けて見ていきます。

独自施策・条例に基づく処理と標準化対象外の都市基盤

標準化の対象外となる独自施策や都市基盤では、業務やサービスに合わせた独自の開発が行われています。次のような事例があり、目的と仕組みは事例ごとに異なります。

  • 加古川市:約二千八百種類の手続きをオンライン化する独自フォーム
  • つくば市:FIWARE準拠のデータ連携基盤とMaaS・IoT連携
  • 会津若松市:七分野・四十超のサービスと会津コインをデータ基盤で連携
  • えびの市:二十二施設の予約にスマートロックと決済を組み合わせる

加古川市は既製パッケージに業務を合わせず、スマートフォン申請から内部処理までを一気通貫にしました。デジタル手続条例を制定し、個別条例改正の事務負荷をゼロにしています。

さらに、同市はワクチン接種予約に抽選方式を実装し、二十六万人への迅速な給付も実現しました。独自フォームと条例が施策を支えた事例です。

つくば市は、交通・環境データを統合するため、国際標準FIWAREに準拠した基盤を独自に構築しました。MaaSやIoTセンサーとは、APIを使って連携しています。また、会津若松市は「スマートシティ会津若松」として、各サービスを同じデータ基盤でつなぎ、独自の地域通貨「会津コイン」も展開しています。

えびの市は公共施設予約システムを約十ヶ月で構築しました。これらは標準化の枠外で政策目的を実現するため、独自開発が選ばれた例です。

移行困難システム(特定移行支援システム)

既存システムが標準化の期限に間に合わない場合は、特定移行支援システムとして期限の延長が認められます。

  • 該当理由:現行が個別開発、または現行ベンダーが標準化対応を行わない
  • 期限:原則の二〇二五年度末から、二〇二六年度以降へ延長
  • 全国の状況:二〇二五年一月末時点で二千九百八十九システム、全体の八・六%

政令指定都市では、独自スクラッチや専用パッケージを全面的にカスタマイズしたシステムの約六割が、移行困難に該当します。また、規模が大きく独自の作り込みが多いほど、移行は難しくなる傾向です。

業務ごとに移行時期がずれると、新旧システム間のデータ連携リスクが残ります。札幌市は、このリスクを避けるため、移行困難システムを同時期に一斉移行する方針です。

過去のフルスクラッチが、将来の標準化移行の負担になる場合があります。そのため、独自開発の設計では、標準や別システムへ移る局面も見据えておく必要があります。

ポイント

独自開発が選ばれるのは、独自施策・条例に基づく処理、都市基盤やデータ連携、移行困難なシステムのいずれかに当たる場合です。どれにも当たらない要件は、標準の枠内で対応を考えます。

ベンダーロックインの回避とデータの引き継ぎ

データ引き継ぎを中心に、全てのデータ、CSV形式、オープンAPI、国際標準を配置した図解。
契約時に引き継ぎ条件と接続方式をそろえる構成です。

独自開発で特に警戒したいのは、特定のベンダーに囲い込まれるロックインです。改修や移行の選択肢が限られ、乗り換えの際に多額の費用が生じる場合があります。

回避策は、契約や調達の段階で組み込んでおきます。具体的には、データ引き継ぎの義務と、オープンな標準の採用という二つの観点から確認します。

データの標準形式での引継ぎ義務

最も実務的な対策は、調達仕様書にデータ引き継ぎ義務を明記することです。えびの市は、公共施設予約システムで条件を定めました。

  • 引き継ぎ対象:蓄積された全てのデータ
  • 費用:契約期間終了時に無償で引き継ぐ
  • 形式:CSV形式を基本とする

蓄積されたデータは、自治体にとって重要な資産です。そのため、自由に取り出せる権利を契約で確保しておくと、次期システムへの乗り換えが容易になります。

ロックインを避ける第一歩は、契約期間の終了時に、データを無償かつ標準形式で引き継ぐ義務を契約に入れることです。独自形式のままでは、特定の事業者への依存が続きかねません。

オープンAPI・標準規格の採用

ロックインを避けるには、独自規格への依存を減らし、オープンAPIや国際標準を選ぶことが役立ちます。

  • API化:拡張や外部システムとの接続を想定した設計
  • 標準規格:FIWAREなど国際標準の採用
  • 事業者変更:複数事業者が機能追加に参入できる設計

MIEROPAやつくば市では、API化を前提に拡張を設計し、国際標準も採り入れています。オープンな設計は、将来の事業者交代や接続を容易にします。さらに、事業者間の競争を通じて、費用を抑えられる可能性もあります。

独自開発は閉じた仕組みだと思われがちです。しかし、標準的な方法で外部とつなぐことが、システムの持続性を支えます。データを取り出しやすいかどうかも、機能と並んで重視したい点です。

ポイント

ロックインを避けられるかは、契約終了時に無償・標準形式でデータを引き継げるかで分かれます。オープンなAPIや標準規格を使えるかも、同じ調達仕様書で確かめます。

レガシーシステムからのデータ移行の難所

レガシーシステム移行前に整理する出力形式、移行対象、現行側、次期側、自治体の役割を示すチェックリスト。
受け渡す形式と担当を先に定めると作業の境界が見えます。

独自開発で長年使ったレガシーシステムから新システムへ移す際には、特有の難所があります。独自の形式や項目を持つデータは、そのままでは移せない場合があるためです。

データ形式の統一と役割分担

移行時には、現行ベンダーと次期ベンダーのどちらが、どこまでを受け持つかを明確にしておく必要があります。出力側と受け取り側の責任を先に定めておくと、移行の段階で担当が決まらず作業が止まる事態を防げます。

  • 現行側:基本データリスト形式での移行データの出力
  • 次期側:出力形式を示したうえでの調達と、受け取り側の役割の設定
  • 自治体:現行の項目を洗い出し、移行対象を早期に判断

札幌市は、現行ベンダーに移行データの出力を義務づけるとともに、次期ベンダーにもこの条件を示したうえで調達しました。

国分寺市では、独自施策のデータ項目が標準システムに入らないことが、移行の時点で判明しました。独自に作り込んだデータが、共通化の局面でそのまま引き継げなかった事例です。このため同市は、マクロ機能やRPAで代替するなど、運用の見直しを迫られました。

新システムに載る項目と載らない項目を分けておくと、載らないデータの扱いを早く決められます。出力と変換の担当や形式も、契約の段階で取り決めておきます。

独自に作り込んだデータは、共通化の局面で引き継げない場合があります。移行の難所は技術面だけでなく、事前の整理や役割分担の不足にもあります。

過渡期の連携と運用見直し

すべての業務を一度に移せない場合は、独自開発の旧システムと新システムが混在する過渡期が生じます。

  1. 先に移す業務と、旧システムに残す業務の切り分け
  2. 新旧システム間の連携方法とテスト範囲の整理
  3. 新システムに載らない独自データの代替方法の決定

旭川市では、古い汎用機に業務を残したまま、一部を先行してガバメントクラウドへ移行(リフト)しました。

連携では、既存の「連携用マスタ」を経由させることで、システム間連携テストの範囲を最小限に抑えています。大規模な連携改修も避けています。

住民記録から戸籍附票や選挙人名簿、介護保険などへ資格情報を連携する自治体では、特に慎重な設計が必要です。連携先が情報を受け取れないと、住民手続きに影響が及びます。

移行時期や連携方法、独自データへの対応は、一枚の移行計画にまとめておくと、過渡期の混乱を避けやすくなります。

ポイント

判断の目安は、データが新システムの項目に載るかどうかと、現行と次期の担当範囲が決まっているかです。この2点を契約の前に確かめておくと、移行時の作業停止を防げます。

フルスクラッチの費用感と財源・共同利用との関係

中核市の平均、人口約二十七万人の中核市、人口約八万人の一般市について、移行前後の運用経費を並べた3つのパネル。
掲載された3例はいずれも移行後の運用経費が増えています。

独自開発を検討するときは、費用感と財源、共同利用との関係を押さえておく必要があります。更改で運用経費が増えるなかでは、財源をどう確保するかが問われます。

独自開発の費用感と財源

標準化とガバメントクラウドへの移行の影響で、更改費用は全国的に上昇傾向にあります。さらに、独自開発を上乗せするには、確かな財源の裏付けが欠かせません。

中核市を対象とした調査では、移行後の運用経費が増えたことが分かっています。増え方は団体の規模によって差があるため、独自開発の費用を見積もるときは、規模ごとの幅をつかんでおく必要があります。

  • 中核市の平均:約三億三千八百万円から約六億八千四百万円
  • 中核市の最大:移行後に五・七倍
  • 人口約二十七万人の中核市:二・〇八億円から七・八四億円、三・八倍
  • 人口約八万人の一般市:一・七四億円から四・〇七億円、二・三倍

標準化二十業務の初期構築には、総務省のデジタル基盤改革支援補助金が活用できます。ただし、対象は標準準拠システムへの移行で、独自開発そのものは賄えません。

独自の住民向けサービスには、地域未来交付金のデジタル実装型などが活用されています。えびの市も、独自の公共施設予約システムの導入にこの枠組みを使いました。

専門人材の確保には、特別交付税措置が使われます。たとえば、大阪府はデジタル人材シェアリングで、一プラン百二十万円のうち二分の一にあたる六十万円を補助しています。

標準化向けの補助と、独自サービス向けの交付金は対象が異なります。そのため、財源ごとに充当先を見極めて計画します。

自治体クラウド・共同利用との関係

独自開発を検討する際は、単独で作る場合と、複数の自治体で共同利用する場合を比べます。共同利用は、開発体制の強化やコスト削減にもつながります。

  • 小平市・東村山市・東久留米市:クラウド協定と共通様式で標準化対応
  • 大阪府:府と市町村による専門デジタル人材の共同調達
  • 人口約一万人の町:運用経費が三千六百万円から六千六百万円へ増加見込み

三市は、事務局どうしがビジネスチャットで調整し、フィット&ギャップ分析の様式を共通化しました。また、大阪府の事業は、単独での人材確保が難しい市町村を支援します。

一方で、共同利用にも注意点があります。自治体クラウドで費用を抑えていた団体では、標準化後に経費が上がる逆転現象もあります。

たとえば、人口約一万人の町では、標準仕様への対応とクラウド利用料の純増により、経費がおよそ一・八倍になる見込みです。

単独開発の価値と、共同化による費用や体制面の利点は、団体の規模や財政状況に照らして判断します。標準化の対象を共同利用に寄せる方法もあります。限られた財源を活かすには、真に独自性が必要な部分だけを独自開発する切り分けが有効です。

ポイント

判断の目安は、運用経費の増加を見込んだうえで、独自開発の上乗せ分を裏付ける財源があるかどうかです。補助と交付金は対象が違うため、財源ごとに充てる先を分けて考えます。

まとめ

自治体のフルスクラッチは、標準化による共通化の流れのなかで、独自開発の範囲を判断することになります。その線引きが制度を起点にしている点が、官公庁や公共システムとの違いです。

基幹二十業務は標準準拠が原則ですが、加古川市やつくば市、会津若松市、えびの市のように、独自開発が選ばれる領域もあります。さらに、政令市を中心に移行困難なシステムも残ります。

ロックインを避けるには、無償かつ標準形式でのデータ引き継ぎと、オープンAPIの採用が要ります。加えて、移行の役割分担と財源の区別、共同利用の費用も検討の対象になります。

標準化の対象は共同利用に寄せ、独自性が必要な部分に絞って開発する方法があります。まず、標準に乗せる範囲と独自に作る範囲を分けて検討します。

▼全体ガイドの記事
・自治体向けシステム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

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

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

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

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。