公共システムの開発期間は、調達・方式・可用性・機器連携の違いによって、半年から数年と幅があります。
ここでいう公共システムは、官公庁の行政事務とは異なり、住民サービスや停止が社会生活に響くインフラが対象です。全体像は、公共システム開発の完全ガイドもご覧ください。
▼全体ガイドの記事
・公共システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
公共システム開発の期間全体像と「公共サービスならでは」の前提
公共システムの全期間は、開発着手前と開発そのものに分けて考えます。公共交通、上下水道、公共施設予約などは、税や公共料金を原資とする公金で整備します。
開発着手前には、原則として仕様書作成、公告、提案審査、契約締結を経ます。調達リードタイムだけで数ヶ月から一年近くかかることもあるため、稼働希望日から逆算するときは、開発工数にこの期間も加えて考えます。
公共システムは、サービスを止められないこと、現場の設備と物理的につながること、多様な利用者が使うことという特性を持ちます。そのため、可用性の要件や設備との連携、移行時期の制約によって、テストや移行は民間の一般的なシステムと比べて長くなります。
公共システムが対象とする領域と期間の考え方
公共システムの対象領域は幅広く、期間を左右する要素も領域ごとに異なります。期間を見積もるときは、リアルタイム性、現場設備との接続、利用者を領域ごとに切り分けます。この切り分けが検討の出発点になります。
- 交通：運行管理やIC乗車券は、ダイヤや運賃の改定に連動する複雑な処理とリアルタイム性を必要とし、規模も大きくなりがちです。
- ライフライン：検針・料金計算・設備保全では、独自の料金体系と、メーターやプラント設備への対応が求められます。
- 公共施設：予約管理は比較的コンパクトですが、決済やスマートロックとの連携が期間を左右します。
- その他：公共工事や、独立行政法人・公社・第三セクターのシステムでは、固有の制度や帳票への対応が必要です。
公共システムが支える範囲は、公共交通やライフラインだけでなく、図書館、体育館、公民館、スポーツ施設の予約にも広がります。
「開発期間」と「稼働できるまでの期間」の分け方
全体スケジュールは、調達準備、調達手続き、開発、移行・稼働の順に進みます。このうち開発には、要件定義からリリースまでが含まれます。
- 調達準備では、RFIや市場調査を行い、仕様書を固めます。
- 調達手続きでは、公告、提案審査、契約締結を進めます。
- 契約後は、要件定義からリリースまでを開発します。
- 移行を経て、システムを稼働させます。
民間では、発注を決めてから数週間で開発を始めることもあります。一方、公共分野では調達の前に準備を重ねるため、着手までの期間が加わります。
ある政令市では、RFIを二度行って仕様書を精緻化しました。さらに、数ヶ月かけて前年度末までに準備を終え、新年度当初に調達を始める計画でした。
また、ある市の観光案内AIチャットボットも、公募型プロポーザルで調達しました。公開から選定、契約を経て、本格運用は翌年度でした。
稼働希望日を起点に、調達リードタイムと開発期間の両方を積み上げることが、現実的な納期設定につながります。
分野別・開発方式別の開発期間の目安
開発期間は、システムの規模と方式によって変わります。方式には、SaaSやパッケージの活用と、フルスクラッチがあります。
公共分野の実例をもとに、代表的な規模帯ごとの期間を見ていきます。どの規模でも、調達リードタイムは別に見込む必要があります。
公共施設予約・住民向けサービス系の期間目安
公共施設予約や住民向けのオンライン申請・案内など、範囲が限られるシステムでは、契約後おおむね半年から一年が目安になります。
- 期間の実例：スマートロックとキャッシュレス決済を連動させた施設予約は、約10ヶ月かかりました。
- 期間を含む作業：要件定義と初期設定、機器設置を行い、職員確認と住民向けマニュアル整備も含みます。
- 方式と連携：SaaSやパッケージでは短縮できる余地がありますが、決済事業者や機器メーカーなど複数社との調整は必ず発生します。
この約10ヶ月は、ある自治体の委託業務で、仕様書の提示から本稼働までの履行期間として設定されていました。
ソフトウェアだけの期間よりも余裕を持たせ、テストとマニュアル整備を削らないことが大切です。また、利用者向けのUI/UXは公開後の評判に直結するので、導入期間を考えるときは、この点も踏まえます。
ライフライン基幹・公共交通運行管理など大規模系の期間目安
上下水道の料金・検針や設備保全、交通の運行管理・料金精算は、一年半から数年規模になります。
- 複雑な処理：大量のデータに加えて、独自の料金体系や運行ダイヤのロジックを扱います。
- 機器連携：メーターやセンサー、プラント設備、券売機、改札機との接続が必要になります。
- 広域基盤：複数の事業者や部局をまたぐ交通・環境データ基盤では、実証実験を含めて数年かかることもあります。
大規模系では、一度に切り替えるビッグバン移行はリスクが高いため、地域や機能ごとに段階的に移行することが多くあります。段階分けの設計も、全体期間を左右します。
規模が大きいほど、要件定義の精度が期間のぶれを決めます。そのため、初期に時間を割くことが納期の短縮につながります。
高可用性・ミッションクリティカル要件がスケジュールに与える影響
公共システムには、停止できない高可用性とミッションクリティカルな要件が求められます。この非機能要件によって、設計やテストが長期化します。
計画には、機能開発だけでなく、可用性を支える冗長化設計、障害対応訓練、長期の検証も含めます。
24時間365日・障害復旧目標とテスト期間の長期化
利用者がいつ使うか分からないため、多くの仕様書は、保守停止を除く24時間365日の利用を求めます。停止を伴う障害は、1営業日以内の復旧が目標とされます。
- 結合テスト：機能どうしが連携して動くかを確認します。
- 運用テスト：障害を起こし、復旧の手順が機能するかを試します。
- 耐久試験：長時間の連続稼働に耐えられるかを検証します。
ある自治体の基幹システム移行では、当初の3ヶ月のテスト期間が、通常業務と並行する確認作業には足りませんでした。
後続業務では約6ヶ月を確保したいと見直されました。また、公共システムではテストが全体の2〜3割を占めることもあります。
テストや検証には、開発と同等かそれ以上の時間を配分します。冗長化設計や障害対応訓練も、工程に織り込みます。
制御系（OT）・現地機器との連携が生む物理的リードタイム
公共システムは、ソフトウェアだけで完結せず、現場の物理設備や機器（OT）につながることがあります。その連携には、別の物理的なリードタイムが生じます。
- ライフライン：メーターやプラントの制御装置と連携する必要があります。
- 交通：券売機や改札機との連携が必要です。
- 公共施設：スマートロックや電子錠の設置が必要になります。
スマートロックの仕様書では、設置位置を事前に確認して算定し、防雨・日除け対策を施したうえでの安定稼働を検討することが求められていました。
20施設を超える場合などは、各施設を訪ねて電波、電源、雨風の影響を調べます。そのため、クラウド単体の場合より導入期間が長くなります。
機器の調達、設置、現地試験は、早い段階で予定に入れておきます。ソフトの完成を待たず、機器側の作業と並行させることが、遅延の防止につながります。
工程別スケジュールと納期を縛る外部要因
納期は、住民生活や制度から逆算して決まる、動かせないゴールになることがあります。ここでは、工程の配分と納期を縛る要因を見ていきます。
要件定義〜リリースまでの工程別期間配分
基本工程は、要件定義、設計、開発、テスト、移行・リリースです。公共システムでは、要件定義とテストが長くなる傾向があります。
- 要件定義：全体の2〜3の時間
- 設計：全体の1〜2の時間
- 開発：全体の3の時間
- テスト：全体の2〜3の時間
- 移行：全体の1程度の時間
この比率は全体を10とした目安です。開発だけで全体の半分を占める前提では、後半に時間が足りなくなります。
料金体系や条例の独自ルールに加え、部署・事業者の要望を丁寧にすり合わせるため、要件定義が長引きます。この段階で認識が食い違うと、後工程で大きな手戻りが生じます。
テストが長引くのは、前述の高可用性要件によるものです。利用者向けのサービスでは、マニュアル整備や職員研修の時間も見込んで、工程表に明記しておきます。
繁忙期・災害期・法改正の施行日から逆算する納期設計
本番切り替え（カットオーバー）は、住民サービスへの影響を抑えられる時期に固定されるのが一般的です。
- 繁忙期：窓口や住民への影響が大きい移行は、年末年始など利用が落ち着く休止期間に行います。
- 災害期：ライフラインや防災関連は、台風・大雪の時期を避ける配慮が必要です。
- 法改正：料金・制度改正に合わせて稼働する場合、法令で定まる施行日は一日も動かせません。
ある自治体は、主要業務の移行を年末年始に固定しました。一方、別の自治体は、制度改正に合わせて他業務も移し、二重の改修費を避けました。
まず動かせないゴールを決め、調達期間と長期のテスト期間を差し引いて、着手時期を逆算します。着手が間に合わないときは、スコープを段階的に分けてでも、最初のゴールを守る判断が必要です。
納期遅延の典型要因と対策
公共システムで開発が当初の予定を超える原因には、典型的なものがあります。事前に想定しておけば、防げる場合もあります。
調達リードタイム・関係者調整の見積り不足
調達準備や関係者調整の時間を少なく見積もると、着手が遅れます。さらに、仕様書の精度が不足すると、入札不調や契約後の認識違いを招きます。
- 公告前の調査：RFIや市場調査で実現可能性と概算費用を把握し、要求を具体化します。
- 関係者の合意：庁内の複数部署や決済事業者、機器メーカー、複数の自治体との調整時間を見込んでおきます。
- 担当範囲の明確化：マルチベンダー環境では、月例会議などで、どこまでを誰が受け持つかを早い段階に決めます。
新旧システム、クラウド基盤、ネットワークで担当が分かれると、障害時の責任分担が複雑になりがちです。そのため、関係者が多いほど調整の場は定例にしておきます。意思決定のルートを先に決めることが、日程を守るための現実的な対策になります。
レガシー・マルチベンダー連携とデータ移行の設計不足
既存システムからのデータ移行や、稼働中のシステムとの連携を見誤ると、それも遅延の要因になります。
- データの特殊性：長年独自に開発されたシステムは、特殊な構造や失われた仕様書があり、抽出・変換の作業が想定外に発生します。
- 並行稼働：新旧システム間のデータ連携を確かめておかないと、業務停止につながります。
- 早期の準備：要件定義の早い段階で現行と新規のデータを突合し、連携テストと複数回の移行リハーサルに十分な期間を確保します。
ある政令市では、個別開発の基幹系が標準化対応の「移行困難システム」に分類されました。同市は、現行ベンダーへのデータ出力を依頼するなど、多くの調整と費用を要しました。
別の政令市では、標準準拠のシステムをオンプレミス、別のクラウド、外部システムとつなぐにあたり、連携パターンを網羅的に洗い出す必要がありました。移行の準備は、プロジェクト全体を通じて段階的に進めます。
まとめ
公共システムの期間は、公共施設予約などで半年から一年、ライフラインや交通の基幹系で一年半から数年が目安です。
開発期間だけでなく、調達準備から稼働までを見込んでおきます。24時間365日の可用性や現地機器との連携も、テストと導入を長くする要因です。
住民サービスや制度改正に合わせた動かせない日程から逆算して、長期テストと移行準備を含む計画を立てます。
分野や方式による期間の違いを踏まえ、可用性と機器連携の影響、工程配分と納期の制約、遅延要因を計画に入れます。調達準備、関係者調整、データ移行は、早い段階から設計しておくと、現実的な計画につながります。
公共システムを開発するなら、実績のある開発パートナーに相談し、稼働時期から逆算した工程表を一緒に描く方法があります。
▼全体ガイドの記事
・公共システム開発の完全ガイド
▼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を創業。