自治体向けシステム開発の開発期間と納期は、標準化の期限、止められない窓口業務、制度改正の日程から逆算して決まります。移行と運用テストは並行して進めます。
職員や提案ベンダーが現実的な日程を描くには、工数と移行期限、納期を判断の軸にし、共同利用の検討も加えて考えます。
▼全体ガイドの記事
・自治体向けシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
自治体向けシステムの範囲と期間の考え方
自治体向けシステム開発は、市区町村や都道府県が住民サービスの窓口業務を支える情報システムを整備・更改する取り組みです。住民記録や地方税、国民健康保険などが対象になります。
官公庁のシステムは、中央省庁を含む行政機関全般の内部行政事務が対象です。一方、自治体向けは基礎自治体・広域自治体が住民に行う手続きに焦点があります。
自治体向けシステムは、民間企業のシステム開発とは前提が根本的に異なります。そのため、対象範囲が曖昧なまま他分野の開発期間の相場を当てはめると、実態とかけ離れた計画になりかねません。
公共システムは、道路や上下水道、公共交通などの公共インフラやサービス全般を対象とします。これに対し、自治体向けは自治体の内部業務と住民手続きが対象です。
「自治体向けシステム」が指す範囲
自治体向けシステムの中核は、住民と接する窓口業務を支える基幹業務システムです。住民のライフイベントに伴う手続きを処理します。
- 住民記録・戸籍：住民基本台帳、戸籍、印鑑登録です。
- 税・保険：地方税、国民健康保険、後期高齢者医療、国民年金です。
- 福祉・子育てなど：介護保険、障害者福祉、生活保護、児童手当、子ども・子育て支援、就学の業務です。
地方税には住民税、固定資産税、軽自動車税が含まれます。国は住民に身近な基幹業務を「標準化対象20業務」と定めています。
全国の自治体では、共通の標準仕様に沿うシステムへの統一が進んでいます。また、基幹業務は独立せず、互いに密接に連携するシステム群です。
住民記録の資格情報は、戸籍附票や課税、各種給付などへ連携します。そのため、更改時は連携先の確認やデータ突合が欠かせません。
連携先の確認やデータ突合に加え、住民サービスを止められず稼働時期の自由度も低いことから、同規模の民間システムより期間が長くなりがちです。
官公庁のシステム・公共システムとの違い
自治体向けシステムと混同されやすいのは、官公庁のシステムと公共システムです。両者は、期間を左右する要因もそれぞれ異なります。
- 官公庁のシステム：中央省庁、地方自治体、独立行政法人など行政機関全般です。
- 自治体向けシステム：住民サービスと窓口業務が対象で、標準化の期限や年度更新が日程を左右します。
- 公共システム：交通、ライフライン、公共施設などが対象で、稼働時間や制御機器との連携が期間の要因です。
官公庁のシステムでは、予算単年度主義や債務負担行為、一般競争入札・プロポーザルが制度的な制約になります。また、政府情報システムのセキュリティ評価制度（ISMAP）も関係します。
自治体にも行政共通の制度は前提としてありますが、日程を左右するのは、全国一斉の標準化・ガバメントクラウド移行の期限と、住民サービスを止められない年度更新です。
公共システムは、公共交通の運行管理や上下水道、電気・ガス、施設予約などが対象です。
公共システムでは、二十四時間三百六十五日の高可用性や制御系（OT）機器との連携が期間を規定します。一方、自治体向けは役所の窓口業務を扱うシステムで、インフラ設備ではありません。
自治体という組織に固有の期間要因は、ここから順に見ていきます。
自治体の窓口業務システム構築にかかる期間の目安
自治体の窓口業務システムを構築・更改する際は、標準準拠システムへの移行が工数と期間の一つの目安になります。自治体が公表した試算値から一業務あたりの工数を確認し、長期化しやすい運用テストの工程も、あわせて見ておきます。
標準化移行の工数目安（1業務あたり約25人月）
基幹業務システムの構築・移行では、フィット＆ギャップ分析からデータ移行、運用テストまで工数がかかります。大阪府吹田市の試算では、工程ごとの工数が次のように見積もられています。
- 計画立案：約六・三人月です。
- システム選定：約三・七人月です。
- 移行：約十五・〇人月です。
この試算は、一業務あたりおおむね二十五人月を想定しています。作業は一業務につき毎月一人月程度続く計算です。
自治体は住民記録や地方税、国民健康保険などを同時に進めるため、標準化対象の二十業務を限られた期間で移行するには、並行体制が前提になります。
構築期間は、開発の長さに加えて、複数業務を同時に動かせる人員を確保できるかにも左右されます。
職員は通常の窓口業務を回しながら、要件やデータの確認にも相応の時間を割きます。そのため、庁内の推進体制を早くから整えることが、期間の短縮につながります。
運用テストが長期化する理由（現場職員の並行作業）
運用テストは、期間見積もりで見落とされやすい工程です。税額や給付額の誤りは住民の不利益に直結するため、十分な確認が欠かせません。
- 実業務データでの確認：総合テストで、算定結果を確かめます。
- 旧システムとの突合：並行稼働による結果の照合です。
- 帳票・外部連携の確認：様式の修正と、連携日程の調整です。
現場職員が通常業務の合間にテストを進めることで、期間が長くなりがちです。たとえば、旭川市では当初三ヶ月を見込んだものの不足したため、後続業務では約六ヶ月を確保する計画に見直しました。
帳票印刷や封入を外部に委託している場合は、委託先との調整に加えて、帳票様式の修正確認も必要になります。外部機関との連携テストも、相手先と日程を合わせる調整が長期化の要因になります。そのため、テスト期間はさらに延びやすくなります。
開発・移行の後半には、少なくとも数ヶ月単位の運用テスト期間を確保しておく必要があります。テストを縮めると、稼働直後の窓口が混乱しかねません。
期間を短くしたい場合は、前半の準備を前倒しします。一方で、後半の確認期間を圧縮して納期を守る方法は現実的ではありません。
標準化・ガバメントクラウド移行が決めるスケジュールの前提
民間や他の公共分野と異なり、自治体の日程は国策として全国一斉に進む標準化・ガバメントクラウド移行に左右されます。
団体の都合では動かせない全国共通の期限が前提になります。次に、原則期限と、間に合わないシステムの例外扱いを見ていきます。
原則2025年度末という全国共通の期限
標準化では基幹二十業務を、国の標準仕様に準拠したシステムへ統一します。その運用先として、ガバメントクラウドが求められています。
- 期限から逆算する：原則期限を上限にした工程の組み立て。
- ベンダーを早く調整する：全国同時期の発注による人材不足への備え。
期限は原則として二〇二五年度末（令和七年度末）です。全国の自治体が同じ期限に向けて移行するため、着手時期を自由に決められません。
発注が集中すると、開発ベンダーやクラウド移行の技術者を確保できない団体が出るおそれがあります。確保できなければ、着手自体が遅れます。
こども・子育て政策やマイナンバー関連施策など、優先度の高い制度改正も並行して進みます。限られた開発リソースがさらに圧迫されるため、早期の調整が出発点になります。
移行困難システム（特定移行支援システム）と期限延長
すべての自治体が原則期限までに移行できるとは限りません。個別開発（フルスクラッチ）や現行ベンダーの標準化非対応などが理由で、二〇二五年度末に間に合わないシステムが出ます。
- 該当の有無を早く確認：対象なら、延長後の期限から工程を組みます。
- 移行順序を決める：新旧システム混在時の連携と業務運用の検討です。
該当するシステムは「特定移行支援システム」とされ、二〇二六年度以降への移行が例外的に認められます。
二〇二五年一月末時点では、全システムの八・六％にあたる二千九百八十九システムが該当し、期限延長の措置が取られました。
政令指定都市では、移行困難システムの割合が約六割にのぼるとされます。その背景には、独自のスクラッチ開発や専用パッケージのフルカスタマイズがあります。
団体の規模が大きく固有要件が多いほど、日程は厳しくなる傾向があります。また、業務ごとに移行時期がずれると、新旧システムが混在する過渡期が生じます。
過渡期には、データ連携や業務運用の検討事項が増え、リスクも高まります。このため、札幌市は移行困難システムを同時期に一斉移行し、連携が中途半端に分断される期間を避ける方針です。
移行困難システムを抱える団体は、個別システムの期限だけでなく、システム全体を見渡し、連携への影響も含めて移行順序を設計します。
年度更新・制度改正から逆算する「止められない」納期設計
窓口業務は住民の生活に直結するため、一日たりとも止められません。そのため、繁忙期や法制度の施行日から逆算し、必ず稼働すべき日を絶対的な期限として日程を組みます。ここからは、稼働時期の制約が日程を決める具体例を見ていきます。
年末年始・年度末の休庁期間を使った分割移行
住民への影響が大きい業務は、窓口が閉まる休庁期間に切り替えます。たとえば、東京都東村山市は業務を二段階に分けて移行する計画です。
- 令和八年一月：住民記録、税務、就学、国民健康保険、児童手当などの一斉移行。
- 令和八年三月：戸籍、生活保護、子ども・子育て支援などの移行。
一度に切り替えると、障害時に窓口全体が止まるリスクが大きいからです。
休庁中に移行し、開庁と同時に正常稼働を確認できる範囲に分けます。これにより、住民への影響を抑えられます。
納期は、開発の完了日ではなく、限られた移行の機会から逆算して決めます。年末年始や年度末を逃すと、次の機会まで半年から一年待つこともあります。
法制度の施行日から逆算するデッドライン
もう一つの絶対的な制約は、法制度の施行日です。税制や社会保障制度は四月一日などに一斉施行されるため、未対応のままでは課税や給付を正しく処理できません。
- 施行日を固定する：制度改正の日を、動かせない期限として扱います。
- 移行日と重ねる：改正対応を新環境で行う順序の検討です。
旭川市は、直近に大幅改正が見込まれる業務を先に移すよう調整しています。旧汎用機（レガシー環境）で改正に対応するより、費用とリスクを抑えられると判断したためです。
該当業務は、ガバメントクラウドへ移行（リフト）する住民記録システムと時期を合わせます。制度改正と標準化移行のタイミングを、あえて重ねる考え方です。
標準化の期限、休庁期間、施行日は互いに関係します。そのため、一枚のカレンダーで日程を合わせ、逆算して設計する必要があります。
自治体クラウド共同利用のスケジュールと広域調整
自治体クラウドは、複数の自治体が同じシステムを共同利用する方法です。コスト削減や運用負荷の分散が期待できます。
一方で、自治体間の合意形成には時間がかかります。共同利用のリードタイムと、都道府県が主導する調整を取り上げます。
協定締結から本稼働まで数年を要する共同調達
共同調達では、複数の自治体が業務運用や仕様をすり合わせます。たとえば、小平市、東村山市、東久留米市の三市の事例を見てみます。
- 協定締結：平成三十年（二〇一八年）十二月の、三市による協定締結。
- 共同利用開始：調達・構築を経た、令和四年（二〇二二年）一月の利用開始。
協定から本稼働までおよそ三年を要する点は、共同利用を検討する自治体にとって準備期間の目安になります。業務フローの違いを埋め、共通仕様に合意する期間が必要になるためです。
共同化すればすぐ安くなるとは限りません。ただし、三市は共同事務局をすでに持ち、標準化のフィット＆ギャップ分析を共通様式で同時に進められました。
さらに、共同で築いた体制は、その後の標準化対応にも役立ちます。初期のリードタイムも、後の更改や制度対応で生かされます。
都道府県主導の広域調整と人材シェアリング
市区町村だけで調整が難しい場合は、都道府県が日程を束ねることがあります。たとえば、長野県と大阪府の例があります。
- 長野県：県内全七十七市町村と広域連合が参加する協議会。
- 大阪府：府と市町村による、専門のデジタル人材の共同確保とシェア。
長野県では、同じベンダーを利用する団体ごとに検討チームを設け、合同で日程や仕様を調整しています。ベンダーの対応負荷を平準化し、個別に交渉するより有利に進める仕組みです。
大阪府の取り組みは、単独では確保しにくい人材を補う点が特徴です。共同調達の枠組みも活用して、人的支援を進めています。
全国一斉の大規模移行では、技術者不足が自治体の遅延に直結します。そのため、都道府県による広域の人材配置と日程調整が重要になります。
単独で移行する団体も、都道府県が用意する支援を早めに把握しておく必要があります。活用できる枠組みを取り込むことは、遅延リスクの低減につながります。
まとめ
自治体向けシステムの開発期間・日程・納期を、市区町村と都道府県の窓口業務に絞って整理しました。官公庁や公共システムとは異なる、固有の制約があります。
標準準拠システムへの移行は一業務あたり約二十五人月が目安です。全国一斉の標準化・ガバメントクラウド移行は二〇二五年度末が原則期限で、移行困難システムには期限延長があります。
止められない窓口業務の納期は、休庁期間や制度改正の施行日から逆算します。共同利用には、数年単位の準備期間がかかる場合があります。
政令市から町村まで、規模によって現行システムの構造と移行の難しさは異なります。そのため、自団体の期間リスクを把握することが欠かせません。
納期を守るには、動かせない日程から逆算し、後半の運用テストを厚く確保することが大切です。あわせて、他システムとの連携やデータ移行も早い段階で計画に入れておきます。
全国的なベンダー不足を見越して、早めに調整を始めます。更改を検討する場合は、自団体の日程制約とベンダーの確保状況を整理しておく必要があります。
▼全体ガイドの記事
・自治体向けシステム開発の完全ガイド
▼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を創業。