担当していた仕事を誰かに渡すことになったとき、いちばん困るのは「何を書けばいいのか分からない」という状態です。自分にとっては毎日やっていることなので、どこまで説明が必要なのか見当がつきません。結果として、手順だけをきれいに並べた資料ができあがり、受け取った人が最初の週で行き詰まる、ということが起こります。ここでは、担当が変わるという期限のある場面で、抜け漏れを減らすための項目の並べ方と、渡し方の手順を整理します。事情や理由に踏み込む必要はありません。必要なのは、次の人が明日から回せる状態にすることだけです。
引き継ぎで漏れるのはどこか｜手順ではなく前提と例外
引き継ぎ資料が役に立たなかったという話を分解すると、たいていは同じところでつまずいています。書かれていないのは手順ではありません。手順は目に見えるので書きやすく、たいていの資料にはきちんと並んでいます。抜け落ちるのは、その手順を支えている前提と、いつもと違うときの例外です。
手順は書ける、前提は書かれない
前提というのは、たとえば「この作業は月初に回すが、それは請求のしめが月末だから」といった、順番の理由にあたる部分です。理由を知らないまま手順だけを渡されると、受け取った人は順番を入れ替えてよいのか判断できません。忙しい時期に「今日はここを後回しにしても大丈夫だろうか」と迷ったとき、頼れるのは理由の記述です。手順の一行ごとに理由を書く必要はありませんが、順番に意味がある箇所だけは、ひとこと添えておくと後で効いてきます。
もうひとつの前提は、関係者との暗黙の了解です。この人には先に一報を入れる、この部署は締切の二日前に動き出す、といった段取りは、資料に書かれないまま担当者の記憶に置かれがちです。人の名前をそのまま並べるのが難しい場合でも、どの役割の相手に、どのタイミングで声をかけるのかは書けます。
例外は年に数回しか出てこない
例外処理は、頻度が低いぶん記憶からも抜けます。毎月やっている作業は書き忘れませんが、決算のときだけ発生する確認や、特定の取引先にだけ必要な手続きは、引き継ぎ資料を書いている最中には思い出しにくいものです。カレンダーや過去のメール、共有フォルダの更新履歴を後ろにさかのぼって、そのとき何が起きていたかを拾い出すと、記憶だけに頼るより取りこぼしが減ります。
書き出す項目一覧｜作業・関係者・期限・権限・判断基準
抜け漏れを減らすいちばん確実な方法は、毎回同じ項目を並べることです。書く順番が決まっていれば、書きながら「ここが埋まっていない」と自分で気づけます。次の並びは、担当業務ごとにそのまま写して使える形にしてあります。
そのまま使える項目テンプレート
業務ひとつにつき、次の八項目を上から埋めていきます。空欄が残ったら、それが今の時点での抜けです。
- 担当業務と目的｜何という名前の仕事で、誰のために、何を成立させるためにやっているのかを一文で書きます。目的が書けない作業は、そもそも引き継ぐべきか相談の対象になります。
- 作業の手順｜一回分の流れを、開始のきっかけから完了の確認までを通しで書きます。途中で他部署に渡す作業があれば、渡す先と戻ってくる形も書きます。
- 頻度と期限｜毎日なのか、週の決まった曜日なのか、月次や年次なのかを書きます。期限は日付そのものより「何のしめに間に合わせるのか」を書いたほうが、暦がずれたときに応用が利きます。
- 関係者と連絡先｜社内と社外を分けて、役割と窓口を書きます。個人の連絡先を並べるより、部署名や共有アドレスなど、人が変わっても届く窓口を優先します。
- アカウントの扱い｜どのシステムを使うか、どの権限が必要かを書きます。ここに認証情報そのものは書きません。申請と停止の手順は管理部門の案内に従います。
- 判断が要る場面｜迷いが出る条件と、そのときの相談先を組にして書きます。「この金額を超えたら上長へ」のような線引きは、実際の数字を職場の規程で確認したうえで、規程のどこに書いてあるかも添えます。
- 過去のトラブル｜過去に起きた不具合と、そのときの対応、結果を書きます。同じことが再発したときの初動が早くなります。
- 保管場所と所在｜ファイル、紙の書類、鍵のかかる場所など、必要なものがどこにあるかを書きます。フォルダ名だけでなく、どこから入るかの経路で書きます。
一業務一枚で作る
すべてを一つの長い文書にまとめると、更新しづらくなり、読む側も自分に関係する部分を見つけられません。業務ごとに一枚を作り、先頭に一覧をつける形にすると、担当が変わったあとも部分的に直せます。一覧には業務名、頻度、次の期限だけを並べておくと、受け取った人がその週にやることを把握しやすくなります。
手順書の粒度をどこに合わせるか
粒度で悩むのは自然なことです。細かすぎれば書き終わらず、粗すぎれば読んでも動けません。基準を一つ決めるとすれば、「その業務を一度も見たことがない人が、隣に誰もいない状態で最後まで進めるか」です。
受け手が初めて触る前提で書く
同じ部署の人が引き継ぐ場合でも、その人がその作業を見たことがあるとは限りません。社内で共通の言い回しは省いてよいものの、その業務でしか使わない略語や、そのチームだけの呼び方は、初出の場所で説明を添えます。判断に迷ったら、直接の後任ではなく、その次に担当する人が読むつもりで書くとちょうどよくなります。
画面の文言をそのまま写す
システム操作の手順は、記憶で書くと言葉がずれます。実際に画面を開き、ボタンやメニューの表記をそのまま写すと、受け取った人が探し回らずに済みます。画面の見た目は更新で変わることがあるため、いつ時点の画面かを添えておくと、食い違いが出たときに古い記述だと気づけます。図や画面の画像を貼るときは、社外に出せない情報が写り込んでいないかを確認します。
例外処理とトラブル対応をどう残すか
例外の記述は、書き方の型を決めておくと集めやすくなります。思い出した順に箇条書きで足していける形にしておくのがこつです。
起きたこと・やったこと・結果の順で書く
過去のトラブルは、原因の分析まで書こうとすると手が止まります。まずは、どういう状況で何が起きたか、そのとき自分は何をしたか、その結果どうなったかを三行で残します。原因が分からなかったものは「原因は特定できていない」とそのまま書いて構いません。分からなかったという情報自体が、次の担当者にとっては手がかりになります。
判断が要る場面は条件と相談先をセットにする
例外は、判断とセットで初めて使える情報になります。どういう条件のときに通常の手順から外れるのか、そのとき誰に確認するのかを並べて書きます。相談先は個人名だけにせず、その人が不在のときの代わりも書いておくと、担当が変わった直後の止まりを防げます。社内規程や就業に関わる取り扱いが絡む場合は、資料の中で解釈を断定せず、規程の該当箇所や人事・総務の窓口を案内する形にとどめます。
アカウント・権限・保管場所の引き渡しで確認すること
ここは、引き継ぎの中でいちばん慎重に扱う部分です。使えるようにすることと、安全に渡すことを両立させる必要があります。
パスワードは資料に書かない
引き継ぎ資料にパスワードやワンタイムコード、秘密の質問の答えを書くことは避けます。資料は共有フォルダに置かれ、メールで転送され、印刷されることもあります。書いた本人が想定していない範囲まで広がるのが資料というものです。書いてよいのは、どのシステムを使うか、どの権限区分が必要か、申請はどこに出すか、という三点までです。もし過去の資料に認証情報が書かれているのを見つけたら、そのまま引き継がず、管理部門に相談してください。
権限の申請と停止は管理部門の手順に従う
アカウントの受け渡しは、自分の判断で共有するものではなく、情報システム部門や総務など、管理を担当する部署の手順に沿って行います。一般には、後任の分を新しく申請し、前任の分は所定の時期に停止する、という流れで案内されていることが多いのですが、手順も呼び名も職場によって異なります。引き継ぎ資料には「どこに、どの申請を出すか」だけを書き、実際の可否や時期の判断は管理部門に委ねるのが安全です。共有アカウントを使っている業務がある場合も、扱いは自分で決めず、管理部門に確認します。
保管場所は経路で書く
ファイルの場所は、名前だけでは見つかりません。どの共有ドライブの、どのフォルダから、どうたどるのかという経路で書きます。紙の書類や鍵のかかる保管庫がある場合は、場所に加えて、開けるために誰の許可が要るのかも書きます。アクセス権が付いていないと、そもそも存在に気づけないフォルダもあるため、権限の申請項目とひもづけておくと親切です。
口頭で伝える部分と文書で残す部分の分け方
すべてを文書にするのは現実的ではありませんし、逆にすべてを口頭で伝えると、その場にいなかった人には何も残りません。分け方の目安は、繰り返し必要になるかどうかです。
繰り返し使うものは文書へ、機微な話は口頭で
手順、期限、窓口、判断の条件は、後から何度も参照されるので文書に残します。一方で、取引先とのやりとりの温度感や、社内の関係についての配慮といった、書き方を誤ると受け取り方が変わってしまう話は、口頭で補うほうが向いています。ただし口頭で伝えたことも、「この件は口頭で共有済み」と一行だけ資料に残しておくと、伝えた事実そのものは記録されます。人物についての評価を文書に書き残すことは避け、事実として必要なことだけを書くようにします。
引き継ぎ期間のスケジュールと立ち会いの回数
資料を渡して終わりにすると、受け取った人は最初の実行でつまずきます。期間の長さは職場や業務量によって大きく変わるため一律には決められませんが、進め方の順番は共通しています。
読む・やってみる・見てもらう
最初に資料を読んでもらい、分からない箇所に印をつけてもらいます。次に、実際の作業を後任がやってみて、前任が横で見ます。最後に、前任は口を出さずに見守り、終わってから気づいた点を伝えます。この三段階を通すと、資料に書いたつもりで書けていなかった部分が表に出てきます。立ち会いを一度だけにすると、その日たまたま発生しなかった作業が抜けたままになります。月次や年次の作業がある業務では、実際にその時期が来たときに確認できるよう、あらかじめ質問できる状態を用意しておくのが現実的です。
渡した後に質問が来たときの窓口の決め方
引き継ぎで最後まで決めないまま流れがちなのが、渡した後の質問先です。ここを決めておかないと、後任は個人的なつながりを頼るしかなくなり、前任の側も、どこまで応じるべきか分からないまま連絡を受けることになります。
おすすめは、質問の受け先を個人ではなくチームや上長に置き、そこで受けてから必要に応じて前任に確認する形にすることです。窓口をチームに置いておけば、同じ質問が二度目に来たときには資料に追記され、三度目には誰も聞かなくて済みます。あわせて、いつまでその体制をとるのか、業務時間内のどの手段で連絡するのかも決めておきます。期間や連絡方法は職場の運用によって違うため、上長と合意したうえで、資料の先頭に書いておきます。
もう一つ決めておきたいのが、資料の更新責任です。引き継ぎ資料は渡した時点から古くなり始めます。誰がいつ見直すのかを一行決めておくだけで、次の担当交代のときに一から作り直す手間がなくなります。
よくある質問
- 引き継ぎ資料はどのくらいの分量で作ればよいですか
- 分量よりも、業務ごとに同じ項目がそろっているかを優先してください。担当業務と目的、手順、頻度と期限、関係者、アカウントの扱い、判断が要る場面、過去のトラブル、保管場所の八項目が埋まっていれば、短くても実用に足ります。長さを目標にすると、書きやすい手順ばかりが増えて前提と例外が抜けます。
- アカウントのパスワードはどう伝えればよいですか
- 引き継ぎ資料にパスワードやワンタイムコードを書くことは避けてください。資料は共有や印刷で広がるためです。後任のアカウントを新しく用意する申請と、前任の権限を停止する手続きは、情報システム部門や総務など管理を担当する部署の手順に従います。資料には申請先と必要な権限区分だけを書きます。
- 時間が足りません。何から手をつけるべきですか
- まず業務名と頻度と期限だけの一覧を作ってください。全体像があれば、後任も上長も、残りをどう埋めるか判断できます。そのうえで、期限が近い業務と、止まると影響が大きい業務から順に中身を書いていきます。頻度の低い年次作業は、あとから追記できるように見出しだけ立てておくと抜けにくくなります。
- 後任がまだ決まっていない場合はどうしますか
- 後任が決まっていなくても、書ける項目は先に埋められます。特定の人に向けた説明ではなく、その業務を初めて見る人が読む前提で書いておくと、誰が受け取っても使えます。決まっていないこと自体は上長と共有し、質問の受け先を暫定でどこに置くかだけ先に決めておくと、渡す段になって慌てずに済みます。
- 口頭で伝えたことも資料に残すべきですか
- 繰り返し必要になることは文書に残し、書き方によって受け取り方が変わる話は口頭で補うのが目安です。口頭で伝えた場合も、その件を共有済みだと一行だけ資料に書いておくと、伝えた事実は記録に残ります。人物についての評価は文書に残さず、事実として必要な情報だけを書くようにしてください。