仕事の引き継ぎで大切なのは、手順書を渡すことではありません。
後任者が、一人でも判断して仕事を進められる状態を作ることです。
僕も以前、「これなら完璧だ」と思った手順書を部下に渡したものの、質問が次々に出てきて、引き継ぎに失敗しました。
この記事では、その経験から気づいた「手順書に本当に必要な情報」と、後任者が一人で仕事を進められる状態を作る方法を紹介します。
詳しく書いた手順書が、後任者に伝わらなかった
僕は以前、自分が担当していた業務を部下へ引き継ぐことになりました。
引き継ぐ以上、中途半端な状態では渡したくありません。
そこで、その業務の手順書を一から作りました。
業務の流れだけでなく、
「イレギュラーが起きたらどうするのか」
「誰に相談するのか」
「どこへ報告するのか」
といった内容まで記載しました。
自分では、「この手順書があれば大丈夫だ」と思っていました。
長年その仕事をやってきた僕の目から見れば、かなり詳しく作ったつもりだったのです。
手順書を部下へ渡したときは、「よし。これで一つ、自分の仕事を離せる」くらいに考えていました。
ところが、実際に部下が仕事を始めると、質問が次々に出てきました。
「これは、どういう意味ですか？」
「これは、何のことを言っているんですか？」
そのたびに僕は、「これくらい、言わなくても分からないかな」と思っていました。
正直、「仕事を覚えるのが苦手なのかな」と感じたこともあります。
しかし、後日あらためて自分の手順書を読み返してみると、
「あ、この説明が抜けている」
「ここは、もっと詳しく書かないと分からないな」
という箇所がいくつも見つかりました。
自分では完璧だと思っていた手順書が、初めてその仕事をする人から見れば、決して親切なものではなかったのです。
そこで初めて気づきました。
長年その仕事をしてきた自分と、初めて仕事をする人では、見えているものがまったく違う。
僕には理解できる手順書でも、ほかの誰かが同じように理解できるとは限りません。
僕の手順書で実際に抜けていた3つの説明
実際に部下から質問を受けて、手順書を読み直してみると、大きく3つの説明が不足していました。
1．社内用語を説明していなかった
手順書には、職場で普段使っている略称を、そのまま記載していました。
例えば「ALS」「NSW」といったアルファベットです。
僕にとっては毎日のように使う言葉なので、見ればすぐに意味が分かります。
ところが部下から、「これは何ですか？」と聞かれました。
そのとき初めて、「そうか。この言葉自体を知らない可能性があるのか」と気づいたのです。
長く働いていると、社内用語や略語まで「誰でも知っている言葉」のように感じてしまいます。
しかし、担当したことがない人にとっては、初めて見る言葉かもしれません。
手順書を作るときは、社内用語や略語についても、「初めて読む人が意味を理解できるか」という視点で見直す必要があります。
2．「確認する」の基準を書いていなかった
もう一つ、僕がよく使っていた言葉が、
「データの内容を確認する」
です。
自分では十分な説明だと思っていました。
しかし、部下から、
「この画面のどこを確認すればいいんですか？」
と聞かれました。
一瞬、「そこを確認する以外に何があるんだろう」と思いました。
でも、よく考えれば当然です。
僕は何年もその画面を見ています。
どの項目を確認し、何なら正常で、どの状態なら異常なのかを経験で知っています。
部下には、その経験がありません。
「確認する」と書くだけではなく、
・どこを見るのか
・何と何を比較するのか
・どの状態なら正常なのか
・違っていたらどうするのか
まで書かなければ、本当の意味で「確認方法を伝えた」とはいえなかったのです。
3．作業を始めるタイミングを書いていなかった
作業の内容は書いているのに、「いつ始めるのか」を書いていない仕事もありました。
部下から、
「この業務って、いつやればいいんですか？」
と聞かれたことがあります。
その仕事は、あるデータが転送されてきたら始める業務でした。
僕にとっては、それが当たり前です。
しかし、手順書には書いていませんでした。
そのため部下は、自分の好きなタイミングで行えばよい仕事だと受け取っていたのです。
「何をするか」だけでは足りません。
いつ、何をきっかけに始めるのか。
これも立派な手順の一つです。
手順書を見返した僕は、「こんな大事なことまで書いていなかったのか」と反省しました。
引き継ぎは、手順書を渡せば終わりではない
当時の僕は、手順書を渡した時点で、「これで引き継ぎは終わった」くらいに考えていました。
大きな勘違いでした。
僕は、その仕事を何年も担当しています。
ある意味では、息をするように仕事を進められます。
何が起きたら作業を始めるのか。
どこを見るのか。
異常があったら誰へ連絡するのか。
すべて頭の中に入っています。
しかし、初めて担当する部下には、その前提がありません。
さらに、僕の手順書にはもっと大切なことが抜けていました。
「何のために、この仕事をするのか」という目的です。
何のために行うのか。
やらなければ何が起きるのか。
この仕事の後には、誰の仕事が続いているのか。
僕自身は理解していました。
だからこそ、わざわざ説明する必要がないと思っていたのです。
でも、それこそが経験者の落とし穴でした。
自分が読むための手順書と、初めて仕事をする人が一人で使える手順書は、まったく別物です。
引き継ぎで本当に渡したい5つの情報
この経験をしてから、僕は「引き継ぎでは何を渡す必要があるのか」を考えるようになりました。
少なくとも、次の5つは必要だと感じています。
1．仕事の目的
最初に伝えたいのは、
「何のために、この仕事をするのか」
という目的です。
単に「このデータを入力する仕事です」ではありません。
そのデータを入力することで、誰が何に使い、最終的に何を守っているのかまで伝えます。
目的が分かれば、手順書に書かれていないことが起きたときにも、何を優先すべきか考えやすくなります。
2．具体的な手順
もちろん、具体的な作業方法も必要です。
いつ、何を使い、どの順番で進めるのか。
初めて担当する人が実際に操作する姿を想像しながら記載します。
「確認する」「処理する」「対応する」といった曖昧な表現だけで終わらせないことも大切です。
3．完了と異常の判断基準
「この仕事は、どこまでやれば終わりなのか」も明確にしておきます。
同時に、「どの状態なら異常なのか」も必要です。
異常が起きた場合は、
「どこを確認するのか」
「誰へ相談するのか」
「どこまで自分で判断してよいのか」
まで書いておけば、後任者も動きやすくなります。
4．例外が起きたときの対応
実際の仕事は、毎回手順書とまったく同じようには進みません。
過去に起きたトラブルや、よくある例外があるなら、それも共有します。
特に、過去に失敗したことは重要です。
何が起きたのか。
なぜ起きたのか。
現在は何をして再発を防いでいるのか。
ここまで分かれば、後任者が同じ失敗を繰り返す可能性も下げられます。
5．現在進行中の仕事と関係者
手順書だけでは引き継げないものもあります。
それが、現在進行中の仕事です。
「どこまで終わっているのか」
「次に何をするのか」
「期限はいつなのか」
「誰とやり取りしているのか」
を別に整理して渡します。
どれだけ立派な手順書があっても、進行中の仕事が抜けていれば、引き継ぎ直後から問題が発生するかもしれません。
手順より先に「目的」を伝える理由
5つの中でも、僕が特に大切だと感じているのが「目的」です。
例えば、ある仕事で、「データを入力する」という作業があったとします。
しかし、本当の目的は「データを入力すること」ではありません。
僕が担当していた仕事では、
後工程の人が正しい情報を使って、予定どおり作業できる状態にすること
が目的でした。
この違いは大きいです。
「データを入力すれば仕事は終わり」と考えていれば、入力を終えた時点で本人の仕事は完了します。
しかし、間違ったデータを入力すれば、そのデータを使用する後工程で問題が起きます。
修正するために、もう一度作業をやり直すことになるかもしれません。
反対に、
後工程へ正しい情報を渡すことが自分の仕事なんだ。
と理解していれば、入力後に内容を確認する意味も理解しやすくなります。
実際、僕が入力ミスを指摘した際、部下から、「でも、データを打つことだけが僕の業務ですよね？」と言われたことがあります。
僕には、「自分は入力さえすればよい」と仕事を切り分けて考えているように聞こえました。
もちろん、本人にも考えるべき部分はあったと思います。
ただ、同時に、「そもそも僕は、この仕事の目的をきちんと説明しただろうか」とも考えました。
目的まで共有していれば、「自分の作業が終わればそれでいい」ではなく、その先の工程まで意識して仕事を進めやすくなります。
手順は、「どうやるか」を教えてくれます。
目的は、「なぜやるのか」を教えてくれます。
引き継ぎには、どちらも必要なのだと感じています。
後任者に実際にやってもらう
手順書がある程度できたら、次は実際に後任者に仕事をしてもらいます。
ここも、以前の僕が勘違いしていたところです。
説明して手順書を渡しただけでは、本当に理解できているか分かりません。
僕なら、
自分が見せる → 一緒に行う → 後任者だけで行う → 分からなかった点を手順書へ追加する
という流れで進めます。
自分では完璧だと思っていた手順書でも、実際に使ってもらうと抜けている部分が出てきます。
そこで、
「なぜここで止まったのか」
「何が分からなかったのか」
を確認し、手順書へ反映します。
「質問された＝理解力がない」と考えるのではなく、
「手順書のどこに改善できる部分があるのだろう」
と考える。
僕自身の失敗を振り返ると、この視点がとても大切だと思っています。
引き継ぎ資料は、後任者に直してもらう
さらに僕が大切だと思っているのが、最後は後任者の目で手順書を直してもらうことです。
長年その仕事をしている人ほど、手順書の欠点を見つけにくくなります。
なぜなら、書いていない情報まで自分の頭の中で補いながら読めてしまうからです。
これは、僕自身が先輩から仕事を引き継いだときにも感じました。
先輩が作ってくれた手順書を読んでみると、僕には分からない部分がたくさんありました。
業務の流れは書いてある。でも、
「なぜそうするのか」
「どこを見るのか」
「この場合はどうするのか」
といった部分が抜けています。
そこで、実際に仕事をしながら、「ここも書いた方が分かりやすいな」と思ったところを、自分で追加していきました。
すると、最初にもらった手順書よりも、自分にとって使いやすい資料になりました。
この経験から思うことがあります。
初めてその仕事をする人だからこそ見える「分かりにくさ」は、その瞬間にしか見えないかもしれない。
慣れてしまえば、その人にとっても「当たり前」になってしまいます。
だからこそ、後任者が実際に仕事を始めた直後に、
「どこが分かりにくかった？」
「何が書いてあれば迷わなかった？」
と聞き、手順書へ反映してもらうのです。
僕は、手順書を最初に作った人が、一人で完成させる必要はないと思っています。
むしろ、手順書は、作った人ではなく、初めて使った人の目で完成させる。
それくらいの考え方でちょうどいいのかもしれません。
引き継ぎのゴールは、後任者が一人で判断できること
以前の僕は、
「手順書を作った」
「説明した」
「渡した」
ここまでやれば、引き継ぎは完了だと思っていました。
でも、今はそう考えていません。
どれだけ詳しく説明しても、後任者が仕事をするたびに、「これはどうすればいいですか？」と聞かなければ進められない状態なら、まだ引き継ぎの途中です。
仕事の目的を理解している。
基本的な手順が分かっている。
正常と異常を判断できる。
イレギュラーが起きたときには、自分で考え、必要なら相談できる。
そこまでできるようになって、ようやく自分の手から仕事が離れていくのだと思います。
もちろん、すべての仕事を一人で判断できるようになるまでには時間がかかります。
分からないことを質問するのも当然です。
大切なのは、「二度と質問されない状態」を作ることではありません。
自分で判断できる範囲を少しずつ広げていくことです。
僕が最初に作った手順書には、その視点がありませんでした。
自分が分かることを、そのまま文章にしただけだったのです。
部下から何度も質問されたことで、初めてその違いに気づけました。
だから今は、こう考えています。
引き継ぎのゴールは、自分が説明し終わることではない。後任者が一人でも仕事を進められる状態を作ることだ。
手順書を作るときは、「自分が分かるか」ではなく、「初めてこの仕事をする人が、これを見て判断できるか」という視点で、一度読み返してみてください。
そこに、これまで自分では気づかなかった説明の抜けが見つかるかもしれません。
コメント