昨日まで「〇〇さんに聞けば分かる」で回っていたシステムの窓口が、来月からいなくなる。開発会社の担当者から届いた「体制変更のご連絡」というメール一本に、心当たりのある方も多いのではないでしょうか。契約している会社自体が変わるわけではないのに、なぜか不安になる。それは、システムの細かい経緯や過去のやり取りの多くが、契約書ではなく担当者個人の記憶の中にあることを、無意識のうちに知っているからです。
この記事では、開発会社の担当者交代が決まったときに何を確認し、どう引き継ぎを進めれば実害を防げるかを、通知を受け取った直後の初動から、後任者との最初のやり取り、万一引き継ぎが不十分だった場合の対処まで、時系列に沿って解説します。結論を先に言うと、やるべきことは大きく3つです。「引き継がれる情報の範囲を書面で確認する」「後任者と顔合わせの場を作る」「引き継ぎ後1〜2ヶ月は動作確認を厚めに行う」。この3つを押さえれば、担当者交代による混乱の大部分は避けられます。
担当者交代の連絡が来たらまず確認すること
体制変更の連絡を受け取ったら、感情的に動揺する前に、まず事実関係を整理することが先決です。焦って「困ります」と抗議しても、多くの場合その開発会社側の人事は既に決定事項であり、覆りません。こちらが主導権を握れるのは「引き継ぎの中身」であって「交代の可否」ではないという前提に立つ必要があります。
最初に確認すべきは次の3点です。
- 交代の理由（退職か、社内異動か、担当プロジェクトの変更か）
- 交代のタイミング（いつまで前任者と連絡が取れるか、引き継ぎ期間はどれくらいか）
- 後任者の情報（名前、役割、これまでの経験、直接連絡できる窓口になるか）
理由によって警戒レベルは変わります。社内異動であれば前任者は同じ会社に残るため、後から質問することもできます。一方、退職の場合は連絡が取れる期間が限られるため、より急いで情報を引き出す必要があります。特に、開発会社側の体制自体が不安定化している兆候（短期間での担当者交代が続く、会社からの説明が曖昧など）が見られる場合は、SLA（サービス品質保証）や保守契約の内容を見直すきっかけとしても捉えるべきタイミングです。
「担当者が変わります」という連絡だけを受けて、具体的な引き継ぎ内容の説明がないまま日付だけが決まっていく、というケースは珍しくありません。連絡を受けたその場で「引き継ぎ資料の共有をお願いできますか」と一言添えるだけで、開発会社側の対応の丁寧さが大きく変わります。
なぜ担当者交代で引き継ぎ漏れが起きるのか
担当者交代のトラブルの多くは、悪意や手抜きではなく、そもそも「引き継ぐべき情報」が言語化・文書化されていないことに起因します。日々の細かいやり取り、電話や口頭での約束、過去に発生した不具合の対応経緯といった情報は、正式な議事録や仕様書には残らず、担当者個人の記憶と、担当者のメールボックス・チャット履歴の中にだけ存在していることが多いのです。
このような属人化した情報は、契約書やSOW（作業範囲記述書）のような公式ドキュメントには現れません。発注者側が「どうせ会社として契約しているのだから、担当者が変わっても情報は引き継がれるはず」と考えていても、実際には開発会社の社内でも十分な引き継ぎ資料が作られないまま担当が変わることがあります。特に、次のような情報は引き継ぎから漏れやすい傾向があります。
| 漏れやすい情報 | 理由 |
|---|---|
| 過去のイレギュラー対応の経緯 | 議事録に残らない口頭合意が多い |
| 「なぜこの仕様にしたか」の背景 | 決定理由はチャットの奥に埋もれがち |
| 発注者側の担当者の性格・要望の癖 | 個人の感覚として記憶されているだけ |
| 未解決のまま棚上げされている懸案事項 | 優先度が低いまま忘れられやすい |
| 検収や支払いに関する口頭の調整事項 | 正式な変更契約を結ばずに運用で処理されがち |
これは開発会社を批判するための話ではありません。発注者側の社内でも同じことが起きます。担当者が退職するときに属人化した業務の引き継ぎが不十分になるのと、構造としては全く同じです。だからこそ、引き継ぎを「相手の善意」に任せず、発注者側からも能動的に確認する姿勢が必要になります。
引き継ぎで確認すべき情報の全体像
担当者交代のタイミングで確認すべき情報は、大きく4つのカテゴリに分けて整理すると漏れが減ります。順に見ていきましょう。
契約・体制まわりの確認事項
まず、契約そのものに変更が生じないかを確認します。
- 契約主体（会社名・契約番号）に変更はないか
- 保守契約の範囲・料金に変更はないか
- 緊急時の連絡先・エスカレーションのルートに変更はないか
- 定例ミーティングの頻度・参加者に変更はないか
担当者個人が変わるだけであれば、これらは基本的に変わらないはずです。もし料金や対応範囲に言及があった場合は、それは単なる担当者交代ではなく契約条件の変更にあたるため、書面での正式な合意を必ず取り付けてください。口頭やメールの一文だけで済ませてしまうと、後で「言った・言わない」のトラブルに発展しやすくなります。
プロジェクトの経緯・背景の確認事項
次に、システムそのものの経緯に関わる情報です。
- これまでの主要な意思決定とその理由
- 過去に発生した不具合とその対応内容
- 現在進行中の案件・保留中の懸案事項
- 次回のアップデートや改修の予定
これらは前任者の頭の中にしかない可能性が高い情報です。可能であれば、交代前に前任者・後任者・発注者の三者が同席するミーティングを設定し、口頭での引き継ぎの場を作ってもらうことをおすすめします。文書だけの引き継ぎでは、文面に現れない「勘所」が抜け落ちやすいためです。
システムへのアクセス・技術情報の確認事項
これは最も実害に直結しやすい領域です。
- サーバー・管理画面へのアクセス権限の管理者は誰か
- ソースコードの管理場所（リポジトリ）と、発注者側のアクセス権
- ドメイン・SSL証明書などの契約名義
- 開発環境・本番環境の切り分けと、それぞれの管理者
担当者が個人のアカウントで各種サービスにログインしている場合、退職と同時にそのアカウントが凍結され、緊急時にアクセスできなくなるリスクがあります。この点は、過去に紹介した納品完了時に受け取るべきもの一覧の考え方と共通しており、「本来は発注者の名義であるべきものが、開発会社の個人名義になっていないか」を確認する良い機会でもあります。
履歴・記録の確認事項
最後に、過去のやり取りの記録そのものが失われないかを確認します。
- 過去の議事録・メール・チャット履歴は、後任者が引き続き参照できる状態か
- 発注者側にも同じ記録が残っているか（開発会社側だけに依存していないか）
- 検収書・請求書など契約関連書類は誰が保管しているか
開発会社側の社内チャットやメールは、担当者の退職と同時にアクセスできなくなることがあります。発注者側でも、重要なやり取りは自社側のメールやシステム管理台帳にコピーして残しておく習慣が、こうした場面で効いてきます。
交代の理由別に見る注意点の違い
担当者交代の理由は、大きく分けて「退職」「社内異動」「担当プロジェクトの変更（体制再編）」の3パターンに分類できます。それぞれで注意すべきポイントが異なるため、理由に応じて対応の力の入れどころを変えることをおすすめします。
退職によるケースは、最も引き継ぎリスクが高いパターンです。前任者が社外に出てしまうと、原則として連絡が取れなくなります。退職日までの猶予期間が短い場合(1〜2週間程度)は、口頭での引き継ぎミーティングを最優先で依頼し、資料化を待っている余裕がないことも多いです。可能であれば、退職が決まった時点でできるだけ早く、開発会社側に「引き継ぎに十分な時間を確保してほしい」と要望を伝えておくと、後々の負担が変わってきます。
社内異動によるケースは、前任者が同じ会社に在籍し続けるため、事後的に質問できる余地が残ります。ただし、異動後は前任者も新しい業務で多忙になるため、「後からいつでも聞ける」と油断していると、実際には数ヶ月連絡が取りづらくなることもあります。異動が決まった段階で、引き継ぎ期間中にまとめて確認しておくのが安全です。
体制再編によるケース（担当者個人の異動ではなく、プロジェクトのアサインが組織的に変わる場合）は、開発会社側の営業判断や採算性が絡んでいることもあります。この場合、担当者だけでなく、対応の優先度や体制の厚みそのものが変わる可能性があるため、引き継ぎ内容の確認と合わせて、今後のサポート体制について改めて説明を求めることが望ましいです。
いずれのケースでも共通して言えるのは、「理由を深掘りしすぎない」ことです。退職の背景を根掘り葉掘り尋ねても、得られる情報は限られますし、開発会社側との関係を損ねるだけの場合があります。理由の把握は、あくまで引き継ぎの緊急度・優先度を判断するための材料と捉え、確認すべき実務情報に集中するのが得策です。
引き継ぎ資料を依頼するときの伝え方
「引き継ぎ資料をください」とだけ伝えても、開発会社側も何を用意すればよいか判断に迷うことがあります。具体的な項目をこちらから提示したほうが、スムーズに、かつ漏れなく引き継ぎが進みます。以下は、そのまま使えるメール文面の例です。
平素より大変お世話になっております。
担当者変更のご連絡をいただき、承知いたしました。円滑な引き継ぎのため、以下の情報についてご共有いただけますでしょうか。
>
1. これまでの主な対応経緯（意思決定の理由を含む）
2. 現在進行中の案件・保留事項の一覧
3. サーバー・システムへのアクセス権限の現状
4. 保守契約の対応範囲・緊急連絡先の再確認
5. 可能であれば、前任者様・後任者様との顔合わせのお時間
>
お手数をおかけしますが、何卒よろしくお願いいたします。
このように具体的に項目を挙げることで、開発会社側も準備がしやすくなります。また、「顔合わせの時間」を明示的にお願いすることが重要です。文書だけのやり取りで済ませようとする開発会社もありますが、口頭での引き継ぎには文書化されない情報が多く含まれているため、多少の手間がかかっても直接話せる場を設けてもらう価値は大きいと考えます。
後任者との最初のやり取りで見ておきたいポイント
後任者と初めてコミュニケーションを取る場面は、今後の関係性を占う意味でも重要です。ここで確認しておきたいのは、後任者の「能力」そのものよりも、「引き継ぎがどの程度きちんと行われたか」を見極めることです。
具体的には、以下のような質問を投げかけてみると、引き継ぎの深さが見えてきます。
- 「〇〇の機能を追加した経緯はご存知ですか」（過去の意思決定への理解度)
- 「現在保留になっている案件はご存知ですか」（進行中案件の把握度)
- 「緊急時の連絡フローは変わりますか」（体制面の理解度)
これらの質問に対して、後任者が資料を見ながらでも的確に答えられる場合は、引き継ぎが比較的しっかり行われていると判断できます。逆に「確認して折り返します」という回答が続く場合は、まだ引き継ぎの途中である可能性が高く、当面は前任者への確認も並行して依頼したほうが安全です。
また、後任者の経験年数やこれまでの担当実績を無理に聞き出す必要はありませんが、「どのような体制でこのプロジェクトを担当されますか（一人体制か、チーム体制か)」を確認しておくことは有益です。一人の担当者に依存する体制は、今回と同じ担当者交代のリスクを今後も抱え続けることになるためです。
引き継ぎ後1〜2ヶ月に注意して見るべきこと
引き継ぎの説明を受けた直後は問題がないように見えても、実際に運用が始まってから抜け漏れが表面化することがあります。担当者交代後の1〜2ヶ月は、次のような点を意識的に注意深く見ておくことをおすすめします。
- 問い合わせへの回答スピードと精度が落ちていないか。過去の経緯を踏まえた回答ができているかを見ます。
- 定例ミーティングの進行が変わっていないか。開発プロジェクトの定例ミーティングの回し方で触れたように、議事録の質や進捗報告の粒度は担当者のスキルに左右されやすい部分です。
- 保守契約の対応範囲の認識にズレが生じていないか。前任者の頃は無償対応してもらえていた作業が、後任者になった途端に「それは追加費用です」と言われるケースがあります。月額保守費で何をやってもらえるのかで解説した内容を踏まえ、契約書の記載と実際の対応の整合性を確認してください。
- 緊急時の対応が想定通り機能するか。可能であれば、軽微な問い合わせを意図的に投げてみて、対応フローが実際に機能するかを確認するのも一つの方法です。
これらの確認は、後任者を疑ってかかるためのものではなく、双方にとって「認識のズレを早期に発見し、修正できる」ための予防策です。ズレに気づかないまま数ヶ月が過ぎると、修正のコストがどんどん大きくなっていきます。
引き継ぎが不十分だったと感じたときの対処
十分に依頼したつもりでも、実際には情報が引き継がれておらず、後任者とのやり取りで「そのあたりは分かりません」という回答が続くことがあります。そのような場合の対処法を整理します。
まずは前任者への確認ルートを維持してもらう
退職や異動の直後であれば、開発会社の窓口を通じて前任者に確認してもらうことがまだ可能な場合があります。「後任者だけでは分からない事項があるため、〇〇さん(前任者)に確認いただけますか」と、開発会社の管理職や窓口に依頼してみましょう。これは前任者個人への直接連絡というより、開発会社の組織としての対応をお願いする形が望ましい進め方です。
発注者側の記録で穴を埋める
前任者に確認する手段が既にない場合は、発注者側に残っている記録（過去のメール、議事録、請求書、システム管理台帳など）から経緯を再構築するしかありません。これは手間のかかる作業ですが、システム担当者にとっては避けて通れない場面です。過去に紹介した社内システムの現状調査（棚卸し）のやり方の手順が、そのままこの場面でも応用できます。
契約上の対応範囲を書面で再確認する
引き継ぎの過程で、保守契約の対応範囲について後任者と認識のズレが生じた場合は、感情的な水掛け論にせず、契約書と過去の契約不適合責任の考え方に立ち戻って整理することが有効です。契約書に明記されていない部分については、トラブル時の交渉術で解説した進め方を参考にしてください。
それでも改善しない場合
複数回の依頼にもかかわらず引き継ぎの質が改善しない、あるいは開発会社全体の体制が不安定な様子がうかがえる場合は、その開発会社との関係を長期的にどう続けるかを再検討する必要が出てきます。すぐに他社への切り替えを決断する必要はありませんが、開発会社と長期的にうまく付き合う方法で触れているように、複数の選択肢を平時から把握しておくことは、いざというときの交渉力にもつながります。
引き継ぎ確認チェックリスト（保存版）
ここまでの内容を、実際に使えるチェックリストの形にまとめます。担当者交代の連絡を受けたら、この一覧を印刷するかメモアプリにコピーして、一つずつ埋めていく形で使ってください。
初動（連絡を受けた当日〜数日以内）
- [ ] 交代の理由（退職・異動・体制再編）を確認した
- [ ] 前任者と連絡が取れる最終日を確認した
- [ ] 後任者の氏名・連絡先を確認した
- [ ] 「引き継ぎ資料の共有をお願いできますか」と一言伝えた
引き継ぎ内容の依頼（前任者在籍中）
- [ ] 契約主体・保守契約の範囲に変更がないか確認した
- [ ] 緊急連絡先・エスカレーションルートに変更がないか確認した
- [ ] これまでの主要な意思決定とその理由の共有を依頼した
- [ ] 現在進行中の案件・保留事項の一覧を依頼した
- [ ] サーバー・システムへのアクセス権限の管理者を確認した
- [ ] ソースコードの管理場所と、自社のアクセス権を確認した
- [ ] ドメイン・SSL証明書などの契約名義を確認した
- [ ] 過去の議事録・メール・チャット履歴の保管状況を確認した
- [ ] 前任者・後任者・自社の三者ミーティングを依頼した
後任者との初回コミュニケーション
- [ ] 過去の意思決定について、後任者がどこまで把握しているか確認した
- [ ] 保留中の案件について、後任者が認識しているか確認した
- [ ] 今後の担当体制（一人体制かチーム体制か）を確認した
交代後1〜2ヶ月のフォロー
- [ ] 問い合わせへの回答スピード・精度に変化がないか確認した
- [ ] 定例ミーティングの質に変化がないか確認した
- [ ] 保守契約の対応範囲の認識にズレが生じていないか確認した
- [ ] 緊急時対応フローが実際に機能するか確認した
すべての項目を一度に埋める必要はありません。特に「引き継ぎ内容の依頼」の項目は、前任者の在籍期間に応じて優先順位をつけ、時間が限られる場合はアクセス権限まわりと緊急連絡先を最優先で確認することをおすすめします。命綱に関わる情報から埋めていく、という考え方です。
担当者交代に備えて平時からできること
担当者交代は、発注者側の都合でコントロールできる出来事ではありません。だからこそ、交代が起きてから慌てるのではなく、平時から「担当者が変わっても困らない状態」を自社側で作っておくことが、最も確実な対策になります。
- 開発会社とのやり取りは、可能な限り複数人（自分ともう一人）で共有する
- 重要な決定事項はメールやチャットで文書化し、口頭のみで済ませない
- 自社側のシステム管理台帳に、システムごとの経緯・契約内容・担当者情報をまとめておく
- 開発会社の担当者の名刺・連絡先だけでなく、会社としての代表窓口も控えておく
これらは、属人化を防ぐ社内システム管理台帳の作り方で紹介した考え方と表裏一体です。自社の担当者が属人化しないようにする取り組みは、実は開発会社側の担当者交代への備えにもなっています。情報を「誰か一人の頭の中」に依存させず、記録として残しておくという原則は、社内・社外を問わず共通しているのです。
社内の関係者・上長への共有も忘れずに
担当者交代の対応は、システム担当者一人で抱え込んでしまいがちですが、影響が及ぶ範囲によっては社内の関係者にも共有しておくべき場面があります。
例えば、システムを日常的に利用している他部署の担当者がいる場合、開発会社の窓口が変わることで問い合わせの宛先やレスポンスの傾向が変わる可能性があります。「しばらくの間、対応にいつもより時間がかかるかもしれません」と一言周知しておくだけで、現場からの不満やクレームを未然に防げます。
また、保守費用や契約条件について何らかの変更提案があった場合は、金額の大小にかかわらず、決裁権を持つ上長への報告を怠らないようにしてください。担当者交代のタイミングは、開発会社側からすると契約条件を見直す自然な区切りでもあります。悪質な値上げ交渉とは限りませんが、「言われるがまま同意してしまった」という状況を避けるためにも、社内での合意形成のプロセスを省略しないことが重要です。
社内共有の際は、次のような点を簡潔に伝えると、過不足のない報告になります。
- 誰が、いつ、どのような理由で交代するのか
- 契約条件・費用に変更はあるか、ないか
- 自分（システム担当者）として何を確認し、何を依頼したか
- 現時点で懸念点や不安要素はあるか
特に最後の「懸念点や不安要素はあるか」は省略されがちですが、後になって問題が表面化したときに「実は最初から少し不安だった」と分かることは珍しくありません。小さな違和感であっても、記録として残しておくと、後日の判断材料になります。
引き継ぎが良好に進んだ場合でも油断しない
ここまで、引き継ぎに不安がある場合を中心に解説してきましたが、実際には多くのケースで、開発会社側もそれなりに配慮した引き継ぎを行ってくれます。資料もきちんと共有され、後任者も的確に受け答えができ、大きな問題もなく引き継ぎが完了した、というケースも十分にあり得ます。
そうした場合であっても、油断は禁物です。引き継ぎ直後は良好に見えても、後任者が実際に手を動かして初めて気づく疑問点や、資料には書かれていなかった細かい仕様の存在が、数週間から数ヶ月経ってから表面化することがあります。これは後任者の能力不足というより、どれだけ丁寧な引き継ぎであっても、実際に運用してみないと分からないことが一定数存在するという、構造的な限界によるものです。
したがって、引き継ぎが順調に進んだ場合でも、前述の「交代後1〜2ヶ月に注意して見るべきこと」は変わらず実施することをおすすめします。順調に見える引き継ぎほど、発注者側の確認の目が緩みがちになるため、意識的にチェックの機会を設ける必要があります。
まとめ
開発会社の担当者交代は避けられない出来事ですが、その影響の大きさは、引き継ぎの進め方次第で大きく変わります。連絡を受けたらまず事実関係(理由・タイミング・後任者情報)を確認し、契約・経緯・アクセス権限・履歴の4カテゴリで具体的に引き継ぎ内容を依頼する。後任者との最初のやり取りでは引き継ぎの深さを見極め、交代後1〜2ヶ月は対応の質を意識的に観察する。そして、もし引き継ぎに不安が残るなら、前任者への確認ルートや自社側の記録を頼りに穴を埋めていく。
こうした一つひとつの対応は地味に見えるかもしれませんが、システムが止まる、情報が失われる、費用の認識がズレるといった実害を防ぐための、最も現実的な予防策です。担当者が変わるたびに一から関係を作り直すのではなく、平時からの記録と、交代時の丁寧な確認を積み重ねることで、開発会社との関係を長期的に安定させていくことができます。
次回は、引き継ぎの土台となる社内側の記録体制について、社内システムの現状調査（棚卸し）のやり方や属人化を防ぐ社内システム管理台帳の作り方もあわせてご覧ください。
