転職。引継ぎ。残されるもの。 続編。
誰かが抜けると誰かがその穴埋めをしなければなりません。
その人が抜けると同時にそのシステムが消滅してくれれば都合が（？）良いのですが
そうもいかないわけです。
誰か新たに人を入れるにしても、入ってすぐにその業務を引き継ぐ事もできません。
引き継ぐ事を前提に人を入れる事もありますが、それで引継ぎが完了したからと言って
その人に全ての責任を背負込ませるのは少し酷というものでしょう。
（そして完璧に引継ぎが完了する時間は大抵ありません）
つまりある程度そこで業務をこなしてきた誰かがその業務を引き継がなければなりません。
引継ぎ。この内容はその業務により様々です。
その人が抱えてきた業務を全て引き継ぐわけです。（厳密に言えば不可能に近いことです）
プログラム、設計書、運用業務、運用マニュアル、サーバー、ネットワーク、業務に関連する人との
人間関係に至るまで。etc・・・。etc・・・。
これはほとんどその人がその会社で働いてきた歴史そのものを引き継ぐ事になります。
責任と言うものもその中の一つです。
それぞれ役割が決まって働いているわけですから、その業務を行う上での責任があるわけです。
引継いだというからには、その責任をもってその人の業務を変わって行っていく事になります。
システム開発の現場にあってありがたくない引継ぎの一つがバグです。
他人が設計し構築したシステムなのに、引継いだ後に出たバグはその人が対応する事に
なったりします。そして、そのバグ自体の責任もまたしかり。
（私論をいうと、これでああだこうだは言って欲しく（言いたくも）ないんですがね・・・。）
バグがゼロというシステムはほぼありません。（当然そういうものだといって構築する事は論外ですが）
そしてこういうものは、その当の本人が辞めたり抜けたりした後に、発見される事が多々あります。
これには、当時の開発手法が悪かったり、開発やテストの責任者の進め方が悪かったりと
歴史的な背景があったりするわけすが、それに対して今責任を持っている自分が文句を言っても
はじまりません。
こうした引継ぎをスムーズに行うためには、開発や運用業務の手法を平準化すると言うことが
その一つにあげられると思います。
それこそフローを辿っていけば、誰でもできると言う事が理想の状態となります。
開発手法の平準化としては、コーディングや命名規則、フレームワーク
の導入、設計書（マニュアル）の
テンプレート化などがあげられると思います。
もう一つは、ナレッジの共有でしょうか。
業務に関わるノウハウを集約し共有する事です。
平準化により、対応のフローなどが明確になりますが具体的な対応方法などは、そのフローの中に
全て組み込むわけにも行きません。
サポートの業務などであれば、対応方法はその内容により千差万別です。
それらのノウハウを蓄積し共有する事で引継いだ後でもどのように対応したかが明らかになります。
もっとも、こうした引継ぎというのはある意味無駄を引き起こします。
「引継ぐ」と言う業務自体、その会社にとってなんらメリットがあるものではありません。
短いスパンでこの引継ぎというものが発生すれば、かなりの無駄が生じます。
（引継ぐ人と引継がれる人、2人の時間が消費されるわけですから）
一番良いのは辞めてくれない事です。
当然その人の人生、あれこれ制限する事は会社にありませんが、転職すると言う事が当たり前の
様にに考えられている昨今、会社を離れていく一番の理由は、その会社での自分の評価や
自分が行っている業務に魅力がもてない事だったりするのではないでしょうか。
こうした、引継ぎの無駄を抑制するには会社自体が、その人を何時までもこの会社で働いていたい
と思わせるような職場作りをする必要というものがあるのではないでしょうか。
