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

概要

業務引き継ぎ時に遭遇しがちなケースとその解決策ついて自分の思っていることをまとめる。
あくまで自分の意見である。

問題点

プロダクトの数が多い

プロダクト数にたいしてエンジニアが足りないケース。

1プロダクトに最低エンジニア1人ほしい。

メンバー総入れ替え

プロダクトのメンバーが一気に入れ替わるケース。

例えば、暖簾分けのように、プロダクトに習熟した人、新しく参画した人を同時に在籍させ、半年以上教育したのち、習熟した人を入れ替えるという流れだと望ましい。

ミーティング多い&長い

  • 引き継ぎミーティングが1時間以上/件、複数件/日
  • 内容は用意したドキュメントを読むだけ

といったケース。

事前にドキュメントを読んでおいて、わからなかったら資料にコメントしたり、まとめて通話で質問して、それをメモするのが望ましい。
ドキュメントは必要であるが、そこに書いてある詳細なことはその知識が必要なときに都度調べればよい。
最初の顔合わせには必要性を感じる。

説明することが目的になっている

説明だけ受けて「これで引き継ぎは終わりです」といったケース。

引き継ぎの目的は、引き継ぎ元が説明することではなく、引き継ぎ先のチームが業務を遂行できることである。
例えば、下記4つをこなすといいのではないかと思った。

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

システムに対する認識の相違

「このシステムは面倒をみることがほとんどないので楽ですよ」といったケース。

裏を返せば運用・改善・監視がほとんどされておらず中身が良くない状況になっていることになる。
エンジニアには、「面倒をみることがほとんどがないので楽」というような状況はまずいということを説明していく責任があると感じた。

ドキュメントが足りない・編集できない

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

ツールはなんでもいいが、バージョンを管理し、後続のチームが更新できるようになっていれば望ましい。

リリースのハードル高い

ブランチ運用の流れが独自運用になっているケース。

例えば、手順が多く(5個以上)、「必ず〇〇すること」のように赤字で注釈をつけ運用でカバーしている。
これでは手順の間違いによる事故を招くことが容易に想像できる。

GitOpsなどを導入し、なるべくミスが起こりにくい、起こっても即座に巻き戻せるような手順が望ましい。 ブランチ運用はなるべくgithub-flow/git-flowに寄せるのが望ましい。 こうすると、引き継ぐときも「github-flowです」の一言で済む。
もし上記のブランチ運用フローで解決できない場合は、独自のブランチ運用フローを考えるのではなく、業務フローの方を見直すことも必要である。なぜなら、GitHub社と自社を比較した場合、ほとんどのケースでソフトウェア開発の知見はGitHub社のほうが多いため。