これは Supershipグループ Advent Calendar 2020の2日目の記事です。
Supership プロダクト開発本部にて働いておりますKujouです。
Supership入社当初はプロダクト開発に注力しておりましたが、
最近はチームを見たり、SS社内のデータ基盤運用をしていたり、採用に関わったりと幅広く仕事をしています。
今年はコロナ禍の影響なのか凄く早く感じた1年でした。
その中でサービス/プロダクトを自分個人やチームで引き継ぐということがいくつかあり、
それをうまくやるにはどうすればよかったかな、と振り返りの意味も込めてこの記事を書くこととしました。
記事で書くこと
- 引継ぎ業務を遂行する時に感じたことの振り返り
- その時に準備してあると良いなと思ったこと
引継ぎは様々な場面で起こる
「引継ぎ」は大小さまざまなパターンがあると思いますが、多くの人が経験していると思います。
- 新しい人が入社して、作業の引継ぎをする
- 新しい部署が出来たり、サービスを立ち上げたりして異動のために引継ぎをする
- 業務効率化のため、同じような作業を集約させるときに引継ぐ
- 退職のために引き継ぐ
などなど、引継ぎが発生する場面を挙げていったらキリがないですが、
今回は特に「サービスやプロダクトの開発者としての引継ぎ」に焦点を当ててみようと思います。
引継ぎには段階がある
プロダクト開発やサービスの開発側として引き継ぐときに感じたことは、
引継ぎには大きく分けて3つくらいの段階があるということでした。
それは、
1. 作業の引継ぎ
2. コミュニケーションの引継ぎ
3. 意思決定の引継ぎ
という段階です。
作業の引継ぎ
最初は「作業の引継ぎ」です。これはもっとも基本となるところで、現在開発しているプロダクトの中で、
開発者が実際に手を動かして書いていたコードを修正したり追加したり、調査をしたりするという作業です。
この作業を引き継いだ人も正しく出来ることが「作業の引継ぎ」となります。
そこでは、以下のような部分が最低限必要かなと感じます。
- プロダクト/サービスで動いているコードが管理されていること
- それぞれにテストコードが存在し、CI上で動かす管理がされていること
- 機能の仕様が書かれたドキュメントが存在し、正しく最新の状態を表していること
もう少し細かく言うと色々出てきますし、
コード上のclassの役割の正しさとか命名とか「理解しやすいコード」などはあると思いますが、
本題としては少しズレるので割愛します。
上記に記載した部分はコードの修正や追加などをスムーズに行うには必須ともいうべき部分であり、
今更書くことでもないのですが、仕様などのドキュメントは最新のものを意外と管理できてなかったりするので
変更作業の中にドキュメント更新までを含め、一連のフローにしておくと良いかと思います。
コミュニケーションの引継ぎ
続いては「コミュニケーションの引継ぎ」になります。
開発側は1人ということはあるかもしれませんが、あるサービスやプロダクトを開発する現場においては、
多くの人は1人ではなく、チームとして仕事をしているかと思います。
ビジネスサイドのメンバーやクライアント、状況によってはサービスを運用するメンバーや、
開発側でも役割によってはいくつかの領域に分かれるなど1つのチームとして対応することが多いのかなと。
そこではビジネスサイドやクライアントからの質問、運用メンバーから仕様の質問、
開発メンバーからの疑問など、様々なコミュニケーションが発生します。
それをきちんと引き継いだ人が対応出来るようになることが「コミュニケーションの引継ぎ」となります。
その中では以下のような部分が整理されていると良いかなと思っています。
- ビジネスメンバーが入力するQ&Aシートなど、今まで行われてきた質問とその対応
- コミュニケーションを行うことで発生した問題を開発側でissue化している、もしくは自動でissue化するなどの仕組み
おそらくslackを使って仕事をされている方も多いと思いますし、とても便利だと自分も感じますが
ある質問がslack会話だけで終わると、サービスやプロダクトとしての知見が貯まらないこともあるので注意が必要です。
重要なのは過去どういったコミュニケーションが行われていたかをきちんと可視化しておくことにより、
その向き先が変わっても同じように対応出来るようになるように準備しておくことですね。
意思決定の引継ぎ
プロダクトの仕様/機能の理解が進んでいくと実際の作業やコミュニケーションを対応出来るようになります。
これに加えて具体的なアーキテクチャや利用している技術の決定理由、そのシステムが作られた背景を深く理解することで、
「そのプロダクトやサービスをどうしていくべきか」という「意思決定」が出来るようになります。
この引継ぎの最終段階とも言えるのが「意思決定の引継ぎ」だと自分は感じました。
ここでは「インセプションデッキ」をきちんと作っておくこと、適宜見直すことがかなり有用だなと。
インセプションデッキがどういったものであるかはここでは割愛しますが、その中の項目として抜粋しますと、
「我々ははなぜここにいるのか」
プロダクトやサービスが作られた背景を理解することに役立つ
「エレベーターピッチ」
このプロダクトの強みの理解、より強化していくべき部分の理解に役立つ
「夜も眠れなくなるような問題はなんだろう？」
システム的に最低限担保しなければならない部分の理解、さらに言うと妥協できる部分の理解に役立つ
などなど、プロダクトを開発するということだけでなく、
引継ぎなどそれ以外の場面でも有用な情報がまとめられていますので、
仮に社内システムであってもインセプションデッキを正しく作り、更新していくことは意味があることかと思います。
そういった情報を引き継がれた側が正しく理解すると、ある問題が起こったときにシステム的にどうすべきかという
「意思決定」が出来るようになります、ここまで行えるようになれば引継ぎは完了したと言っても良い状態になると思います。
総論
引継ぎに関しては現場で色々と発生していると思うのですが、こういったことを意識すると、
スムーズに引き継げるのかなと思い改めて振り返ってみました。
新しい業務や人を受け入れる体制などを整えると共に、いつか発生する引継ぎも意識して整理していきたいですね。
Supershipではプロダクト開発やサービス開発に関わる人を絶賛募集しております。
ご興味がある方は以下リンクよりご確認ください。
是非ともよろしくお願いします。