官公庁のシステム開発の開発期間・スケジュール・納期について

官公庁のシステム開発は、中央省庁・地方自治体・独立行政法人などが住民サービスや行政事務を支える情報システムを整備する取り組みですが、その進め方は民間企業のシステム開発とは前提が大きく異なります。最も大きな違いは、税金を原資とすることに由来する「予算制度」「調達（入札）制度」「情報セキュリティ基準」という三つの制約です。民間であれば経営判断で発注先を即決し、必要に応じて予算を追加投入できますが、官公庁では会計年度独立の原則や予算単年度主義のもとで予算が編成され、原則として一般競争入札や公募型プロポーザルといった公正な手続きを経なければ発注できません。さらに、政府機関等のサイバーセキュリティ対策のための統一基準群やISMAP（政府情報システムのためのセキュリティ評価制度）に基づく審査が求められるため、同じ規模のシステムであっても、民間より着手前後に多くの時間を要します。「入札から稼働まで結局どのくらいかかるのか」「標準化対応でスケジュールはどう変わるのか」という疑問を持つのは当然のことです。

本記事では、官公庁のシステム開発の開発期間・スケジュール・納期に焦点を当て、開発方式別の期間目安、入札から契約までに要するリードタイム、単年度予算主義と債務負担行為による複数年度契約の設計、地方公共団体情報システムの標準化・ガバメントクラウド移行がスケジュールに与える影響、工程別の期間配分とセキュリティ審査のプロセス、そして納期遅延の典型要因とその対策までを、具体的な数値とともに体系的に解説します。システム調達や情報システム部門を担当する職員の方はもちろん、官公庁向けシステムを受注しようとするベンダー担当者の方にとっても、着手前から稼働までの全体像を把握し、現実的なスケジュールを描くための判断軸が身に付く内容です。

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

▼全体ガイドの記事
・官公庁のシステム開発の完全ガイド

官公庁システム開発の期間全体像と入札〜契約までのリードタイム

官公庁のシステム開発を考えるうえでまず理解しておきたいのは、「開発そのものにかかる期間」と「開発に着手できるようになるまでの期間」を分けて捉える必要があるという点です。民間では発注を決めてから数週間で開発が始まることも珍しくありませんが、官公庁では予算要求・調達仕様書の作成・入札公告・提案審査・契約締結という一連の手続きを経る必要があり、この着手前の期間だけで数ヶ月から一年近くを要することがあります。したがって、システムを稼働させたい時期から逆算してスケジュールを組む際は、開発期間そのものに加えて、この調達リードタイムを必ず織り込む必要があります。以下では、開発方式ごとの期間目安と、着手前に要する調達プロセスの期間を具体的に見ていきます。

官公庁のシステム開発は、採用する方式によって開発期間が大きく変わります。最も短期で導入できるのは、ガバメントクラウド上で提供される標準準拠のSaaSやクラウドサービスを設定中心で利用する方式で、既存の標準仕様に沿った業務であれば、設計・構築・移行を含めておおむね6ヶ月から1年程度が目安となります。次に、行政向けパッケージ製品をベースに自団体固有の帳票や運用ルールへカスタマイズを加える方式では、要件のすり合わせとカスタマイズ開発が加わるため、1年から1年半程度を見込むのが現実的です。そして、固有要件が極めて多く既製品では対応できない業務をフルスクラッチで構築する場合は、要件定義からテスト・移行までを通して1年半から3年程度を要することもあります。とくに政令指定都市のように業務規模が大きく固有要件が多い団体では、税や国民健康保険といった業務でこの傾向が顕著になります。

また、これらの期間はあくまで契約締結後に開発に着手してからの目安であり、システムの重要度が高いほど、稼働前の受入テストや並行稼働、職員向けの操作研修に要する期間も長くなります。住民の生活に直結する基幹業務システムでは、本番稼働前に旧システムと新システムを一定期間並行して動かし、算定結果や帳票の突合を行う「並行稼働」を数ヶ月確保することが一般的です。この検証期間を短縮しようとすると稼働後の重大な不具合につながりかねないため、期間圧縮の対象にはしにくい工程であることを理解しておく必要があります。

官公庁の調達では、契約方式によって着手前のリードタイムが変わります。価格のみで落札者を決める一般競争入札に対し、システム開発のように技術力が問われる案件では、価格と技術提案を点数化して評価する総合評価落札方式や、提案内容そのものを審査する公募型プロポーザル方式が多く採用されます。これらの方式では、調達仕様書の作成、入札公告、質問回答期間、提案書の作成期間、審査委員会による評価、落札者決定、契約締結という手順を踏むため、公告から契約締結までだけでも2ヶ月から4ヶ月程度を要するのが一般的です。とくにプロポーザル方式では、事業者が提案書を作成するための十分な期間を確保する必要があり、公示から契約までのスケジュールは余裕を持って設計しなければなりません。

さらに注意したいのは、この調達手続きの前段に「予算化」というプロセスがあることです。プロポーザル案件は、予算が確保されてから実際に公示されるまで数ヶ月から1年程度のタイムラグが生じることも珍しくありません。予算要求は前年度に行われ、議会の承認を経て新年度に執行されるという流れになるため、発注側が「システムが必要だ」と考えてから実際に契約を結ぶまでには、予算サイクルと調達手続きを合わせて半年から一年以上かかるケースが多く見られます。ベンダー側から見れば、案件情報を把握してから受注するまでのリードタイムが長いということでもあり、双方にとって早い段階からの情報共有と概算スケジュールの共有が、後工程の遅延を防ぐ鍵になります。

予算制度・標準化対応がスケジュールに与える影響

官公庁のシステム開発スケジュールを民間と大きく分けているのが、予算制度と、近年進行している標準化・共同化という国策の存在です。予算は会計年度独立の原則と予算単年度主義のもとで編成されるため、複数年度にまたがる開発を進めるには特別な制度的仕組みが必要になります。また、住民記録や税をはじめとする基幹業務については、国が定める標準仕様への準拠とガバメントクラウドへの移行が全国一斉に進められており、この移行期限がスケジュールの前提条件そのものになっています。以下では、複数年度契約を可能にする債務負担行為と、標準化・ガバメントクラウド移行がスケジュールに与える影響を整理します。

予算単年度主義とは、各会計年度の予算はその年度の議会の議決に基づいて執行するという原則で、会計年度独立の原則とあわせて、その年度の歳出はその年度の歳入でまかなうという考え方を支えています。しかし、システム開発は要件定義から稼働まで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の管理基準は、政府機関等のサイバーセキュリティ対策のための統一基準群を参照して作られており、ガバナンス基準・マネジメント基準・管理策基準という三層で構成されています。

審査そのものも相応の時間を要します。ISMAPの外部評価では、対象となる管理策が1,000項目を超えるため、監査機関による評価には数ヶ月単位の期間が見込まれます。監査機関が作成する実施報告書は、クラウドサービス事業者が定める評価期間の末日から3ヶ月以内に作成することとされており、事業者側から見ればサービス登録までに一定のリードタイムがかかります。発注側の視点では、すでにISMAP登録済みのサービスを前提に設計すれば審査待ちの影響を最小化できますが、独自要件が強く未登録のサービスを新たに評価する必要がある場合は、この評価期間をスケジュールに大きく織り込まなければなりません。加えて、システムごとに統一基準群に沿ったセキュリティ設計・リスク評価・点検を行う必要があり、これらの工程を開発の後半に固めてしまうと稼働時期が押されるため、早い段階からセキュリティ担当と連携して並行して進めることが重要です。

納期遅延の典型要因と対策

官公庁のシステム開発における納期遅延は、技術的な難しさよりも、合意形成・他システム連携・データ移行といった行政特有の事情に起因することが多く見られます。とくに、仕様を固めたはずの段階での追加要望や、住基・税・マイナンバーといった他システムとの連携調整、そして長年運用してきたレガシーシステムからのデータ移行は、遅延の代表的な引き金です。ここでは、これらの典型要因がなぜ発生するのかと、スケジュール面でどう備えるべきかを解説します。あらかじめリスクとして工程に織り込んでおくことが、稼働時期を守るための最も現実的な対策になります。

官公庁のシステム開発で頻発するのが、仕様を凍結したはずの後になって追加要望が出てくる事態です。行政では複数の部署や担当者が利用者となるため、要件定義の場に全ての関係者が揃わないまま仕様を固めてしまうと、開発が進んでから「この帳票が必要だった」「別の課の運用も考慮してほしい」といった要望が後出しで発生します。これを防ぐには、要件定義の段階で関係部署を漏れなく巻き込み、意思決定者による正式な承認をもって仕様を凍結し、以降の変更は変更管理のルールに沿って影響とスケジュールを評価したうえで扱うという運用を徹底することが有効です。制度改正が控えている場合は、その反映時期と本番稼働時期の関係を早期に整理しておくことも欠かせません。

他システムとの連携も、遅延を招きやすい要因です。行政システムは、住民基本台帳、税、国民健康保険、マイナンバー（社会保障・税番号）制度に関わる中間サーバーなど、多数のシステムと連携して動作するため、連携先の仕様確認やインターフェース調整、連携テストに想定以上の時間がかかります。連携先が国や他団体の共通システムである場合、こちらの都合だけではスケジュールを動かせず、連携テストの実施時期が制約になることもあります。対策としては、連携が必要なシステムを要件定義の早い段階で棚卸しし、それぞれの連携方式・データ項目・テスト時期を明確化して、連携調整を独立したタスクとして計画に組み込むことが重要です。連携をプロジェクトの後半にまとめて着手すると、依存関係が一気に顕在化して納期を圧迫する結果になりがちです。

もう一つの大きな遅延要因が、データ移行の難しさです。官公庁では、長年にわたり独自にカスタマイズしてきたシステムに、膨大かつ複雑な住民データや過年度の履歴データが蓄積されています。これを新システムへ移行する際には、データ項目の対応づけ（マッピング）、文字コードや外字の扱い、過去データの正確な引き継ぎといった論点が数多く発生します。現状では、業務システムで利用するデータ項目を規定する統一的な標準が十分に整っていない領域もあり、データ要件・連携要件の標準化そのものが課題として残っています。移行の設計を軽く見積もると、テスト段階でデータ不整合が大量に見つかり、原因調査とデータクレンジングに追われて稼働が遅れる、という展開に陥りがちです。

対策の基本は、データ移行を独立した工程として早期に着手し、移行リハーサルを複数回繰り返すことです。実データを用いた移行テストを本番前に段階的に行い、そのたびに不整合を洗い出して修正するサイクルを回すことで、本番移行時のリスクを大きく下げられます。また、一度に全業務を切り替える一斉移行が難しい場合は、業務や対象範囲を区切って段階的に移行する方式も選択肢になりますが、この場合は移行期間中に新旧システムが併存することになるため、その間のデータ整合性の確保や二重運用の負荷をあらかじめ設計しておく必要があります。段階移行の設計が不十分なまま進めると、移行途中で業務が混乱し、かえって全体の期間が延びることになりかねません。移行方式の選択とリハーサル計画を、要件定義と同じ重みでスケジュールに組み込むことが、納期遵守の分かれ目になります。

予定通り稼働させるためのスケジュール設計と発注側・ベンダー側の実務

ここまで見てきた制約を踏まえると、官公庁のシステム開発を予定通り稼働させるためには、開発工程だけを見るのではなく、予算・調達・審査・移行を含めた全体を一つのスケジュールとして設計することが不可欠です。稼働させたい時期から逆算し、そこにたどり着くために必要な調達スケジュールと予算措置のタイミングを先に固めるという「後ろから前へ」の発想が求められます。発注側とベンダー側がそれぞれ果たすべき役割を理解し、早期から連携することが、無理のない現実的な計画につながります。

官公庁のシステム開発では、稼働時期が制度改正の施行日や年度替わり、標準化の移行期限といった動かせない期日に紐づくことが多いため、その日から逆算してスケジュールを引くことが基本になります。たとえば、ある年度の4月から新システムを稼働させたい場合、前年度末までに並行稼働と受入テストを終える必要があり、そのためには開発とセキュリティ審査を前年度の秋までに完了させ、要件定義を前年度の前半から始めなければなりません。さらに、その開発に着手するための契約は前々年度中に締結し、そのための調達手続きと予算の債務負担行為の議決を、それぞれ数ヶ月前に完了させておく必要があります。このように逆算すると、稼働の1年半から2年前には準備を始めなければならないケースが多く、「思い立ってから間に合わせる」ことが難しいのが官公庁システムの実情です。

逆算スケジュールを組む際は、各工程に「行政特有のバッファ」を持たせておくことも大切です。合意形成の往復、審査の待ち時間、連携先の都合による調整など、自らのコントロールが及ばない要素が多いため、民間の感覚で工程を詰めすぎると、想定外の待ち時間で全体が押し出されてしまいます。とくに、年度末の検収集中や、議会の開催時期といった時間的制約は動かしにくいため、これらの固定点を先に押さえ、その間を工程で埋めていく発想が有効です。全体像を一枚のスケジュールに落とし込み、関係者間で共有しておくことが、後工程での認識のずれを防ぎます。

発注側である官公庁の職員にとって重要なのは、調達仕様書の段階で要件をできる限り明確にし、想定するスケジュールと前提条件を仕様書に盛り込んでおくことです。要件が曖昧なまま調達すると、契約後の要件定義で認識のずれが表面化し、追加要望や仕様変更が多発してスケジュールが崩れます。あわせて、関係部署の役割分担と意思決定の窓口を早期に定め、稟議・決裁の流れを事前に整理しておくことで、合意形成に伴う待ち時間を短縮できます。庁内での調整に要する時間を軽視せず、プロジェクトの一工程として計画に位置づけることが、発注側に求められる準備です。

ベンダー側にとっては、官公庁特有の制約を理解したうえで、現実的なスケジュールを提案できるかどうかが信頼につながります。予算サイクルや議会日程、セキュリティ審査の所要期間、連携先の都合といった外部要因を織り込み、余裕を持った工程とリスク対応の考え方を提案の段階から示すことが大切です。また、標準化対応のようにベンダーのリソースが全国的に逼迫している局面では、早期の情報共有と体制確保が納期遵守を左右します。発注側とベンダー側が、契約前の段階から概算スケジュールと前提を共有し、双方のリスク認識をすり合わせておくことが、結果として手戻りの少ない、予定通りの稼働を実現する近道になります。riplaでは、こうした官公庁特有の制約を踏まえたシステム開発の計画づくりから伴走した支援を行っています。

まとめ

官公庁のシステム開発は、予算制度・調達制度・セキュリティ基準という民間にはない制約のもとで進むため、開発期間そのものだけでなく、着手前の調達リードタイムや審査・移行を含めた全体で納期を捉える必要があります。開発方式によって6ヶ月から3年程度と幅があり、そこに公告から契約までの2ヶ月から4ヶ月、さらに予算化までのタイムラグが加わるため、稼働時期から1年半から2年前には準備を始める逆算の発想が欠かせません。単年度予算主義のもとで複数年度契約を可能にする債務負担行為の議決、標準化・ガバメントクラウド移行の期限、統一基準群やISMAPに基づくセキュリティ審査といった要素を、それぞれ独立したタスクとして早期にスケジュールへ織り込むことが、計画倒れを防ぐ鍵になります。

納期遅延は、仕様凍結後の追加要望、住基・税・マイナンバーなど他システムとの連携調整、そしてレガシーデータの移行という行政特有の要因から生じやすいため、これらをリスクとして工程に組み込み、関係部署を巻き込んだ合意形成と、移行リハーサルの反復を計画的に進めることが重要です。発注側は要件と前提を明確にした調達を、ベンダー側は外部制約を織り込んだ現実的な提案を心がけ、契約前から双方でスケジュールと前提を共有しておくことで、動かせない稼働期日を守る確度を高められます。本記事が、官公庁のシステム開発における現実的なスケジュール設計の一助となれば幸いです。

▼全体ガイドの記事
・官公庁のシステム開発の完全ガイド

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