転職する理由というのは人様々だと思いますが、転職するという事は本人だけの問題
ではなく残された側にも大きく関わってくるものがあります。
一つはその人が抱えている業務を誰がどのように引き継ぐか。
進行中のプロジェクトがあるのであれば、それを引き継ぎ滞りなく最後まで進め
なければなりません。
システム開発・運用の現場では、その人が途中まで作り上げたコードを引き継いで
開発を進めなければならない場合もあります。
運用中のシステムであれば、そのシステムの全体像を把握した上で、定常的に
発生する運用業務とその作業内容を引き継ぎシステムが停止する事無い様に
運用を行わなければなりません。
また、その本人のみが抱え込んでいる業務というのも多数あったりもします。
一つの業務を複数の人で共有しながら行うという事が体制的には望ましいですが
コスト面からそのような体制は取られておらず、属人的（トラックナンバー が1）な業務
というのが存在するというのは良くあるのではないでしょうか。
そのような業務を全て全て吸収しておかなければ、その人がいなくなった後に問題が
表面化するということが良くあります。
前の人が引き継いでくれなかったから・・・と言っても仕方ありません。
今業務を行っているのは自分自身なわけですから、引継ぎを行う期間内で疑問点を
その本人に投げてまとめておく必要があります。
と言っても引継ぎの期間が非常に短い場合もあります。
引継ぎの期間がそれなりにあると言っても、複数・複雑な業務を引き継ぐ事になると
どうしても表面的なことしか引き継げずに、コアな部分が引き継げない事もよくある事です。
このような問題でその時にあわてないためにも、日ごろからそういったことに対する
備えをしておく事が大事だと思います。
運用においてはマニュアルを整備したり、プログラミングにおいては開発規則を整備して
誰が見ても分かりやすいコードを書くように徹底したり、プロジェクト全体としては誰かが
抜けても差し支えの無い体制を整えておいたり、メンバー間で関連のある業務について
コミュニケーションをとるようにしたり。
が、先ほども言ったとおり体制はほとんどの場合で、そのメンバーの誰かが辞めても
滞りなく業務が行えるように、と言った具合にはなっていません。
当然、誰かが辞める前提で体制など整えられるかと言う意見もあるかもしれませんが
辞めないにしても誰かが病気をして、長期離脱する事もあるわけです。
そういったことを考えずに、そうなった場合に考えようと言う事で大体の場合、業務が
行われていたりします。
（そして残されたメンバーがかなりの犠牲を強いられます・・・）
また、やめる側もなるべく早い段階でその業務に関連するメンバーに辞める事を伝え
引継ぎの期間を十分に取るようにした方がよいでしょう。
あまり引継ぎに対する意識が無く、さっさと辞めてしまうとその職場のメンバーとの
人間関係も悪くなってしまいます。
辞めてしまえば関係ないということではありません。
世間は狭いです。転職先の会社が取引先だったりする事もありますし、何時どこで
またパタッと会うかも分かりません。
その時に、あの時は・・・と言うような事を言われないためにも、立つ鳥跡を濁さずで
スマートな退職と言うものをしたい（していただきたい）ものです。