ITシステム維持管理の開発期間と納期は、規模と改修範囲を定め、工程ごとに期間を配分し、要件に合う開発手法を選ぶことで、現実的な水準に近づきます。
期間の目安、工程配分、開発手法の違い、納期短縮と遅延対策を順に見ます。全体像は、完全ガイドもご覧ください。
▼全体ガイドの記事
・ITシステム維持管理の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
ITシステム維持管理プロジェクトの開発期間の全体像
ITシステム維持管理は、稼働中のシステムをIT資産として捉える取り組みです。日々の運用・保守に加え、機器更新計画、資産台帳、ライセンス管理も対象になります。こうした取り組みを通じて、中長期的なライフサイクルコスト（LCC）を無駄なく抑えていきます。
運用と保守は、作業の性質が異なります。運用は、システムの構造を変えない定常的・予防的な業務です。たとえば、稼働監視やバックアップがこれにあたります。
ログ確認や再起動も、この運用に含まれます。一方で、保守は、バグ修正やOSアップデートのように、変更を伴う非定常的・突発的な技術介入です。セキュリティパッチの適用や劣化機器の交換も、保守に含まれます。
対象は、ハードウェアとソフトウェアに加え、セキュリティやネットワークにも及びます。さらに、「2025年の崖」に象徴されるレガシーシステムのブラックボックス化も課題です。
担当者1〜2名に業務が偏る属人化は、IT人材不足のリスクにつながります。また、維持管理の良し悪しは、ITコストと事業継続性を左右します。
予兆監視が不足すると、設備故障で生産ラインが止まり、出荷遅延などの損失が生じます。パッチが未適用の状態は、攻撃や情報漏洩、信用失墜につながるおそれがあります。
資料が不足していたり、属人化していたりすると、原因の調査が難しくなる場合もあります。さらに、予防保守を削ると、是正保守が増え、深夜・休日の対応費や代替機の調達費が積み重なって、LCCが膨らむことがあります。
企業では、監視の自動化や部分改修に加え、老朽化への対応や抜本的な刷新を行う維持管理プロジェクトが増えています。開発期間は、対象システムの規模や改修範囲、既存資産の複雑さによって変わります。そのため、まず規模別の目安をつかみ、計画の出発点にします。
小規模（保守改善・部分改修）は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割を超える見積もりは、要件定義や設計、テストが軽視されている可能性があります。そのうえ、後工程で手戻りが起こるリスクにも注意が必要です。
現状分析・要件定義フェーズ（約15%）
24週の案件であれば、要件定義に約3.5〜4週を割り当て、既存システムの現状分析（As-Is分析）もこの期間に行います。
- 範囲：改修対象と、どこまで直し、どこを直さないか。
- 要件：性能や可用性、セキュリティ、移行面の条件。
- 基準と変更：完了の判定と、仕様が変わったときの管理プロセス。
ドキュメントが残っておらず、有識者も減っているブラックボックス化したシステムほど、現状分析に時間がかかります。実際には、計画の段階で要件定義の比率が低めに見積もられがちです。その結果、決めきれないまま基本設計以降を圧迫することがあります。
要件定義書には、スコープと除外項目を明記しておきます。また、変更管理のプロセスを契約に含めておくと、納期を守るための有効な予防策になります。
設計・改修実装フェーズ（約60%）
設計は約6週（25%）、改修実装は約8週（35%）で、合わせて全体の約6割です。両工程は、それぞれの役割を分けて進めます。
- 設計：改修範囲を詳細に詰め、既存システムとの整合性を検証する。
- 実装：監視自動化スクリプトの開発、老朽化機能の改修、セキュリティパッチの適用。
稼働中のシステムを扱うため、新規開発以上に、「今動いているものを壊さない」設計が求められます。
ブラックボックス化したシステムでは、実装の途中で想定外の仕様が判明することがあります。そのため、設計段階で現状を把握しておくことが、実装の生産性に直結します。
設計と実装の精度や生産性が、プロジェクト期間の長さを左右します。
テスト・リリース準備フェーズ（約25%）
テストは約4週（15%）、リリース準備は約2週（10%）です。それぞれの作業内容も、この期間に含めます。
- テスト：改修箇所の動作確認に加え、稼働中の既存システムへの影響を回帰の観点から確かめることも特に重要です。
- リリース準備：本番切替の手順確認、切替リハーサル、ロールバック手順の整備。
資料が不十分なシステムでは、無関係に見える箇所への副作用が、本番移行後に判明することがあります。そのため、テスト範囲は広めに取ります。
維持管理では、業務を止めずに切り替える必要がある案件が多くあります。さらに、切替タイミングの調整にも時間がかかります。
納期が迫ると、テストやリリース準備が削られがちです。ただし、圧縮しすぎると本番後の障害対応が増え、総コストと総期間が膨らみます。
ライフサイクルモデル（開発手法）による期間の違い
同じ規模でも、開発手法によってスケジュールや初回改修の完了までの期間が変わります。要件がどの程度固まっているか、プロジェクトの特性はどうかに応じて、手法を選びます。
経済産業省の「システム管理基準」は、代表的なモデルとしてウォーターフォール、スパイラル、アジャイルを挙げています。維持管理でどのモデルを選ぶかが、無理のない納期を組むための出発点になります。
ウォーターフォール・スパイラル・アジャイルの違い
各モデルは、要件の変更しやすさや扱うリスクが異なるため、改修の性質に合わせて比べる必要があります。
- ウォーターフォール：要件を確定し、現状分析・要件定義→設計→実装→テスト→リリースの順に進める。
- スパイラル：試作と評価を繰り返して、段階的に完成度を高める。
- アジャイル：短期サイクルを反復し、優先度の高い改修から完成させる。
ウォーターフォールは予定と予算を見通しやすく、基幹系刷新のように変更の少ない大規模案件に向きます。ただし、ウォーターフォールでは、終盤に大きな変更が入ると手戻りが生じ、期間が大幅に延びるおそれがあります。
スパイラルは、老朽化対応のようにリスクの高い改修を、段階的に検証したい案件に適しています。アジャイルは、変更に強く初回リリースを早めやすい手法で、現場を見ながら改善する監視自動化とも相性が良いと言えます。
段階的な改修によるリリース期間短縮
納期を縮めるには、改修の対象を一気に広げず、影響度の低い部分から段階的に着手する方法が有効です。
- 着手箇所：影響範囲の狭い社内システムや優先度の高い一部機能。
- 進め方：既存の運用フローと比べながら検証し、対象を少しずつ広げる。
- 老朽化対応：事業継続性に影響する基幹部分は後回しにし、周辺から刷新する。
周辺システムから進めると、初期段階のリスクとロールバックの負荷を抑えられます。
早期に改修効果を確認でき、予算やスケジュールに制約があっても優先箇所を完了できます。さらに、現場の変化に応じて、後続の優先順位も調整できます。
納期を短縮する具体的な方法
納期を縮めたいとき、まず人員を増やすことを考えがちです。ただし、担当者を急に増やすと既存システムの理解に時間がかかり、立ち上がりが遅れて逆効果になる場合もあります。
品質を保ったまま期間を縮めるため、見積もりと作業項目の調整、契約と変更管理の実践策を紹介します。
多段階見積りとテーラリングの徹底
工程ごとに見積もりの精度を上げ、規模に合った作業を選ぶことが、現実的なスケジュールにつながります。
- 多段階見積り：工程が進むたびに、見積もりを実態に合わせて更新する。
- テーラリング：組織や案件の規模に応じ、作業項目を取捨選択する。
初期の不確かな見積もりを絶対目標にすると、現状分析の後に実態とのずれが分かります。そのずれを無理に帳尻合わせすると、遅延を招きます。
小規模な部分改修では不要な作業を削り、大規模刷新では必要な工程を手厚くします。こうして工数の無駄を減らし、期間短縮につなげます。
契約形態の使い分けと変更管理ルールの事前策定
工程の性質に応じて契約を使い分け、変更時のルールをあらかじめ決めておきます。要件定義には、十分な工期と工数を割り当てます。
- 準委任契約：現状分析や要件定義などの超上流工程、完成後の運用テスト。
- 請負契約：仕様が確定した後の製造と改修実装。
- 変更管理：発注者とベンダーの間で、事前にルールを定める。
要件は変わる前提で変更管理と契約範囲を決めておくと、手戻りや責任範囲を調整できます。さらに、多段階見積り、テーラリング、契約の使い分けを組み合わせると、仕様変更があっても計画的に進められます。
納期遅延の典型要因と対策
綿密に計画しても、遅延のリスクは残ります。そこで、維持管理で起きやすい要因を事前に把握し、対策を契約や進捗管理の仕組みに組み込みます。
要件定義不足と見切り発車
遅延の要因として最も多いのは、要件定義の期間と工数の不足です。計画の段階で要件定義に割り当てる比率が低い案件は多く、決めきれないまま基本設計以降を圧迫します。
- 見切り発車：完了基準や発注者・ベンダー間の合意が不明確なまま実装する。
- 見積りの曖昧さ：着手後に、実際の開発規模とのずれが表面化する。
- 対策：十分な工期と工数を確保し、完了基準を明文化してから次の工程に進む。
仕様が未確定のまま実装すると、後工程で変更が多発し、大規模な作り直しにつながります。また、曖昧な見積もりは、コスト増と納期遅れを同時に招くことがあります。
既存システムのブラックボックス化への対策
もう一つの遅延要因は、既存システムのブラックボックス化です。有識者の退職や異動が進むと、内部構造を把握する人がいなくなり、現状分析が不足したまま計画が進むことがあります。
- 見積り更新：初期の不確かな概算を絶対視せず、工程に合わせて見直す。
- 変更管理：要件は変わる前提で、管理ルールを事前に決める。
- 契約の使い分け：超上流工程と運用テストは準委任、仕様確定後の実装は請負とする。
分析が不足したまま着手すると、実装段階で想定外の仕様が次々と判明し、スケジュールが崩れます。対策は、As-Is分析と、To-Be（改修後の姿）を見える形にすることです。
多段階見積り、変更管理、契約の使い分けを組み合わせると、遅延リスクを現実的な範囲に抑えられます。
まとめ
規模別の期間と工程の配分に続き、開発手法や納期短縮、遅延対策を見てきました。
開発期間の目安は、小規模で1〜3か月・50万〜200万円、中規模で4〜9か月・200万〜1,000万円、大規模で10か月以上・1,000万〜3,000万円です。
工程の配分は、要件定義が15%、設計が25%、実装が35%です。テストは15%、リリース準備は10%が目安になります。この配分は、見積もりの妥当性を判断する材料になります。
ウォーターフォール、スパイラル、アジャイルのどれを選ぶかで、進め方が変わります。影響度の低い箇所から段階的に改修すると、初期リスクを抑えられます。
納期を守るには、多段階見積りとテーラリング、契約の使い分けが欠かせません。さらに、変更管理のルールを事前に合意しておくことも大切です。要件定義にも、十分な工期と工数を割り当てます。
ブラックボックス化を放置せず、現状分析に時間をかけることが、無理のない納期設定と遅延リスクの抑制につながります。
具体的なスケジュールを相談する際は、複数の開発会社に現状のシステム構成と改修範囲を示し、見積もりを取ることから始めます。
▼全体ガイドの記事
・ITシステム維持管理の完全ガイド
▼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を創業。