業務の引き継ぎの難しさを考える

概要

現在チームが変わって業務の引き継ぎを受けている。
自分は引き継ぎを受ける側が二回目ぐらい(昨年の前チーム参画時)で、現状のつらい点、こうしたら個人的には嬉しいという点を記録する。
引き継ぐときに読み返して引き継ぎ元のチームが楽できるようにしていきたい。

つらい点

引き継ぐプロダクトの数が多い

4つのプロダクトを一気に引き継いでいる。エンジニア3人(うち一人は教育期間中の新人)、デザイナ1人なので人数が足りない。
1プロダクトに最低1人はほしい。

ミーティング多すぎ

引き継ぎミーティングがあったが、そのほとんどが、ドキュメントを見ながらそのとおりに話すというものなので、かなり苦痛だった。
しかも1件4時間くらいありかなり長い。
顔を突き合わせてドキュメントを読む必要性あるのか疑問に感じた。
言わなくても読めばわかるし、わからなかったら資料にコメントしたり、まとめて通話で質問して、それをメモすればよいと思う。

また、説明だけ受けてこれで引き継ぎは終わりです。といった感じだったので、かなり違和感を感じた。
引き継ぎの目的は、引き継ぎ元が説明することではなく、引き継ぎ先のチームが業務を遂行できることであると思う。

ドキュメントは必要であるが、そこに書いてある詳細なことはその知識が必要なときに都度調べればよい。

理想として、下記4つをこなすといいのではないかと思った。

  • 全体像・概要・役割を自分で説明できる
  • ナレッジがどこにあるか把握できる
  • 業務がリスト化されその手順がまとまっている
  • 上記手順に沿ってハンズオン形式で業務を経験する

ドキュメントが足りない・品質が低い

システム構成図、クラス図、ER図などが足りない。または古くなっている。バージョン管理されてない。
jpgになっており編集できない。

ツールは何でもいいけど、バージョン管理してて後続のチームが更新できるようになっていれば良いと思う。

リリースのハードル高杉

ブランチ運用の流れが独自運用になっててつらい。
8個くらい手順が書いてあって、「必ず〇〇すること」のように赤字で注釈がたくさんついており、運用でカバーしている様子が溢れている。
先日早速事故りそうになった。

github-flow/git-flowに寄せたい。引き継ぐとき「github-flowです」の一言で済ませたい。

今後の目標

その他にも

  • テストが書いていない
  • アプリがバージョン管理されてない
  • コードの中身もお察し

という感じで頭が痛くなってきたので一旦終了。

まずは運用周りを整備してストレスなくリリースできるところまで持っていきたい。