タスクの引き継ぎで止まらない形｜渡すもの、渡せないもの
タスクの引き継ぎが決まってから慌てて資料を書き始めるチームは多く、そして書いた資料はたいてい読まれません。引き継ぎがうまくいかない原因は、資料の出来ではなく、普段タスクをどこに置いていたかにあります。引き継ぎとは、担当者の頭の中にあるものを別の頭に移す作業ではなく、頭の外に出ていたものを次の人が見つけられるようにする作業だからです。この記事では、引き継ぎで渡せるもの、渡しにくいもの、そもそも渡せないものを分けたうえで、担当が変わっても進行が止まらない形を、進行をとりまとめる立場から具体的に組み立てます。
引き継ぎは特別な行事ではなく、毎月起きる出来事になった
引き継ぎというと退職や異動の場面が思い浮かびますが、5人から数十人のチームで実際に起きている引き継ぎは、もっと小さく、もっと頻繁です。
引き継ぎの回数は、人の入れ替わりだけでは数えられない
産休や育休、長期の休暇、体調不良による数日の欠勤、繁忙期の応援、外部の協力者の契約期間の終了、担当替え。どれも引き継ぎです。さらに社内での役割変更や、案件の途中でのチーム再編もあります。数えていくと、規模が20人前後のチームでも、何らかの引き継ぎが月に1回から2回は発生している計算になります。
このうち、正式な引き継ぎ資料が作られるのは、退職と異動のときだけです。残りは口頭とチャットで済まされます。つまり大半の引き継ぎは、記録に残らない形で行われています。あとから「あの件、誰が持っていましたか」と探すことになるのは、この記録に残らないほうの引き継ぎです。
現場でしばしば出るのは、「1週間の休みを取ろうとしたら、その準備に3日かかった」という話です。休む本人が3日かけて棚卸しをしなければならない状態は、引き継ぎの問題というより、普段の置き場所の問題です。
使える時間は、思っているより短い
引き継ぎに使える期間は、こちらの都合では決まりません。期間の定めのない雇用について、民法には次の定めがあります。
当事者が雇用の期間を定めなかったときは、各当事者は、いつでも解約の申入れをすることができる。この場合において、雇用は、解約の申入れの日から二週間を経過することによって終了する。 出典: e-gov.go.jp
就業規則で1か月前の申し出を求めている会社は多く、実際の運用は各社の規則や個別の契約によって変わります。ここは法の解釈にあたるので、具体的な事案では所管の窓口や社会保険労務士に確認してください。ただ、制度の側が想定している最短が2週間である以上、引き継ぎの設計は「2週間しかない場合でも回るか」を基準に置くのが安全です。
そして体調不良や急な事情による離脱では、この2週間すら確保できません。引き継ぎ資料を書く時間がゼロだった場合に何が残るか。そこが本当の設計の分かれ目になります。
業務委託の場合はさらに短い前提で考える
外部の協力者との契約は、期間満了で自然に終わることが多く、更新しない判断が直前になることもあります。業務委託の相手に引き継ぎ資料の作成を求められるかどうかは契約内容によりますし、作業として依頼するなら対価の話が必要になります。ここも契約実務の領域なので、判断に迷うときは専門家に相談してください。
実務上の答えとしては、外部の協力者に依存する部分ほど、日々の進行を社内側の板に残しておく必要がある、ということになります。相手の手元にしか記録がない状態は、契約が終わった瞬間に何も残りません。
引き継ぎで落ちるものは、性質の違う3つに分かれる
引き継ぎがうまくいかないとき、何が落ちたのかを具体的に言えるチームは多くありません。落ちるものを分類すると、渡せるもの、渡しにくいもの、渡せないものの3つに分かれます。それぞれ対処法がまったく違います。
渡せているのは「作業の手順」だけである
引き継ぎ資料に書かれるのは、ほぼ手順です。どのシステムにログインして、どのファイルを開いて、どこに数字を入れて、誰に送るか。これは文章にできますし、読めば再現できます。
手順は渡せます。だから引き継ぎ資料は手順で埋まります。書く側も、書けるものから書くので当然です。問題は、手順を渡し終えた時点で「引き継ぎは完了した」と両者が思い込むことです。
実際には、手順を知っていても仕事は進みません。手順どおりに進まない場面が出たときに止まるからです。止まるのは、次に説明する2つが渡っていないからです。
渡しにくいのは「判断の理由」である
なぜこの取引先には請求書を月末ではなく20日に送っているのか。なぜこの案件だけ確認の回数が1回多いのか。なぜこの作業は水曜ではなく火曜にやることになっているのか。
こうした理由は、たいてい過去のトラブルや相手の事情から生まれています。そして、理由を知っている本人にとっては当たり前になりすぎていて、引き継ぎ資料に書く発想が出てきません。書く価値のある情報だと認識されないまま、本人と一緒に消えます。
理由が消えると何が起きるか。次の担当者は、手順どおりにやります。そして20日ではなく月末に請求書を送り、相手の締めに間に合わず、支払いが1か月ずれます。ここで初めて「なぜ20日だったのか」が分かるわけですが、失った信用は戻りません。
判断の理由は、引き継ぎのときにまとめて書き出そうとすると絶対に出てきません。思い出す手がかりがないからです。理由は、判断したその瞬間にタスクへ書き残す以外に確実な方法がありません。
そもそも渡せないのは「相手との関係」である
3つ目は、渡そうとしても渡らないものです。取引先の担当者との信頼関係、社内の別部署にいる話の早い人、無理を聞いてもらえる協力先。これらは人と人の間に生まれたもので、名簿を渡しても移りません。
前任者が電話1本で頼めていたことが、後任者だと3日かかる。これは後任者の能力の問題ではなく、関係が引き継がれていないだけです。ここを能力の問題として扱うと、後任者が消耗します。
関係は移せませんが、関係の存在を可視化することはできます。「この件は先方のA部門の担当者と直接やりとりしている」「この協力先には過去に無理な納期をお願いした経緯がある」といった情報が板の上にあれば、後任者は自分で関係を作り直す準備ができます。ゼロから関係を作る時間を、あらかじめ工程に見込んでおけるようになるだけでも違います。
とりまとめる立場としては、引き継ぎの直後は2か月ほど、外部とのやりとりに時間がかかる前提で工程を組むのが現実的です。関係の再構築には時間がかかるという事実を、能力評価と切り離して扱ってください。
引き継ぎ資料が読まれなくなる理由は、量ではなく構造にある
引き継ぎ資料を丁寧に作ったのに使われなかった、という話はよく聞きます。原因は分量ではありません。
資料は「読む順番」を持っていない
引き継ぎ資料は、書く人の頭の順番で書かれます。業務Aの説明、業務Bの説明、関係者一覧、注意事項。読む側が知りたいのは「いま目の前にあるこのタスクをどう進めるか」なので、順番が噛み合いません。
結果として、後任者は資料を最初に一度だけ通読し、その後は開かなくなります。困ったときに探す先として資料が選ばれないのは、探すコストが「前任者にチャットで聞く」より高いからです。人は必ず安いほうを選びます。
資料は更新されない
引き継ぎ資料は、引き継ぎのために書かれた文書です。引き継ぎが終われば役目を終えたとみなされ、誰も更新しません。1か月後には手順が変わり、3か月後には半分が事実と違っています。
事実と違う部分が1か所でも見つかると、読む側は残り全部を疑い始めます。ここが致命的です。1割が古いだけの資料が、実質的にはゼロと同じ扱いになります。
資料と実際の仕事が別の場所にある
いちばん大きいのはこれです。引き継ぎ資料は文書として存在し、実際のタスクは別の場所で動いています。この2つがつながっていないので、タスクを進めながら資料を参照するという動作が発生しません。
逆に言えば、タスクそのものに情報が付いていれば、資料を探す動作は不要になります。そのタスクを開けば、経緯も判断の理由も過去のやりとりもそこにある。これが、引き継ぎ資料を書かなくてよい状態です。
担当が変わっても止まらない形をつくる、先に決める6つのこと
引き継ぎが決まってから動くのでは遅い、というのが結論です。普段から決めておくことを6つに整理します。どれも道具を入れ替えなくても着手できます。
仕事の置き場所を、人から板へ移す
「この案件はBさんが持っている」という状態が、引き継ぎを難しくしている根本原因です。Bさんが持っているものの中身が外から見えないので、渡すときに全部を言語化しなければならなくなります。
やることは単純で、案件ではなくタスクの単位で板に並べ、それぞれに担当を1人だけ置きます。担当は「そのタスクを進める人」であって「その案件を所有する人」ではありません。この区別をチームで揃えると、引き継ぎは「担当欄を書き換える作業」に近づきます。
板に並べる粒度は、1日から3日で終わる大きさを目安にしてください。1週間を超えるタスクは中身がブラックボックス化し、進捗が「やっています」としか表現できなくなります。逆に1時間単位まで割ると入力の手間が勝って更新されなくなります。
状態の名前を、チームで先に決める
引き継ぎのときにいちばん時間を食うのは、「これは今どうなっているのか」の確認です。状態の呼び名がチームで揃っていないと、この確認が1件ずつの口頭説明になります。
最初は4段階で足ります。着手前、進行中、確認待ち、完了。ここに「確認待ち」を必ず入れてください。止まっているタスクの大半は、誰かの返事を待っている状態です。これが「進行中」に混ざっていると、引き継いだ人は自分が動かせるものと動かせないものを区別できません。
さらに一歩進めるなら、確認待ちには「誰の返事を待っているか」を書く欄を用意します。この欄があるだけで、引き継ぎ当日の説明が半分になります。
判断の理由を書き残す場所を、あらかじめ決める
前述のとおり、判断の理由は後からまとめて書き出せません。決めたその場で書く必要があります。
そのためには、書く場所が決まっていて、書くのに手間がかからないことが条件です。タスクのコメント欄でも、専用の欄でもかまいません。重要なのは、チーム全員が同じ場所に書くことです。ある人はチャット、ある人は表計算、ある人は自分のメモ帳という状態だと、後から集められません。
書く内容は1行で十分です。「先方の締めが20日なので前倒し」「前回の案件で色味の指摘が入ったため確認を1回追加」。この1行があるかないかで、次の担当者が同じ失敗をするかどうかが決まります。
習慣として定着させるコツは、書く対象を絞ることです。すべての作業に理由を書かせると誰も続きません。標準と違うやり方をした時だけ書くというルールにすると、量が現実的になります。
期限と、待っている相手を分けて書く
期限だけが書かれたタスクは、引き継いだ人にとって扱いにくいものです。期限が明日でも、自分が動けるとは限らないからです。
期限、着手できる日、待っている相手。この3つを分けて持つと、引き継いだ人は自分の判断で優先順位を組めます。とりまとめる立場から見ても、期限が迫っているのに他人待ちのタスクを早期に見つけられるようになります。
すべてのタスクに3つ書く必要はありません。他人が絡むタスクにだけ書けば足ります。実務上、他人待ちが発生するのは全体の3割前後で、そこに絞れば運用の負担は軽く済みます。
社外の人にどこまで見せるかを決める
引き継ぎの場面で意外と時間がかかるのが、権限の整理です。誰がどの板を見られるのか、外部の協力者はどこまで見えているのか。これが曖昧だと、引き継ぎのたびに一件ずつ確認することになります。
先に決めておくべきなのは、外部の人を招くときの既定のルールです。案件ごとに板を分けて、その板だけを見せるのか。社内用の板と外部共有用の板を分けるのか。どちらでも運用できますが、決まっていないと、担当が変わるたびに判断が揺れます。
権限の考え方は道具によって大きく違うので、選定の段階で確認しておくと後が楽になります。データの扱いやアクセス制御の方針については、安全性の考え方にどこまでの範囲が説明されているかを見ておくと、社内で説明を求められたときにそのまま使えます。
引き継ぎの単位を、案件ではなくタスクにする
最後は考え方の話です。「案件Aを引き継ぐ」と表現すると、範囲が曖昧になります。案件Aに含まれる作業が何件あるのか、誰も正確には言えないからです。
「案件Aのタスク12件のうち、進行中の4件と確認待ちの3件を引き継ぐ」と言えれば、抜けが起きません。引き継ぎの完了判定も、担当欄の書き換えが終わったかどうかで機械的に判断できます。
この形にすると、引き継ぎのミーティングで話す内容が変わります。全体の説明ではなく、「確認待ちの3件について、誰の返事を待っているか」だけを話せば済みます。所要時間は30分程度に収まります。
引き継ぎの実務を、3つの期間に分けて動かす
準備ができている前提で、実際の進め方を時系列で整理します。
引き継ぎが決まってから当日まで
まずやるのは、資料を書くことではありません。板を実態に合わせることです。
引き継ぐ人に、自分の担当タスクを上から見直してもらい、状態を正しくします。完了しているのに残っているもの、実は誰も動いていないもの、そもそも板に載っていないものを洗い出します。この作業で必ず出てくるのが、板に載っていない仕事です。定例の作業、月次の処理、頼まれごと。これらを追加するのが、この期間の主な仕事になります。
次に、確認待ちのタスクについて相手の名前を埋めます。「A社のBさんの回答待ち」「経理の承認待ち」。ここが埋まっていれば、引き継いだ人はその日から動けます。
最後に、標準と違うやり方をしているタスクに、その理由を1行足します。全部は無理なので、引き継ぐ人に「後任が同じようにやったら困るもの」だけを選んでもらってください。経験上、この選別は本人にしかできません。
引き継ぎ当日にやること
当日は、板を一緒に見ながら進めます。上から順に、状態と待ち相手を確認していくだけです。全体像の説明から入らないでください。全体像は、個々のタスクを見ていくうちに自然に伝わります。
この場で必ず確認しておくとよいのが、次の3点です。1つ目は、判断に迷ったときに誰に聞けばよいか。2つ目は、これまで自分の裁量で決めていた範囲はどこまでか。3つ目は、定例のやりとりがある相手は誰か。この3点は板に書きにくく、口頭でしか伝わりません。
そして、担当欄を実際にその場で書き換えます。後でやると必ず漏れます。
引き継いだあとの1か月
引き継ぎは当日で終わりません。運用として押さえておきたいのは、前任者への質問を1本の経路にまとめることです。
個別にチャットで聞くと、答えがその2人の間だけに残り、また消えます。質問と回答は、対象のタスクに書いてください。同じ質問が3か月後に別の人から出たとき、そこに答えがあります。
とりまとめる立場では、引き継ぎ後の1か月間、対象の板を週に一度見るようにしてください。見るのは進捗ではなく、動いていないタスクです。引き継ぎ直後に止まるタスクには、渡っていなかった情報が必ず隠れています。
資料を書かなくても済む状態を、あらかじめ作っておく
ここまでの話をひっくり返すようですが、理想は引き継ぎ資料を書かないことです。急な離脱では書く時間がないからです。
平時にできている状態とは何か
書かなくて済む状態を具体的に言うと、次のようになります。その人が明日から来なくなっても、板を見れば、その人が抱えていたタスクが全部見つかり、それぞれの状態が分かり、止まっているものについては誰の返事待ちかが分かる。標準と違うやり方をしているものには理由が付いている。
これだけです。手順書は必須ではありません。手順は再現できる人が社内に他にいるか、調べれば分かることが多いからです。分からないのは、状態と、判断の理由と、待ち相手です。
抜き打ちで確かめる方法
できているかどうかを確かめるには、実際に試すのが早いです。とりまとめる人が、チームの誰か1人を選んで、その人のタスクを板だけ見て説明してみます。本人には聞きません。
説明できない箇所が、そのまま引き継ぎで落ちる箇所です。3人ほど試せば、チームの弱点が見えます。これを四半期に一度やっておくと、実際の引き継ぎで慌てなくなります。
属人化をゼロにする必要はない
ここで注意したいのは、属人化そのものを敵視しないことです。専門性が必要な仕事は、担当が固定されるのが自然です。無理に全員ができるようにすると、全員が中途半端になります。
目指すのは、属人化した仕事の「状態」が外から見えることです。中身は本人にしかできなくてよい。ただし、いま何件抱えていて、どれが止まっていて、いつまでのものかは、外から見える。この線引きで十分に回ります。
道具を選ぶときに、引き継ぎの観点から見る場所
道具を入れ替える予定がなくても、いま使っているものが引き継ぎに向いているかは点検する価値があります。
見るのは機能一覧ではなく、更新の手数
引き継ぎに強い道具かどうかは、機能の多さでは決まりません。状態を変えるのに何回の操作が必要か、コメントを1行足すのに何秒かかるか。ここだけです。
手数が多い道具は、忙しくなると更新が止まります。更新が止まった板は実態とずれ、ずれた板は引き継ぎで使えません。3回を超えるクリックで状態が変わらないなら、運用か道具のどちらかを見直したほうがよいという目安があります。
板の形式でタスクを並べる道具は、状態の変更がカードを動かす動作で完結するため、この点では有利です。カードを一覧するタイプの道具でどこまでできるかは、できることに整理されている範囲を見ると判断しやすくなります。
いま使っている道具ごとの、引き継ぎでの詰まりどころ
道具ごとに、引き継ぎで問題になる場所は違います。
カード型の板を使っているチームでよく出るのは、無料の範囲での上限や、板をまたいだ一覧のしにくさです。担当が変わったときに、その人のタスクを横断で拾えるかどうかが分かれ目になります。この点はTrelloとの比較で、板の数の扱いや一覧のしかたがどう違うかを確認できます。
多機能なタスク管理を使っているチームでは、設定項目の多さが引き継ぎの障壁になることがあります。前任者が組んだ独自の設定を後任者が理解できず、触れなくなる形です。設定を最小限にする方向の設計と比べたい場合は、Asanaとの比較が参考になります。
文書とデータベースを兼ねる道具を使っている場合、引き継ぎ資料そのものは作りやすい反面、進行中のタスクの状態を全員で更新し続ける運用に持ち込みにくいという声があります。文書中心の設計と板中心の設計の違いはNotionとの比較にまとまっています。
自動化を作り込んでいるチームでは、その自動化を誰も直せなくなる形の属人化が起きます。作り込みの度合いと引き継ぎやすさは反比例するので、どこまで作り込むかは方針として決めておいてください。設定の考え方の違いはmonday.comとの比較で確認できます。
開発と一体で管理しているチームでは、開発以外の工程が板の外にこぼれることがあります。営業やデザインの工程まで同じ板に載せるかどうかは選択です。この点の設計思想の違いはBacklogとの比較にあります。
日本語で作られた板型の道具を検討している場合の違いはJootoとの比較にまとまっています。候補が複数あるときは、比較の一覧で条件を並べて見比べるほうが早く終わります。
乗り換えるときに引き継ぎが二重に発生する問題
道具を入れ替える判断をすると、その移行自体が全員分の引き継ぎになります。ここを軽く見ると、移行の途中で運用が止まります。
移行時に確認すべきなのは、過去のデータをどこまで持っていけるかです。自動で取り込める範囲は道具によって大きく違い、対応しているのが特定のサービスだけ、という場合もあります。実際の取り込み範囲はTrelloからの移行のような移行の説明ページで、何が移って何が移らないかを事前に読んでおいてください。
現実的な進め方は、過去分を全部移そうとしないことです。進行中のタスクだけを新しい板に手で移し、完了済みのものは元の場所に残す。これなら移行にかかる時間が読めます。
選定と運用で実際に効いてくる、費用と制限の見方
引き継ぎの観点で費用を見ると、機能の話よりも「誰を何人招けるか」が重要になります。
人数で区切るか、機能で区切るか
多くの道具は、上位プランでしか使えない機能を設けています。この設計だと、引き継いだ人が「その機能を使いたいがプランが足りない」という状況に当たることがあります。社内で交渉が必要になり、そこで進行が止まります。
一方で、機能で絞らず、区切るのは人数とボードの数だけという設計の道具もあります。この形だと、使い始めてから機能の壁で止まる場面が減ります。反面、人が増えれば費用は素直に伸びるので、外部の協力者を多く招く運用では人数の見込みを先に立てる必要があります。具体的な区切り方は料金で確認してください。
引き継ぎで招く人数を、先に数えておく
引き継ぎのたびに人が増えることを見落としがちです。前任者を一定期間残したまま後任者を追加すると、その間だけ人数が1人多い状態になります。数か月にわたる引き継ぎでは、この分の費用が発生します。
人数の数え方は道具ごとに違い、閲覧のみの人を含めるかどうかも分かれます。ここは選定時に必ず確認してください。数え方の違いによる費用差は、機能の差より大きくなることがあります。
検討から早く外すための情報を探す
選定にかける時間も有限です。効率よく進めるコツは、できることよりできないことを先に読むことです。
たとえば、ソースコードのリポジトリ機能は持たない、自動化や外部サービスとの連携の豊富さでは勝負しない、画面は日本語のみ、自動で取り込めるのは特定のサービスからだけ、といったことが明示されている道具であれば、条件に合わないチームはその時点で候補から外せます。こうした情報はよくある質問にまとめられていることが多いので、機能一覧より先に読むほうが時間の節約になります。
比較で集まる質問から見える、引き継ぎで詰まる場所
道具の比較ページに寄せられる質問を性質ごとに眺めると、引き継ぎで詰まる場所には偏りがあることが分かります。
質問は「移せるか」より「見えるか」に集まる
比較の場面で多いのは、データを移せるかという質問だと思われがちですが、実際に多いのは、担当者別に横断で見られるか、止まっているものを見つけられるか、という運用側の質問です。
これは引き継ぎの実態と一致します。困っているのは過去データの移動ではなく、いま誰が何を持っているかが見えないことです。比較の一覧で候補を並べるとき、機能の有無の欄より、一覧のしかたと絞り込みの欄を先に見ると、判断が早くなります。
できないことが書かれている道具のほうが選びやすい
もうひとつ特徴的なのは、できないことが明示されている道具のほうが、比較検討が短く終わるという点です。できることだけが並んだ資料は、どれも同じに見えます。
できることやTrelloからの移行のように、対応範囲と非対応の範囲が同じ場所に書かれていると、条件に合わないチームがその場で離脱できます。とりまとめる立場から見ると、離脱できることは損ではありません。合わない道具を導入してから気づくコストのほうがはるかに大きいからです。
権限の質問は、引き継ぎの直前に増える
権限や公開範囲に関する質問は、導入時よりも運用が始まってから増えます。外部の協力者を招く必要が出たとき、担当が変わったとき、部署をまたいだとき。つまり引き継ぎの場面です。
安全性の考え方のような、データの扱いと権限の方針がまとまったページは、導入時に一度読んで終わりにせず、引き継ぎの手順に組み込んでおくと確認漏れが減ります。引き継ぎのたびに「この人にどこまで見せるか」を判断するのではなく、既定のルールを決めておくのが実務的です。
結局のところ、引き継ぎで残るのは形だけである
引き継ぎがうまくいったチームと、そうでないチームの差は、資料の丁寧さではありません。普段からタスクが板の上にあり、状態が更新され、標準と違う判断に理由が付いているかどうか。この差だけです。
前任者の頭の中にあったものは、多かれ少なかれ失われます。それは避けられません。避けられるのは、頭の外に出せたはずのものまで一緒に失うことです。作業手順は渡せます。判断の理由は、その場で書いていれば渡ります。相手との関係は渡せませんが、関係があるという事実は渡せます。
引き継ぎの準備を始めるのに、引き継ぎが決まるのを待つ必要はありません。今日、自分のチームの誰か1人を選んで、その人のタスクを板だけ見て説明してみてください。説明できなかった箇所が、次に埋めるべき場所です。
Q1. 引き継ぎ資料はどこまで詳しく書けばよいですか？
作業手順を細かく書くより、標準と違うやり方をしている箇所とその理由に絞ってください。手順は他の人でも再現できたり調べれば分かったりしますが、なぜその順番なのか、なぜこの取引先だけ扱いが違うのかは本人しか知りません。分量の目安は、進行中のタスク1件につき1行から3行です。全業務を網羅した長い文書は、1か月で古くなり読まれなくなります。
Q2. 急な欠員で引き継ぎ期間がまったく取れないときはどうすればよいですか？
まず対象者のタスクを板から全部拾い、状態と期限だけを確認します。次に、止まっているタスクについて相手先へ状況確認の連絡を入れます。この2つで当面は回ります。手順が分からないものは、外部への連絡が必要なものから順に着手し、社内で完結するものは後回しでかまいません。判断の理由が分からないタスクは、いったん標準のやり方に戻す判断も選択肢になります。
Q3. 引き継ぎのミーティングにはどれくらい時間を取るべきですか？
板が実態に合っていれば30分程度で足ります。全体像の説明から入らず、板を一緒に見ながら状態と待ち相手を確認していく形にしてください。逆に、板が更新されていないと数時間かけても終わりません。時間がかかる場合は、引き継ぎの問題ではなく普段の記録の問題なので、まず前任者にタスクの棚卸しをしてもらう時間を別に確保するほうが確実です。
Q4. 引き継ぎ後、前任者にどのくらい質問してよいものですか？
期間を決めて、経路を1本にするのが実務的です。目安は1か月で、質問と回答は必ず対象のタスクに書き残してください。個別のチャットでやりとりすると答えがその2人の間に残り、同じ質問が繰り返されます。前任者が社外へ出る場合は、退職前の最終週に、確認待ちのタスクだけを一緒に洗い出しておくと、その後の質問が大幅に減ります。