業務引き継ぎの際の考慮ポイント

この記事は#エンジニアと人生 #2 Advent Calendar 2022 の11日目の記事です。

18日目は 大庭 慎一郎 さんの Bluetooth LEと人生でした。

---

h1d3mun3です。

自分が担当していた業務を引き継ぐ必要があったので、そのときに何を考えていたのかとか、何をゴールとして引き継ぎをしたのかなんかをブログに残そうと思います。

業務の引き継ぎにおいてのゴール

業務の引き継ぎ後の状態とは色々あると思いますが、ここでは2つに分割して考えようと思いました。

1. 引き継いだ担当者が、一旦は業務を実施できる
2. 引き継いだ担当者が、業務の発生した背景を理解して業務を遂行できる状態になること

後者の状態になることを目標として引き継ぎ作業を行いました。

一番最初にやったこと

引き継ぎ業務の中から、重点的にコミュニケーションする対象を決める

メンバーのスキル感に濃淡はありますし、自分が担当している業務であったとしても、別の担当者でサポートができるような業務もあるだろうと考えて、自分が担当している業務の中でどの業務を重点的にコミュニケーションを実施して引き継いでいく必要があるかを検討するため、どのような業務を引き継ぐべきか確認したところ、下記二つがメインとなることがわかりました。

• アプリチームとしての業務
• iOSアプリチームとしての業務

今回の場合は

• iOSアプリエンジニアとAndroidアプリエンジニアが1つになったチームに所属していた
• iOSアプリ関連について、歴史的な経緯や技術的な現状に精通したエンジニアが少なくなってしまう

というケースだったため、アプリチームとしての業務についてはチームに残るメンバーにサポートをお願いするかたちですすめ、僕の方からはiOSアプリエンジニアとしての業務について重点的にコミュニケーションを行い引き継ぐことにしました。

具体的な作業をリストアップしていく

具体的にどのような業務を引き継ぐべきかを一旦僕の方でリストアップしていきました。

「僕の目に入っていないけど大事な作業もきっとあるはず」ということで、一旦リストアップが完了したあと自分が所属するチームの上長や同じチームのメンバーとも、調整しながら重点的に引き継ぐ業務を洗い出して行きました。

このように自分以外のメンバーからも意見を聞くことによって、いざ業務の引き継ぎが完了したあと、「やっぱこれわかんないんだけど！」という事態の発生を避ける事ができると考えています。

引き継ぎ先を決める

ここまでで、重点的にコミュニケーションを行なう必要のある引き継ぎはリストアップできたので、誰に業務を引き継ぐか、を検討しました。

今回僕の場合は属人化させるとかえって悪影響が出ることが想定される業務がほとんどだったため、引き継ぎ対象の業務全てをチーム全体に対して引き継ぐことにしました。

ススメカタを検討する

引き継ぐ業務と引き継ぎ先が決まったので、具体的にどうやって引き継ぐかを検討しました。

引き継ぐ業務を確認してみると、作業に慣れが必要などの理由ですぐに作業を引き継げないものや、ドキュメントを読めばなんとかなるものなど、引き継ぎ作業の難易度に濃淡がありました。

これらを踏まえた上で、下記のような戦略で引き継ぐことにしました。

• 記録が必要なものについてはなにかの媒体で記録を残すようにする
  • 今回はGitHub Issueや、各種ドキュメントサービスなど、開発で利用しているサービスをメインに記録を残しました。
    • EX: 年度末自己分類報告書を送ったこと、リリースブランチを作成したこと、App Store Connectにバイナリをアップロードしたこと・・・etc
• ナレッジを残す必要があるものについては、ナレッジを可能な限り細かく残す
  • チームで利用していたドキュメントサービスがあったので、そちらに詳細にナレッジ・ドキュメント・議事録などを残しました。
  • ドキュメントは残したあと、GitHub Issueに「ドキュメントを残したこと」を記録で残すとともに、スクラムで言うDaily Standupなどの場でチームに展開し、「残したドキュメントを誰も読んでいない」という事態を避けるようにしました
    • EX: なぜこのやり方を採用したのか、このときのBiz側の要求はどのようなものだったのか・・・etc
• 難易度が高い業務については、上記すべてを実施した上で、説明会を実施しました。
  • チームで利用していたドキュメントサービスがあったので、そちらに詳細にドキュメントを残しました。
  • その上でGitHub Issueにドキュメントを残したことを記録で残しました。
  • 残したドキュメントを事前に共有した上で、チーム全員でMTGを実施し、実際に画面共有をしながらドキュメントに残した作業を実施し、チームメンバーの理解がなるべく深くなるようにしました。
  • 「一回共有しただけでは本当に実施できるか微妙な作業」については、更に追加で「実際に引き継ぐ人が同じ作業をドキュメントを見ながらやってみる」という会を別途設定し、実際に作業ができることを確認しました。
    • このときチームメンバーが見落とした作業がないことや、勘違いなどを防ぐため、僕も参加し、オブザーバー的に作業を確認していました。

また、引き継ぎが適切に実施できたことを確認するため、下記も実施しました。

• 上記を実施した上で、1週間ほど僕が作業を一切実施せず、すべての作業をチームメンバーに任せてみて、適切にチームメンバーが業務を実施できることを確認する期間を設定

そして引き継ぐ・・・

ここまでで全てできているので、あとはやるだけでした。

引き継ぎ後に設定していた1週間の期間も引き継いだ作業については、適切に回すことができました。

引き継ぎを終えてみて

当初計画していた引き継ぎについては概ね予定通りに引き継ぐことができました。

その一方で、チームメンバーが変わったことや、アプリの状況も変化するなど、業務の環境が変化し別途調整する作業が発生してしまうなど、臨機応変に対処しなければならない事案も発生してしまいました。

そのため当初の計画外の部分で、準備が不十分な状態で引き継いでしまったものや、引き継ぎの際の説明が足りなかったであろう部分もおそらくあり、チームメンバーに対しては申し訳なく思っています。

このような振り返りもありますが個人的には概ね適切に業務を引き継ぐことができたのではないか、と考えています

業務を引き継ぐ際は、なぜこのような業務を行っているのか・この業務によって解決したい課題はなにか・業務の社内的/チームコンテキストなど、様々な情報がありますがどのように引き継いでいくかを適切に検討することによって、引き継ぎの際のネガティブインパクトを最小限にすることができる、ということが学べました。