引き継ぎを考えているエンジニアの方へ
引き継ぎの形態には、だいたいこの3つくらいのパターンがある。
- 工程が進み前工程から人員を絞り込む（要員減）
- プロジェクト期間中に要員が離任する（交代）
- 定期ローテーションによる交代（交代）
引き継ぎは1つのプロジェクトくらいの大変さがある。その上、引き継ぎを完了したと報告を受けても実際に引き継いだ要員が引き継いだ業務を引き継ぎ前と同じように行えるか確証はない。
実際のプロジェクトで引き継ぎを受ける側になったり、引き継ぎで渡す側になったりすると、これであとやれるのとかどうなるかわからんとか思いながら引き継げたことにしていた。
引き継いで渡す側の立場で思うことは、引き継ぎは無理ゲーだなと。
- 引き継ぎを渡す側（高いスキル）と受ける側（低いスキル）のスキルセットの違いは引き継ぎで埋められない
- 引き継ぐ業務の情報（リポジトリ）が多過ぎて実態は引き継げていない
- 完了条件の間違い
- 引き継げているか検証できない
特に1つ目の項目はどんなに引き継ぎの準備と引き継ぐ時間を取ってもキリがない。何より、４番目の引き継げているか引き継いだ担当業務を一回りやらないとできているかできていないかさっぱりわからない。引き継いだ側の空手形でしかない。
こう言うと、『じゃあ、業務を標準化しておけば良いじゃないか』と言いたくなるところだが、定型業務でなければ標準化すること自体意味がないことは理解できるだろうか。少なくともコストが労力に合わない。
何より、多くのプロジェクトでは（大型でなければ）システム開発の開発作業プロセスを標準化しないし、開発標準化プロセスの標準化の必要性に気づきもしない。
現場にあるのは、そのエンジニアの独自の作業の仕方で積み上がった情報の山である。ここから考えると、以下の２点に集約できる。
と思うようになった。つまり、新任者には、『情報はここにあるからね』『インデックスはこれね』とやっておしまいでいいのではないか、と言うことであるがどうだろう。
