こんにちは、hacomono開発本部フィーチャー部フィーチャーチームのすがじゅんです。
私の所属するフィーチャー部では直近、開発設計レビューを定例化したので今回はそのお話をしたいと思います。
いままでどのようにレビューしていたか
これまでフィーチャーチームでは中規模開発（社内では中玉案件と呼んでいます）以上では必ず設計レビューを実施しようね、という流れになっていました。
中玉の開発担当になったメンバーは設計と設計書作成を行い、各メンバーの予定を確認してMTGの場を設置し、1時間程度でgoogle meetやslackのハドルミーティングでレビュー会を実施していました。
何が問題だったか
社内には相当数の開発タスクが存在しており、どのチケットが要設計なものなのかが明確になっていませんでした。そのためレビューが実施されるのは「誰が見てもこれは設計が必要だよね」というチケットに限定されていました。
小さな案件の設計レビューに多くのメンバーを招待して時間を取るのをためらうこともあり、結果的にレビューの機会そのものが少なくなっていました。
設計のレビューを行わないことによる問題点
- 設計が開発担当者の思考に依存する
- 特定機能への影響が読み切れずデグレやバグ発生の可能性が高まる
- 設計上の問題に気付けずに、実装後のfix作業が起こりやすくなる
このように設計 → レビューを行わないことによる問題は多分にあると思います。
定例化しました
だったら定例にしてしまおうと思い、フィーチャーチームでは毎週月曜日と水曜日に定例レビューを設けることにしました。議題があるメンバーは当日12:00までにslackのリマインダーに返信してレビュー開催の旨を共有することにしています。特に議題がなければスキップです。
定例化した結果
そもそも定例化されてるのでメンバーの予定は抑えられています。そのため「これ設計レビューしたいな」というものがあったら気軽に開催しやすくなり、結果として開催頻度が増えました。
ちなみに私のチームでは毎週木曜日に週次の定例もあるのですが、そこでも議題があったらレビューできるので週3回レビューの機会があることになります。
ちなみに過去参加者0だったとかそういうことは起きていません… 笑
開催されると積極的に集まってきてくれています。
まとめ
設計の精度をあげることはよりよいプロダクトに直結します。レビュワーにとっては他の機能の内部構成を知るいい機会にもなります。
より良い運用になるよう今後もブラッシュアップしていきたいと思っています！
株式会社hacomonoでは一緒に働く仲間を募集しています。
エンジニア採用サイトや採用ウィッシュリストもぜひご覧ください！
