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

自治体向けシステム開発におけるフルスクラッチ・オーダーメイド開発とは、市区町村や都道府県が既製のパッケージやサービスをそのまま使うのではなく、自団体の業務や施策に合わせてシステムを一から独自に構築する開発手法です。いま自治体のシステムは、地方公共団体情報システムの標準化によって、住民記録・戸籍・地方税・国民健康保険・介護保険・児童手当といった基幹二十業務を、原則二〇二五年度末までに国が定める標準準拠システム、すなわちパッケージやSaaSへ統一する大きな転換期にあります。この「標準化・共通化」の流れは、一見するとフルスクラッチとは逆方向に見えます。しかし実際には、標準化の対象外となる領域や、自治体独自の施策・条例に基づく処理、そして標準化に間に合わない移行困難システムなど、依然として独自開発が選択・維持される場面が確かに存在します。行政機関全般を対象とする官公庁のシステムや、公共インフラを対象とする公共システムとは異なり、自治体のフルスクラッチは「標準化という強い共通化圧力のなかで、どこを独自に作るべきか」という固有の判断が問われるのが特徴です。

本記事では、自治体向けシステム開発のフルスクラッチ・オーダーメイド開発に焦点を当て、標準化時代に自治体で独自開発が選ばれる意味と隣接分野との違い、独自施策・条例対応や標準化対象外の都市基盤・移行困難システムといった独自開発が選ばれる具体的な場面、契約段階で仕込むべきベンダーロックイン回避策、長年使ったレガシーシステムからのデータ移行の難所、そして独自開発の費用感と財源、自治体クラウド共同利用との関係までを、実際の自治体名と数値を交えて体系的に解説します。標準化への対応と並行して独自システムの整備を検討する自治体の職員の方にとって、限られた財源のなかで独自開発の是非を判断するための軸が得られる内容です。

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

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

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

自治体向けシステムのフルスクラッチを考えるうえでまず押さえておきたいのは、標準化という共通化の圧力が強まる現在、独自開発の位置づけそのものが大きく変わったという点です。かつては自団体の業務に合わせてシステムを独自に作り込むのが当たり前でしたが、いまは「標準に合わせる」ことが原則となり、独自開発はその例外として明確な理由が求められるようになりました。この前提の変化を理解したうえで、隣接分野との違いを押さえていきます。

地方公共団体情報システムの標準化では、基幹二十業務について、国が定めた標準仕様に準拠したシステムへ移行することが求められ、自治体独自のカスタマイズは原則として許容されなくなります。そのため、現行システムと標準仕様との差異を洗い出す「フィット＆ギャップ分析」が最重要の工程となり、差異が生じた場合には、自治体側が業務改革（BPR）を行って業務フローをシステムに合わせるか、あるいはRPAソフトやマクロ機能といった外部ツールで独自要件を代替する運用見直しが求められます。岐阜市や国分寺市の事例では、この差異への対応が実務上の大きな課題となっています。こうした標準化の潮流のなかで、フルスクラッチや独自開発が意味を持つのは、標準準拠システムでは満たせない要件が明確に存在する領域に限られます。言い換えれば、独自開発を選ぶには「なぜ標準では駄目なのか」を説明できる合理的な理由が不可欠です。基幹二十業務そのものを独自に作り込む余地は原則なくなった一方、標準化の対象外である住民向けサービスや都市基盤、独自施策を支えるシステムには、依然として独自開発の出番があります。標準化時代のフルスクラッチは、闇雲な作り込みではなく、標準に乗せる部分と独自に作る部分を戦略的に切り分ける判断そのものだといえます。

自治体向けシステムのフルスクラッチは、隣接する二つの領域の独自開発とは判断の力点が異なります。官公庁のシステム全般では、大規模な府省庁基幹系のように、そもそも既製品では対応できない業務をフルスクラッチで構築する場面や、一般競争入札・総合評価落札方式・プロポーザルといった調達方式の使い分けが論点の中心になります。公共システムでは、制御系機器やIoT、現場設備との複雑な連携が独自開発を必要とする主な理由であり、二十四時間稼働のインフラを支える作り込みが問われます。これに対して自治体向けシステムの独自開発を規定するのは、何よりも「標準化との関係」です。基幹二十業務は標準準拠システムへ寄せることが原則である以上、独自開発が許されるのは標準化の枠の外か、標準化に間に合わない移行困難システムか、あるいは自治体独自の施策・条例を実現する部分に絞られます。つまり自治体のフルスクラッチは、他分野のように「複雑だから独自に作る」という技術起点の判断だけでなく、「標準化の対象かどうか」という制度起点の判断が強く働くのです。この制度との関係を無視して独自開発に走ると、標準化の方針と衝突したり、将来の共通化の妨げになったりするため、標準化の全体像を踏まえた慎重な線引きが求められます。

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

標準化の波のなかでも、自治体が独自にシステムを構築・維持するケースは確かに存在します。それはどのような場面なのでしょうか。大きく分けると、自治体独自の施策や条例に基づく処理、標準化の対象外である都市基盤やデータ連携、そして標準化期限に間に合わない移行困難システムの三つに整理できます。ここでは、それぞれの実際の事例を見ていきます。

独自開発が選ばれる第一の場面が、自治体独自の施策や条例に基づく処理です。兵庫県加古川市は、約二千八百種類の手続きをオンライン化する際、既製のパッケージに業務を合わせるのではなく、独自フォームを開発して、スマートフォンからの申請から内部処理までを一気通貫で処理するシステムを構築しました。同時に「デジタル手続条例」を制定して個別条例改正の事務負荷をゼロにし、独自開発の強みを生かして、ワクチン接種予約での抽選方式の実装や二十六万人への迅速な給付を実現しています。第二の場面が、標準化の対象外である都市基盤やデータ連携システムです。茨城県つくば市は、交通や環境のデータを統合するため、国際標準であるFIWAREに準拠したデータ連携基盤を独自に構築し、MaaSやIoTセンサーをAPIで連携させています。福島県会津若松市は「スマートシティ会津若松」として、七分野で四十を超えるサービスを同一のデータ基盤で連携させ、独自の地域通貨「会津コイン」まで展開しています。宮崎県えびの市は、公共施設予約システムにおいて、市内二十二施設にスマートロックとキャッシュレス決済を独自に組み合わせたシステムを、約十ヶ月の期間で構築しました。これらはいずれも標準化の枠外にあり、自治体の政策的な狙いを実現するために独自開発が選ばれた例です。

独自開発が関わる第三の場面が、過去にフルスクラッチで作り込まれた既存システムが標準化に間に合わない「移行困難システム」の問題です。現行システムが個別開発（フルスクラッチ）である、あるいは現行ベンダーが標準化対応を行わないといった理由により、原則の二〇二五年度末までに標準準拠システムへ移行できないシステムは、「特定移行支援システム」として二〇二六年度以降への期限延長が認められています。二〇二五年一月末時点で、全国のシステムのうち八・六パーセントにあたる二千九百八十九システムがこれに該当します。とりわけ、独自のスクラッチ開発や専用パッケージのフルカスタマイズで現行システムを構築してきた政令指定都市では、移行困難システムに該当する割合が約六割にのぼり、団体の規模が大きく独自の作り込みが多いほど、標準化への移行が難しくなる傾向がはっきり表れています。北海道札幌市では、これらの移行困難システムについて、業務ごとに移行時期がずれて新旧システムが混在する過渡期のデータ連携リスクを避けるため、同時期に一斉移行する方針を採っています。この場面が示すのは、過去のフルスクラッチが将来の標準化移行の重荷になりうるということであり、独自開発を選ぶ際は、いずれ標準や別システムへ移る局面まで見据えた設計が欠かせないという教訓でもあります。

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

フルスクラッチや独自開発で最も警戒すべきなのが、特定のベンダーに囲い込まれてしまう「ベンダーロックイン」です。独自に作り込んだシステムは、そのベンダーでなければ改修も移行もできない状態に陥りやすく、次期システムへの乗り換え時に多額の費用を請求されるリスクがあります。これを防ぐには、契約・調達の段階で対策を仕込んでおくことが決定的に重要です。ここでは、データの引き継ぎ義務とオープンな標準の採用という二つの観点から見ていきます。

ベンダーロックインを防ぐ最も実務的な方法が、調達仕様書のなかにデータの引き継ぎ義務を明記しておくことです。宮崎県えびの市は、公共施設予約システムの調達仕様書に「契約期間終了時には、蓄積された全てのデータを本市に無償で引き継ぐこと。データ形式はCSV形式を基本とする」と明記しました。これによって、次期システムへ移行する際のデータ抽出で、現行ベンダーから費用を請求されないよう、あらかじめロックをかけているのです。独自開発では、システムに蓄積されたデータこそが自治体の最も重要な資産であり、それを自由に取り出せる権利を契約段階で確保しておくことが、将来の乗り換えの自由度を大きく左右します。データ形式を汎用的なCSVと定めておく点も重要で、特定ベンダーの独自形式でしか出力できないと、結局そのベンダーに依存し続けることになりかねません。契約終了時のデータ引き継ぎを「無償で」「標準的な形式で」と具体的に義務づけておくことが、独自開発におけるロックイン回避の第一歩になります。フルスクラッチを選ぶ際は、目先の機能要件だけでなく、契約終了という出口の局面でどうデータを守るかまでを、仕様書に落とし込んでおくことが求められます。

ロックインを防ぐもう一つの柱が、特定企業の独自規格ではなく、オープンなAPIや国際標準の規格を採用することです。三重県が構築した共同データ連携基盤「MIEROPA」や、前述のつくば市の事例では、API化を前提とした拡張設計や、FIWAREをはじめとする国際標準を採用しています。こうしたオープンな設計思想を貫くことで、将来的なベンダーの交代や、別のシステムとの接続が容易になります。独自開発というと、その団体だけの閉じたシステムを作るイメージを持たれがちですが、実際には逆で、外部と標準的な方法でつながれるように作っておくことが、独自開発を持続可能にする鍵になります。特定ベンダーの独自仕様に依存したシステムは、短期的には作りやすくても、拡張や連携のたびにそのベンダーへ依頼せざるを得ず、長期的にはコストも自由度も悪化します。オープンAPIや標準規格を採用しておけば、後から機能を追加する際にも複数の事業者が参入でき、競争を通じて費用を抑えられます。自治体が独自開発を選ぶ際は、囲い込まれない設計、すなわちデータの取り出しやすさと外部連携のしやすさを、機能そのものと同じくらい重視することが、賢明な投資につながります。

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

独自開発で長年使い込んできたレガシーシステムから新システムへデータを移すとき、そこには特有の難所が待ち構えています。独自に作り込まれたデータは、そのシステムだけで通用する形式や項目を持つことが多く、そのままでは新システムに載せられないためです。ここでは、データ移行における役割分担のあり方と、新旧システムが混在する過渡期の連携について見ていきます。

レガシーシステムからのデータ移行では、現行ベンダーと次期ベンダーの間で作業範囲と責任をどう分担するかが、成否を大きく左右します。北海道札幌市では、現行ベンダーの作業範囲に「移行データを基本データリスト形式で出力すること」を義務づけ、それを次期ベンダーに明示したうえで調達を行っています。データを取り出す側と受け取る側の責任範囲をあらかじめ明確にすることで、移行時に「どちらの担当か」で揉めて作業が止まる事態を防いでいるのです。一方、東京都国分寺市では、新システムへの移行時に、標準化対象外の独自施策で使っていたデータ項目が標準システムには入らなくなるという事態が発覚し、マクロ機能やRPAで代替するなどの運用見直しを迫られました。これは、独自開発で作り込んだデータが、標準化という共通化の局面でそのまま引き継げないことを端的に示す事例です。データ移行を計画する際は、現行システムのデータ項目を早期に棚卸しし、新システムに載る項目と載らない項目を仕分けたうえで、載らないものをどう扱うか、そして誰がどの形式でデータを出力・変換するのかという役割分担を、契約段階で明確にしておくことが不可欠です。データ移行の難所は、技術そのものよりも、この事前の整理と役割分担の甘さから生じることが多いのです。

すべての業務を一度に移行できない以上、独自開発のレガシーシステムと新システムが混在する「過渡期」が必ず生じます。この過渡期のシステム間連携を、いかに無理なく設計するかが重要になります。北海道旭川市では、古い汎用機からの移行にあたり、一度にすべてを標準化するのではなく、先にガバメントクラウドへ移行（リフト）させる業務と汎用機に残す業務を分け、汎用機内の既存の「連携用マスタ」を経由させることで、システム間連携のテスト範囲を最小限に抑える工夫を行っています。新旧が併存する期間に、両者をどうつなぐかを既存の仕組みを活かして設計することで、大規模な連携改修を避けているのです。過渡期の連携は、住民記録を起点に戸籍附票や選挙人名簿、介護保険などへ資格情報が連携する自治体システムでは、とりわけ慎重な設計が求められます。連携先が正しく情報を受け取れなければ、住民の手続きに直接影響が出るためです。独自開発のシステムを段階的に移行する際は、どの業務をいつ移すか、その間の連携をどう保つか、そして新システムに載らない独自データをどの業務ツールで代替するかを、一枚の移行計画として整理しておくことが、過渡期の混乱を避ける現実的な備えになります。

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

独自開発を検討するうえで避けて通れないのが、費用感とその財源、そして共同利用との関係です。標準化に伴うシステム更改だけでも運用経費が大きく膨らむなか、独自開発を上乗せするとなれば、財源の裏付けは一層重要になります。ここでは、費用の目安と活用できる財源、そして単独開発と共同利用のどちらを選ぶかという論点を整理します。

独自開発を含むシステム更改の費用は、標準化とガバメントクラウド移行の影響もあって、全国的に上昇傾向にあります。中核市を対象とした調査では、移行前の運用経費が平均約三億三千八百万円だったのに対し、移行後は平均約六億八千四百万円へと、平均二・三倍、最大で五・七倍に膨らんでいます。人口約二十七万人のある中核市では二・〇八億円から七・八四億円へと三・八倍に、人口約八万人のある一般市では一・七四億円から四・〇七億円へと二・三倍に増加しました。こうした費用増のなかで独自開発を上乗せするには、確かな財源の裏付けが欠かせません。財源としては、標準化二十業務の初期構築費に対する総務省の「デジタル基盤改革支援補助金」がありますが、これは標準準拠システムへの移行が対象であり、独自開発そのものを賄うものではありません。独自の住民向けサービスを導入する際には、地域未来交付金のデジタル実装型といった枠組みが活用されており、宮崎県えびの市は独自の公共施設予約システムの導入財源としてこれを活用しました。また、専門人材の確保には特別交付税措置が使われ、大阪府ではデジタル人材シェアリングにおいて一プラン百二十万円のうち二分の一にあたる六十万円を府が補助しています。独自開発の財源計画では、標準化向けの補助と、独自サービス向けの交付金とを区別し、どの財源をどこに充てられるかを正確に見極めることが重要です。

独自開発を検討する際には、単独で作り込むのか、それとも複数自治体で共同利用するのかという選択肢を常に天秤にかける必要があります。共同利用の枠組みは、開発体制の強化とコスト削減の両面で有効です。東京都の小平市・東村山市・東久留米市の三市は、自治体クラウドの協定を結んだうえで、ビジネスチャットを用いて事務局間で緊密にすり合わせを行い、フィット＆ギャップ分析を共通の様式化するなど、効率的な標準化対応を進めています。大阪府では、市町村が単独では難しい専門デジタル人材の確保を、府と市町村で共同調達する形のシェアリング事業として提供しています。一方で、共同利用には注意すべき側面もあります。すでに自治体クラウドで費用を低く抑えていた団体では、標準化によって逆に経費が跳ね上がる「逆転現象」が起きており、人口約一万人のある町では、移行前の運用経費三千六百万円が、標準仕様への対応やクラウド利用料の純増によって六千六百万円、およそ一・八倍へ増大する見込みとなっています。独自開発か共同利用かを判断する際は、独自性を追求して単独開発することの価値と、共同化によるコスト・体制面のメリットを、自団体の規模と財政状況に照らして冷静に比較することが求められます。標準化の対象部分は共同利用に寄せ、真に独自性が必要な部分だけを独自開発する、というメリハリのある切り分けが、限られた財源を活かす現実的な戦略になります。

まとめ

本記事では、自治体向けシステム開発のフルスクラッチ・オーダーメイド開発について、標準化という共通化圧力のなかで独自開発をどう位置づけるかという自治体固有の視点から解説しました。行政機関全般を対象とする官公庁のシステムや、公共インフラを対象とする公共システムとは異なり、自治体の独自開発は「標準化の対象かどうか」という制度起点の判断が強く働きます。基幹二十業務は標準準拠システムへ寄せることが原則となる一方、加古川市の独自フォームやつくば市・会津若松市の都市基盤、えびの市の施設予約システムのように、独自施策・条例対応や標準化対象外の領域では依然として独自開発が選ばれています。また、過去にフルスクラッチで作り込まれたシステムが移行困難システムとして残る問題も、政令市を中心に顕在化しています。独自開発を成功させる鍵は、データの無償・標準形式での引き継ぎ義務やオープンAPIの採用によってベンダーロックインを避けること、レガシーからのデータ移行で役割分担と過渡期の連携を丁寧に設計すること、そして標準化向けの補助と独自サービス向けの交付金を区別した財源計画を立てることにあります。標準化の対象は共同利用に寄せ、真に独自性が必要な部分だけを独自開発するというメリハリのある切り分けが、限られた財源を活かす戦略になります。独自開発を検討されている自治体の方は、まず標準に乗せる部分と独自に作る部分の線引きから始めることをお勧めします。

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

株式会社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を創業。