業務を引き継ぐ — Patter

The case

引き継ぎが難しいのは、渡す側が業務を知りすぎているからです。どの手順が本当に重要で、どれが形式だけかを知っている。数ヶ月に一度だけ現れる例外を知っている。ある依存先が不安定で、実はそこだけ別の方法で処理していることも知っている。でもそれは文書化されていない。する必要がなかったから。

だから引き継がれるのは、資料に書いてある内容です。相手はうなずいて、その場は終わる。二週間後、誰も予想していなかった質問が来る。実際に業務を動かしてみて初めてわかることは、その前には聞けないから。

解決策はより詳しい資料ではなく、順序を変えることです。まず実際のプロセスを再現する。それから書き起こす。そして相手が動かすのを見てから、手を離す。見ているときに、抜けているものが見えてくる。必ず出てくる。

相手が一人で業務を動かせるようになるまで、引き継ぎは終わっていません。それまでの作業はすべて準備です。

業務引き継ぎ

業務の手順を記憶だけで書き出す。まだ既存の資料は見ない。何も見ずに思い出せることが、相手に伝えるべき内容のおおよその輪郭になる。
書き出した内容を既存のマニュアルと照合する。抜けている箇所や食い違いをメモする。マニュアルは現状に追いついていないことが多い。
文書化されていない詳細を加える。例外的なケース、イレギュラーな対応、手順4が動かないときの対処法。自分だけが知っている部分がここに集まる。
関連する依存関係を整理する。ツール、アクセス権、認証情報、関係する人。業務が接続しているすべてのもの。
相手が業務を始めるために必要なものがそろっているか確認する。アクセス権の確認はミーティングの前に済ませておく。当日に発覚するのは避ける。
引き継ぎ資料を作成する。手順を順序通りに、依存関係と例外を明記して。自分がいなくても業務を回せる内容にする。
問題が起きやすい箇所を二、三点挙げる。何が止まるか、どう対処するか、すぐに解決できない場合は誰に連絡するか。
業務全体を通して説明する。一緒に最初から最後まで確認する。相手はまだ自分では動かさない。
相手に実際に業務を動かしてもらい、横で見る。本当に問題が起きたとき以外は口を挟まない。何を見落とすかに注目する。
見落としていた箇所をフォローする。具体的に、簡潔に。
大きな抜けがあった場合は繰り返す。@9 に戻る。
自分がいなくなった後に問題が起きたときの対応を決めておく。担当者名、資料、連絡先のいずれか。「とりあえず連絡して」ではなく、具体的に決める。
相手が一人で対応できるか確認する。判断するのは自分ではなく、相手自身。

自分流にアレンジ

ほとんどの引き継ぎが失敗するのは、手順9ではなく手順3です。文書化されたプロセスと実際に動いているプロセスはたいてい一致しない。いつからか定着した回避策、暗黙の了解になっている近道、過去のトラブルをきっかけに追加されたチェック項目。このステップを省くと、不完全な地図を渡すことになります。

実際に相手に業務を動かしてもらうステップ（手順9）は、複雑な業務では代替が効きません。「理解しました」という言葉と、実際にやっている姿は別物です。どこで手が止まるか、何を飛ばすかを見るほうが、どんな質問をするより多くのことがわかります。

シンプルな業務であれば、手順6と7をひとつの短い資料にまとめても構いません。クライアント対応、経理、運用など、問題が起きたときの影響が大きい業務については、別々に残しておくほうが安全です。「何かあったときの対処法」の資料は、切迫した状況で実際に開かれるものです。

引き継ぎを何度か経験すると、手順1が楽になってきます。業務を実行しながら記録しておく習慣が身につくからです。それはまた別の習慣ですが、この引き継ぎルーティンをずっと速くしてくれます。