機能追加実装時のこれまでの課題

1人の担当者が実装し、すべての実装が完了した後にコードレビューが行われるという流れでした

しかし、この場合、以下のような課題がありました

上記の問題を解決すべく、タスクの分解を提案してみました

タスクを分解するとなんで上記の問題が解決するの?

機能追加チームのメンバー全員を集めて機能を説明し、やるべきことをホワイトボードに皆で書き出しました

その後、各タスクのゴールを明確にし、それぞれをissueにして優先順をつけました

これにより、以下の効果が期待できます

参加メンバーにたずねてみました!

全容を把握しやすい
- 最初の段階でタスクの全容を把握できたので安心感を持って進められた
- 複数人でタスクを分解したことによって自分では考慮できていなかったタスクの漏れなどに事前に気づくことができた
- リリースまでの残タスクが明確にわかった
ヘルプの依頼/受けが容易
- 自分が手一杯になったときに作業の分担を簡単にお願いすることができた
- 案件開始時に仕様と大枠の実装方針を共有していたため、後半に実装ヘルプに入る際にスムーズに入ることができたのでよかった
レビューしやすい
- 細かくレビューしていただくので大きな手戻りがない
- コードレビューのコストが下がった
  - レビューの単位が細かくなったため、より細かいことをしっかりレビューできるようになった
  - 誰でも気軽にレビューできるようになった
その他
- 1issue1課題にしたため、issue上でのやり取りがシンプル
  - 大きいissueだと、いろいろな話題が1つのissueで行われるため、話題がとっちらかりやすい

目論見通りの効果を感じていただけて何よりでした!

レビューが滞った
- レビューのフィードバックが返ってこないとなかなか次のタスクを進めることができないことがあった
- レビュー待ちの状態で次々とタスクを進めていくとIssueを分割した意味がなく、かえってブランチを統合するときに面倒になった
- コードレビューが遅れたため、依存関係があるissueが停滞した
細かくしすぎた
- 分割の粒度が細かすぎたかもしれない。良い点でもあるがやり過ぎるとレビューもしにくくなると感じた。スピーディーにレビュー & マージできれば問題ないが、レビュアーも業務があるため限界がある
ブランチのルールが決まっていなかった
- ブランチの分割がうまくできずにブランチの統合に戸惑った
- ブランチの切り方を最初に共有できていなかったため、ブランチの依存関係がとっちらかった
その他
- 複数人でタスクを分割していくので場所と時間のスケジューリングが必要
- 一番難しいところは、結局ベテランのメンバーが実装した
  - 本当はそこも誰でも実装できるようにしたかった

レビューを滞らせてしまったのと、issueを細かくしすぎて、さらにそれ毎にブランチを切ったためにブランチが混乱してしまったのが、今回の大きな課題でした...

ブランチの切り方を共有する
- 今回失敗したブランチの切り方は改善の余地がありそうです
- 👉 最初にworkingブランチを作って、基本的にはそこからの子ブランチとする。孫ブランチはなるべく作成しない
issueの粒度をもう少し大きくする
- ブランチ（イシュー）分割の粒度を良い感じにすり合わせる
コードレビュー
- コードのレビュー待ちの状態の時にできるタスクを用意しておいた方が待ちの時間を有効に使えると思いました
- コードレビューの時間を作る
その他
- 今回は基本的には1人の担当者が実装をしたので、もっと1つの機能をチームで実装するようにしていく