ソフトウェア運用保守の開発期間・スケジュール・納期について

ソフトウェアの運用保守を外部に委託しよう、あるいは既存の委託先を見直そうとするとき、発注担当者が真っ先に気にするのが「どれくらいの期間を見ておけばよいのか」という開発期間・スケジュール・納期の問題です。新規にソフトウェアを開発する場合であれば、要件定義から納品までを一本のラインで積み上げていく感覚を持ちやすいのですが、運用保守の場合はそうはいきません。「委託先を選ぶ期間」「契約を締結する期間」「実際に引き継いでソフトウェアの保守運用を開始する期間」という、新規開発とは性質の異なる複数のフェーズが積み重なっており、さらに運用開始後も機能追加や不具合修正といった保守改修（改良開発）が継続的に発生し続けます。現行の委託先との契約満了が近づいているのに、次の選定に着手するタイミングを見誤り、契約の空白期間が生じてしまうというトラブルも実務では珍しくありません。

本記事では、ソフトウェア運用保守を外部委託する際の全体スケジュールを、委託先選定プロセスから契約締結、引き継ぎ・体制構築までのフェーズごとに分解して解説します。あわせて、準委任・請負・SLAという契約形態によって「納期」の意味合いがどう変わるのか、運用開始後に発生する保守改修に特有の工期の考え方、そして納期やスケジュールを左右する具体的なリスク要因についても整理しました。これから運用保守の委託先を探す方はもちろん、既存の契約更新や切り替えのタイミングを検討している方にとっても、実務に直結する判断材料となる内容です。最後までお読みいただくことで、余裕を持ったスケジュール設計と、契約形態に応じた納期の見極め方が身に付くはずです。

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

▼全体ガイドの記事
・ソフトウェア運用保守の完全ガイド

ソフトウェア運用保守を外部委託する際の全体スケジュール

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

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

最終候補が2〜3社に絞られた後は、PoC（概念実証）や面談を通じて最後の1社を決定するフェーズに入ります。実際の問い合わせ対応やちょっとした改修依頼を試験的に依頼してコードの読解力や対応品質を見極めたり、保守担当予定のエンジニアと直接面談したりすることで、提案書だけでは見えない実力を確認します。このPoC・面談フェーズには6〜10週間を見込むのが一般的です。委託先が確定したら契約締結のステップに移り、SLA条項や免責事項、引き継ぎ計画などを契約書の文言に落とし込みます。とくに引き継ぎ計画の記載は重要で、次のフェーズである運用立ち上げがスムーズに進むかどうかは、この契約段階でどこまで具体的な取り決めができているかに大きく左右されます。法務レビューが社内で必須の企業は、この期間にさらに1〜2週間程度の余裕を見込むと安全です。要件定義からここまでを合計すると、おおむね4〜6ヶ月という期間になることを念頭に置いてスケジュールを組みましょう。

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

契約形態（準委任・請負・SLA）で変わる納期の捉え方

ソフトウェア運用保守における「納期」は、新規開発における納期とは意味合いが異なります。運用保守の業務内容は、障害調査や問い合わせ対応のような継続的なサービス提供と、機能追加・改修のような明確な成果物を伴う作業に分かれており、どちらの性質に近いかによって適した契約形態が変わります。契約形態の選び方を誤ると、「納期は努力目標にすぎなかった」「柔軟に仕様変更したかったのに追加費用や期間延長を求められた」といったミスマッチが起こります。ここでは、準委任契約・請負契約・SLAの3つの切り口から納期の考え方を整理します。

準委任契約は、障害調査や問い合わせ対応、定期的な監視、コードレビューへの助言など、継続的なサービス提供に向く契約形態です。成果物の完成そのものを保証する契約ではないため、「作業の完了期限（納期）」が厳格に定められないことが多く、対応が多少遅れても契約上は免責されるケースがあります。ソフトウェア運用保守では、日々発生する軽微な不具合調査や、仕様に関する問い合わせ対応のように、あらかじめ作業量やゴールを完全には見積もれない業務が多く存在します。こうした業務を無理に請負契約の枠にはめようとすると、想定外の作業が発生するたびに追加見積もりが必要になり、かえって対応が遅くなることがあります。準委任契約のもとでは、稼働時間や体制の確保が中心的な約束事となるため、発注側は「納期」ではなく「対応時間帯」「稼働工数」「エスカレーションのルール」を明確にしておくことが、実務上のスケジュール管理の要になります。

一方、請負契約は機能の追加や改修など、明確な成果物が定義できる作業に向く契約形態です。仕事の完成と納期を約束するため、「いつまでに、どの機能がリリースされるか」というスケジュールが明確になり、発注側としては予算とスケジュールの見通しを立てやすいメリットがあります。ただし、請負契約は成果物とその完成期限をあらかじめ固定する性質上、途中の仕様変更には対応しにくく、追加費用や期間延長が発生しやすいという特徴があります。ソフトウェア運用保守の文脈では、機能追加や大きめの改修案件を請負契約として切り出し、日常的な保守・問い合わせ対応は準委任契約でカバーするというハイブリッドな契約形態を組むケースが多く見られます。請負契約で納期を確実に守ってもらうためには、着手前の要件定義をできる限り具体化し、開発途中での仕様変更をむやみに持ち込まないという発注側の規律も同時に求められます。

ソフトウェア運用保守においては、SLA（サービス水準合意）で定める数値が、実質的な「納期」や「スケジュール基準」として機能します。たとえば「障害発生後の通知は30分以内」「初報応答時間は2時間以内」「障害復旧は6時間以内」といった対応時間があらかじめ規定され、これらの基準に基づいて日々の業務スケジュールが組み立てられます。準委任契約や請負契約が「一つの作業がいつ完了するか」を定めるのに対し、SLAは「発生した事象に対して、どの時間軸で反応すべきか」という繰り返し発生する業務の速度基準を定める点が特徴です。SLAの数値は業務の重要度によって段階的に設定されることが多く、事業に致命的な影響を及ぼす重大障害には短い応答・復旧時間、軽微な不具合には比較的余裕を持った対応時間を割り当てるのが実務的な設計です。委託先を選定する際は、この対応時間の水準が自社の事業要件に見合っているか、SLA未達時のペナルティや報告義務がどう定められているかまで確認しておくことが、「納期」を実質的に守らせる重要なポイントです。

保守改修（改良開発）に特有の工期の考え方

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

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

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

保守改修の規模を判断する目安として、ある企業の生産管理基準では「工期3ヶ月以内、かつ工数1000時間以下」の開発を「小規模開発」とし、「工数1000時間以下」の保守を「小規模保守（改造）」と定義して管理している事例があります。この基準をそのまま自社に当てはめる必要はありませんが、日々発生する保守改修の依頼を「小規模」「中規模」「大規模」といった社内共通の物差しで分類し、おおまかな工期の目安を持っておくことは、委託先との見積もりのすり合わせをスムーズにするうえで有効です。とくに小規模保守と位置づけられる案件であれば、月額の保守契約の範囲内で対応してもらえるのか、それとも別途見積もりが必要な追加開発として扱われるのかを、契約段階で線引きしておくことをおすすめします。この線引きが曖昧だと、いざ改修が必要になったときに範囲をめぐる調整が発生し、着手までのリードタイムが延びる原因になります。

納期・スケジュールを左右するリスク要因と実務対策

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

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

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

5つ目の要因は、テスト環境とテストデータの再利用性です。本番環境に近いテスト環境が用意されているか、過去のテストケースやテストデータを流用できるかどうかは、テスト工程の効率と納期に直結します。テスト環境をその都度ゼロから構築しなければならない状況では、改修のたびに準備コストがかさみ、スケジュールを圧迫します。また、実データを使用する場合はテスト実施の時間帯やリソースに制限がかかり、期間が延びることもあります。これら一連のリスク要因に共通する対策は、「見えないリスクを契約前に可視化する」ことです。委託先選定のRFPフェーズや契約前のPoCの段階で、既存ドキュメントのサンプル提示や、テスト環境の有無、過去の不具合対応履歴の共有を求め、リスクの大きさをあらかじめ把握しておきます。そのうえで、見積もりスケジュールには全体の15〜20%程度をバッファとして確保しておくことが、スケジュール遅延を最小限に抑える現実的なアプローチです。

まとめ

本記事では、ソフトウェア運用保守の開発期間・スケジュール・納期について、委託先選定プロセスから契約形態ごとの納期の考え方、保守改修の工期、遅延リスクまでを体系的に解説しました。運用保守の委託先を選定し契約締結までこぎつけるには約4〜6ヶ月、その後の引き継ぎ・体制構築には約2ヶ月（8週間）を要し、全体で6〜8ヶ月というリードタイムを見込んでおく必要があります。契約形態については、継続的なサービス提供に向く準委任契約、明確な成果物と納期を約束する請負契約、日々の対応速度を規定するSLAという3つの性質の違いを理解し使い分けることが実務上の要点です。また、保守改修は既存ソースコードの調査・分析に工数の約30%を要するなど新規開発とは異なる工期の考え方が求められ、「工期＝2.0〜3.0×工数の3乗根」という計算式や「工期3ヶ月以内・工数1000時間以下」という小規模開発の目安基準も参考になります。さらに、ドキュメントの整備状況やソフトウェアへの習熟度、変更箇所の分散度、残存バグ、テスト環境の再利用性といった要因がスケジュールを大きく左右します。これらのリスクを契約前にできる限り可視化し、一定のバッファを確保したスケジュールを組むことが、安定してスタートさせる最大のポイントです。運用保守の委託や切り替えを検討されている方は、まず現行ソフトウェアの棚卸しから始め、余裕を持ったスケジュールで信頼できるパートナーを探すことをお勧めします。契約更新が近い場合はとくに、逆算したスケジュールを早めに社内で共有し、決裁や予算確保のプロセスも並行して進めておくことが、計画通りの運用開始を実現する近道です。

▼全体ガイドの記事
・ソフトウェア運用保守の完全ガイド

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