保守ベンダーを変更するうえで、もっとも神経を使うフェーズが現行ベンダーから新ベンダーへの引き継ぎです。ドキュメントや知識が不十分なまま切り替えると、保守開始直後から問い合わせ対応・障害対応に支障が出かねません。一方で、現行ベンダーに不満を抱えている場合でも、引き継ぎ期間中は協力してもらわなければ、スムーズな移行は難しいものです。

本記事では、製造業・工場システムを前提に、引き継ぎで何を渡すか・どう進めるか・よくあるトラブルと対策を、現場の視点から具体的に解説します。

想定読者

本記事は、次のような方を対象に書いています。

• 保守ベンダーの変更を決定し、現行ベンダーとの引き継ぎをどう進めるか悩んでいる情シス担当者
• 引き継ぎに向けてドキュメント整備が不十分であることに気づいており、何を優先すべきか知りたい方
• 現行ベンダーが引き継ぎに非協力的で、交渉の進め方を模索している方

---

1. 引き継ぎで渡すもの：全体像と優先順位

引き継ぎの成否は「何を渡すか」の設計で7割決まります。まず「引き継ぎ対象の全体像」を把握し、何がそろっていて、何が不足しているかを確認することから始めます。

カテゴリ1：ドキュメント類

カテゴリ2：ソースコード・設定ファイル

カテゴリ3：運用・保守の知見（最も抜けやすい）

このカテゴリが最も引き継ぎで漏れやすく、切替後のトラブルの原因になります。

• よくある問い合わせ集：「月末にXXエラーが出る」「Yの処理が遅いときはどうする」など
• 過去の障害事例と対処内容：「いつ、何が起きて、どう対処したか」の記録
• カスタマイズの経緯：「なぜこの実装にしたか」「過去に変更した理由」
• 月次・年次の定期作業一覧：棚卸前の締め処理、年度初めのマスタ更新など
• 業者・外部サービスの連絡先：クラウドサービスのアカウント、証明書の更新先など

カテゴリ4：環境情報

• サーバー・ネットワーク構成図（本番・検証・開発環境ごと）
• 他システムとの接続先一覧（IP・ポート・API URL・認証情報の格納場所）
• ID・アカウント管理一覧：サーバーログイン、DB管理者、クラウドコンソールなど
• 証明書・ライセンスの有効期限一覧：SSLサーバ証明書、商用ソフトのライセンス等

---

2. 現行ベンダーとの交渉：協力を引き出すために

現行ベンダーの心理を理解する

保守契約の終了は、現行ベンダーにとってビジネス上の損失です。感情的になったり、非協力的な態度を取ったりするケースがあります。しかし、ほとんどの場合、適切な報酬とプロとしての扱いがあれば、責任を持って引き渡しに応じてもらえます。

現行ベンダーを「敵」として扱わず、「引き継ぎというプロジェクトにおける重要なパートナー」として接することが、協力を引き出す基本姿勢です。

交渉のポイント4つ

1. 早めに意向を伝える

変更が決まったら、遅くとも引き継ぎ計画を立てる3ヶ月前（できれば半年前）には意向を伝えます。「突然の終了宣告」は感情的な反発を招きやすく、引き継ぎへの協力も得にくくなります。

2. 引き継ぎ作業の報酬を明示する

引き継ぎ作業（ドキュメント整備・説明会・質問対応等）は、現行ベンダーの通常の保守業務の範囲外になる場合があります。追加報酬や、引き継ぎ専用の追加契約・覚書を準備して交渉します。「ただ働き」を求めると、消極的な対応しか得られません。

3. 契約上の引き渡し義務を確認する

保守契約や開発時の業務委託契約に、ソースコード・設計書の引き渡し義務が明記されているか確認します。義務が不明確な場合は、追加の覚書を締結して引き継ぎ範囲と引き渡し期日を文書化します。

4. 「渡すもの・期日・受け取り方法」を一覧にして提示する

抽象的な話ではなく、「〇〇のドキュメントを、〇月〇日までに、〇〇の形式で提供してください」という具体的な依頼書を作成して提示します。現ベンダーが「何をすればよいか」を明確にすることで、対応しやすくなります。

---

3. 引き継ぎプロジェクトの進め方

全体スケジュールの目安

引き継ぎ計画書の作成

三者（現ベンダー・新ベンダー・自社情シス）の役割とスケジュールを一枚の文書にまとめます。

引き継ぎ計画書の必須項目：

• 引き継ぎ対象の全リスト（ドキュメント、ソース、環境、知識）
• 各アイテムの引き渡し期日・担当者（現ベンダー）・受け取り担当者（新ベンダー）
• 説明会・キックオフのスケジュール（日程・参加者・アジェンダ）
• 並行稼働期間の条件（何の問い合わせを新ベンダーが対応し、何を現ベンダーに確認するか）
• 引き継ぎ完了の定義と確認方法

説明会の運営のコツ

書面だけでは伝わらない知識（業務フロー、障害時の動き方、過去のトラブル経緯等）は、説明会を数回に分けて設定します。

効果的な説明会の進め方：

• 新ベンダーが質問リストを事前送付し、現ベンダーが準備して答える形式にする
• 自社の情シスと現場のキーユーザーも同席させ、「業務上の疑問点」をその場で確認する
• 説明内容を議事録として残す（後で参照できるようにする）
• 1回で全部をこなそうとせず、テーマごとに分割（例：画面操作→バッチ処理→障害対応→連携系）

引き継ぎ完了の定義

「引き継ぎ完了」の基準を事前に決めておかないと、「これで終わりか」「まだ足りない」という認識のズレが生じます。

引き継ぎ完了の定義例：

• 主要ドキュメント（設計書、バッチ仕様、DB定義）の受領・内容確認済み
• 業務フローと主要機能の説明会を完了し、新ベンダーが概要を理解した
• 代表的な問い合わせパターン3〜5件について、新ベンダーが独自に対応できた
• 本番に近い環境での受入テスト合格
• 現場（キーユーザー）からの動作確認サイン

---

4. よくある引き継ぎトラブルと対策

トラブル1：「言った言わない」問題

状況：口頭で「説明した」「聞いていない」という行き違いが発生する

対策：説明会は必ず議事録を取り、双方がサイン（または承認メール）する。重要事項はメールや文書で確認する（口頭のみで終わらせない）。

トラブル2：現ベンダーから「ドキュメントがない」と言われる

状況：引き継ぎ依頼をしたら「当時の資料がない」「担当が変わって分からない」と言われた

対策：「ないドキュメント」はヒアリングで補完する（現ベンダーに口頭説明を求め、こちらで記録する）。リバースエンジニアリング（ソースや動作から仕様を逆引き）を新ベンダーに依頼する方法もある。「ドキュメントがない箇所」自体をリスクとして記録し、保守開始後の対応計画を立てる。

トラブル3：切替後すぐに障害が発生する

状況：保守責任が新ベンダーに移った直後、問い合わせや軽微な障害が集中した

対策：切替前に「よくある問い合わせ集」を整備し、新ベンダーが初見で対応できる準備をしておく。切替後1〜2ヶ月は、現ベンダーに「質問があれば連絡できる状態」を維持する（契約上合意しておく）。

トラブル4：引き継ぎ期間が長引く

状況：当初3ヶ月の予定が、ドキュメント不足や調整困難で6ヶ月以上かかっている

対策：引き継ぎ計画書にマイルストーンを設け、遅延時の対応を事前に合意しておく。引き継ぎ報酬の支払いスケジュールとアイテム完了を紐づける条件を最初から設定する。

---

ここまで読んで「自社の引き継ぎ計画を一緒に整理したい」「現ベンダーとの交渉に困っている」という場合は、お気軽にご相談ください。

---

5. 引き継ぎを進めやすくする「事前準備」

保守ベンダーの変更を考え始めた段階から、以下の準備を進めておくと、いざ引き継ぎになったときに格段に楽になります。

• 保守作業の記録をつける：問い合わせ内容と対処をメモしておく（保守ベンダーに依頼して共有してもらう）
• 自社でドキュメントのコピーを保持する：納品時に必ず設計書のコピーを保管する習慣をつける
• 契約書の「引き渡し条項」を確認する：更新・再契約のタイミングで条項を整備する
• ソースコードへのアクセス権を持つ：バージョン管理リポジトリへの読み取り権限を維持する

システムがブラックボックス化している場合

引き継ぎ前に「見える化」を進めておくことが、引き継ぎの品質と速度を大きく改善します。

よくある質問

Q. 引き継ぎ期間はどのくらいが適切ですか？

A. システムの規模・複雑さ・ドキュメントの充実度によって大きく異なります。ドキュメントが整っている小規模システムであれば2〜3ヶ月、ブラックボックス化が進んでいる中大規模システムでは6ヶ月〜1年以上が現実的です。引き継ぎ開始前に「対象範囲・ドキュメント状況・現ベンダーの協力度」を確認したうえで、スケジュールを策定することをお勧めします。

Q. 引き継ぎ中に現ベンダーとのトラブルが発生した場合はどうすれば良いですか？

A. 冷静に「記録」を残すことが最重要です。連絡事項はメールで確認、説明会は議事録を残す、という習慣が、万が一の際の証跡になります。それでも解決しない場合は、法務や顧問弁護士に相談の上、契約上の権利（ソースコードの引き渡し要求等）を行使する手順を踏みます。

Q. 新ベンダーに引き継ぎの負担をどこまで任せられますか？

A. 新ベンダーが「引き継ぎを主体的にリードする」スタイルの会社であれば、引き継ぎ項目一覧の作成、現ベンダーへのヒアリング、ドキュメント整備のほとんどを任せることが可能です。選定時に「引き継ぎ経験が豊富か」「引き継ぎ計画を提案できるか」を確認しておくと、引き継ぎフェーズの情シスの負担が大きく変わります。

---

まとめ

保守ベンダー変更の成否は、引き継ぎの質に大きく左右されます。本記事のポイントを振り返ります。

• 引き継ぎで渡すものは4カテゴリ（ドキュメント・ソース/設定・運用知見・環境情報）で整理し、優先度をつける
• 運用・保守の知見（よくある問い合わせ、過去の障害対処、カスタマイズの経緯）が最も抜けやすく、最も重要
• 現行ベンダーとの交渉では、早めの意向伝達・引き継ぎ報酬の明示・具体的な依頼書の提示が協力を引き出すカギ
• 引き継ぎ完了の定義を事前に決め、「言った言わない」のトラブルをドキュメントで防ぐ
• 切替後は並行稼働期間を設け、現ベンダーへの質問が可能な状態を維持する

製造業・工場システムでは、「止めてはいけない」という前提があるからこそ、引き継ぎの計画と準備を丁寧に進めることが大切です。

---

c3index に相談する

シースリーインデックスは、製造業のお客様の保守ベンダー変更に伴うドキュメント整備・現行ベンダーとの引き継ぎ調整・技術的な受入支援を行っています。「引き継ぎの進め方を一緒に整理したい」「現行ベンダーとの交渉に困っている」という段階からでもお気軽にご相談ください。