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

システムの運用保守を外部に委託しようとするとき、多くの発注担当者が最初につまずくのが「一体どれくらいの期間を見ておけばよいのか」という点です。新規開発であれば要件定義から納品までのスケジュールを引く感覚がありますが、運用保守の場合は「ベンダーを選ぶ期間」「契約する期間」「実際に引き継いで運用を開始する期間」という、開発とは異なる複数のフェーズが存在します。しかも、これらのフェーズは単純に足し算すればよいわけではなく、それぞれの工程内にも複数のステップが入れ子になっているため、全体像を把握しないままスケジュールを引くと、あとから「想定より数ヶ月長くかかった」という事態に陥りがちです。とくに現行のベンダーとの契約が満了に近づいているのに、次のベンダー選定に着手するタイミングを見誤り、契約の空白期間が生じてしまうというトラブルは実務でも珍しくありません。システム運用保守の切り替えや新規立ち上げは、思っている以上に長いリードタイムを要するプロジェクトであり、社内の予算稟議や決裁のスケジュールとあわせて逆算しておかないと、いざ本番稼働を迎える直前になって体制が整わないという事態にもなりかねません。

本記事では、システム運用保守を外部委託する際の全体スケジュールを、ベンダー選定プロセスから契約締結、引き継ぎ・体制構築までのフェーズごとに分解して解説します。あわせて、運用開始後に発生する保守改修（改良開発）の工期の考え方、そして納期やスケジュールを左右する具体的なリスク要因についても整理しました。これから運用保守の委託先を探す方はもちろん、既存ベンダーからの切り替えや契約更新のタイミングを検討している方にとっても、実務に直結する判断材料となる内容です。最後までお読みいただくことで、余裕を持ったスケジュール設計ができるようになるはずです。とくに複数部門が関わる大規模システムほど、社内調整だけでもリードタイムが必要になるため、早め早めの着手が結果的に全体のスケジュールを守ることにつながります。

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

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

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

システム運用保守を外部委託する場合、要件定義からベンダー選定・契約締結までに約4〜6ヶ月、契約後の引き継ぎ・体制構築から運用開始までに約2ヶ月（8週間）を要し、全体で約6〜8ヶ月の期間を見込むのが標準的なスケジュール感です。新規開発のスケジュールに比べると地味に感じられるかもしれませんが、「誰にどこまで任せるか」を見極めるベンダー選定と、既存システムの知識を安全に引き継ぐプロセスには、想像以上に丁寧な時間設計が必要になります。現行の運用保守契約が自動更新される仕組みになっている場合は、この6〜8ヶ月のリードタイムを踏まえて、現行契約満了の6ヶ月前には次のアクションを開始しておくべきだと考えておきましょう。

契約締結までの4〜6ヶ月は、大きく4つのステップに分解できます。最初のステップは要件定義で、現状のシステム構成や課題、求めるSLA（サービスレベル合意）の水準、予算、評価軸を整理します。ここには2〜4週間を見込みます。次にロングリスト作成のステップで、候補となるベンダーを10〜20社程度リストアップします。この段階は1〜2週間程度で完了させるのが一般的です。続いてRFI（情報提供依頼）のステップに入り、各社の基本情報や実績、対応可能な範囲を確認したうえで、5〜7社程度のショートリストへ絞り込みます。ここには3〜4週間ほどかかります。そしてRFP（提案依頼）のステップでは、ショートリストの各社に具体的な提案と見積もりを依頼し、最終候補となる2〜3社に絞り込みます。要件を正確に伝え、複数社から比較可能な提案を引き出す必要があるため、このRFPフェーズが最も時間のかかる工程となり、6〜8週間程度を見込んでおく必要があります。要件定義からRFPまでのこの一連の流れが、システム運用保守の委託先選定における「土台づくり」の期間です。

最終候補が2〜3社に絞られた後は、PoC（概念実証）や面談を通じて最後の1社を決定するフェーズに入ります。ここでは監視精度やヘルプデスクの応答品質を実際にテストしたり、実運用を担当する予定のエンジニアと直接面談したりすることで、提案書だけでは見えない実力を見極めます。このPoC・面談フェーズには4〜6週間を見込むのが一般的です。ベンダーが確定したら、契約締結のステップに移ります。SLA条項や免責事項、引き継ぎ計画などを契約書の文言に落とし込み、双方が合意するまでのプロセスには2〜4週間程度かかります。とくに引き継ぎ計画の記載は重要で、次のフェーズである運用立ち上げがスムーズに進むかどうかは、この契約段階でどこまで具体的な取り決めができているかに大きく左右されます。契約内容の法務レビューが社内で必須となっている企業の場合は、この期間にさらに1〜2週間程度の余裕を見込んでおくと安全です。とくに委託範囲や損害賠償の条項を巡って調整が長引くことも珍しくないため、社内の法務担当者には早い段階から契約前提の共有をしておくことをおすすめします。要件定義からここまでの契約前フェーズを合計すると、おおむね4〜6ヶ月という期間になることを念頭に置いてスケジュールを組みましょう。

契約締結後は、実際に運用保守を開始するための立ち上げ・引き継ぎフェーズに入ります。品質を落とさずに新しい体制へ移行するためには、約2ヶ月（8週間）をかけた段階的なプロセスを踏むことが推奨されています。1〜2週目は、技術スタックの理解や環境へのアクセス確認、既存の設計書・運用マニュアルのレビューを通じて、システム全体像を把握する期間です。3〜4週目は、保守手順や監視・ログ確認方法、障害対応フローの理解に加えて、過去のトラブル事例を分析し、ドキュメント化されていない暗黙知を習得する期間にあてます。5〜6週目は、現行担当者の監督下で実際の保守作業や軽微な障害対応、デプロイ作業を経験する実務OJTの期間です。そして7〜8週目には、監督なしでの独立作業を行い、運用マニュアルの最新化と緊急連絡体制の最終確認を済ませたうえで、定常運用へと移行します。この8週間の引き継ぎプロセスを短縮しようとすると、暗黙知の移転が不十分なまま本番運用がスタートしてしまい、初期のトラブル対応で立ち往生するリスクが高まるため注意が必要です。

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

運用保守体制が立ち上がった後も、機能追加や仕様変更に伴う「保守改修（改良開発）」は継続的に発生します。この保守改修の工期は、新規開発の工期算定とは異なる考え方をする必要があり、見積もり時の思わぬ落とし穴になりやすいポイントです。ここでは、保守改修に特有の工期の考え方と、実務で使われる規模別の目安を整理します。

新規開発の場合、要件定義から設計・実装へと比較的まっすぐに工程が進みますが、保守改修では着手前に必ず「既存システムの調査・分析」という工程が挟まります。改修対象の機能がシステムのどこにどう実装されているか、変更によってほかの機能に影響が及ばないか（影響範囲の特定）を調べる作業です。この調査・分析には、作業全体の時間の約30%が費やされることがあると言われています。新規開発の見積もり感覚のまま保守改修のスケジュールを引いてしまうと、この調査工数を見落とし、着手直後から遅延が発生する原因になります。とくに、自社が開発を依頼していないベンダーに保守改修を依頼する場合や、開発から時間が経過して仕様の詳細を誰も正確に把握していない場合は、この調査フェーズがさらに長引く傾向があります。保守改修の見積もりを依頼する際は、実装作業そのものの工数だけでなく、この調査・分析フェーズの工数がどの程度見込まれているかを必ず確認するようにしましょう。

保守改修の規模から大まかな工期を予測する一般的なモデルとして、「工期 ＝ 2.0〜3.0 ×（工数の3乗根）」という計算式が用いられることがあります。たとえば改修に必要な工数が8人月と見積もられた場合、8の3乗根はちょうど2ですから、工期は2.0〜3.0×2＝4〜6ヶ月程度が目安になる、という考え方です。この式が示唆しているのは、工数を単純に人数で割って工期を短縮しようとしても、実際には人を増やせば増やすほど工期が比例して縮むわけではないという実務上の感覚です。改修の影響範囲を正しく共有するためのコミュニケーションコストや、複数人が同じコードベースを触ることによる調整コストが発生するため、工数と工期の関係は直線的ではなく、この3乗根に近い形になりやすいのです。もちろんこれはあくまで目安の計算式であり、実際の工期はシステムの複雑さや体制によって変動しますが、「人を投入すれば工期はいくらでも短縮できる」という誤解を避けるための参考値として押さえておくと、発注時のスケジュール交渉に役立ちます。ベンダーから提示された見積工期がこの目安から大きく外れている場合は、テスト工程や既存システムの調査工数がどのように積算されているかを個別に確認し、根拠を明らかにしてもらうことをおすすめします。

保守改修の対応スピードは、自社に開発機能を持つ内製体制か、外部ベンダーへの委託かによっても大きく変わります。内製の場合は、既存システムの仕様を熟知したエンジニアが社内にいるため、前述の「既存システム調査」の工数を大幅に圧縮でき、小規模な改修であれば数日〜数週間で対応できるケースもあります。一方、外部ベンダーへ都度依頼する形態では、改修要件の伝達から見積もり取得、契約手続きを経てようやく着手となるため、内製に比べてリードタイムが長くなりがちです。とくに保守契約の範囲外の追加開発として扱われる場合は、別途見積もりと発注のプロセスを踏む必要があり、着手までに数週間を要することも珍しくありません。この対応スピードの差を踏まえ、頻繁に発生する軽微な改修は月額固定の保守契約の範囲に含めてもらう、あるいは準委任契約でエンジニアの稼働時間をあらかじめ確保しておくといった契約形態の工夫によって、改修対応のスピードを高めることができます。改修の発生頻度と緊急度を事前に見積もったうえで、自社に合った契約形態を選ぶことが、保守改修のスケジュールを安定させる鍵となります。改修依頼から着手までのリードタイムをSLAの一項目として明文化しておくベンダーも増えており、契約段階で「軽微な改修は5営業日以内に着手する」といった基準を合意しておくと、発注のたびに交渉するコストを省くことができます。

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

ここまで見てきたベンダー選定・引き継ぎ・保守改修のスケジュールは、いずれも一定の前提条件のもとでの目安にすぎません。実際のプロジェクトでは、いくつかの要因によってスケジュールが大きく遅延することがあります。ここでは、システム運用保守の納期・スケジュールに影響を与える代表的な5つのリスク要因を整理し、それぞれへの実務的な対策を解説します。

最も大きな遅延要因となるのが、設計書や運用マニュアルの整備状況です。ドキュメントが存在しない、あるいはソースコードと内容がアンマッチを起こしている場合、担当者はコードそのものを読み解いて仕様を推測する「リバースエンジニアリング」的な作業に膨大な時間を費やすことになり、引き継ぎや改修作業が大幅に遅延します。また、システムのつくり（モジュール化の度合い）やデータ構造が複雑であるほど、この理解に要する時間はさらに伸びます。対策としては、運用保守の契約を結ぶ前の段階で、既存ドキュメントの有無と最新性を棚卸しし、不足があれば引き継ぎ期間中にドキュメント整備のタスクを明示的に組み込んでおくことが有効です。ドキュメントの整備状況を軽視したまま楽観的なスケジュールを組んでしまうと、後になって大幅な見直しを迫られることになります。可能であれば、契約締結前のPoCや面談の段階で設計書の一部を実際に見せてもらい、記載の粒度や更新頻度を確認しておくと、引き継ぎフェーズにかかる期間をより精度高く見積もることができます。

2つ目の要因は、既存システムへの習熟度です。ベンダーや担当者がシステムをどれだけ熟知しているかによって生産性は大きく変動し、ドキュメント化されていない暗黙知をOJTや過去事例の分析で適切に引き継げない場合、トラブル発生時の対応が遅れます。3つ目は変更箇所の分散度・結合度です。ある機能の修正が共通ライブラリなどに影響を及ぼし、変更箇所がシステム全体に分散している場合、調査作業が多岐にわたるうえ、機能低下（デグレード）が起きていないかを確認するためのリグレッションテストの範囲が膨らみ、テスト工数が跳ね上がります。4つ目は既存システムの正確性、つまり残存バグの多さです。引き継ぎ中や改修時のテストで既存の不具合が頻発すると、その原因調査や手戻りに工数を奪われ、スケジュール全体の遅延を招きます。これら3つの要因はいずれも、契約前のヒアリングや初期の引き継ぎフェーズでどこまで実態を把握できるかによってリスクの大きさが変わってくるため、可能な限り早い段階で現行システムの状態を確認しておくことが重要です。

5つ目の要因は、テスト環境とテストデータの再利用性です。本番環境に近いテスト環境が用意されているか、過去のテストケースやテストデータを流用できるかどうかは、テスト工程の効率と納期に直結します。テスト環境をその都度ゼロから構築しなければならない状況では、改修のたびに準備コストがかさみ、スケジュールを圧迫します。これら5つのリスク要因に共通する実務的な対策は、「見えないリスクを契約前に可視化する」ことです。具体的には、ベンダー選定のRFPフェーズや契約前のPoCの段階で、既存ドキュメントのサンプル提示を求める、テスト環境の有無を確認する、過去の障害対応履歴を共有してもらうといった働きかけを行い、リスクの大きさをあらかじめ把握しておきます。そのうえで、見積もりスケジュールには一定のバッファ（余裕期間）を確保しておくことが、システム運用保守におけるスケジュール遅延を最小限に抑えるための現実的なアプローチです。目安としては、全体スケジュールの15〜20%程度をバッファとして確保しておくと、想定外の調査や手戻りが発生した場合でも、本番運用の開始日を大きくずらさずに対応できる余地が生まれます。

まとめ

本記事では、システム運用保守を外部委託する際の開発期間・スケジュール・納期について、ベンダー選定プロセスから保守改修の工期、遅延リスクまでを体系的に解説しました。運用保守の委託先を選定し契約締結までこぎつけるには約4〜6ヶ月、その後の引き継ぎ・体制構築には約2ヶ月（8週間）を要し、全体で6〜8ヶ月というリードタイムを見込んでおく必要があります。現行契約の満了が近づいている場合は、この期間を逆算して6ヶ月前にはアクションを開始することが望ましいでしょう。また、運用開始後に発生する保守改修は、既存システムの調査・分析に工数の約30%を要するなど新規開発とは異なる工期の考え方が求められ、「工期＝2.0〜3.0×工数の3乗根」という計算式も参考になります。さらに、ドキュメントの整備状況やシステムへの習熟度、変更箇所の分散度、残存バグ、テスト環境の再利用性といった要因が、スケジュールを大きく左右します。これらのリスクを契約前の段階でできる限り可視化し、一定のバッファを確保したスケジュールを組むことが、システム運用保守を安定してスタートさせるための最大のポイントです。運用保守の委託や切り替えを検討されている方は、まず現行システムの棚卸しから始め、余裕を持ったスケジュールで信頼できるパートナーを探すことをお勧めします。スケジュールの精度は、初期段階でどれだけ正確に現状を把握できたかに比例するという点を、あらためて意識しておきましょう。契約更新のタイミングが近い場合はとくに、逆算したスケジュールを早めに社内で共有し、決裁や予算確保のプロセスも並行して進めておくことが、計画通りの運用開始を実現する近道となるでしょう。

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

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