すのふら

日々の備忘録

引継ぎって一体何を引き継げばいいんだ?

f:id:snofra:20151110011630j:plain

今月でプロジェクトを抜ける人がいて、今担当作業の引継ぎを受けている。
あれ、俺も今月で抜ける予定じゃなかったっけ? と思って聞いてみたら暫くその予定はないらしい。抜ける動き出しが遅かった……。

俺は引継ぎをするのもされるのも苦手で、引継ぎミーティングがあってもそもそも何を情報として得ればいいのか分からず
質問ありますか? とか聞かれても特にありませんとしか答えられない。
つーか実際に業務やってもいないし、作業内容聞いてもへえ以外の感想ねえよ、な感じである。

とはいえ適当に聞くとその人がいなくなった後の後任となる俺が地獄を味わうので、多分こういう風に引き継ぎはしたほうがいいのかなと思ったことをメモしておく。


■後任者はどこまでキャッチアップすることを求められているのか

当然、離任者の相互互換になるまで業務を理解してもらうのがベストだと思う。
だけど、実際少ない引継ぎ時間で今までのノウハウを全て吸収するのは結構厳しい。そもそも業務やってないんだから、その作業に対してのどのくらい工数かかるか肌感覚も分からないし。

俺が管理する側だったら、最初は時間がかかってもいいからとにかく業務がどのようなものなのか全体を理解して質問に答えられるレベルであってほしいと思う。
業務が分かっていないけど、やらなきゃいけない作業は分かりますだと、単なる作業者で終わってしまう。

作業者レベルに落ちると、なぜそうなのかあるべきを考えることができないので、目の前にある問題の正誤を判断できない。ちょっと扱いにくい人になってしまう。

恐らく後任者にまず最初に憶えておいて欲しいのは業務の全体像なんじゃないかと思う。


■どういうところを引継ぎで確認したほうがいいのか

引継ぎを受けると、業務という観点ではなく、作業の観点での引き継ぎをしがちだし、されてしまうけど本当は違うんじゃないかと思う。
作業の観点だけ聞くと、横のつながりが分からなくて説明を受けているのがどのようなことを意味しているのか、そもそも全体のどの辺の話をしているのかイメージがつかない。

今受けている引継ぎもそうで、そもそも機能間の連携が分からないのでデータベースに値がどこで格納されて、どこで使われて、結局どこへ行くのが分からず、細かいこと聞いてもクエスチョンマークしか浮かばなかった。

クエスチョンマークで引継ぎ完了はさすがに互いに時間の無駄遣いなので、とったアクションとして全体フローとデータベースの連携について時間使って確認した。
そうすると何となく聞いていて、データの流れとかがイメージしやすくなった(ような気がする)。
資料の書き方だけ教えてもらっても、これが一体どのタイミングで使われるのか分からないと、いつこの資料を書けばいいのか分からない。みたいなこと。

作業単位の話は仕様書なり手順書なりきっとある*1ので、全部聞かなくてもコアになるところ問題多かったところだけ押さえておけばなんとかなるんじゃないかなーと思う。


■引継ぎ受けるなら最低限やっておきたいこと

引き継ぎうける前に一通りその人がかかわっている資料くらい目を通すべきだとは思う。だけど正直そんな時間全く取れないのが現実だったりする。
なので用語は頭に入れてから臨んでいる。

正直引継ぎ資料見てもわかんないので、せめて用語くらい憶えてからいくと話聞いたときその言葉の意味が分からずイミフwとならないので当然、説明内容に対する理解度は違う。


■まとめ

引継ぎを受けるときの最優先とすべきことはきっと引き継ぐ業務の全体像なんだと思う。
枝葉の部分はあとからゆっくり確認できるが、根幹のところ(なぜそのような仕様になったのか)は今しか確認できないので、真っ先に抑えるべきなんだと思う。

引継ぎ受ける前に用語を憶えておくと、最初の説明の時点でのつまづかないんじゃないのかなあ。

*1:ないところも残念ながらある。そのときはソースコードなりで理解するしかない……