システム運用保守の開発期間・スケジュール・納期について

システム運用保守を外部委託する場合、選定から契約までに約4〜6ヶ月、契約後の引き継ぎに約2ヶ月(8週間)を見込みます。全体では約6〜8ヶ月が目安です。

稟議や決裁、複数部門の調整も含めて日程を逆算し、早めに着手しましょう。準備が遅れると、本番稼働の直前に体制が整わない事態も起こり得ます。

▼全体ガイドの記事
・システム運用保守の完全ガイド

システム運用保守を外部委託する際の全体スケジュール

契約前フェーズの要件定義からRFPまで、4段階とそれぞれの期間を並べた時系列図
段階ごとの期間を比べると、RFPに最も長い時間を見込みます。

要件定義から選定・契約までに約4〜6ヶ月、契約後の引き継ぎに約2ヶ月(8週間)かかります。新規開発と異なり、委託範囲の選定や既存知識の引き継ぎに丁寧な時間設計が必要です。そのため、全体では約6〜8ヶ月が標準的な目安になります。

現行契約が自動更新であれば、6〜8ヶ月のリードタイムを踏まえて、満了の6ヶ月前には次の行動を始めましょう。

契約前フェーズ:ロングリスト作成〜RFI〜RFPの流れ(4〜6ヶ月)

契約までの4〜6ヶ月は、要件定義からRFPまでの4段階で進みます。各段階で候補を絞り込みながら、次の段階へ進みます。

  • 要件定義:構成や課題を整理し、求めるSLA(サービスレベル合意)や予算、評価軸を決める段階です。
  • ロングリスト作成:候補ベンダーを10〜20社程度挙げる。
  • RFI(情報提供依頼):基本情報、実績、対応範囲を確かめ、5〜7社程度に絞ります。
  • RFP(提案依頼):具体的な提案と見積もりを求め、最終候補を2〜3社まで狭めます。

RFPでは、要件を正確に伝えたうえで、各社が比べられる提案を出してもらう必要があるため、4段階の中でいちばん時間がかかります。

要件定義には2〜4週間、ロングリスト作成には1〜2週間程度を見込みます。RFIには3〜4週間ほど、RFPには6〜8週間程度かかります。要件定義からRFPまでが、選定の土台になります。

PoC・面談から契約締結までの最終選定プロセス

候補を2〜3社に絞ったあとは、PoC(概念実証)や面談で最後の1社を選びます。

  • PoC・面談:監視精度やヘルプデスクの応答品質を試すことと、実運用予定のエンジニアとの対話
  • 契約締結:ベンダー決定後に、SLA条項、免責事項、引き継ぎ計画を双方で合意する

提案書だけでは見えない実力を確かめるPoC・面談には、4〜6週間が一般的です。

契約合意には2〜4週間程度かかります。引き継ぎ計画をどこまで具体化できるかが、次の立ち上げを左右します。取り決めを具体的にしておくほど、運用立ち上げも円滑に進みます。

法務レビューが必須の企業は、契約合意にさらに1〜2週間程度の余裕を見込みましょう。委託範囲や損害賠償の調整は長引くこともあるため、法務担当者には早めに契約の前提を共有しておきます。

要件定義から契約締結までの契約前フェーズは、おおむね4〜6ヶ月です。この期間を踏まえて日程を組みます。

運用立ち上げ・引き継ぎフェーズの8週間ステップ

契約締結後は、運用保守の開始に向けて引き継ぎを進めます。品質を保つには、約2ヶ月(8週間)が推奨されます。

  1. 1〜2週目:技術スタックや環境へのアクセス、設計書、運用マニュアルを確認して、全体像をつかむ。
  2. 3〜4週目:保守手順、監視・ログ確認、障害対応フローを学び、過去事例から暗黙知を身につける。
  3. 5〜6週目:現行担当者の監督を受けながら、保守作業、軽微な障害対応、デプロイを経験する。
  4. 7〜8週目:監督なしで作業し、マニュアル更新と緊急連絡体制の確認を済ませてから定常運用へ移る。

引き継ぎを急ぐと、暗黙知が十分に移らないまま本番を迎えることになり、トラブル対応で停滞しやすくなります。

ポイント

全体の期間は、契約前の4〜6ヶ月に引き継ぎの約2ヶ月を加えて見るのが基本です。現行契約が自動更新なら、満了の6ヶ月前には次の行動を始めると、日程に余裕が生まれます。

運用開始後に発生する保守改修(改良開発)の工期の考え方

保守改修の工期見積もりを調査・分析、工期予測モデル、8人月の例に分けた3枚のパネル図
工数だけでなく、調査の比重と規模に応じた期間も確認できます。

運用が始まったあとも、機能追加や仕様変更に伴う保守改修(改良開発)は続いて発生します。

保守改修では、新規開発とは異なる工期の考え方が必要で、見積もりの際に見落としやすい点でもあります。ここでは、その工期の考え方と規模別の目安を見ていきます。

既存システムの調査・分析に工数の30%を要する理由

保守改修では、着手前に既存システムの調査・分析が必要です。

  • 実装箇所の確認:対象機能がどこにどう実装されているかの把握
  • 影響範囲の特定:変更が他の機能へ及ぶかどうかの見極め

この調査・分析に、作業全体の約30%を費やすことがあると言われています。

新規開発と同じ感覚で日程を組むと、調査工数が抜け落ち、着手直後から遅れが出ます。また、依頼先が開発元でない場合や、時間の経過で仕様を把握する人がいない場合は、調査が長引く傾向があります。

見積もりでは、実装工数に加えて、調査・分析にどの程度の工数を見込むかを確認しましょう。

規模から工期を予測する計算式(2.0〜3.0×工数の3乗根)

規模から工期を予測するモデルに「工期=2.0〜3.0×(工数の3乗根)」があります。

  • 8人月の例:8の3乗根は2なので、工期は2.0〜3.0×2で4〜6ヶ月程度が目安になります。

工数を人数で割っても、工期がその分だけ比例して縮むとは限りません。影響範囲の共有や、複数人が同じコードを扱う際の調整にコストがかかるためです。

工数と工期の関係は直線ではなく、3乗根に近い形になりやすいとされます。

ただし、式はあくまで目安で、実際の工期はシステムの複雑さや体制によって変わります。この式は、発注時の交渉材料としても使えます。

提示された工期が目安から大きく外れる場合は、テスト工程や既存システムの調査工数の積算根拠を確認しましょう。

内製と外部委託で変わる改修対応スピードの違い

保守改修の速さは、内製か外部ベンダーへの委託かによって変わります。

  • 内製:仕様を知るエンジニアが社内にいれば、既存システムの調査を圧縮できます。
  • 外部委託:要件伝達、見積もり、契約手続きを経てから着手するため、期間が長くなりがちです。

内製では、小規模な改修を数日〜数週間で対応できるケースもあります。

一方で、契約範囲外の追加開発には、別途見積もりと発注が必要です。このため、着手まで数週間かかることも珍しくありません。

頻繁に起きる軽微な改修は、月額固定の保守範囲に含める方法があります。また、準委任契約でエンジニアの稼働時間を確保する方法も、対応を速める工夫の一つです。

発生頻度と緊急度を見積もり、自社に合う契約形態を選ぶことが、日程の安定につながります。

改修依頼から着手までの期間をSLAに明記するベンダーも増えています。たとえば、「軽微な改修は5営業日以内に着手」などを契約時に合意しておけば、依頼のたびに交渉する手間を省けます。

ポイント

保守改修の工期は、調査工数を含めて見積もり、人数だけで縮まると考えないことが要点です。内製か外部委託かで着手までの期間も変わるため、調査工数の積算根拠を確かめておくとよいでしょう。

納期・スケジュールを左右する5つのリスク要因

納期に影響する資料、習熟度、変更箇所、テスト環境を確認する4枚のチェックカード
確認する対象を契約前にそろえると、日程の見直しにつながる要因を把握できます。

ここまでの選定、引き継ぎ、改修の期間は、一定の前提条件に基づく目安です。ただし、実際の計画は複数の要因によって大きく遅れることがあります。

ここでは、納期に影響しやすい代表的な要因と、それぞれの実務的な対策を見ていきます。

ドキュメント整備状況とシステムの理解容易性

設計書や運用マニュアルの整備状況は、納期を遅らせる大きな要因です。

  • 資料不足・不一致:コードから仕様を推測するリバースエンジニアリングに膨大な時間がかかり、引き継ぎや改修が遅れます。
  • 構造の複雑さ:モジュール化の度合いやデータ構造が複雑なほど、理解に時間がかかります。

発注側は、契約前に資料の有無と最新性を確かめ、不足分の整備を引き継ぎ期間の作業に組み込みます。

資料の不足を見込まずに楽観的な日程を組むと、あとで大幅な見直しが必要になります。

可能なら契約前のPoCや面談で設計書の一部を見せてもらい、記載の粒度や更新頻度を確認しましょう。

引き継ぎの質・変更箇所の分散度・残存バグ

引き継ぎや改修の進み具合は、既存システムの状態に左右されます。

  • 習熟度:理解度によって生産性が変わり、暗黙知をOJTや過去事例から引き継げないと障害対応が遅れます。
  • 変更箇所の分散・結合:影響調査やリグレッションテストが広がり、テスト工数が増えます。
  • 残存バグ:引き継ぎや改修時に不具合が頻発すると、原因調査や手戻りで全体の進みが鈍ります。

たとえば、共通ライブラリなどに変更が及ぶと、デグレード確認のテスト範囲も膨らみます。

これら3要因のリスクは、契約前のヒアリングや初期の引き継ぎで実態を把握できるかで変わります。そのため、可能な限り早く現行システムの状態を確かめておく必要があります。

テスト環境とデータの再利用性、遅延を防ぐための実務対策

テスト環境とデータの再利用性は、テスト効率と納期に直結します。

  • 環境の近さ:本番環境に近いテスト環境があるかどうか
  • 過去資産の再利用:テストケースやデータを流用できるかの見極め

環境を毎回ゼロから作る状況では、改修のたびに準備コストがかさみます。

どの要因にも共通する対策は、見えにくいリスクを契約前に把握しておくことです。具体的には、RFPや契約前のPoCで、設計書の提示や過去の障害対応履歴を確かめます。

見積もり日程には余裕期間(バッファ)を確保しましょう。遅延を抑えるための現実的な対策で、全体の15〜20%程度を見ておくのが目安です。

バッファを確保しておけば、想定外の調査や手戻りがあっても、本番運用の開始日を大きくずらさずに済みます。

ポイント

納期の遅れは、設計書の整備状況、引き継ぎの質、テスト環境の再利用性に左右されやすいです。契約前にこれらを確かめ、日程に余裕を見込んでおくと、遅れを小さくできます。

まとめ

この記事では、委託時の期間や納期を、ベンダー選定、保守改修、遅延リスクの面から整理しました。選定から契約まで約4〜6ヶ月、引き継ぎ・体制構築に約2ヶ月(8週間)かかり、全体では約6〜8ヶ月を見込みます。そのため、現行契約の満了前6ヶ月には動き始めるのが望ましいでしょう。

保守改修では、調査・分析に工数の約30%を要することがあります。工期の見積もりには、工期=2.0〜3.0×工数の3乗根という式も参考になります。

日程は、資料の整備や習熟度、テスト環境の再利用性などに左右されます。このため、リスクを契約前に洗い出し、バッファを確保しておくことが、安定した運用開始につながります。

委託や切り替えを検討する場合は、現行システムの状況を一覧にし、余裕を持ってパートナーを探しましょう。

日程の精度は、初期の段階で現状をどこまで正確に把握できたかで決まります。契約更新が近い場合は、逆算した日程を社内で早めに共有しておくことが必要です。

決裁や予算の確保も並行して進めることで、計画どおりの運用開始につながります。

▼全体ガイドの記事
・システム運用保守の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。