ソフトウェア運用保守を外部に委託すると、全体で約6〜8ヶ月で運用を開始できます。委託先の選定と契約に約4〜6ヶ月、契約後の引き継ぎに約2ヶ月（8週間）かかります。
契約形態による納期の違い、保守改修の工期、遅延の要因も取り上げます。全体像は完全ガイドもご覧ください。
▼全体ガイドの記事
・ソフトウェア運用保守の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
ソフトウェア運用保守を外部委託する際の全体スケジュール
標準的な全体期間は約6〜8ヶ月です。要件定義から委託先の選定・契約まで約4〜6ヶ月かかり、そのあと契約後の引き継ぎと体制構築に約2ヶ月（8週間）をかけて運用を開始します。
委託先の選定では、誰にどこまで任せるかを見極める必要があります。さらに、既存ソースコードや運用ノウハウの引き継ぎにも、丁寧な時間設計が欠かせません。なお、現行契約が自動更新される場合は、満了の6ヶ月前には次の準備を始めましょう。
契約前フェーズ：要件定義〜RFI〜RFPの流れ（4〜6ヶ月）
契約までの4〜6ヶ月は、要件定義からRFPまでの選定に充てます。選定は次の4つの段階で進み、各段階で候補を絞りながら、比較できる提案を揃えていきます。
- 要件定義で、発注側の条件を整理する
- 候補をロングリストにまとめる
- RFIで情報を集め、候補を絞り込む
- RFPで提案と見積もりを比べる
要件定義では、現状のソフトウェア構成、対象アプリケーションの範囲、求めるSLA（サービスレベル合意）の水準を整理します。あわせて予算と評価軸を決め、2〜4週間を見込みます。
ロングリストでは、候補を10〜20社程度挙げます。次にRFI（情報提供依頼）で、基本情報、実績、対応可能な技術領域を確認し、5〜7社程度に絞ります。この段階には3〜4週間ほどかかります。
RFP（提案依頼）では、候補各社に具体的な提案と見積もりを求めます。技術要件を正確に伝えて比べられる提案を受け取り、最終候補を2〜3社に絞ります。
RFPは選定のなかで最も時間がかかる工程で、各社の提案準備に6〜8週間程度を見込みます。要件定義からRFPまでの一連の工程が、委託先選定の土台になります。
PoC・面談から契約締結までの最終選定プロセス
最終候補が2〜3社に絞れたら、PoC（概念実証）と面談で1社に決めます。提案書だけでは見えない部分を、この段階で確かめるためです。
- PoC：試験的な依頼で実務能力を確かめる
- 面談：保守担当予定のエンジニアと直接話す
- 契約：条件を合意して締結する
PoCでは、問い合わせ対応や小規模な改修を試し、コードを読む力と対応品質を見極めます。PoCと面談には6〜10週間を見込みます。
契約書には、SLA条項や免責事項、引き継ぎ計画を記載します。特に、具体的な引き継ぎ計画が、次の運用立ち上げを左右します。
なお、社内で法務レビューが必須なら、さらに1〜2週間程度の余裕を見込んでおくとよいでしょう。要件定義から契約締結までは、おおむね4〜6ヶ月です。
引き継ぎ・体制構築の8週間ステップ
契約後は、品質を保ったまま新体制へ移れるよう、約2ヶ月（8週間）かけて段階的に引き継ぎます。
- 1〜2週目：技術と環境の把握
- 3〜4週目：保守手順と不具合対応の理解
- 5〜6週目：監督下での保守作業の経験
- 7〜8週目：独立作業と最終確認
1〜2週目は、技術スタックや開発・実行環境へのアクセスを確認したうえで、既存の設計書と仕様書をレビューします。
3〜4週目は、過去のトラブルを分析して、文書になっていない暗黙知も身につけます。
5〜6週目は、現行担当者の監督のもとで、実際の保守作業や軽微な不具合対応、リリース作業を経験します。
7〜8週目は、監督なしで作業します。そのうえで、運用マニュアルを更新し、緊急連絡体制を確認してから定常運用へ移ります。
期間を短縮すると、ソースコードの暗黙知を十分に移せないまま本番運用が始まり、初期トラブルへの対応が滞るリスクがあります。
契約形態（準委任・請負・SLA）で変わる納期の捉え方
運用保守の納期は、新規開発の納期とは意味が異なります。業務は、継続サービスとして提供するものと、成果物を伴う作業とに分かれるため、契約形態ごとに納期の捉え方も変わります。
業務に合う契約形態を選ぶことが大切です。契約を誤ると、納期が努力目標にとどまったり、仕様変更で追加費用や期間延長が生じたりすることがあります。準委任、請負、SLAの3つから、それぞれの納期の捉え方を見ていきます。
準委任契約：継続的なサービス提供と納期の柔軟性
準委任契約は、作業量やゴールを事前に見積もりきれない継続業務に向いています。成果物の完成を保証する契約ではないため、作業の完了期限が厳格に定まらず、対応が多少遅れても契約上は免責される場合があります。
- 対象業務：障害調査、問い合わせ、定期監視、コードレビュー助言
- 約束の中心：稼働時間や体制の確保
- 管理項目：対応時間帯、稼働工数、エスカレーション
こうした業務を請負に当てはめると、想定外の作業ごとに追加見積もりが必要となり、対応が遅れる場合があります。そのため、発注側は、納期の日付よりも先に、上の管理項目の取り決めを明確にします。実務上の予定は、その取り決めをもとに組み立てます。
請負契約：成果物の完成と納期を約束する代わりの制約
請負契約は、機能追加や改修など、成果物を明確に定義できる作業に適しています。仕事の完成と納期を約束する契約です。
- 利点：「いつまでに、どの機能をリリースするか」が明確
- 制約：途中の仕様変更で追加費用や期間延長が起こりやすい
また、日常的な保守や問い合わせは準委任で担い、大きな機能追加や改修を請負として切り出す組み合わせも多く見られます。
請負の納期を守るためには、発注側が着手前に要件を具体化し、開発中の仕様変更をむやみに加えないことも欠かせません。
SLAが実質的な「納期」として機能する仕組み
SLA（サービス水準合意）は、事象への対応時間を定めることで、実質的な納期や業務予定の基準になります。
- 通知：障害発生後30分以内
- 初報：応答時間を2時間以内に設定
- 復旧：障害発生後6時間以内
準委任や請負は、個々の作業の完了時期を扱います。一方で、SLAは事象が起きるたびの対応速度を扱います。
対応時間は、業務の重要度に応じて段階的に設定されます。たとえば、重大障害には短い応答・復旧時間を、軽微な不具合には比較的余裕のある時間を割り当てます。
選定の際は、対応時間が事業の要件に合うかを確認します。あわせて、SLA未達時のペナルティや報告義務も確かめておきます。
保守改修（改良開発）に特有の工期の考え方
運用開始後も、機能追加や仕様変更に伴う保守改修（改良開発）は続きます。そのため、工期の見積もりには新規開発とは異なる考え方が必要です。実務では、規模別の目安を工期と工数で示すこともあります。
既存ソースコードの調査・分析に工数の30%を要する理由
保守改修では、実装の前に既存システムの調査・分析（現行理解）が欠かせません。調査には、改修全体の時間の約30%が費やされることがあります。
- 実装箇所：対象機能がソースコードのどこにあるか調べる
- 影響範囲：変更がほかの機能に及ぼす影響を特定する
- 見積もり：調査工数を実装工数と分けて確認する
開発から時間が経って仕様を正確に把握する人がいない場合や、別の委託先に依頼する場合は、調査が長引く傾向があります。
新規開発の感覚で日程を組むと、調査工数を見落とし、着手直後の遅延につながります。
規模から工期を予測する計算式（2.0〜3.0×工数の3乗根）
規模から工期を予測するモデルに、「工期＝2.0〜3.0×（工数の3乗根）」があります。COCOMO法などで用いられることがあります。
- 計算の目安：工数から大まかな工期を見積もる
- 読み取れること：人員を増やしても工期は比例して縮まらない
- 使い方：発注時のスケジュール交渉の参考にする
8人月の3乗根は2です。この値を式に当てはめると、2.0〜3.0×2＝4〜6ヶ月程度が目安になります。
影響範囲の共有や、複数人で同じコードを扱う調整にはコストがかかるため、工数と工期は直線的な関係になりません。この式はあくまで目安で、実際の工期はソフトウェアの複雑さや体制で変わります。
小規模開発・保守の目安基準（工期3ヶ月以内・工数1000時間以下）
ある企業の生産管理基準では、工期3ヶ月以内かつ工数1000時間以下の開発を「小規模開発」とする事例があります。同じ基準では、工数1000時間以下の保守を「小規模保守（改造）」と定義しています。
- 社内運用：小・中・大規模を共通の基準で分類する
- 契約範囲：小規模保守を月額契約に含めるかどうか
この基準をそのまま自社に当てはめる必要はありません。ただし、社内で工期の目安を共有しておくと、委託先との見積もりのすり合わせに役立ちます。
この区切りは契約時に決めておきます。線引きが曖昧だと、範囲の調整で着手が遅れる原因になります。
納期・スケジュールを左右するリスク要因と実務対策
選定、引き継ぎ、保守改修の期間は、一定の前提に基づく目安です。実際には、複数の要因が重なってスケジュールが遅れることがあります。代表的な要因は、ドキュメントの整備状況、変更箇所の分散度・結合度、テスト環境の再利用性の3つで、いずれも契約前の確認と、引き継ぎや準備の計画で手を打てます。
ドキュメント整備状況とソースコードの理解容易性
設計書や仕様書の整備状況は、大きな遅延要因になります。資料がない、あるいは資料がコードと合わない場合は、仕様をコードから推測するリバースエンジニアリングに近い作業に追われ、引き継ぎや改修が遅れます。
- 事前確認：既存ドキュメントの有無と最新性を洗い出す
- 引き継ぎ：不足している資料の整備を作業として組み込む
- 契約前：PoCや面談で設計書の粒度と更新頻度を見る
モジュール化やデータ構造が複雑だと、理解に時間がかかります。設計書の状態を踏まえておくと、引き継ぎ期間の見積もり精度を高められます。
変更箇所の分散度・結合度と既存ソフトウェアの品質
委託先や担当者がどれだけシステムを熟知しているかで、生産性は大きく変わります。
- 習熟度：担当者の理解不足や暗黙知の移転不足で対応が遅れる
- 変更範囲：結合度が高いと調査と回帰テストが増える
- 残存バグ：原因調査や手戻りで全体の日程が後ろへずれる
変更が共通モジュールに及ぶと、機能低下（デグレード）を防ぐリグレッションテストの範囲が広がり、テスト工数が増えます。また、引き継ぎ中や改修時のテストで既存の不具合が頻発すると、確認作業が増えて日程が読みにくくなります。
契約前のヒアリングや初期引き継ぎで、現行の状態を確認しておくとよいでしょう。
テスト環境の再利用性とバッファ確保という現実解
テスト環境やテストデータを再利用できるかは、テストの効率と納期に直結します。そのため、準備の状況を事前に確認しておきます。
- 環境：本番に近いテスト環境があるかを見る
- テスト資産：過去のケースやデータを流用できるか調べる
環境を毎回ゼロから構築すると、準備コストが増えます。また、実データを使う場合は、実施時間帯やリソースが限られ、期間が延びることがあります。
共通する対策は、見えないリスクを契約前に洗い出しておくことです。RFPやPoCの段階で、資料、テスト環境、過去の不具合対応の履歴を確かめます。
見積もりの日程には、全体の15〜20%程度のバッファを確保しておきます。遅延を最小限に抑えるための、現実的な方法です。
まとめ
委託先の選定、契約形態ごとの納期、保守改修の工期、遅延リスクを順に見てきました。選定と契約に約4〜6ヶ月、引き継ぎに約2ヶ月（8週間）かかり、運用開始まで全体で約6〜8ヶ月です。
準委任は継続的なサービス提供、請負は明確な成果物と納期、SLAは日々の対応速度を扱います。業務の性質に合わせて、契約を使い分けます。
保守改修は、調査・分析に工数の約30%を要する場合があります。工期は「2.0〜3.0×工数の3乗根」で見る方法があります。
目安の事例には、工期3ヶ月以内かつ工数1000時間以下の小規模開発があります。小規模保守は、工数1000時間以下とする基準です。
ドキュメント、習熟度、変更範囲、残存バグ、テスト環境が日程に影響します。契約前に状態を確認し、全体の15〜20%程度の余裕を持つと、安定した運用開始に役立ちます。
委託や切り替えを検討する際は、まず現行ソフトウェアの状態を洗い出し、余裕のある日程で委託先を探します。契約更新が近い場合は、逆算した予定を社内で早めに共有し、決裁と予算確保も並行して進めておくとよいでしょう。
▼全体ガイドの記事
・ソフトウェア運用保守の完全ガイド
▼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を創業。