自治体向けシステム開発の開発期間・スケジュール・納期について

自治体向けシステム開発とは、市区町村や都道府県といった地方公共団体が、住民記録・戸籍・地方税・国民健康保険・介護保険・障害者福祉・生活保護・児童手当・子育て支援といった住民サービスの窓口業務を支える情報システムを整備・更改する取り組みです。同じ「行政のシステム」という言葉で語られる官公庁のシステムが、中央省庁を含む行政機関全般の内部行政事務を広く対象とするのに対し、自治体向けシステムは「基礎自治体（市区町村）・広域自治体（都道府県）という組織そのものが、目の前の住民に対して行う手続き業務」に焦点があります。また、道路・上下水道・公共交通・公共施設といった公共インフラや公共サービス全般を対象とする公共システムとも異なり、扱うのはあくまで自治体の内部業務と住民手続きです。この違いを押さえておかないと、開発期間の見積もりも大きくずれてしまいます。

本記事では、自治体向けシステム開発の「開発期間・スケジュール・納期」に焦点を当て、窓口業務システムの構築にかかる工数と期間の目安、全国一斉で進む地方公共団体情報システムの標準化・ガバメントクラウド移行がスケジュールに与える影響、移行困難システム（特定移行支援システム）の期限延長、年度更新や制度改正の施行日から逆算する「絶対に止められない」納期設計、複数自治体による自治体クラウド共同利用のリードタイム、そして自治体規模別に異なる期間リスクまでを、実際の自治体の事例と具体的な数値を交えて体系的に解説します。情報システム担当課の職員の方はもちろん、自治体向けにシステムを提案するベンダー担当者の方にとっても、現実的なスケジュールを描くための判断軸が得られる内容です。

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

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

自治体向けシステムとは何か──官公庁・公共システムとの違いと期間の考え方

自治体向けシステム開発の期間を考える前に、まず「自治体向けシステムとは何を指すのか」を明確にしておく必要があります。ここを曖昧にしたまま他分野の開発期間の相場を当てはめると、実態と大きくかけ離れた計画になってしまうためです。自治体向けシステムは、民間企業のシステム開発とは前提が根本的に異なるだけでなく、同じ公共分野の「官公庁のシステム」や「公共システム」ともスケジュールの決まり方が違います。以下では、まず対象範囲を整理したうえで、隣接する二つの領域との違いを押さえます。

自治体向けシステムの中核をなすのは、住民と直接接する窓口業務を支える「基幹業務システム」です。具体的には、住民基本台帳（住民記録）、戸籍、印鑑登録、地方税（住民税・固定資産税・軽自動車税）、国民健康保険、後期高齢者医療、国民年金、介護保険、障害者福祉、生活保護、児童手当、子ども・子育て支援、就学といった、住民のライフイベントに紐づく手続きを処理するシステム群がこれにあたります。国は、これらのうち住民に身近な基幹業務を「標準化対象20業務」として定め、全国の自治体で共通の標準仕様に沿ったシステムへ統一する取り組みを進めています。自治体向けシステム開発の期間を語るうえで最大の特徴は、こうした基幹業務システムが「一つの独立したシステム」ではなく、住民記録を起点に戸籍附票・選挙人名簿・課税・各種給付へと資格情報が連携する、密接に結合したシステム群だという点です。そのため、一つの業務システムを更改するだけでも、連携先とのインターフェース確認やデータ突合が必要になり、期間が民間の同規模システムより長くなりがちです。加えて、自治体は住民サービスを一日も止められないため、稼働時期の自由度が極めて低く、その制約が開発スケジュール全体を規定します。

自治体向けシステムは、隣接する二つの領域としばしば混同されますが、スケジュールを左右する要因が異なります。まず「官公庁のシステム」は、中央省庁から地方自治体、独立行政法人までを含む行政機関全般を対象とし、予算単年度主義や債務負担行為、一般競争入札・プロポーザル、政府情報システムのセキュリティ評価制度（ISMAP）といった、行政共通の制度的制約が期間を決める中心テーマになります。これに対して自治体向けシステムでは、そうした制度は前提として存在しつつも、実際にスケジュールを支配するのは「全国一斉に進む標準化・ガバメントクラウド移行の期限」と「住民サービスを止められない年度更新のタイミング」という、自治体固有の事情です。一方の「公共システム」は、公共交通の運行管理、上下水道や電気・ガスといったライフライン、公共施設の予約管理など、社会インフラや施設運営を対象とし、二十四時間三百六十五日の高可用性や制御系（OT）機器との連携が期間を規定します。自治体向けシステムはインフラ設備ではなく「役所の窓口業務そのもの」を扱う点で、これらと明確に区別されます。本記事では以降、自治体という組織に固有の期間要因に絞って解説していきます。

自治体の窓口業務システム構築にかかる期間の目安

自治体の窓口業務システムを構築・更改する場合、どの程度の工数と期間を見込めばよいのでしょうか。近年は標準準拠システムへの移行という形での更改が主流となっており、その工数感が一つの目安になります。ここでは、実際の自治体が公表した試算値をもとに、一業務あたりの工数と、期間が想定より膨らみやすい運用テスト工程について具体的に見ていきます。

自治体の基幹業務システムの構築・移行には、要件のすり合わせにあたるフィット＆ギャップ分析からデータ移行、運用テストまで、多大な工数を要します。大阪府吹田市が公表した標準準拠システムへの移行試算では、一業務あたりおおむね二十五人月の工数が必要と想定されています。その内訳は、計画立案フェーズに約六・三人月、システム選定フェーズに約三・七人月、そして移行フェーズに約十五・〇人月というもので、一業務につき毎月一人月程度の工数が発生し続ける計算です。ここで重要なのは、自治体はこの二十五人月規模の作業を、住民記録・地方税・国民健康保険・介護保険といった複数業務について同時並行で進めなければならない点です。標準化対象の二十業務すべてを限られた期間内に移行するとなれば、一業務ずつ順番に進める余裕はなく、複数チームによる並行体制が前提になります。つまり自治体向けシステムの構築期間は、単純な「開発期間の長さ」だけでなく、「同時にいくつの業務を動かせる人員を確保できるか」という体制の問題と密接に結びついているのです。職員側にも、通常の窓口業務を回しながら要件確認やデータ確認に相応の時間を割く負荷がかかるため、庁内の推進体制づくりそのものが期間短縮の鍵になります。

自治体向けシステムの期間見積もりで最も見落とされやすいのが、運用テスト工程の長期化です。住民の税額や給付額の算定を扱う以上、算定誤りは住民の不利益に直結するため、単体テストや結合テストに加えて、実際の業務データを用いた総合テストや、旧システムとの並行稼働による結果突合を十分な期間確保する必要があります。しかもこの運用テストは、現場の職員が通常の窓口業務と並行して行うため、当初の想定以上に時間がかかりがちです。北海道旭川市の事例では、当初は三ヶ月のテスト期間を設けていたものの、それでは時間が足りず、後続業務の移行にあたっては「余裕をもって約六ヶ月の期間を確保したい」と計画を見直しています。テストが長引く要因としては、職員が本来業務の合間にテストを進めざるを得ないことに加え、帳票の印刷や封入を外部委託している場合の帳票様式の修正確認、外部機関との連携テストの日程調整などが挙げられます。したがって、自治体向けシステムのスケジュールを引く際は、開発・移行そのものの期間だけでなく、少なくとも数ヶ月単位の運用テスト期間を後半に厚く確保しておくことが、稼働後の重大な障害を避けるための現実的な備えになります。テスト期間を圧縮してスケジュールを守ろうとすると、稼働直後の窓口混乱という形で跳ね返ってくるため、短縮するなら前半の準備を前倒しするのが定石です。

標準化・ガバメントクラウド移行が決めるスケジュールの前提

自治体向けシステムのスケジュールを民間や他の公共分野と決定的に分けているのが、国策として全国一斉に進められている「地方公共団体情報システムの標準化・ガバメントクラウド移行」です。これは、自団体単独の都合だけでは動かせない、全国共通の期限が前提条件として設定されているという特殊な状況を生み出しています。ここでは、原則的な期限と、期限内に間に合わないシステムに対する例外的な取り扱いを整理します。

地方公共団体情報システムの標準化では、住民記録・地方税・国民健康保険をはじめとする基幹二十業務について、国が定める標準仕様に準拠したシステムへ統一し、ガバメントクラウド上で運用することが求められています。この移行の期限は、原則として二〇二五年度末（令和七年度末）とされました。全国のすべての自治体が同じ期限に向けて一斉に移行を進めるため、自団体だけ好きな時期に着手すればよいという状況ではありません。この「全国共通の期限」は、二つの意味でスケジュールを厳しくします。一つは、期限そのものが動かせない上限として作用し、そこから逆算した工程を組まざるを得ないこと。もう一つは、全国の自治体が同時期にベンダーへ発注するため、開発ベンダーやガバメントクラウド移行を担う技術者の取り合いが起き、ベンダーを確保できない団体では着手そのものが遅れるリスクが高まることです。加えて、こども・子育て政策やマイナンバー関連施策といった優先度の高い制度改正が並行して発生し、限られた開発リソースをさらに圧迫します。自治体向けシステムのスケジュールは、こうした全国規模のリソース逼迫を前提に、早期にベンダーと調整を始めることが現実的な出発点になります。

すべての自治体が原則期限内に移行できるわけではありません。現行システムが個別開発（フルスクラッチ）で構築されている、あるいは現行ベンダーが標準化対応を行わないといった理由により、二〇二五年度末に間に合わせることが困難なシステムが存在します。これらは「特定移行支援システム（いわゆる移行困難システム）」として位置づけられ、二〇二六年度以降への移行が例外的に認められています。二〇二五年一月末時点では、全システムのうち八・六パーセントにあたる二千九百八十九システムがこれに該当し、期限延長の措置が取られました。とりわけ、独自のスクラッチ開発や専用パッケージのフルカスタマイズで現行システムを構築してきた政令指定都市では、移行困難システムに該当する割合が約六割にのぼるとされ、団体の規模が大きく固有要件が多いほどスケジュールが厳しくなる傾向がはっきり表れています。この移行困難システムの存在は、スケジュール設計に二つの影響を及ぼします。第一に、自団体のシステムが移行困難に該当するかどうかを早期に見極め、該当するなら延長後の期限に向けた別の工程を引く必要があること。第二に、業務ごとに移行時期がずれると、新旧システムが混在する「過渡期」が生じ、その間のデータ連携や業務運用に多大な検討要素とリスクが発生することです。この過渡期リスクを避けるため、北海道札幌市では移行困難システムを同時期に一斉移行する方針を採り、システム間の連携が中途半端に分断される期間を作らないよう工夫しています。移行困難システムを抱える団体ほど、全体のスケジュールを俯瞰した移行順序の設計が重要になります。

年度更新・制度改正から逆算する「止められない」納期設計

自治体の窓口業務は、住民の生活に直結するため一日たりとも止めることができません。そのため自治体向けシステムのスケジュールは、業務の繁忙期や法制度の施行日から逆算し、「この日までに必ず稼働していなければならない」という絶対的なデッドラインを起点に組み立てられます。ここでは、稼働時期の制約がどのようにスケジュールを規定するのか、具体的な事例で見ていきます。

住民影響の大きい業務を切り替える際、自治体は窓口が閉まる休庁期間を狙って移行作業を行います。東京都東村山市の事例が、この分割移行の緻密さをよく示しています。同市では、住民記録・税務・就学・国民健康保険・児童手当といった住民影響の大きい多くの業務を、年末年始の休庁期間である令和八年（二〇二六年）一月に一斉移行し、戸籍・生活保護・子ども子育て支援といった業務を令和八年三月に移行するという、二段階の分割スケジュールを組んでいます。なぜこのように分けるのかというと、すべての業務を一度に切り替えると、万一トラブルが発生した際に窓口全体が機能停止に陥るリスクが大きすぎるためです。休庁期間中に移行を完了させ、開庁と同時に新システムで正常に業務が回ることを確認できる範囲に区切ることで、住民への影響を最小化しています。この事例が示すのは、自治体向けシステムの納期は「開発が終わったら稼働する」のではなく、「休庁期間という限られた移行の窓」に合わせて逆算されるということです。年末年始や年度末という数少ない切り替えのチャンスを逃すと、次の機会まで半年から一年待たされることもあり、スケジュールの柔軟性は極めて低くなります。

自治体向けシステムのもう一つの絶対的な制約が、法制度の施行日です。税制改正や社会保障制度の改正は、四月一日など特定の日から一斉に施行されることが多く、その日にシステムが対応していなければ、住民への課税や給付を正しく処理できません。したがって、制度改正の施行日は動かしようのないデッドラインとして機能します。北海道旭川市の事例では、この制約を逆手に取った移行順序の工夫が見られます。同市は、直近で大幅な制度改正が見込まれる業務について、古い汎用機（レガシー環境）のまま法改正対応をするとコストもリスクも高くなると判断し、そうした業務を先にガバメントクラウドへ移行（リフト）させる住民記録システムとタイミングを合わせて移行するよう、スケジュールを調整しています。つまり、「どうせ制度改正対応が必要になるなら、その改修を新環境で一度に済ませたほうが合理的だ」という発想で、制度改正の施行時期と標準化移行の時期を意図的に重ねているのです。このように、自治体向けシステムのスケジュールは、標準化の期限・休庁期間・制度改正の施行日という複数の固定的な制約が絡み合うため、それらを一枚のカレンダー上で整合させる緻密な逆算設計が欠かせません。

自治体クラウド共同利用のスケジュールと広域調整

単独の自治体でシステムを調達・運用するのではなく、複数の自治体が共同で同一のシステムを利用する「自治体クラウド」という選択肢があります。スケールメリットによるコスト削減や運用負荷の分散が期待できる一方で、自治体間の合意形成に相応の時間がかかるため、スケジュールの観点では独特のリードタイムを織り込む必要があります。ここでは、共同利用の期間感と、都道府県が主導する広域調整の動きを見ていきます。

自治体クラウドの共同調達は、参加する複数の自治体が業務運用のやり方や仕様をすり合わせる必要があるため、単独調達よりも準備に時間がかかります。東京都の小平市・東村山市・東久留米市の三市による共同利用の事例では、平成三十年（二〇一八年）十二月に「住民情報システム共同利用に関する協定」を締結し、その後にシステムの調達と構築を経て、令和四年（二〇二二年）一月から三市共同での自治体クラウド利用を開始しています。協定締結から本稼働まで、およそ三年のリードタイムを要した計算です。この数字は、共同利用を検討する自治体にとって重要な目安になります。複数団体で足並みをそろえるには、業務フローの違いを埋める調整や、共通仕様の合意形成に相当の期間が必要であり、「共同化すればすぐ安くなる」というものではないのです。ただし、この長期にわたって築かれた強固な協力体制は、後の標準化対応において大きな武器になります。三市はすでに共同の事務局体制を持っていたため、その後の標準化に向けたフィット＆ギャップ分析を三市同時に、共通の様式で効率的に進めることができました。つまり、共同調達の初期投資的なリードタイムは、その後の継続的な更改や制度対応の局面で回収されていく性質のものだと理解しておくとよいでしょう。

市区町村単独では調整しきれない広域の課題については、都道府県が主導して市町村のスケジュールを束ねる動きも広がっています。長野県では、県内全七十七市町村と広域連合が参加する推進協議会を設置し、複数団体が同じベンダーを利用しているケースごとに検討チームを発足させて、合同でのスケジュール調整や仕様のすり合わせを行っています。同じベンダーの顧客をまとめて調整することで、ベンダー側の対応負荷を平準化し、個々の自治体が孤立して交渉するよりも有利にスケジュールを進められる仕組みです。また大阪府では、市町村が単独では確保しづらい専門のデジタル人材を府と市町村で共同確保・シェアリングする事業を展開し、共同調達の枠組みを活用した人的支援のスケジュールを回しています。標準化のような全国一斉の大規模移行では、技術者の不足がそのまま個々の自治体の遅延に直結するため、都道府県が広域で人材とスケジュールを差配する役割の重要性が高まっているのです。単独団体のスケジュールを考える際も、都道府県が用意するこうした広域支援の枠組みを早期に把握し、活用できるものは取り込んでおくことが、遅延リスクの低減につながります。

まとめ

本記事では、自治体向けシステム開発の開発期間・スケジュール・納期について、市区町村・都道府県という基礎自治体・広域自治体の窓口業務システムに焦点を当てて解説しました。行政機関全般を対象とする官公庁のシステムや、公共インフラ・施設を対象とする公共システムとは異なり、自治体向けシステムのスケジュールは、標準準拠システムへの移行工数（一業務あたり約二十五人月）、全国一斉に進む標準化・ガバメントクラウド移行の原則二〇二五年度末という期限、移行困難システムの期限延長、休庁期間や制度改正の施行日から逆算する止められない納期、そして自治体クラウド共同利用の数年単位のリードタイムといった、自治体固有の要因によって規定されます。さらに、政令市から町村まで規模によって現行システムの構造と移行難易度がまったく異なるため、自団体の位置づけを踏まえた期間リスクの把握が欠かせません。納期を守る鍵は、動かせないデッドラインから逆算し、運用テストを後半に厚く確保したうえで、他システム連携とデータ移行を独立したタスクとして早期に計画へ組み込み、全国的なベンダー逼迫を見越して早めに調整を始めることにあります。自治体向けシステムの更改を検討されている方は、まず自団体のスケジュール制約とベンダーの確保状況を整理することから始めることをお勧めします。

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

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