「人数半減の中で総開発量UPを実現させた秘訣 by エイチームコマーステック Advent Calendar 2023」の4記事目(8日目)は村林がお送りします。よろしくお願い致します！
私たちのチームでは、常に開発後にメンバー間でコードなどのレビューを行っています。問題がなければそのままリリースを行いますし、問題があれば解決されるまで、修正、レビューを繰り返します。
今日から2日間に分けて施策リリースまでの1つの重要な工程である「レビュー期間」の短縮というテーマで書かせていただきます！レビュー期間が延びがちという方はぜひ読んでいただければと思います！よろしくお願い致します！
なぜレビュー工程を効率化したのか・効率化してどうなったか
ここから2記事にわたってレビューについての記事を書いていきますが、本題に入る前に「なぜレビューの効率化を重点的に行ったか」について多少触れておきたいと思います。
重点的に効率化を行った理由を一言で言えば「レビュー工程が最も非効率だったから。」に尽きます。ソースコードが完成したと思ってから、レビューを出し、リリース準備完了までの期間は、大きな改修でなくとも1週間以上かかることが良くありました。また時間がかかるだけではなく、レビュー・修正にかかる期間が全く読めないという問題もありました。レビュー・修正にかかる時間を読み誤ると、次の施策のスケジュールにまで影響を与えスケジュール調整に時間を要するということも多く経験してきました。
レビュー期間の短縮に力を入れたことにより、昔は1週間以上かかっていたレビューも今では感覚値ですが2営業日程度で完了させることができ、リリース遅延も減少したことによりスケジュール調整工数も大きく抑えることができました。
レビューの大敵！設計変更
なぜレビュー工程に大きく時間がかかっていたのか？その原因の一つに「設計変更等、大きな変更をレビュー工程で指示せざるを得なかったから」があります。
「もうすぐリリースできる！」と開発者が思っていても、実際にレビューに出したら「このライブラリはあんまり使用するべきではないですね。。。ライブラリの選定を変えてください！」と言われれば、修正・再レビューに時間を要するのは容易に想像できるかと思います。単なるコードの変更ではなく、設計の変更、技術選定の変更、仕様の変更をこのコードレビューで要求していたことがレビュー期間に時間を要していた原因の一つです。
最終段階から設計段階に戻らないために
このような問題は、開発に着手する前に設計など大枠の開発方針を各メンバー相談し合意をとっておくことで解消することが可能です。ということは、多くの方が理解できる基本的なことかと思いますが、なぜ当時はやれなかったのでしょうか？その理由は下記のようなことがあったかと思います。
- 相談すべき相手が忙しいかもしれないと思って相談できずにいる
- 誰にどのような方法で相談すればよいのかがわからない
- メンバー全員に相談する機会が少なく、待っていると開発スケジュールが遅れてしまう
- 相談が必要なこと(ほかの人が別意見を持っていること)だと気づけない
- などなど
2記事目で触れた朝会を手厚くしたことによって、毎日のように自分が担当の施策の実装方針の相談ができる機会が生まれたり、タスクボードによって他のエンジニアが何をやっているかの透明性が増したことによって、「躓きそうだから先に設計方針を聞いておこう」等レビュアーが先回りすることが可能になりました。
もちろん、「大枠の開発方針の事前合意をとっておいた方がよい」という共通認識があることが大前提になりますが、コミュニケーションの見直しがこれらの改善に大きく寄与しました。詳細はぜひそちらの記事をご覧いただければと思いますが、まとめると下記のようなことが貢献したかと思います。
- 誰もが気軽に相談ができる機会を毎日作った
- 他メンバーのタスクの見える化によって、周りのメンバーがフォローできる体制を作った
事前合意をとるべき対象は何か？
「開発着手前に大枠の合意をとるべき」という話を今までしてきましたが、大枠とは何でしょうか？1～100まですべて合意をとるとそれはもはやコードレビューと変わらないですし、少なすぎてもレビュー段階でひっくり返りで戻りが大きくなることになります。
大枠の定義はチームとして正解がこれだ！というものを定義したわけではないですし、厳密なルールとして運用しているわけではありませんが、一つの目安として我々のチームでよく議論の対象となっているものを例示させていただいています。
- 要件の問題点と回避策
- DBのスキーマ構造
- フロントエンド/バックエンドの役割分担
- APIのI/F
- 使用ライブラリ
- その他プログラム全体にかかわる意思決定
最後に
これらのコミュニケーションの工夫によってレビューの時間が大幅削減できました。大きな手戻りを発生させないのが、効率的なレビューを行う上での第一歩になりました。
「最終段階のレビューで何とかする」という流れを是正し、「レビューは設計に関するレビューなら開発前のフェーズに行うなど、フェーズごとに細かな単位で実施する」という流れにもっていくことで、大きく効率化を達成しました。
今回の記事では出戻りが大きな指摘をどう回避するか？という話を記載しました。次回記事では細かな粒度の話について書いていきます！もしご興味がありましたら次回記事もご購読いただければと思います！よろしくお願い致します！