この話は業務によります。
経理のようなものだと、月単位にサイクルがありますので、日次業務、週次業務、月次業務が存在します。
ですからその場合は1か月が適切だということになります。
もちろん決算だとか四半期での報告会の仕事まで見たら1年になりますけど、そこまでスパンが長い仕事は、引き継ぐという性質のものではなく、毎年調整するべきものになります。
まあひと月です。日常経理に起きるすべての事態を目撃させながら引き継ぐことができますので。
普通の事務職ならまあ1週間。
これらは、業務のライフサイクルからくる話です。
しかし、例外があって、引き継ぎ相手と現場を退くものが同じ期間に同席しないのなら話は別です。
その場合は数日です。といっても1日か2日です。
前任者が、業務上のこぶのある場所を説明した資料を作るだけになりますから。
往々に派遣の仕事の引き継ぎがそういうことになります。
完全にバトンタッチで交代するということを要請されますから、前任者と後任者は同じ空間に居ない。
実際のところ、きれいな引き継ぎは不可能です。
どうしても自分が手をつけてやってみると不明点疑問点が出るものですし、一度理解したと思ったことが違った温度の話だったりしますので。
前任者も後任者も正社員で、単純に異動で仕事を引き継がれる場合は、どうしてもわからなくなると別部署にいる前任者に連絡を取って聞いたりすることが発生します。
この場合は1年たってもきっちり引き継ぎ終わらないというような見え方になります。
前任者が退職する場合、は、今言ったパタンに近くなります。
正式な引き継ぎは数日から2週間ぐらいでやるとしても、わからなくなって退職した人間の自宅に電話して質問するということをひきずります。
ソフト開発なんかの引き継ぎは、基本的に不可能と考えたほうがいいのが事実です。
仕様書設計書類がありますと、まあそれを見ればいいから引き継ぎ期間なんて数時間で大丈夫です。
しかし、まともにそういう書類が矛盾ない状態でそろっていることが少ないですから。最悪設計書自体がまともな形になっていないこともありうる。
最悪ソースのコメントを見ろといって退社するプログラマなんて結構多い。
結局引き継いだ人間が全部読み直し自分の手を使って実験し、ところどころ直しながら自分のものにすることで、業務の引き継ぎにはなります。
そのかわりノウハウの引き継ぎということにならないのがほとんどです。
引き継ぎ期間なんて、1週間でも1日でもおんなじです。
公式の引き継ぎ期間というのはまあ1,2週間と考えるのが無難でしょう。
お礼
ありがとうございました。