引き継ぎはこのくらいで十分
そろそろ年度末も近づいてくると開発案件はリリースの予定があるかもしれないし、維持管理案件でも年度で一区切りすることもあるだろう。
開発案件で如何にかこうにかリリースに漕ぎ着けられる（と言うことにしているだけかもしれない）と局面が開発から維持管理になり開発体制は縮小し維持管理体制にシフトしたりする。
こうした区切り、イベントに伴うのが人員の異動である。まあ、それに限らずメンバが入れ替わったりすることは定常的にあるといえばあるので、人事異動で慌てて引き継ぎなんて無理とか言う方がアホだとは思う（体制の構築当初から人員のリスクを織り込んでおけと言う話である）。
メンバの入れ替えでのToDo的なリストを整理したことがあったのだが、リストを書いている途中でこれは業務の可視化そのものだと思い始めてきたが一旦書き終わったらそのままだった。
リストを同じ属性でグルーピングすると案件の
- 案件の契約に関すること
- 案件のプロジェクトマネジメントに関すること
- 案件の業務に関すること
の3つに分類できた。一般的な引き継ぎの前提、つまりメンバの入れ替えや体制縮小で考えると『誰かが担っていた業務を誰かに受け渡す』活動をすると言うことになる。その観点で3番目の項目を引き継ぎと位置付けるわけだ。
ところが、プロジェクトマネージャやマネージャなどの案件の責任者を変えるとなると１まで含めることになる。本来はメンバであろうが（正社員なら）知っておかなければならないことなのだが。
特に1番目や2番目については担当者がマネージャに限られるので何をしているかさえ知らないことが多い。引き継ぎのイベントのタイミングで可視化して、それを（知って良い権限を持っている）メンバに教えておくことは割と組織の中では大事なことだと思うのである。
ところで3番目の一般に言う引き継ぎを行おうとすると実は成果物の説明になることが多い。そうした説明を受けるとプロジェクトで作っていなかった要件なり仕様なりを決めた経緯を教えろと言うことが多い。結果は何かしらのドキュメントやコードになっているものだが、なぜそうなったのか、誰がそう決めたのかはどこにも残っていない。あったとしても議事録やメールを漁らないと紐解けない。
引き継ぎ期間が長くなるのはこうした経緯を文書化するためだったり、本来反映されていなければならなかったドキュメントの更新作業の積み残しだったりする。さらにそうした引き継ぎ期間で作られる補足的なドキュメントもあやふやな記憶や文書のツギハギでパッチワークするからなかなか怪しいものである。
3番目の引き継ぎ作業で必要なことは、
- リポジトリ（構成情報）
- 分担（SOW）
の仕組みだけで良いと思う。それ以上説明しても頭に入らないし、聞き逃して終わりである。だったら、引き継ぎ期間で最小の1サイクルの業務をペアで回すのがいい。
どうせ実際にその業務をやるときにならないとドキュメントなんて真面目に読みはしないのだから。
