ITシステム維持管理の開発期間・スケジュール・納期について

ITシステム維持管理とは、稼働中のシステムを単なる「動いている状態の維持」ではなく、長期的な価値と業務適合性を最良の状態に保つべき「IT資産」として捉え、日々の運用・保守はもちろん、ハードウェアの更新計画や資産台帳管理、ライセンス管理までを含めて中長期的なライフサイクルコスト（LCC）を最適化していく、包括的な取り組みを指します。混同されやすい「運用」と「保守」にも明確な違いがあり、運用は稼働監視・バックアップ・ログ確認・再起動などシステム構造に変更を加えない定常的・予防的な業務、保守はバグ修正・OSアップデート・セキュリティパッチ適用・劣化機器の交換などシステムに変更を加える非定常的・突発的な技術的介入を指します。対象領域もハードウェア、ソフトウェア、セキュリティ、ネットワークと多岐にわたり、いわゆる「2025年の崖」に象徴されるレガシーシステムのブラックボックス化や、担当者1〜2名への属人化によるIT人材不足リスクが叫ばれる中、維持管理の巧拙が企業のITコストと事業継続性を大きく左右する時代になっています。

維持管理を怠ると、予兆監視の不足が突然の設備故障や生産ライン停止・出荷遅延といった業務停止による損失を招いたり、パッチ未適用がサイバー攻撃・情報漏洩による社会的信用の失墜につながったりするほか、ドキュメント未整備・属人化によって原因調査すら困難になる「対応不能化」、そして予防保守を削った結果として緊急対応（是正保守）が多発し深夜休日対応費や代替機調達費が累積してLCCが肥大化するリスクを抱えることになります。こうした背景から、既存システムの監視自動化、部分的な改修、老朽化対応、あるいは抜本的な刷新といった「維持管理プロジェクト」に着手する企業が増えていますが、いざ発注を検討する段階になると「どのくらいの開発期間がかかるのか」「納期はどう見積もればよいのか」「スケジュールが遅延する要因は何か」という疑問に必ず突き当たります。本記事では、ITシステム維持管理プロジェクトの開発期間・スケジュール・納期に焦点を当て、規模別の期間目安、工程別の期間配分、ライフサイクルモデルによる違い、納期を短縮する具体的な方法、そして納期遅延の典型要因とその対策までを体系的に解説します。

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

▼全体ガイドの記事
・ITシステム維持管理の完全ガイド

ITシステム維持管理プロジェクトの開発期間の全体像

ITシステム維持管理プロジェクトの開発期間は、対象システムの規模・改修範囲・既存資産の複雑さによって大きく変動しますが、まずは規模別のおおまかな目安を把握しておくことが計画の出発点になります。一般的な期間と費用の相場感は、小規模（保守改善・部分改修）で1〜3か月・50万〜200万円、中規模（業務システムの維持管理刷新・改修）で4〜9か月・200万〜1,000万円、大規模（基幹系の維持管理刷新）で10か月以上・1,000万〜3,000万円が一つの目安です。維持管理プロジェクトはハードウェア・ソフトウェア・セキュリティ・ネットワークという広い対象業務領域のうち、どこまでを改修スコープに含めるかによって工数が大きく変わるため、着手前にスコープを明確にしておくことが、後の期間見積もりの精度を左右します。

規模別にもう少し具体的に見ていきましょう。小規模の維持管理プロジェクトは、監視ツールの導入によるアラート対応の自動化、既存画面の軽微な表示修正、OSアップデートに伴う不具合修正といった部分改修が該当し、1〜3か月・50万〜200万円程度で完了することが多く、エンジニア1〜2名の体制で進められます。中規模の維持管理プロジェクトは、業務システムの一部機能刷新、老朽化したミドルウェアの入れ替え、複数システム間の連携改修などが該当し、期間は4〜9か月、費用は200万〜1,000万円が目安です。プロジェクトマネージャー・エンジニア・場合によってはインフラ担当者を含めた体制で進めるのが一般的です。大規模の維持管理プロジェクトは、基幹系システムそのものの刷新や、老朽化したオンプレミス環境からの全面的な移行など、事業継続性に直結する改修が該当し、10か月以上・1,000万〜3,000万円が目安となります。これらはあくまで初期の概算であり、正確な期間は現状分析と要件定義を経て初めて確定する点を理解しておく必要があります。

同じ「中規模」でも、実際の開発期間が4か月で終わるプロジェクトと9か月かかるプロジェクトがあります。この差を生む変数を理解しておくことが、現実的なスケジュール策定の鍵です。第一の変数は非機能要件の考慮漏れです。性能・可用性・セキュリティ・移行要件といった非機能要件の検討が不足したまま進めると、運用テスト以降や本番移行後になって初めて致命的な問題（システムダウンなど）が発覚し、手戻りによって期間が大きく伸びます。第二の変数は要求の膨張です。改修を進める過程で「ついでにここも直したい」という要求が積み重なると要件定義工程そのものが延び、プロジェクト全体の規模と期間に影響します。第三の変数はテーラリング（組織・プロジェクト規模に応じた作業項目の修整）の不足です。標準的な開発プロセスをそのまま適用してしまうと、小規模な改修案件であっても本来不要な作業項目が残ってしまい、生産性が低下して期間が間延びします。これらの変数を見積もり段階で洗い出し、楽観的すぎない期間を設定することが、後の遅延を防ぐ第一歩になります。

工程別スケジュールと期間配分

開発期間を正しく見積もるには、プロジェクト全体をいくつかの工程に分解し、それぞれにどれだけの期間が必要かを把握することが不可欠です。ここでは、中規模の維持管理プロジェクト（約6か月＝24週程度）を例に、現状分析・要件定義から設計・改修実装、テスト・リリース準備までの標準的な期間配分を見ていきます。一般的な工程配分の目安は、要件定義が全体の約15%、設計が約25%、実装が約35%、テストが約15%、リリース準備が約10%です。この比率を頭に入れておくと、各社から提示された見積もりのスケジュールが妥当かどうかを判断しやすくなります。たとえば「実装だけで全体の6割超」という見積もりが出てきた場合、要件定義や設計、テストが軽視されている可能性があり、後工程での手戻りリスクが高いと推測できます。

要件定義フェーズは、24週のプロジェクトであれば約3.5〜4週を割り当てます。維持管理プロジェクトにおいては、この期間に既存システムの現状分析（As-Is分析）が欠かせません。ドキュメントが未整備で有識者も減少している「ブラックボックス化」した既存システムほど、この分析に時間を要します。この工程で、改修対象範囲、非機能要件（性能・可用性・セキュリティ・移行要件）、完了基準を明文化します。しかし実際のプロジェクトでは、計画段階でこの要件定義に割り当てる比率が低く見積もられがちで、決めきれないまま基本設計以降の工程を圧迫してしまうケースが少なくありません。要件定義書を明文化し、「どこまで直すか・直さないか」というスコープと除外項目を明示し、後から仕様が変わった場合の変更管理プロセスを契約に組み込んでおくことが、納期遵守の最大の予防策になります。

設計フェーズには約6週（25%）、改修実装フェーズには約8週（35%）、合わせて全体の約6割を割り当てます。設計フェーズでは、改修範囲の詳細設計に加え、既存システムとの整合性検証が重要になります。維持管理プロジェクトは既存の稼働システムに手を入れる性質上、新規開発以上に「今動いているものを壊さない」設計への配慮が求められます。続く実装フェーズでは、監視自動化スクリプトの開発、老朽化した機能の改修、セキュリティパッチの適用作業などを進めます。既存システムのブラックボックス化が進んでいる場合は、この工程で想定外の仕様が発覚することもあるため、設計段階での現状把握の精度がそのまま実装フェーズの生産性に直結します。この設計・実装フェーズが全体の約6割を占めるため、ここでの精度と生産性がプロジェクト全体の期間を決定づけます。

テストフェーズには約4週（15%）、リリース準備フェーズには約2週（10%）を割り当てます。維持管理プロジェクトのテストでは、改修箇所そのものの動作確認に加えて、既存の稼働中システムへの影響を検証するリグレッションテストが特に重要です。ドキュメントが不十分な既存システムでは、一見無関係に見える箇所への副作用が本番移行後に発覚することもあるため、テスト範囲を広めに取ることが望ましいといえます。リリース準備フェーズでは、本番環境への切替手順の確認、切替リハーサル、ロールバック手順の整備を行います。維持管理プロジェクトは業務を止めずに切り替える必要があるケースが多く、切替タイミングの調整にも時間を要します。納期が逼迫すると真っ先に削られがちなのがこのテスト・リリース準備の期間ですが、ここを圧縮しすぎると本番稼働後の障害対応に追われ、結果として総コストと総期間が膨らみます。

ライフサイクルモデル（開発手法）による期間の違い

同じ規模の維持管理プロジェクトでも、採用するライフサイクルモデル（開発手法）によってスケジュールの組み方と「初回改修完了までの期間」は大きく変わります。経済産業省の「システム管理基準」でも、代表的なライフサイクルモデルとしてウォーターフォール、スパイラル、アジャイルの3種が挙げられており、プロジェクトの特性や要件の固まり具合に応じて選択することが求められています。ITシステム維持管理プロジェクトでどのモデルを選ぶかは、納期最適化の出発点になります。

ウォーターフォールは、要件を先に確定し、現状分析・要件定義から設計・実装・テスト・リリースまでを順番に進める手法です。要件を最初にすべて固めてから作るため、全体のスケジュールと予算が見通しやすく、基幹系の刷新など仕様変更の少ない大規模プロジェクトに向いています。一方、要件確定後の仕様変更には弱く、終盤で大きな変更が入ると手戻りが発生して期間が大幅に伸びるリスクがあります。スパイラルは、試作と評価を繰り返しながら漸進的にシステムを進化させていく手法で、老朽化対応のようにリスクの高い改修を段階的に検証しながら進めたいプロジェクトに向いています。アジャイルは、短期のサイクルを反復しながら要件定義からテストまでを進める手法で、優先度の高い改修から順に完成させていくため仕様変更に強く、初回リリースを早められるのが最大の利点です。監視自動化のように現場の運用フローを見ながら改善を重ねていくプロジェクトでは、アジャイルとの相性が良いといえます。

納期の観点で特に有効なのが、改修対象を一気に広げるのではなく、影響度の低い部分から段階的に着手していく考え方です。維持管理プロジェクトは稼働中のシステムを扱うため、全システムを一斉に刷新するのではなく、まずは影響範囲の狭い社内システムや優先度の高い一部機能から改修に着手し、既存の運用フローと比較検証しながら段階的に対象を広げていくアプローチが有効です。たとえば老朽化対応であれば、事業継続性への影響が大きい基幹部分を最後に回し、周辺システムから段階的に刷新していくことで、初期段階でのリスクとロールバックの負荷を抑えられます。この方式のメリットは、早期に改修効果を確認できること、予算やスケジュールが制約されている場合でも優先度の高い部分から確実に完了させられること、そして現場の状況変化に応じて後続フェーズの優先順位を柔軟に組み替えられることです。

納期を短縮する具体的な方法

納期短縮は、単に人を増やせば実現できるものではありません。むしろ維持管理プロジェクトでは、担当者を急に増やしても既存システムの理解に時間がかかり、立ち上がりが遅れて逆効果になることもあります。ここでは、品質を犠牲にせずに開発期間を短縮するための実践的な手法を紹介します。

第一の手法は「多段階の見積り方式」の採用です。プロジェクト初期段階の不確定な見積りをそのまま絶対的な目標にしてしまうと、後になって現状分析の結果と乖離が生じ、無理な帳尻合わせが遅延を招きます。工程が進むごとに、より精度の高い見積りへと段階的に更新していくことで、実態に即した現実的なスケジュール管理が可能になります。第二の手法はテーラリング、すなわち組織やプロジェクトの規模に応じて作業項目を適切に取捨選択することです。標準的な開発プロセスを機械的にすべて適用するのではなく、小規模な部分改修であれば不要な作業項目を削り、大規模な刷新であれば必要な工程を手厚くするといった調整を行うことで、無駄な工数を削減し、期間短縮につなげられます。

第三の手法は、契約形態の使い分けです。要件が固まっていない超上流工程（現状分析・要件定義）や、完成後の運用テストの工程では準委任契約を、仕様が確定した後の製造・改修実装の工程では請負契約を採用するというように、工程の性質に応じて契約形態を切り替えることで、手戻りのリスクと責任範囲を適切にコントロールできます。第四の手法は、変更管理ルールの事前策定です。維持管理プロジェクトでは「要件は途中で変わるもの」という前提に立ち、発注者とベンダーの間であらかじめ変更管理ルールを確立しておくことが重要です。加えて、要件定義工程そのものに十分な工期・工数を割り当てておくことも欠かせません。これらを組み合わせることで、期中の仕様変更に振り回されることなく、計画的にスケジュールを進められます。

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

どれだけ綿密に計画しても、納期遅延のリスクはゼロにはなりません。重要なのは、維持管理プロジェクトで特に発生しやすい遅延の典型要因を事前に把握し、対策を契約や進捗管理の仕組みに組み込んでおくことです。

最も多い遅延要因は、要件定義の期間・工数不足です。計画段階でこの工程に割り当てる比率が低いプロジェクトは多く、決めきれないまま次の基本設計以降の工程を圧迫してしまいます。これに関連するのが、要件が未確定のまま次工程へ進んでしまう「見切り発車」です。完了基準が不明確で発注者・ベンダー間の合意形成もないまま実装に進んでしまうと、後工程で仕様変更が多発し、大規模な作り直しにつながります。また、あいまいな見積りのまま着手してしまうと、実際の開発規模とのズレが表面化し、コスト増と納期遅れを同時に招きます。対策としては、要件定義工程に十分な工期・工数を確保すること、そして完了基準を明文化してから次工程に進むことを徹底することが基本になります。

第二の遅延要因は、既存システムのブラックボックス化です。長年にわたり保守を担ってきた有識者の退職・異動が進むと、システムの内部構造を把握している人がいなくなり、As-Is分析やTo-Be（改修後の姿）の可視化が不十分なまま計画が進んでしまいます。この状態で着手すると、実装段階になって想定外の仕様が次々と発覚し、スケジュールが崩れます。対策としては、前述の「多段階の見積り方式」でプロジェクト初期の不確定な見積りを絶対視せず工程の進行に応じて更新すること、要件は変わるものという前提で変更管理ルールを事前に確立しておくこと、そして超上流工程・運用テストは準委任契約、仕様確定後の製造・改修実装は請負契約というように契約形態を使い分けることが有効です。これらの対策を組み合わせることで、遅延リスクを現実的な範囲にコントロールできます。

まとめ

本記事では、ITシステム維持管理プロジェクトの開発期間・スケジュール・納期について、規模別の期間目安、工程別の期間配分、ライフサイクルモデルによる違い、納期短縮の手法、そして遅延要因と対策までを体系的に解説しました。開発期間の目安は小規模で1〜3か月・50万〜200万円、中規模で4〜9か月・200万〜1,000万円、大規模で10か月以上・1,000万〜3,000万円であり、要件定義15%・設計25%・実装35%・テスト15%・リリース準備10%という工程配分を押さえておくことが、見積もりの妥当性を判断する基準になります。維持管理プロジェクトはウォーターフォール・スパイラル・アジャイルというライフサイクルモデルの選択によって進め方が変わり、影響度の低い部分から段階的に着手することで初期段階のリスクを抑えられます。納期を守るためには、多段階見積りやテーラリングによる無駄な工程の削減、契約形態の使い分け、変更管理ルールの事前合意に加え、要件定義工程への十分な工期・工数の割り当てが不可欠です。既存システムのブラックボックス化を放置せず、現状分析に十分な時間をかけることが、無理のない納期設定と遅延リスクの最小化につながります。具体的なスケジュールの相談は、複数の開発会社に現状のシステム構成と改修範囲を提示して見積もりを取ることから始めることをお勧めします。

▼全体ガイドの記事
・ITシステム維持管理の完全ガイド

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