結論：クライアントの担当者交代が進行を止めるのは、プロジェクトの文脈が担当者個人の記憶に依存しているからだ。決定ログ・変更履歴・スコープ文書がツール上に残っている状態であれば、新担当者は自分で参照でき、立て直しの時間が大幅に短縮される。
案件が動いている最中に、クライアント側の担当者が変わる。
異動・退職・組織再編。理由はさまざまですが、連絡が来るタイミングはたいてい突然です。「来月から担当が変わります。後任の〇〇を紹介させてください。」という一文で、それまで積み上げた関係と文脈の継承が問われることになります。
担当者が変わること自体は避けられません。問題は、その交代がプロジェクトを止めたり、既に合意したことを白紙に戻すリスクを持つことです。
この記事では、クライアントの担当者交代がプロジェクトに与える影響を最小化するための、引き継ぎ設計を整理します。
担当者交代がプロジェクトを揺らす理由
クライアントの担当者が変わったとき、プロジェクトが揺れる原因は共通しています。文脈が引き継がれないことです。
前任者との間で積み上げた文脈というのは、なぜこのデザイン方針になったか、どの選択肢を検討してこの方向に絞ったか、クライアント社内でどんな議論があってこのスコープが決まったか、といった経緯です。これらは口頭のやり取りや担当者の記憶にしか残っていないことが多く、担当者が変わると丸ごと失われます。
新担当者の立場からすると、前任者から引き継ぎを受けたとしても、プロジェクトの「なぜ」の部分は分からないまま着任することがほとんどです。「前任者はこう言っていましたが、私はこう思います」という発言が出てくるのは、文脈の断絶からきています。
交代直後に起きやすいこと
担当者が変わった直後、制作側でよく起きることがあります。
1つ目は、既に決定済みの事項の再検討です。新担当者が「この方針は本当に正しいのか」と疑問を持つのは自然ですが、前任者との経緯が伝わっていないと「一度検討した選択肢を、また最初から検討する」という状況が生まれます。
2つ目は、関係性のリセットです。前任担当者との間で育てた「こういうコミュニケーションが円滑に進む」という了解が、新担当者には通用しないことがあります。関係性を再構築する時間が必要になります。
3つ目は、スコープの再解釈です。前任者が「これは対象外」と明示していても、新担当者がその境界を知らずに追加要件として持ち込んでくることがあります。
文脈をツール上に残す設計
担当者交代のリスクを最も効果的に下げるのは、プロジェクトの文脈をツール上に蓄積しておくことです。
担当者が変わっても失われない記録として、タスク管理ツールに残すべき内容があります。
決定ログ：いつ・誰が・何を決定したかのコメント記録。「この方針はX月X日の打ち合わせでクライアント側〇〇さんが承認」という形で残す。
変更履歴：仕様変更・スコープ変更が発生したとき、依頼の経緯と承認の流れをタスクのコメントに時系列で記録する。
スコープ文書：このプロジェクトで何をやり・何をやらないかを明文化したドキュメントをタスク管理ツール上に置く。
これらがツール上に残っていれば、新担当者が「前任者から何をどこまで聞いたか」に関わらず、自分で参照できます。担当者の記憶に依存せず、プロジェクトの文脈が引き継がれる状態になります。
変更ログを残す設計の詳細は クライアントの仕様変更が来ても、プロジェクトを止めない体制の作り方 に書いています。
新担当者への引き継ぎミーティングの設計
担当者交代が発生したとき、新担当者とのはじめのミーティングで確認すべきことがあります。
まず「どこまで引き継ぎを受けているか」を聞くことです。前任者からの引き継ぎの質は担当者によって大きく違います。資料を全部共有されている人もいれば、口頭で5分話しただけという人もいます。把握度を確認してから、補足が必要な内容を整理します。
次に、これまでの経緯の中で新担当者が「なぜ？」と思っている部分を引き出します。「この方針はどういう経緯で決まったのか」「この部分は対象外になっているのはなぜか」という疑問を放置したまま進めると、後から再検討の要求として出てきます。最初に整理しておく方が、プロジェクト全体の工数を減らします。
クライアント担当者の社内コーディネーションを支える設計は クライアントの窓口担当者を、外部から支える 3 つの動き で扱っています。
担当者が頻繁に変わるクライアントへの対応
担当者が短期間に何度も変わるクライアントには、個人への依存を下げる設計が有効です。
担当者個人との関係性ではなく、プロジェクトの状態そのものをクライアントの組織に見える形にしておくことです。タスク管理ツール上にプロジェクトの全情報が蓄積されていて、クライアント側の誰でも参照できる状態であれば、担当者が変わるたびに一から説明する手間が大幅に減ります。
また、承認フローを担当者個人の意思決定ではなく、複数名が確認できる形にしておくことも有効です。担当者1人の承認に依存すると、その人が変わったときに承認の根拠も失われます。
この記事で書いた設計は、担当者交代への対応であると同時に、プロジェクト全体の透明性を高める設計でもあります。文脈がツール上に残っていれば、クライアント側の誰が担当になっても、外注メンバーが変わっても、プロジェクトは動き続けます。
関連記事
仕様変更の引き継ぎ設計：クライアントの仕様変更が来ても、プロジェクトを止めない体制の作り方
クライアント担当者のサポート：クライアントの窓口担当者を、外部から支える 3 つの動き
プロジェクトクロージングの設計：プロジェクトクロージングを「納品で終わり」にしない 5 つの動き
Paqut で、プロジェクトの文脈を残す
Paqut では決定ログ・変更履歴・スコープ文書をタスク上に集約し、クライアントと外注メンバーが同じ場所で参照できます。