官公庁システムの開発期間は、方式によって6ヶ月から3年程度です。予算化や入札にも数ヶ月から1年近くかかるため、納期は稼働時期から逆算して見通すことが大切です。
官公庁のシステム開発は、中央省庁・地方自治体・独立行政法人が住民サービスや行政事務を支える情報システムを整備する取り組みです。民間は経営判断で発注先を即決し、必要なら予算を追加できます。一方、官公庁は税を原資とした予算に従い、発注にも原則として公正な手続きが必要です。
▼全体ガイドの記事
・官公庁のシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
官公庁システム開発の期間全体像と入札〜契約までのリードタイム
官公庁では、開発期間と着手前の期間を分けて考える必要があります。
民間では発注を決めてから数週間で開発が始まることもあります。
一方、官公庁では予算要求から契約までの手続きを経るため、着手前だけで数ヶ月から一年近くかかる場合があります。
稼働時期から逆算するときは、開発期間に調達のリードタイムも含めて考えます。
調達のリードタイムは、予算要求から、調達仕様書の作成、入札公告、提案審査を経て契約に至るまでの期間です。
開発方式別（ガバメントクラウド上のSaaS／パッケージ＋カスタマイズ／フルスクラッチ）の期間目安
官公庁の開発期間は方式で大きく変わります。契約後の期間は、標準仕様に沿う範囲と固有の要件の多さで決まるため、方式ごとの目安を下に並べます。
- SaaS・クラウド：ガバメントクラウドの標準準拠サービスを設定中心で使う場合、設計・構築・移行を含めて6ヶ月から1年程度。
- パッケージ＋カスタマイズ：固有帳票や運用ルールの調整を含めて、1年から1年半程度。
- フルスクラッチ：既製品で対応できない業務の場合、1年半から3年程度かかることがあります。
フルスクラッチの期間には、要件定義からテスト・移行までが含まれます。
政令指定都市の税や国民健康保険では、業務規模と固有要件の多さから、期間が長くなる傾向があります。
ここまでの期間は、契約後に着手してからの目安です。
業務の重要度が高いほど、受入テストや操作研修、並行稼働にも長い期間が必要になります。
住民生活に直結する基幹業務では、新旧のシステムを一定期間動かし、算定結果や帳票を突き合わせる並行稼働を行います。並行稼働は一般に数ヶ月を確保しますが、短縮すると重大な不具合につながりかねないため、期間を縮めにくい工程です。
入札・契約プロセスが着手前に要する期間
契約方式によって、着手前に要する期間は変わります。技術力を評価する案件では、次の2つの方式が使われます。
- 総合評価落札方式：価格と技術提案を点数にして、合計で評価する形式。
- 公募型プロポーザル方式：提案内容そのものを審査する形式。
調達は、まず調達仕様書を作成して公告します。
質問への回答や提案書の作成を経て、審査と落札者の決定を行い、最後に契約を結びます。
公告から契約締結までは一般に2ヶ月から4ヶ月程度です。
とくにプロポーザルでは、提案書を作る期間も確保しておく必要があります。
調達手続きの前には予算化が必要で、予算を確保してから公示までに、数ヶ月から1年程度のタイムラグが生じる場合もあります。
予算要求は前年度に行い、議会承認を経て新年度に執行します。
必要性を認識してから契約までは、予算サイクルと調達を合わせて半年から一年以上かかるケースが多くあります。
案件の把握から受注までが長いため、発注側とベンダー側は早い段階で情報と概算日程を共有し、後工程の遅延を防ぎます。
予算制度・標準化対応がスケジュールに与える影響
官公庁の開発日程が民間と異なるのは、予算制度と、標準化・共同化という国の方針があるためです。
会計年度独立の原則と予算単年度主義のもとでは、複数年度にまたがる開発に特別な制度が必要になります。
住民記録や税などの基幹業務では、国の標準仕様とガバメントクラウドへの移行が全国で進んでおり、その期限が日程の前提になります。
債務負担行為による複数年度契約と、標準化・クラウド移行の影響を、順に見ていきます。
単年度予算主義と債務負担行為による複数年度契約の設計
予算単年度主義は、各年度の予算をその年度の議会議決に基づいて執行する原則です。会計年度独立の原則とあわせて、年度の歳出を同じ年度の歳入で賄うという考え方を支えています。
複数年度契約では、議決の仕組みに加えて、年度ごとの支出と工程の区切りを合わせて見る必要があります。押さえる点は4つです。
- 契約期間：開発は1年を超えることが多く、単年度予算では契約を完結できない場合があります。
- 債務負担行為：議会の議決で後年度の債務を負担し、通常はおおむね5年以内の契約を可能にします。
- 年度ごとの支出：制度を設けても、実際の支出には各年度の歳出予算が必要です。
- 工程の区切り：開発工程に加えて予算と議決から逆算し、年度末検収と翌年度の執行開始に合わせます。
国では国庫債務負担行為、地方公共団体では債務負担行為と呼びます。議決が間に合わなければ、長期の契約は結べません。こうした制度を踏まえ、工程と予算年度をそろえることで、資金面の手戻りを防げます。
地方公共団体情報システム標準化・ガバメントクラウド移行のスケジュールへの影響
標準化は、住民記録・税・福祉など20業務を対象に、国の標準仕様へ統一し、ガバメントクラウド上で共通に使える形にそろえる取り組みです。
共通の期限が全国の自治体にとっての上限となるため、自団体の都合だけでは日程を決められません。この期限は現場にも大きく影響します。
- 標準移行の目標：原則として令和7年度（2025年度）までに移行します。支援期間は2023年4月から2026年3月です。
- 例外的な移行：特定移行支援システムは令和8年度以降も認められ、令和10年度末までに適合します。
- 作業状況：2025年8月時点で約3割の自治体が作業中か未着手で、期限の達成は困難との見方もあります。
- 体制確保：全国一斉の移行で開発会社を確保しにくく、確保できない団体では遅延リスクが高まります。
- 制度改正への対応：こども・子育てやマイナンバー関連など優先度の高い改正も並行するため、早めの調整と余裕が必要です。
要件定義〜リリースまでの工程別スケジュールとセキュリティ審査
契約後は要件定義から設計、開発へと進み、テストと移行を経て稼働に至ります。また、官公庁ではこれらの工程にセキュリティ審査が加わります。
政府機関等のサイバーセキュリティ対策の統一基準群に基づく管理と、ISMAPによるクラウド評価には、いずれも時間がかかります。そのため、工程ごとの期間配分と審査の影響を確認し、開発と並行して早めに準備を進めます。
工程別の期間配分（要件定義・設計・開発・テスト）
1年から1年半程度のパッケージ＋カスタマイズ案件では、工程配分の目安を次のように考えます。
- 要件定義：全体の2割から3割で、3ヶ月から5ヶ月程度。
- 設計・開発：合わせて全体の4割程度。
- テスト・移行準備：全体の3割前後。
官公庁では、民間より要件定義が長引きやすく、合意形成にも時間がかかります。制度上の正確性や条例・規則との整合が求められ、複数部署の稟議・決裁も必要になるため、要件が確定するまでに往復が増えます。
発注側と開発会社は、要件定義に厚めに期間を確保して、後工程を安定させます。
算定に誤りがあると住民に不利益を与えるため、単体・結合テストに加えて、実業務データを使った総合テストを行います。
旧システムとの並行稼働や結果の突き合わせにも、時間を確保しておく必要があります。検証を縮めると、重大な障害のリスクが高まります。
日程を短縮したい場合は、テストを削るのではなく、要件定義や設計を前倒しできるよう調達日程を工夫します。
配分は、規模や重要度によって変わります。合意形成に時間がかかる前半と、品質検証を妥協できない後半の両方を踏まえて計画します。
統一基準群・ISMAP評価に基づくセキュリティ審査プロセス
ISMAPは、政府のセキュリティ要件を満たすクラウドサービスを評価して登録し、政府機関等が調達する際の水準を確保する制度です。
クラウドの選定と各システムの審査準備は、納期に影響します。そのため、登録状況と評価に必要な期間を確認しておきます。
- サービス選定：政府情報システムでは、原則としてISMAP登録済みのサービスから選びます。
- 管理基準：統一基準群を参照し、ガバナンス、マネジメント、管理策の三層からなる構成です。
- 外部評価：対象の管理策は1,000項目を超え、監査評価には数ヶ月単位の期間を見込みます。
- 報告書と登録：監査機関は、事業者が定める評価期間の末日から3ヶ月以内に報告書を作成し、登録までには一定期間を要します。
- システムごとの対応：設計、リスク評価、点検は後半にまとめず、セキュリティ担当と早い段階から並行して進めます。
登録済みのサービスを前提にすれば、審査待ちの影響を抑えられます。一方で、独自の要件から未登録のサービスを評価する場合は、その期間を大きく見込む必要があります。
納期遅延の典型要因と対策
遅延は、技術的な難しさよりも、合意形成、他システムとの連携、データ移行など、行政特有の事情から生じることが多くあります。
仕様凍結後の追加要望、住基・税・マイナンバーとの調整、レガシーシステムからの移行は、代表的な引き金です。
それぞれの要因の背景と日程上の備えを確認し、リスクを工程に織り込むことが、稼働を守る現実的な対策です。
仕様凍結後の追加要望・他システム連携（住基・税・マイナンバー）
仕様変更や外部システムとの連携では、関係者や連携先との調整が遅延につながります。
- 追加要望：複数の部署や担当者が使うため、仕様を固めた後に帳票や別課の運用について要望が出ることがあります。
- 変更管理：関係部署を漏れなく招いたうえで、意思決定者の正式な承認をもって凍結します。以降の変更は、ルールに沿って影響と日程を評価します。
- 制度改正：改正が控える場合は、制度の反映時期と本番稼働時期の関係を早めに整理します。
- 連携先の調整：住民基本台帳や税などの業務に加え、マイナンバー（社会保障・税番号）制度の中間サーバーとも連携するため、関係先との調整に時間がかかります。
- 連携計画：連携先と方式を早期に定め、データ項目とテスト時期も含めて独立したタスクにします。
国や他団体の共通システムは、自団体の都合だけで日程を動かせず、テスト時期も制約されます。後半に調整を集めると依存関係が表面化し、納期を圧迫します。
連携先の仕様確認やインターフェースの調整、連携テストにも、想定以上の時間がかかることがあります。
レガシーデータ移行・段階移行の設計不足
長年カスタマイズしてきたシステムには、住民データや過年度の履歴が蓄積されています。そのため、移行では多くの論点が生じます。
- 項目対応：新旧のデータ項目を対応づける作業が必要です。
- 文字の扱い：文字コードや外字を確認します。
- 履歴継承：過去のデータを正確に引き継ぎます。
業務データ項目の標準が十分でない領域もあり、データ要件や連携要件を標準化すること自体が課題になります。設計を軽く見積もると、テストで不整合が見つかり、原因の調査やデータのクレンジングに時間を取られて、稼働が遅れます。
移行は独立した工程として早めに着手します。本番前には実データで段階的にテストし、そのつど不整合を洗い出して修正します。このサイクルを複数回繰り返すことで、本番移行時のリスクを大きく下げられます。
一斉移行が難しい場合は、業務や範囲を区切って段階的に移行する方法も選べます。その間、新旧のシステムが併存します。
併存している間は、データの整合性と二重運用の負荷を設計しておく必要があります。設計が不足すると業務が混乱し、全体の期間が延びかねません。
移行方式とリハーサル計画を、要件定義と同じ重みで日程に組み込めるかどうかが、納期を守れるかの分かれ目です。
予定通り稼働させるためのスケジュール設計と発注側・ベンダー側の実務
ここまでの制約を踏まえると、予定どおりに稼働させるには、予算の確保から移行までを一つの日程にまとめる必要があります。
稼働日から逆算して、必要な調達日程と予算措置を先に固めます。そのうえで、発注側とベンダー側が互いの役割を理解し、早い段階から連携します。
稼働時期から逆算する全体スケジュールの組み方
制度改正の施行日、年度替わり、標準化の期限など、動かせない稼働日から必要な工程を逆算します。
- 稼働前の完了条件：年度初めの稼働なら、前年度末までに並行稼働と受入テストを終え、開発と審査は前年度秋までに完了させます。
- 着手と調達：要件定義は前年度の前半に始め、契約は前々年度中に結びます。調達と債務負担行為の議決も、数ヶ月前に終えます。
- 準備開始：稼働の1年半から2年前に準備が必要なケースが多く、直前の着手では間に合いにくいのが実情です。
- 余裕と固定日：合意、審査待ち、連携調整の期間に幅を持たせ、民間の感覚で詰めすぎないようにします。年度末検収や議会日程は、先に押さえておきます。
- 日程共有：全体日程を一枚にまとめて関係者と共有し、後工程の認識違いを防ぎます。
発注側・ベンダー側それぞれの準備と連携のポイント
予定どおりの稼働に向け、発注側とベンダー側はそれぞれの準備を契約前から進めます。
- 仕様の明確化：発注側は要件・日程・前提条件を調達仕様書に示し、契約後の認識違いや変更を防ぎます。
- 庁内体制：発注側は関係部署の役割、意思決定窓口、稟議・決裁の流れを定め、庁内調整も工程に含めます。
- 現実的な提案：ベンダー側は、予算と議会の日程、審査期間、連携先の都合を織り込んだ、余裕ある工程とリスク対応を示します。
- 体制と前提の共有：標準化で人員が逼迫する局面では、早期に体制を確保し、契約前から概算日程・前提・リスク認識を共有します。
双方が契約前から前提をそろえることで、手戻りを抑えられます。
riplaは、官公庁特有の制約を踏まえたシステム開発の計画づくりから支援しています。
まとめ
官公庁システムの開発期間は、方式によって6ヶ月から3年程度です。これに、公告から契約までの2ヶ月から4ヶ月と、予算化の期間が加わります。
稼働の1年半から2年前には準備を始め、債務負担行為や標準化期限、セキュリティ審査を、移行と合わせて日程に織り込みます。
追加要望、連携調整、データ移行をリスクとして扱い、関係部署との合意形成や移行リハーサルを計画に組み込みます。
発注側は要件と前提を明確にし、ベンダー側は外部制約を含む現実的な提案を行います。契約前から日程を共有し、稼働期日に備えます。
▼全体ガイドの記事
・官公庁のシステム開発の完全ガイド
▼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を創業。