「A社のB担当者さんが辞めたと連絡が来た」——ベンダーから担当者交代の連絡を受けたとき、発注側が焦るのは珍しくありません。長年の取引の中で、そのシステムに関するほぼすべての文脈を知っているのがその担当者一人だった、というケースは多い。これはベンダー側の属人化であると同時に、発注側のリスク管理の問題でもあります。ベンダー担当者交代が引き起こす典型的な問題ベンダーの担当者が交代したとき、発注側でよく起きる問題は次の3つです。過去の経緯が引き継がれない。 「なぜこの仕様になっているか」「以前どういう問題があってこう対処したか」「口頭で合意した運用上のルール」——こうした文脈は、長年の担当者の頭の中にあり、正式な文書に残っていないことがほとんどです。担当者が変わると、こうした文脈がリセットされます。新担当者のキャッチアップに時間がかかる。 新しい担当者が「前任者と同じ水準で対応できる」ようになるまで、数週間〜数ヶ月かかることがあります。その間、対応品質が落ちたり、毎回「ゼロから説明する」手間が発生したりします。契約・価格の見直し交渉が発生する。 担当者交代のタイミングで契約内容の見直しが提案されることがあります。前任者の時代に積み上げてきた「非公式な優遇」が消える、あるいは料金改定が提示されるケースもあります。担当者交代前にやるべきこと（引継ぎ期間中の動き方）ベンダーから担当者交代の連絡が来たとき、「新しい担当者をよろしくお願いします」と受け身になるのは得策ではありません。引継ぎ期間中に発注側として動くべきことがあります。前担当者との引継ぎミーティングを設定する。 前担当者が在籍中に、発注側・前担当者・新担当者の三者で引継ぎミーティングを開きます。このとき確認すべきは「現在進行中の案件」だけでなく、「システムの構成と経緯」「過去の障害と対処の記録」「口頭合意・慣例として運用しているルール」「現在の契約スコープと費用の根拠」です。ドキュメントの受け取りを求める。 ベンダー側に、現行システムの仕様ドキュメント・構成図・過去の変更履歴の共有を依頼します。「保守契約の中に仕様書の提供が含まれているか」を契約書で確認し、含まれている場合は請求の根拠として使えます。新担当者の能力・権限を確認する。 新担当者が「前任者と同等の技術的判断ができるか」「緊急時に社内でどの程度の決裁権を持っているか」を早めに把握しておくと、障害発生時などの対応判断がしやすくなります。発注側が「知らなかった」情報を棚卸しする機会として使うベンダー担当者の交代は、発注側にとってシステム情報を棚卸しするタイミングにもなります。「前任者が全部把握していたので、自社では把握できていない情報が多い」という状態のまま担当者が変わると、次の担当者との関係でも同じ状態が続きます。このタイミングで、発注側として「自社でどの情報を持っておくべきか」を整理する機会にできます。具体的には、以下を自社の台帳に記録しておくことが目安です。システム構成の概要図、ベンダー連絡先（代表・担当・緊急時）、保守契約の内容・費用・更新時期、定常作業の内容と頻度、過去3年間の主な障害・変更の記録、現在積み残している課題・検討事項。これらが自社に残っていれば、担当者が誰に変わっても「新担当者がゼロからキャッチアップする」ではなく「こちらが把握していることを共有する」という主導権のある関係を維持できます。そもそも「ベンダー担当者に依存しすぎる」構造を変える※ベンダー依存の根本的な問題については「なぜシステム引継ぎは失敗するのか」で詳しく解説しています。ベンダー担当者交代のたびに業務が揺れる状況が続くなら、根本的な問題は「発注側がシステムの実態を把握していない」ことにあります。ベンダーの担当者が「このシステムのことを一番よく知っている人」であり続ける構造では、担当者が変わるたびに同じリスクが繰り返されます。この構造を変えるには、発注側として最低限の「システムの実態理解」を自社に持つことが必要です。「設計書がない」「ソースコードの中身が分からない」という状態のシステムでも、現在稼働しているシステムの振る舞いや業務との関連を調べることで、実態の輪郭を把握することはできます。これがシステム現行調査の役割です。引継ぎ期間中に整備すべきドキュメントの具体的な内容は、「システム引継ぎチェックリスト完全版」を参照してください。ライクバードでは、グループ子会社・中堅企業向けの引継ぎラボを提供しています。「ベンダー依存を減らしたい」「担当者が変わっても業務が止まらない体制を整えたい」という段階からご相談ください。→ システム引継ぎラボについて詳しく見る