業務引継ぎは、仕事を見直す機会でもある――IT現場の経験から

皆さんは、退職やプロジェクトからの離任に伴い、業務引継ぎをしたことがあるだらう。

私は、情報処理技術者という仕事を続けてきたものの、転職やプロジェクト異動を比較的頻繁に経験しており、数えきれないほどの引継ぎをしてきた。

ITの場合、とりわけ私のように設計や構築を担当していると、プロジェクトを離れる際に引き継ぐものは、製品や一般的な技術情報だけではない。

その業務を通じて得られた独自のノウハウや、プロジェクトの経緯、さらには関係者との調整の中で知り得た事情など、さまざまなものがある。

これらを後任者が引き続き業務を行えるようにするためには、資料を作成するだけでなく、対面で説明し、必要に応じて実際の作業を交えながらレクチャーすることも必要になる。

ところが、引継ぎの内容というものは、相手の経験や置かれている状況によって、適宜変えていかなければならない。

あまり経験のない人に、技術的な背景や細かな事情を一から説明しても、かえって受け手が嫌気を覚えてしまうことがある。

そうした場合には、まず業務を一定のパターンに整理し、その範囲内で作業を進められるようにすることが大切になる。

一方、経験豊富なベテランに対して、「こういう場合には、こうしてほしい」という手順だけを伝えると、今度は「なぜそうするのか」という疑問を抱かせてしまうことがある。

実際、業務上行ってきたことの中には、必ずしも最善の方法ではなく、その時々の状況に応じて、やむを得ず続けてきたものもある。

そうした事情や背景まで伝えることができれば、経験豊富な後任者は、その理由を理解した上で、よりよい方法を考えてくれるかもしれない。

場合によっては、私がやりきれなかった改善を引き継ぎ、さらに作業品質を高めてくれることも期待できる。

繰り返すが、業務引継ぎの主たる目的は、これまで担当してきた人が離任しても、新しい担当者やプロジェクトに残る人たちが、支障なく業務を継続できるようにすることである。

しかし、それだけではない。

長らく同じプロジェクトに参画してきたがゆゑに、いつの間にか特定の人にしか分からなくなっている業務、いわゆる属人化した仕事を見直す機会でもある。

担当者がいなくなって初めて、その人しか知らないことがあったと気づくようでは、組織として困るのである。

引継ぎを通じて、これまで暗黙のうちに行われてきた作業を整理し、手順や資料に残すことで、業務そのものを改善できる可能性もある。

そして、引継ぎを行う側にとっても、それは貴重な時間となる。

自分がこれまで何をしてきたのか、どのような工夫をしてきたのか、何が未解決のまま残っているのか。

それらを振り返り、整理することは、自らの仕事を総括することにもつながる。

業務引継ぎとは、単に自分の仕事を次の人に渡すことではない。

これまでの仕事を振り返り、次の人がよりよい仕事をできるように、その経験を未来へつなぐことでもあるのである。