こんにちは、LIGのシステム開発部門でPM（プロジェクトマネージャー）を兼務している鎌です。
「自社で運用してきたWebサイトやシステムを外部に委託したいけれど、どうやって引き継げばいいのか分からない」
そんな悩みを抱えている企業のWeb担当者やPMの方は多いのではないでしょうか？ 実際に求人マッチングサイトを運営するある企業様では、社内体制で運用を続けてきたものの、他案件の増加により外部パートナーへの委託を検討されていました。
しかし「現在の品質を維持しながらスムーズに移行できるのか」という不安から、なかなか踏み切れずにいたそうです。
運用保守の外部委託において最も重要なのが「引き継ぎ期間」の設計です。
短すぎると委託先がシステムを十分に理解できず障害対応で混乱しますし、長すぎるとコストが膨らみ現行担当者の負担も長期化してしまいます。
今回は、実際の支援事例をもとに、品質を落とさずに運用保守を外部委託するための2ヶ月引き継ぎプロセスを解説します。
目次
なぜ運用保守の引き継ぎには2ヶ月必要なのか
「なぜ2ヶ月も必要なの？」と感じる方もいるかもしれません。
一般的に、Webシステムの運用保守を外部委託する際、1ヶ月程度の短期引き継ぎを計画する企業も少なくありません。しかし経験上、これでは以下のような問題が発生します。
- システム全体像の理解が不十分：技術スタック、インフラ構成、既存の障害対応フローなどを把握しきれない
- 暗黙知の移転ができない：ドキュメント化されていない運用ノウハウや過去のトラブル事例を学ぶ時間がない
- 独立作業への移行が急：監督下でのOJTが不足し、いきなり独立対応を求められてミスが発生しやすい
ある企業様のケースでは複数の技術スタックが混在し、仕様が複雑化していました。このような環境では、各技術の理解だけでなく、それらがどう連携しているかの全体像を把握することが必要不可欠です。
そこで私たちは、システムの複雑さと必要な学習内容を考慮して、8週間（約2ヶ月）の段階的な引き継ぎプロセスを提案しました。
引き継ぎプロセスの全体像
2ヶ月の引き継ぎプロセスは、4つのステップで進めていきます。
| 期間 | 実施内容 |
|---|---|
| 1-2週目 | システム全体像の把握 |
| 3-4週目 | 保守運用業務の習得 |
| 5-6週目 | 実務OJT（共同対応） |
| 7-8週目 | 独立運用準備 |
それぞれのステップを詳しく見ていきましょう。
ステップ1：システム全体像の把握（1-2週目）
引き継ぎの最初の2週間は、「システムとは何か」を理解する期間です。
主な実施内容
- システム概要の説明：サービスの目的や主要機能、ユーザー層を把握する
- 技術スタックの把握：インフラ、フロントエンド、バックエンドの技術スタックを理解する
- 環境構築：開発環境・ステージング環境・本番環境へのアクセス設定と動作確認を行う
- 既存ドキュメントのレビュー：システム設計書や運用マニュアル、過去の障害対応履歴を確認する
このフェーズでは、委託先のリードエンジニアが中心となって、現行担当者からの説明を受けながら全体像を把握していきます。
ポイント：既存ドキュメントの精度は事前に確認しておこう
ドキュメントが充実していれば計画通りに進みますが、不足している場合は追加のヒアリングやコード解析に時間がかかります。
提案段階で「既存ドキュメントの有無や精度により作業超過が見込まれる場合は週次定例等にて報告・相談のうえ、時間単位での精算となる」という条件を設定し、柔軟な対応を可能にしていました。
ステップ2：保守運用業務の習得（3-4週目）
システムの全体像が理解できたら、次は日常的な保守運用業務を学ぶフェーズです。
主な実施内容
- 保守手順の習得：定期メンテナンスやアップデート作業、バックアップ確認などの手順書に沿った作業を習得する
- 監視・ログ確認方法：監視ツールの使い方や、異常検知時の対応フローを覚える
- 障害対応フローの理解：障害レベルの判定基準、エスカレーションルール、復旧手順を把握する
- 過去事例の分析：過去に発生した障害やトラブルの内容と対応方法を学ぶ
この段階では、実際の作業は現行担当者が行い、委託先メンバーは「見学」や「説明を受ける」ことが中心です。
ポイント：過去事例が、暗黙知の入り口になる
ドキュメントには書かれていない「あるあるトラブル」や「実は気をつけるべきポイント」は、過去事例の分析を通じて初めて見えてきます。
たとえば、「特定の時間帯にアクセスが集中してサーバー負荷が上がりやすい」「ユーザーからの問い合わせで多い誤操作パターンがある」といったプロジェクト特有の情報が、過去の障害対応履歴から明らかになりました。
ステップ3：実務OJT（共同対応）（5-6週目）
業務の流れが理解できたら、いよいよ実際に手を動かすOJTフェーズです！
主な実施内容
- 監督下での保守作業：現行担当者の監督のもと、委託先メンバーが実際の保守作業を担当する
- デプロイ実践：コードの修正からテスト、本番環境へのデプロイまでを一通り経験する
- 軽微な障害対応の実践：発生した軽微な障害に対して、現行担当者のサポートを受けながら対応にあたる
- 週次報告の実施：作業内容や気づいた点を週次定例で報告し、フィードバックをもらう
4つのステップの中でも、このフェーズが最も重要です。実際に手を動かすことで初めて出てくる疑問や不明点を、この段階で丁寧につぶしておきましょう。
ポイント：「分からない」と言える環境が、独立後のトラブルを防ぐ
OJTフェーズで欠かせないのが、委託先メンバーが安心して「分からないことを聞ける」環境づくりです。失敗を恐れて質問を控えてしまうと、独立後に大きなトラブルにつながりかねません。
週次定例などのミーティングでは「今週困ったこと」「理解が不十分だと感じる部分」を率直に共有し、現行担当者が丁寧にフォローする体制を構築していただくよう、協力要請をさせていただきます。
ステップ4：独立運用準備（7-8週目）
最後の2週間は、委託先が独立して運用できるかを検証する期間です。
主な実施内容
- 独立作業の実施：現行担当者の監督なしで、保守作業や軽微なトラブル対応にあたる
- ドキュメントの整備：引き継ぎを通じて得た知見や気づきを運用マニュアルに反映させる
- 引き継ぎ完了確認：チェックリストをもとに、すべての必要事項が習得できているかを確認する
- 緊急連絡体制の確認：独立後に重大な障害が発生した場合のエスカレーション先や連絡方法を確認する
この段階で、委託先メンバーが「監督なしで作業できる」「トラブル発生時に適切な初動対応ができる」というレベルに達していれば、引き継ぎは成功と言えます！
ポイント：「完了」の定義を最初から決めておこう
引き継ぎ完了の判断基準として、たとえば次のようなチェック項目が目安になります。
- 独立作業を監督なしで実施できるか
- トラブル発生時に一次対応（切り分け・報告）ができるか
- ドキュメントが最新化されているか
- 週次報告で重大な懸念事項が挙がっていないか
引き継ぎ成功のための3つのポイント
最後に、引き継ぎを成功させるためのポイントを3つ紹介します。
1. 適切な体制を確保する
引き継ぎには、委託先だけでなく現行担当者の協力が不可欠です。我々（委託先）はPM 0.25人月 + リードエンジニア 1.0人月の体制で引き継ぎを実施し、現行担当者（PM 1名、SE 2名）が週2日程度のサポートを提供する体制を構築しました。
2. 週次報告でPDCAを回す
引き継ぎ期間中は、週次定例で進捗状況や課題を共有しながら、必要に応じて計画を調整していくことが大切です。特に、既存ドキュメントの不足や想定外の技術的複雑さが判明した場合は、早めに認識して対応策を講じることで、大きな遅延を防ぐことができます。
3. 引き継ぎ後の体制も事前に設計する
引き継ぎが完了した後の運用保守体制についても、事前に描いておくと安心です。実際の事例では、引き継ぎ完了後は「運用保守（アプリケーション保守＝現行システムを守っていく活動）」「エンハンス（改善および追加機能の開発）」を同時に進められる体制に移行し、週次報告を継続しながらPDCAサイクルを回す計画が立てられました。
まとめ：段階的な引き継ぎで品質とコストのバランスを取ろう
運用保守の外部委託は、適切な引き継ぎプロセスを設計することで、品質を維持しながらスムーズに移行することが可能です。
今回ご紹介した2ヶ月・4ステップの引き継ぎプロセスは、システムの複雑さや既存ドキュメントの状況によって調整が必要ですが、基本的な考え方は共通しています。
- システム全体像の把握から始める
- 業務習得 → OJT → 独立準備と段階的に進める
- 週次報告でPDCAを回し、問題を早期発見する
- 現行担当者と委託先が協力する体制を作る
「自社のシステム保守を外部委託したいが、どう進めればいいか分からない」とお悩みでしたら、ぜひLIGにご相談ください！ 15年以上のWeb制作・システム開発の実績をもとに、貴社に最適な引き継ぎプロセスをご提案いたします。
