引き継ぎで困らないために、技術者が残しておきたいこと

仕事をしていると、担当の変更や異動、退職などで、業務を引き継ぐ場面があります。

FAエンジニアとして画像検査装置の導入や保守に携わっていた頃は、担当していたお客様や装置を別の担当者に引き継ぐことがありました。その後、職種が変わってITの仕事に移った際には、今度は新しい業務を引き継いでもらう立場になりました。

引き継ぐ側と受け取る側の両方を経験して感じたのは、引き継ぎで本当に困るのは、資料がないことより「資料に書かれていないこと」だということです。

手順だけでは、引き継ぎは完了しない

引き継ぎというと、作業手順や設定内容をまとめた資料を作ることをイメージするかもしれません。もちろん、それは欠かせないものです。

しかし、実際に業務を受け取ってみると、手順書があっても判断に迷う場面は少なくありません。

例えば、「なぜこの設定になっているのか」「この作業はいつから、どういう理由で行っているのか」といった経緯が分からないと、変更してよいのかどうか判断できません。手順は分かっても、その背景が分からないため、少しでも状況が変わると動けなくなってしまうのです。

引き継ぎでは、「何をするか」と同じくらい、「なぜそうしているのか」を伝えることが大切だと感じています。

残しておきたい4つのこと

引き継ぎの資料に、手順以外で残しておきたいと感じるのは、次のようなことです。

1. 経緯と判断の理由

過去にどのような検討をして、今の形になったのか。試してうまくいかなかった方法があれば、それも含めて残しておくと、同じ検討を繰り返さずに済みます。

2. 関係者と、誰に何を聞けばよいか

お客様側の窓口、社内で詳しい人、メーカーの問い合わせ先など。困ったときに誰に相談すればよいかが分かるだけで、受け取った側の不安は大きく減ります。

3. 進行中の作業や、気になっていること

完了していない対応や、まだ問題にはなっていないものの気になっている点です。こうした情報は本人の頭の中にしかないことが多く、引き継ぎで抜け落ちやすい部分です。

4. 「いつもやっていること」

定期的な確認や、ちょっとした気配りのように、本人にとっては当たり前すぎて意識していない作業です。慣れている人ほど、こうした作業を書き忘れてしまいがちです。

自分では「分かりやすい」と思ってしまう

引き継ぎ資料を作るときの難しさは、作る本人がその業務をよく知っていることにあります。

自分にとって当たり前のことは、説明しなくても伝わる気がしてしまいます。専門用語や略語も、普段から使っていると、特に説明が必要だとは感じません。

だからこそ、資料を作ったら、受け取る人に一度目を通してもらうことが大切です。可能であれば、引き継ぐ相手に内容を説明してもらったり、実際に作業してもらったりすると、どこが伝わっていないのかが見えてきます。

引き継ぎは、資料を渡した時点ではなく、相手が一人で対応できるようになって初めて完了するのだと思います。

ITの仕事でも、引き継ぎの考え方は同じ

この考え方は、ITの仕事でもそのまま当てはまります。

システム開発では、コードや設計書が残っていても、仕様がそうなった背景や、過去の不具合の経緯が分からないと、修正の判断に迷うことがあります。対応履歴や議論の記録が残っていれば、後から関わる人がスムーズに状況を理解できます。

最近勉強しているゲーム開発でも、作りかけのものを少し時間を空けて見返すと、「なぜこう作ったのか」を思い出せないことがあります。他人への引き継ぎだけでなく、未来の自分への引き継ぎも、同じように大切なのだと感じています。

まとめ

引き継ぎで困らないために大切なのは、手順を残すことに加えて、経緯や判断の理由、相談先、進行中の課題、そして当たり前になっている作業まで伝えることです。

そして、資料を作って終わりにするのではなく、受け取る人の視点で確認すること。

引き継ぎは、自分が担当していた仕事を、次の人が安心して続けられる状態にする仕事です。いつか自分が引き継ぐ側になったときのためにも、日頃から「この仕事を誰かに渡すとしたら」と意識しておきたいと思います。