はじめに
はじめまして。プラットフォーム事業本部の室木(@masa-m)です。 DMM.comのDMM PointClub Groupにて、GroupLeaderの補佐をしています。 ここ数年は、新組織の組成や組織統合によるプロダクトの引き継ぎが多かったため、 今回はお互いに不幸にならないためのプロダクト引き継ぎノウハウをこちらで共有したいと思います。
引き継ぎが発生する状況について
システムエンジニアを数年やっていれば多くの人が経験していると思います。 私自身の経験で言うと、下記のようなものがありました。
- 退職、契約期間が終了した時に自分が担当していたシステムを引き継ぐ
- チームが別のプロジェクトにアサインするため保守していたプロダクトを他チームに引き継ぐ
- 部署の統廃合により類似プロダクトを集約。業務の効率化を図る目的で引き継ぐ
- 他部署が利用するプロダクトを構築・保守していたが、新部署を作成し内製化を行うため引き継ぐ
1のケースでは、属人化してなければ他の人もある程度状況を把握できていると思うので、 集団で退職とならない限りは、引き継ぐ範囲は小規模になると思います。 今回の記事では、主にチームからチームにプロダクトを引き継ぐ2〜4の場合を想定しています。
引き継ぐ際に注意すること
| NO | 注意点 | 理由 |
|---|---|---|
| 1 | 実務の引き継ぎは、実務担当者が決まってから始めること | 引き継ぐことは決まったが、担当者が決まってない場合があります。担当者以外に先に説明を行った場合、実務担当者への再説明になり二度手間になることが多いです |
| 2 | 実務担当者が付くまでの間は必要な資料を作成・共有し、質問があればQAシートに記載してもらうこと | 実務担当者が付いたあとも必ず必要になるため、予めQAシートを作ることで同じ質問と説明が発生する手間を減らせます |
| 3 | フロントエンド、バックエンド、インフラ、運用などの区分ごとに引き継ぎ元の担当者を付け説明会を実施すること | そうすることで、どの区分の相談を誰にするかが明確になり説明会後の相談がスムーズになります |
| 4 | 説明会や定例作業は動画として残し、あとから引き継ぎミーティングに参加してないメンバーにも閲覧可能にすること | おすすめのツールはZoomです。画面の操作だけではなく、その作業の経緯や現在の状況についても言葉で記録が残せます |
| 5 | 説明会などは動画に残すことを引き継ぎ先のチームに伝え、ミーティング参加メンバーは最小限に抑えること | 引き継ぎミーティングに参加するメンバーが増えれば増えるほど、スケジュールを押さえることが難しくなりリードタイムが伸びます |
| 6 | チャットツールでは引き継ぎメンバーが全員揃っているチャンネルを作成し個人宛のダイレクトメッセージを避けること | 相談された内容を全員が見られるようにすることで、説明の二度手間になることを減らせます。 |
引き継ぎの流れ
各工程の期間は引き継ぐプロダクトの大きさにもよるため、保守しているチームと 引き継ぎ先のチームで話し合って決めるのが良いと思いますが、私自身が「上手く引き継げたな」と思えている実例での工程を以下に紹介します。
1.資料を作成しQAシートの質問欄に記載してもらう
QAシートに記載してもらうために引き継ぎ元チームがすること
- 資料に不足があれば作成し、更新が止まっているものは最新化する
- 運用期間が長いものでは資料も結構散らばっていると思うので、リンク集を作成する
リンク集を作成する区分の例は以下のようになります
- 構成（サーバ構成、システム構成等）
- 機能
- 運用（保守業務）
- コミュニケーション(プロダクトに関連するチャットツールのチャンネルについて)
- 我々が認識しているプロダクトの残課題
2.ソースを読んでもらったあとに説明会の実施
説明会前に実施すること
- ソースを更新できる状態にするためにアカウントの準備を済ませておく(GitやCIツール)
- パブリッククラウド（AWSやGCP)のアカウントも準備を済ませておく
説明会を実施する内容の例は以下のようになります
1.インフラ
・インフラ構成
2.フロントエンド
・概要
・機能
・アーキテクチャ
3.バックエンド
・概要
・機能
・アーキテクチャ
4.定例運用について
・定例業務の概要
・関連チャンネルの概要(チャットツール)
5.管理画面系(CRM)
6.残課題・残作業。
上記内容で説明会を設ける旨を引き継ぎ先チームに伝え、「こういうことも説明会で触れて欲しい」などの要望があれば、適宣追加します。
3.共同運用期間
共同運用中にどこまでやるかは引き継ぎ元・引き継ぎ先のチームで相談します。 例としては下記です。
- 問い合わせの相談対応と変更したソースのレビューだけ引き継ぎ元チームで行う
- 数ヶ月の間は定期的に引き継ぎ元チームからのモブプロのサポートを実施する
- しばらくの間は窓口だけ引き継ぎ元チームに継続してもらい、ソースの変更に関してのアドバイスを行う
4.引き継ぎ完了
共同運用期間に引き継ぎ元チームへの質問や相談が減ってくると思うので、 無事に引き継ぎ先のチームで自走できれば完了です。
まとめ
引き継ぎはわりと短期間に行われることが多く、引き継ぎ先はちゃんと運用できるのか不安が多いと思います。 引き継いだあとにトラブルが多発し、引き継ぎ元のチームの対応が頻発するなど、 お互いが不幸にならないように細かな部分までしっかりとすり合わせることが必要だと思います。
最後に
私の所属するプラットフォーム事業本部では、一緒に働いてくれる仲間を探しています。 少しでもご興味のある方はぜひご応募ください！
