現在のシステム運用保守の外注先に不満を感じながらも、「乗り換えたとして本当にうまくいくのか」「引き継ぎで業務が止まったらどうしよう」という不安から、なかなか踏み切れていないという企業は少なくありません。
外注先への不満は「対応が遅い」「費用が高い割に改善が見えない」「担当者が変わるたびに話がリセットされる」など、多岐にわたります。しかし社内にシステムを詳しく見られるエンジニアがいない場合、乗り換えに向けた具体的な一歩を踏み出すことは難しく感じられます。
乗り換えを難しく感じる理由の多くは、「プロセスが見えない」ことにあります。判断基準・新外注先の選び方・現外注先との交渉・切り替えスケジュールの4点さえ把握できれば、乗り換えは決して難しい作業ではありません。
本記事では、システム運用保守の外注先を乗り換える際の判断基準から、候補会社の選び方、現外注先との解約・引き継ぎ交渉、切り替えスケジュールの設計まで、発注者が実際に動くための手順を順を追って解説します。
失敗しないためのシステム保守の引継ぎチェックリスト
この資料でわかること
システム保守会社の変更を検討中の方が、引継ぎ作業で見落としがちなポイントを網羅した実践的なチェックリストです。
こんな方におすすめです
- 現在の保守会社のサービスに不満を感じている方
- 保守会社の変更を検討しているが、何から始めればよいか分からない方
- 引継ぎ作業でトラブルを避けたい方
入力いただいたメールアドレスにPDFをお送りします。
乗り換えを検討すべき5つのサイン
外注先への漠然とした不満があっても、「これは乗り換えを検討すべき状況なのか」と迷う方は多いです。以下の5つのサインに2つ以上当てはまる場合は、乗り換えを本格的に検討する段階と考えてください。
対応品質・スピードが基準を満たしていない
障害発生時の初動対応が遅い、問い合わせへの回答が翌営業日以降になる、SLA（サービスレベルアグリーメント）で定めた対応時間を繰り返し超過するといった状況が続いている場合は、運用保守の品質として問題があります。
単発のミスは誰にでも起こりますが、「毎回遅い」「謝るだけで改善がない」という状況が3ヶ月以上続いている場合は、構造的な問題として捉えるべきです。
費用の根拠が説明されない
毎月の保守費用が「一式」でしか示されない、作業内容の内訳が不明、変更見積もりを依頼するたびに高額になるといった状況は、費用透明性の欠如を示しています。
システム運用保守費用の相場は、一般的に年間の開発費の10〜20%が目安とされています（詳しくはシステム保守費用の妥当性を見極める完全ガイドを参照）。この範囲から大きく外れている場合や、費用の根拠を尋ねても明確な回答が得られない場合は、見直しのサインです。
担当者が頻繁に変わりシステムがブラックボックス化している
担当者が変わるたびにシステムの理解が引き継がれず、「前の担当者に聞かないと分からない」「過去の経緯が残っていない」という状況が繰り返される場合は注意が必要です。
外注先が自社のシステムについての知識を文書化せず、「属人的な担当者依存」の状態に置いているとすれば、それは発注者にとってリスクです。担当者が退職・異動するたびに品質が下がる構造は、長期的に維持すべき関係ではありません。
自社システムの成長・変化に対応できていない
利用者数の増加に伴うスケールアップ対応、新しいAPIや認証方式への対応、セキュリティパッチの適用など、システムを取り巻く環境は常に変化します。
「今の状態を維持する」という保守にとどまり、「次のステップに向けた提案がない」「新技術への対応を提案してこない」という場合、自社の成長フェーズにそぐわない外注先である可能性があります。
改善提案がまったくない
良い外注先は、定期的な運用レビューの中で「この部分はこう改善できます」「セキュリティ的にここが気になります」という改善提案を自発的に行います。
契約期間中、一度も改善提案を受けたことがない、聞いても「今のままで問題ありません」としか言わない場合は、現状維持に甘んじているサインです。外注先は単なる「問題の処理係」ではなく、システムの健全な発展を共に考えるパートナーであるべきです。
乗り換え前に確認すべき「現状の整理」
乗り換えを決断する前に、現状を整理しておくことが重要です。この整理ができていないと、新しい外注先を選んでから「実は契約が1年縛りだった」「引き継ぎに必要なドキュメントが存在しない」といった問題が判明し、スケジュールが大幅にずれ込みます。
現在の契約書・SLAを読み返す
まず、現在の契約書を取り出して以下の点を確認してください。
- 最低契約期間と解約条件: 何ヶ月前に通知が必要か。中途解約の場合の違約金の有無
- 引き継ぎ義務: 契約終了時に外注先が行うべき引き継ぎ作業の範囲が定められているか
- 資産の帰属: ソースコード・ドキュメント・アカウント情報が「発注者の資産」として明記されているか
特に「引き継ぎ義務」が明記されていない場合は、乗り換え交渉の段階で話し合いが必要になります。事前に把握しておくことで、交渉の準備ができます。
自社が保有しているドキュメントを洗い出す
乗り換えを成功させるには、新しい外注先がシステムを理解するための情報が必要です。以下を確認し、何が手元にあって何が外注先にしかないかを把握してください。
- システム概要書・要件定義書
- サーバ構成図・ネットワーク図
- ソースコードのリポジトリ（GitHubなど）へのアクセス権
- データベース設計書
- アカウント・認証情報一覧（サーバ・各種サービス）
- 既知のバグ・運用上の注意点リスト
これらが「外注先の担当者の頭の中にしかない」状態では、乗り換えの難易度が上がります。現状確認の結果として「外注先に強く依存している」と判明した場合でも、把握しておくことで次のステップで適切に対処できます。
現外注先が保有している情報を特定する
「外注先にしかない情報」を洗い出し、乗り換え時に取り戻す必要がある情報をリスト化します。引き継ぎ交渉の際にこのリストを提示することで、漏れのない引き継ぎを依頼できます。
システム引き継ぎの方法・手順・費用ガイドも合わせて参照すると、引き継ぎで必要になる情報の全体像を把握しやすくなります。
新しい外注先を選ぶ5つの判断基準
新しい外注先を選ぶ際、「どこに頼めばいいか分からない」という悩みは多くの発注者が抱えます。以下の5つの判断基準を設定することで、非エンジニアの担当者でも候補会社を客観的に評価できます。
使用技術との適合性を確認する
現在のシステムが使用している技術スタック（プログラミング言語・フレームワーク・クラウドサービスなど）と、候補会社の得意領域が一致しているかを確認します。
候補会社の公式サイトの実績紹介や、問い合わせ時に「〇〇を使用したシステムの保守実績はありますか？」と直接尋ねることで確認できます。技術スタックが合わない会社に依頼すると、学習コストが発生し対応品質が下がりやすくなります。
保守移管・引き継ぎの実績を確認する
「他社が開発・保守していたシステムを引き継いだ経験があるか」は、乗り換えの文脈では特に重要な確認事項です。
引き継ぎを初めて経験する会社では、ドキュメントが不十分な状態でのシステム理解、前任者との情報授受の進め方など、経験がないと対応が難しい局面に対処できないことがあります。実績の有無とともに、「どのような規模・状況の引き継ぎを経験したか」まで確認するのが理想です。
提案の質で「考える力」を評価する
見積もり依頼や初回打ち合わせの時点で、候補会社が「課題に対してどんな提案をしてくるか」を評価します。
課題を伝えたときに「対応できます」という返答しか来ない会社より、「この部分はまず現状調査が必要で、その後に〇〇という改善が考えられます」というように、思考のプロセスを示してくれる会社の方が、長期的なパートナーとして信頼できます。
提案書や見積書の具体性（工数の根拠・対応手順の記述）も、思考力を判断する材料になります。
費用・SLAの透明性を確認する
初回の見積もり段階で以下を確認してください。
- 月額費用の内訳（どの作業範囲が含まれるか）
- 範囲外の作業が発生した場合の追加費用の考え方
- 対応時間帯（平日のみか、土日・祝日・深夜も対応可能か）
- 障害発生時の初動対応時間（SLA）
これらを最初に明確にしておくことで、後から「そのコストは別途です」というトラブルを防げます。透明性の高い候補会社を選ぶことが、長期的なコスト安定にもつながります。
スモールスタートで関係性を試す
可能であれば、最初から長期契約を締結するのではなく、「小規模な作業を1件だけ依頼する」「3ヶ月の試験期間を設ける」という形でスモールスタートすることを検討してください。
実際に仕事を依頼してみることで、コミュニケーションのしやすさ・対応スピード・成果物の品質を事前に確認できます。候補が複数ある場合は、並行して小規模な依頼を出し、比較評価することも有効です。
現外注先との解約・引き継ぎ交渉の進め方
乗り換えを決断した後に多くの担当者が悩むのが「現在の外注先にどう伝えるか」という問題です。関係が悪化することへの懸念や、「言いにくい」という心理的なハードルがあります。しかし引き継ぎは感情の問題ではなくプロセスの問題です。丁寧に、しかし明確に進めることが重要です。
乗り換えを伝えるタイミングと伝え方
契約の解約は、一般的に「契約終了の2〜3ヶ月前」に通知することが多いですが、契約書に定められた期限を必ず確認してください。
伝え方としては、「御社のサービスに問題がある」という批判的な言い方ではなく、「社内の方針変更により、保守体制を見直すことになりました」という中立的な言い回しが、その後の引き継ぎ交渉を円滑に進めます。感情的な対立が生じると、引き継ぎへの協力を得づらくなるリスクがあるためです。
引き継ぎ協力を書面で依頼する
口頭で「引き継ぎをお願いします」と伝えるだけでは不十分です。「何を、どのフォーマットで、いつまでに渡してもらうか」を書面で合意する必要があります。
引き継ぎ依頼書には以下を含めると効果的です。
- 引き継ぎ対象の情報リスト（ソースコード・設計書・アカウント情報など）
- 各情報の提出フォーマット
- 提出期限
- 不明点が生じた場合の質問方法と対応期間
この書面の合意が、引き継ぎ作業の品質を左右します。
並走期間を設ける
理想的なスケジュールでは、現外注先が完全に離れる前に、新しい外注先が並走する期間を設けます。具体的には、現外注先と新外注先が1〜2ヶ月間同時に関与し、システムの理解と引き継ぎを重複させて進めます。
並走期間を設けることで、「引き継ぎ直後に障害が発生した場合でも対処できる」「新外注先が分からない部分を現外注先に直接確認できる」というメリットがあります。コストはやや増加しますが、リスク低減効果は高いです。
引き継ぎが難航した場合の対策
現外注先が引き継ぎに非協力的な場合や、ドキュメントがまったく存在しない場合は、第三者のエンジニアを活用してシステムを解析・文書化する手段があります。
このような「ソースコードからドキュメントを逆生成する」作業を経験している会社もあります。難航が予想される場合は、新外注先の候補選定段階でこの種の対応実績も確認しておくと安心です。
詳しい引き継ぎの技術的手順については、システム保守の引き継ぎで失敗しないための完全ガイドを参照してください。
乗り換えのスケジュールと段取り
「乗り換えにどのくらい時間がかかるか」は、最初に把握しておきたい情報です。システムの規模にもよりますが、一般的には3〜6ヶ月を見込むのが現実的です。以下にフェーズ別のスケジュールを整理します。
フェーズ1: 候補選定・見積もり（1〜2ヶ月）
まず、候補会社3〜5社に問い合わせを行い、見積もりを取得します。前述の5つの判断基準に基づいて比較評価を行い、最終候補を1〜2社に絞ります。
この段階では、可能であれば小規模タスクの試験依頼も並行して行うと、実際の対応品質を確認できます。
フェーズ2: 現外注先への通知・引き継ぎ準備（1ヶ月）
契約書で定められた期限に従い、現外注先に解約の意思を伝えます。同時に、引き継ぎ依頼書を作成し、引き継ぎスコープの合意を取ります。
この時期に自社側でも行うべき準備があります。アカウント情報の棚卸し、必要なドキュメントのリストアップ、社内関係者への情報共有などです。
フェーズ3: 並走・段階的移管（1〜3ヶ月）
新外注先と現外注先が並走する期間です。新外注先にはまず「軽い問い合わせ対応」や「小規模な修正作業」から始めてもらい、徐々に担当範囲を広げていきます。
現外注先からの引き継ぎ情報の受領確認も、このフェーズで行います。提出された情報に不足がある場合は、この時期に追加依頼します。
フェーズ4: 完全移管・完了確認（最終チェック）
現外注先との契約が終了し、新外注先だけに移行する段階です。移行後2〜4週間は特に密にコミュニケーションを取り、問題が発生した場合にすぐに対処できる体制を整えます。
完了確認のチェックリストとして、以下を用意しておくと安心です。
- すべてのアカウント・認証情報の移転が完了しているか
- ソースコードリポジトリのアクセス権が新外注先に付与されているか
- 現外注先のアクセス権が削除されているか
- 本番環境・開発環境に正常にアクセスできるか
- 監視・アラートの設定が新外注先側で完了しているか
スケジュール設計のコツ
乗り換えのスケジュールは、「現外注先との契約更新タイミング」に合わせて設計するのが最も効率的です。契約更新の2〜3ヶ月前から候補選定を開始することで、契約期間中の中途解約による違約金のリスクを避けられます。
年間で契約更新を迎えるタイミングが分かっている場合は、逆算してフェーズ1の開始時期を設定してください。
乗り換え後に安定稼働させるための3つのポイント
乗り換えが完了した後も、「また同じ問題が起きる」という懸念を持つ方は少なくありません。外注先が変わっても同じ状況が繰り返されるとすれば、問題は外注先の選択だけでなく、発注者側の外注管理の仕組みにもある可能性があります。以下の3点を実践することで、安定した運用保守の関係を長期的に維持できます。
定期レビューの仕組みを作る
新外注先との間で、月次または四半期ごとの定期レビューを設定してください。レビューの議題には以下を含めることを推奨します。
- 前月の対応件数・対応時間の集計
- SLA達成率の確認
- 今後3ヶ月の懸念事項・改善提案
- セキュリティパッチの適用状況
この仕組みがあることで、「問題が蓄積してから気づく」のではなく、「問題が小さいうちに対処できる」体制になります。また、外注先に「定期的に評価されている」という意識を持たせることで、サービス品質の維持・向上を促す効果もあります。
自社でドキュメントを保有する習慣をつける
今回の乗り換え作業で経験したように、システムの情報が外注先にしかない状態は発注者にとってリスクです。今後は、外注先が作成した設計書・構成図・手順書を必ず自社でも保管するルールを設けてください。
具体的には「月次の定例で新規ドキュメントを受領する」「外注先が作業を行う際は、その記録を簡単なレポートで提出してもらう」といった運用ルールが有効です。
ドキュメントを自社が保有することで、将来また外注先を変更する際のハードルが大幅に下がります。
小さな改善提案を引き出す関係づくりをする
外注先との関係を「発注者と受注者」ではなく「パートナー」として捉えることが、長期的な品質向上につながります。
「改善提案があれば気軽に連絡してください」と伝えるだけでなく、「先月の運用を振り返って気になった点はありますか？」と定期的に問いかける姿勢が、外注先の主体的な関与を引き出します。
外注先も「言っても響かない」と感じれば提案しなくなります。小さな改善提案を受けたときに「ありがとうございます。検討します」という反応を返す文化が、良い外注関係を育てます。
システム運用保守の外注先を乗り換えることは、適切な準備と段取りがあれば、多くの場合で6ヶ月以内に完了できます。「乗り換えが怖い」という感覚は、プロセスが見えないことから生まれています。判断基準・候補選定・交渉・スケジュール管理の4つのステップを順番に進めることで、現状への漠然とした不満を、具体的なアクションに変えることができます。
失敗しないためのシステム保守の引継ぎチェックリスト
この資料でわかること
システム保守会社の変更を検討中の方が、引継ぎ作業で見落としがちなポイントを網羅した実践的なチェックリストです。
こんな方におすすめです
- 現在の保守会社のサービスに不満を感じている方
- 保守会社の変更を検討しているが、何から始めればよいか分からない方
- 引継ぎ作業でトラブルを避けたい方
入力いただいたメールアドレスにPDFをお送りします。
