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

公共システムとは、鉄道・バスといった公共交通機関の運行管理やIC乗車券、上下水道・電気・ガスなどのライフラインにおける検針・料金計算・設備保全、図書館や体育館・公民館・スポーツ施設の予約管理、公共工事の入札・積算・管理、さらには独立行政法人・公社・第三セクターが運営するサービスまで、公益性の高い領域を広く支える情報システムの総称です。役所内部の行政事務を対象とする官公庁システムとは異なり、公共システムは「住民・利用者が日常的に使うサービス」や「止まると社会生活に直接影響が出るインフラ」を対象とする点に大きな特徴があります。そのため開発期間の考え方も、単に機能の多寡だけでなく、24時間365日の稼働が求められる可用性要件、現場の設備・機器（OT）との連携、住民サービスを止められない移行時期の制約など、民間の一般的なシステム開発とは異なる前提が数多く絡んできます。「結局のところ稼働までにどれくらいかかるのか」「なぜ公共システムは納期が長くなりがちなのか」という疑問を持つのは当然のことです。

本記事では、公共インフラ・公共サービスを支えるシステム開発の開発期間・スケジュール・納期に焦点を当て、分野別・開発方式別の期間目安、高可用性・ミッションクリティカル要件がスケジュールに与える影響、制御系（OT）や現地機器との連携が生む物理的なリードタイム、工程別の期間配分、そして納期を縛る外部要因（繁忙期・災害期・法改正の施行日）と遅延の典型要因までを、公共分野の具体的な事例とともに体系的に解説します。公共施設や交通・ライフラインのシステムを所管する自治体・事業者の担当者はもちろん、公共分野へシステムを提供しようとするベンダー担当者にとっても、着手前から稼働までの全体像を把握し、現実的なスケジュールを描くための判断軸が身に付く内容です。

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

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

公共システム開発の期間全体像と「公共サービスならでは」の前提

公共システムの開発期間を考えるうえでまず理解しておきたいのは、「開発そのものにかかる期間」と「開発に着手できるようになるまでの期間」を分けて捉える必要があるという点です。公共交通の運行管理や上下水道の料金計算、公共施設の予約システムなどは、いずれも税や公共料金を原資とする公金で整備されるため、原則として仕様書の作成・公告・提案審査・契約締結という調達プロセスを経なければ開発に着手できません。この着手前の期間だけで数ヶ月から一年近くを要することがあり、稼働させたい時期から逆算する際には、開発工数そのものに加えてこの調達リードタイムを必ず織り込む必要があります。さらに公共システムには「サービスを止められない」「現場の設備と物理的につながる」「多様な利用者が使う」という三つの特性があり、これらがテスト期間や移行の段取りを民間システムより長くする要因になります。

公共システムが対象とする領域は幅広く、それぞれ開発期間の性格が異なります。公共交通機関の運行管理システムやIC乗車券・料金精算システムは、ダイヤや運賃改定に連動する複雑なロジックとリアルタイム性が求められ、開発規模が大きくなりがちです。上下水道・電気・ガスといったライフライン事業者の検針・料金計算・設備保全システムは、料金体系の独自性に加えて、現場のメーターやプラント設備との連携が必要になります。図書館・体育館・公民館・スポーツ施設などの公共施設予約システムは、比較的コンパクトな一方で、キャッシュレス決済やスマートロックといった外部サービス・物理機器との連携が期間を左右します。公共工事の入札・積算・管理システムや、独立行政法人・公社・第三セクターの業務システムも、それぞれ固有の制度・帳票に対応する必要があります。開発期間を見積もる際は、これらの領域ごとに「どこにリアルタイム性が要るのか」「どの現場設備とつながるのか」「利用者は誰か」を切り分けて考えることが出発点になります。

公共システムの全体スケジュールは、大きく「調達準備」「調達手続き」「開発（要件定義〜リリース）」「移行・稼働」の四つの局面に分けられます。民間であれば発注を決めてから数週間で開発が始まることも珍しくありませんが、公共分野では調達準備の段階でベンダーへの情報提供依頼（RFI）や市場調査を行い、仕様書を固めてから公告に進みます。ある政令市の進捗管理事例では、調達仕様書を精緻化するためにRFIを二度実施し、前年度末までに調達準備を完了させて新年度当初に調達を始められる状態にする、という数ヶ月がかりの事前準備が行われていました。観光案内向けのAIチャットボットを公募型プロポーザルで調達したある市の事例でも、仕様書公開から受託候補者の選定・契約締結を経て実際の本格運用が始まるのは翌年度、というスケジュールになっています。したがって「システムをいつ動かしたいか」から逆算し、そこに開発期間と調達リードタイムの双方を積み上げて全体像を描くことが、現実的な納期設定の第一歩となります。

分野別・開発方式別の開発期間の目安

開発期間は、対象システムの規模と開発方式（SaaS・パッケージ活用か、フルスクラッチか）によって大きく変わります。ここでは公共分野の実例を交えて、代表的な規模帯ごとの期間感を整理します。いずれの場合も、前段で述べた調達リードタイムを別途見込む必要がある点に注意してください。

図書館や体育館・公民館の予約システム、住民向けのオンライン申請・案内サービスなど、比較的スコープが限定された公共サービス系のシステムは、契約締結後おおむね半年から一年程度が一つの目安となります。ある自治体が計画したスマートロックとキャッシュレス決済を連動させる公共施設予約システムの導入委託業務では、仕様書が示された時点から本稼働までにおよそ10ヶ月の履行期間が設定されていました。この10ヶ月には、要件定義・初期セットアップ・各施設への機器設置・職員による動作確認・住民向けの操作マニュアル整備までが含まれます。パッケージやSaaSをベースにする場合はこれより短縮できる余地がありますが、公共システムでは決済事業者や物理機器メーカーなど複数の外部関係者との調整が必ず発生するため、純粋なソフトウェア開発だけを見た期間感よりも余裕を持たせておくことが賢明です。とりわけ利用者向けのUI/UXは公開後の評判に直結するため、テストとマニュアル整備の工程を削らないことが重要です。

上下水道の料金・検針システムや設備保全システム、公共交通の運行管理・料金精算システムといったライフライン・インフラの基幹システムになると、期間は一年半から数年規模へと大きく伸びます。これらは扱うデータ量が膨大で、料金体系や運行ダイヤに関する独自ロジックが複雑なうえ、現場のメーター・センサー・プラント設備や券売機・改札機といったハードウェアとの連携が不可欠だからです。都市全体の交通・環境データを連携させる基盤づくりのように、複数の事業者・部局をまたぐ大規模なプロジェクトでは、実証実験のフェーズを含めて数年がかりになるケースもあります。こうした大規模系では、一度にすべてを切り替える「ビッグバン移行」はリスクが高いため、地域や機能を区切って段階的に移行する方式が採られることが多く、その段階分けの設計自体が全体スケジュールを大きく左右します。規模が大きいほど、要件定義の精度が期間のブレを決定づけるため、初期の要件固めに十分な時間を割く判断が結果的に納期短縮につながります。

高可用性・ミッションクリティカル要件がスケジュールに与える影響

公共システムを民間システムと最も強く分けるのが、「止まってはいけない」という高可用性・ミッションクリティカルの要件です。この要件は非機能要件のハードルを引き上げ、それがそのままテストや設計の工程を長期化させる形でスケジュールに跳ね返ります。開発期間を検討する際は、機能開発だけでなく、可用性を担保するための冗長化設計・障害対応訓練・長期の検証工程を織り込んでおく必要があります。

公共サービスは利用者がいつ使うか分からないため、多くの調達仕様書で「計画された保守停止時間を除き24時間365日利用できること」「業務停止を伴う障害が発生した場合は1営業日以内での復旧を目標とすること」といった高い可用性が要求されます。この要件を満たすには、単に機能が動くことを確認する結合テストだけでなく、障害を意図的に起こして復旧手順を確かめる運用テストや、長時間の連続稼働に耐えるかを見る耐久試験まで実施しなければなりません。ある自治体の基幹システム移行事例では、当初3ヶ月を予定していたテスト期間について、通常業務と並行して膨大な確認作業を行う必要から時間が足りず、後続業務では「余裕をもって約6ヶ月の期間を確保したい」と見直されています。全体の開発期間に対してテストが約半分を占めることも珍しくないのが公共システムの特徴であり、スケジュールを引く際には開発工程と同等かそれ以上の時間をテスト・検証に割り当てておく必要があります。

公共システムのもう一つの特徴は、画面上のソフトウェアだけで完結せず、現場の物理設備や機器（OT）とつながる場合が多い点です。上下水道のメーターやプラントの制御装置、公共交通の券売機・改札機、公共施設のスマートロックや電子錠などがその代表例で、これらとの連携にはソフトウェア開発とは別の「物理的なリードタイム」が発生します。実際、スマートロックを導入するある公共施設予約システムの仕様書では、電子機器による施錠管理であることから設置位置について十分に事前確認を行って算定すること、機器本体に防雨・日除け対策を施したうえで安定稼働を検討することが求められていました。対象施設が20か所を超えるようなケースでは、各施設に足を運んで電波状況・電源・雨風の影響を調べる現地調査が必要になり、クラウド単体で完結するシステムよりも導入期間が長くなります。制御系との連携がある場合は、機器の調達・設置・現地試験の期間を早い段階でスケジュールに組み込み、ソフトウェアの完成を待ってから設置に取りかかるのではなく、並行して進める段取りを設計することが遅延防止の鍵になります。

工程別スケジュールと納期を縛る外部要因

公共システムの納期は、開発ベンダーの都合ではなく、住民・利用者の生活や制度の都合から逆算して決まる「動かせないゴール」であることが少なくありません。ここでは工程ごとの期間配分の考え方と、納期を縛る代表的な外部要因を整理します。

公共システムの開発工程は、要件定義・設計・開発（実装）・テスト・移行/リリースという流れで進むのが基本ですが、その期間配分は民間システムと重心が異なります。民間では開発工程に最も多くの時間を割くケースが多いのに対し、公共システムでは前工程の要件定義と後工程のテストが長くなる傾向があります。要件定義が長引くのは、料金体系や条例に基づく独自ルール、関係部署や関係事業者の要望を丁寧にすり合わせる必要があるためで、この段階での認識齟齬は後工程で大きな手戻りを生みます。テストが長引くのは前述の高可用性要件によるものです。目安として全体を10とすると、要件定義に2〜3、設計に1〜2、開発に3、テストに2〜3、移行に1程度を配分するイメージで、開発だけが全体の半分を占めるといった前提で計画を立てると、後半で必ず時間が足りなくなります。とりわけ利用者向けサービスでは操作マニュアルの整備や職員研修の時間も見込む必要があり、これらを工程表に明示的に載せておくことが重要です。

公共システムの本番切り替え（カットオーバー）時期は、住民サービスへの影響を最小化できるタイミングに合わせて固定されることが一般的です。窓口業務や住民影響の大きいサービスの移行を、利用が落ち着く年末年始などの休止期間に集中させる例は多く、ある自治体では主要業務のシステム移行を年末年始に固定してスケジュールを組んでいます。ライフラインや防災に関わるシステムであれば、台風や大雪といった災害シーズンを避けて切り替える配慮も必要です。加えて、料金改定や制度改正の施行日に合わせて稼働させなければならない場合、その施行日は法令で決まっているため一日たりとも動かせません。制度改正のタイミングに合わせて他の業務移行もまとめて実施し、二重の改修コストを避けた自治体の例もあります。このように、公共システムのスケジュール設計は「動かせないゴール」を先に固定し、そこから調達リードタイムと長期のテスト期間を差し引いて着手時期を逆算する、という順序で組み立てるのが定石です。ゴールから逆算した結果として着手が間に合わないと判明した場合は、スコープを段階的に分割してでも最初のゴールを死守する判断が求められます。

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

公共システムの開発が当初のスケジュールを超過する原因にはいくつかの典型パターンがあります。あらかじめ想定しておけば予防できるものが多いため、代表的な二つの要因と対策を押さえておきましょう。

最も多い遅延要因が、調達準備と関係者調整に要する時間の過小評価です。仕様書の精度が低いまま公告に進むと、入札不調や落札後の認識齟齬を招き、結果として着手が遅れます。これを防ぐには、公告前にRFIや市場調査を通じて実現可能性と概算費用を把握し、要求事項を具体化しておくことが有効です。また公共分野では、庁内の複数部署、決済事業者・機器メーカーなどの外部事業者、そして場合によっては複数の自治体が関係者として絡むため、合意形成に想像以上の時間がかかります。新旧システムやクラウド基盤・ネットワークで担当ベンダーが分かれるマルチベンダー環境では、障害時の責任の切り分けが複雑になりやすく、ベンダー間・部署間の月例会議などを通じて責任分界点を早期に明確化しておくことが遅延防止につながります。関係者が多いプロジェクトほど、調整の場を定例化し意思決定のルートをあらかじめ決めておくことが、スケジュールを守る現実的な手立てになります。

もう一つの典型が、既存システム（レガシー）からのデータ移行と、稼働中システムとの連携の見込み違いです。長年独自に作り込まれてきた公共システムは、データ構造が特殊であったり仕様書が失われていたりすることがあり、新システムへ移行する際に想定外の抽出・変換作業が発生します。ある政令市では、個別開発で運用されてきた基幹系システムが標準化対応において「移行困難システム」に分類され、現行ベンダーへのデータ出力依頼など多大な調整とコストを要しました。また、新旧システムが並行稼働する過渡期において、既存システムと正しくデータ連携できるかの検証を怠ると業務停止に直結します。別の政令市では、標準準拠システムとオンプレミス環境・別クラウド・外部システムを連携させる際に、想定される連携パターンを網羅的に整理する必要に迫られています。対策としては、要件定義の早い段階で現行システムのデータ調査（現新突合）と連携テスト計画を立て、移行リハーサルを本番前に複数回実施できるだけの期間をスケジュールに確保することが不可欠です。移行は最後にまとめて行う作業ではなく、プロジェクト全体を通じて段階的に準備すべき工程だと捉える必要があります。

まとめ

本記事では、公共インフラ・公共サービスを支えるシステム開発の開発期間・スケジュール・納期について、分野別・方式別の期間目安から、高可用性・制御系連携がスケジュールに与える影響、工程別の期間配分、納期を縛る外部要因と遅延の典型要因までを解説しました。公共システムのスケジュール設計で最も重要なのは、「開発期間」だけでなく「稼働できるまでの調達リードタイム」を含めた全体像で捉えること、そして住民サービスや制度改正から逆算した動かせないゴールを起点に、長期のテスト期間と移行準備を織り込んで計画を立てることです。公共施設予約のような限定的なシステムでおおむね半年から一年、ライフラインや公共交通の基幹システムでは一年半から数年という規模感を念頭に置きつつ、24時間365日の可用性要件や現地機器との連携がテストと導入を長期化させる点を見落とさないようにしてください。現実的なスケジュールを描くには、調達準備の段階から実現可能性を検証し、関係者調整とデータ移行を早期に設計しておくことが成功の近道となります。公共システムの開発を検討されている方は、まずは実績のある開発パートナーに相談し、稼働時期から逆算した現実的な工程表を一緒に描くところから始めることをお勧めします。

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

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