はじめに
DMM.comでDMMポイントクラブのAndroidアプリ開発を担当しているmitohato14です。
本記事では、DMMポイントクラブのAndroidアプリ開発におけるAIコードレビューの取り組みを紹介します。口頭レビュータイムやPRテンプレートといったプロセス面の工夫に加えて、AIコードレビューツールであるCodeRabbitを導入したことで、コードレビューの質と速度、そしてチームの開発体験がどのように変化したのかをお伝えします。
過去に執筆した以下の記事・レビューも併せてご覧ください。
・ CodeRabbitと過ごした1ヶ月 ─ AIコードレビュー導入で実感したチーム開発の進化（DMM Developers Blog）
・ CodeRabbit、実際どう？ ─ チームで使ってわかったAIコードレビューの効果とコツ（Findy Tools）
チームとレビュー体制
チーム構成
DMMポイントクラブのAndroidセクションでは、基本的に4名の開発メンバーでコードレビューを行っています。
| 役割 | 人数 | 主な役割 |
|---|---|---|
| Android TechLead（筆者） | 1名 | 全体のプロセス改善 |
| Androidエンジニア | 3名 | 施策開発 |
近年は様々なAIエージェントの登場により、Androidのコードに変更を加えるメンバーは他にもいますが、この4人が最終的な品質を担保する役割を担っています。
レビュー体制
Pull Request（以下PR）をオープンしたタイミングで4人全員がレビュアーとしてアサインされ、誰か1人以上のApproveでマージが可能となる体制をとっています。
DMMポイントクラブでは複数の施策が同時進行し、メンバーそれぞれが異なる施策のコードを開発していることが多いため、レビュアーは開発に直接関与していない機能の概要も把握した上でコードレビューを行う必要があります。
コードレビューで抱えていた課題
限られた人数で複数の施策を並行して進める体制のもと、コードレビューに関して以下のような課題が顕在化していました。
レビュアー側の課題
- 命名規則の揺れやtypoなど、細かい指摘に時間を取られがち
- レビューの負荷が特定メンバーに偏り、他の作業を圧迫している
- 細かい修正の繰り返しにより、設計や実装の全体像に目が向きにくくなる
レビュイー側の課題
- PR作成からレビュー完了までのリードタイムが長い
- レビューと修正の繰り返しで対応が長期化してしまう
共通の課題
- レビュー品質がレビュアーのスキルや経験に左右されやすく、ばらつきがある
- テストシナリオとテストコードの間にずれが発生しやすい
- コミュニケーション長期化による心理的な負担がある
人力プロセスの改善からスタート
こうした課題に対し、まず取り組んだのが 1日2回の口頭レビュータイム の設置です。
朝と夕方に各30分のレビュータイムを設け、作成したPRの説明や実装相談を行います。
口頭レビュータイムの導入により、以下のような効果がありました。
- PRの背景や意図をレビュアーに直接伝えることで、テキストだけでは伝わりにくいコンテキストを共有できる
- 非同期コミュニケーションだけでは長引きがちなやり取りを、その場で解決できる
- レビュー待ちの時間を減らし、開発のリズムを整えられる
- Android領域に特化した相談や共有事項をスムーズに行える
また、PRテンプレートによるセルフレビューの促進にも取り組みました。ただし、チェック項目の増加による形骸化や心理的コストの問題が発生し、項目の厳選を経て最終的にはチェック項目自体を廃止しました。チェックリストで担保しようとしていた部分は、後述するAIコードレビューや口頭レビュータイムでカバーする形に切り替えています。
これらの取り組みによって、コミュニケーションのロスはある程度減らすことができました。ただ、依然としてレビューの細かい指摘に時間を取られることや、レビューの質のばらつきといった課題は残っていました。
AIコードレビューツールの導入
そうした中、社内全体でAIコードレビューの導入事例が増え始め、本格的に導入を検討するタイミングで社内整備も整った「CodeRabbit」を導入しました。
