Yard 編集部

🙄

「コードレビューどうしてる？品質向上と効率化の現場Tips共有会」イベントレポート

公開

2025-03-13

文章量

約3982字

Yard 編集部

フォロー

Yardの編集部が、テック業界の最新トレンドや知見について発信します。

1. 「良いコードレビューとは」

セッション概要

2. 「ぼくらのPRレビューフロー改善奮闘記」

セッション概要

3. 「AIレビュー導入によるCIツールとの共存と最適化」

セッション概要

4. 「プルリクエストレビューを終わらせるためのチーム体制」

セッション概要

全体を踏まえた感想

「チームやフェーズによる柔軟な運用」と「レビューへのモチベーション設計」が鍵

全体を踏まえた感想

レビューを“終わらせる”ために――チームで方針を守り、仕組みを作り、学び合おう

イベントレポートコードレビュー

Insight

ソフトウェア開発の現場において、コードレビュー（プルリクエストレビュー）は品質向上やチームの効率化に欠かせないプロセス。

しかし、チーム構成や文化、事業フェーズなどによって“どのように行うか”は多種多様で、明確な正解を導きにくい部分でもあります。そこで2025年3月6日に開催された「コードレビューどうしてる？品質向上と効率化の現場Tips共有会」では、4名のエンジニアが各自の実践例と学びを共有しました。

以下では、それぞれのセッション内容や共通して語られたポイントをまとめ、最後に全体の感想を述べます。

1. 「良いコードレビューとは」

発表者： 株式会社 Speee エンジニアリングマネージャー石井秀明 (@danimal141)

セッション概要

石井氏は「良いコードレビュー」を「事業の成長を加速し続けるための仕組み」と位置づけました。多くのエンジニアが日々直面する“レビュープロセス”を、単に「書式ミスを探すもの」ではなく、「プロダクトと組織を継続的に健全化する手段」として捉える視点が印象的です。

最初に見るべきは「開発の目的・完了条件」

コードが正しく要件を満たしているか。
変更前後で悪影響を及ぼす箇所がないか。
事業やユーザーにとって価値があるか。

“コード”そのものを表面的に見るだけでなく、ビジネス要件やドメイン知識と紐づけた“筋の良さ”を確認するのが肝要と語りました。
レビュアー視点：「なぜそれが良くないのか」を丁寧に伝える

人ではなく、あくまでコードに対するフィードバックを行う。
好みレベルの指摘は自動化ツール（リンターなど）で解決し、実装理由や今後の拡張性に関わる部分を重点的に。
「ここは良い！」というポジティブな点も積極的に共有することで、若手の学びを促し、チーム全体のナレッジを活性化する。

レビューイ視点：自分が未来に触るならどう思う？

コードの意図や背景を説明できないほど“曖昧”な設計なら、一度立ち止まって再整理したほうが生産的。
鋭い指摘に落ち込まず「資産になる学び」だと捉える。

“コードレビュー＝プロダクトへの投資”という捉え方が随所に感じられるセッションでした。

2. 「ぼくらのPRレビューフロー改善奮闘記」

発表者： 株式会社Works Human Intelligence Group Manager 丸山三香子 (@moromi25_)

セッション概要

大手企業向け人事システム「カンパニー」の一部機能を担当する開発チームが、約2年にわたってプルリクレビューの運用を試行錯誤してきた事例。少人数チームと機能強化が多くプルリク数が多いチームという2種類の開発スタイルの中で、モブレビュー・全員参加・非同期レビューなどさまざまな方法を試し、得られた知見を紹介しました。

最初：マネージャー1人がレビューを全担当

メンバーの負担は低いが、マネージャー多忙によるレビュー遅延が頻発。
さらに、学習機会がマネージャーに集中してしまう問題が発覚。

全メンバーでモブレビュー

毎日朝会の最後に“レビュー時間”を設け、一斉に確認。
遅延は激減、知識共有が促進され、全メンバーが成長できる。
しかし、表面的なレビューで終わりがちになり、複雑なドメインロジックのチェックが甘くなるケースも。

非同期レビューに切り替え（全員アプルーブ必須）

レビューの質は向上するが、待ち行列が増えて再び遅延の温床に。
レビューを分散させることで個別に時間を取れる一方、タイミングが合わず2週間もマージされない事例も。

現在：チームごとに手法を分化

チーム1は再びモブレビューへ。
チーム2は「1営業日以内に非同期でレビュー」＋「残りはモブで対応」というハイブリッド運用。

ポイントは「チームのフェーズや人数、プロダクト特性に応じて、やり方を変える」ことに尽きる。どんなレビュー方式にも長所と課題があり、その時々の状況を踏まえてフローを柔軟に進化させる姿勢が印象的でした。

3. 「AIレビュー導入によるCIツールとの共存と最適化」

発表者： 合同会社DMM.com エンジニア中島暢哉 (@kamo26sima)

セッション概要

DMM.comの会員基盤開発チームで、コードレビューの効率化と品質維持に悩む中、OSSのAIレビューツール「PRエージェント」を試験導入した経験談。CIツール（リンター、テスト）とAIの住み分けをどう考えるか、導入メリット・デメリットを振り返りました。

導入目的：人間のレビューを高度化する

タイポやデバッグコードの残りといった基本的なミスはAIに任せ、人間はドメインや設計の吟味に集中する。
プルリク説明をAIが要約し、レビュアーの理解をサポートする想定。

導入してみた結果

スペルミスや言語使用の初歩的ミス検出は精度が高く、要約機能も一定のレビュー負荷を削減。
ただし、ドメイン特有の制約には対応できず、「この変更はドメイン的にNG」といった指摘は期待できない。
チームのフェーズやコード量によってはノイズが多くなる場面も。

CIツールとの共存

AIレビュー：推奨レベルの指摘や要約を担う。
リンター／テスト：白黒明確なチェック（規約遵守、動作検証など）で自動的に落とす。

「AIレビューは人間の判断を補強する」という位置づけを徹底し、期待値を適切に管理することが肝要だと結論付けていました。プロダクトやチーム状況次第で効果が変わる点が興味深いところ。

4. 「プルリクエストレビューを終わらせるためのチーム体制」

発表者： 株式会社ラブグラフ執行役員CTO 横江亮佑 (@yokoe24)

セッション概要

出張撮影サービス「ラブグラフ」を運営するチームで、プルリクレビューが滞らないようにするための具体的な策を紹介。「どんな組織でも使える、けれど意外と見落としがち」な仕組みを惜しみなく公開されました。

方針を決める（コーディング規約・テンプレの整備）

リンターで形式的なルールを徹底し、追加ルールやテスト方針は別途ドキュメント化。
プルリクテンプレで「レビュー観点」を明確化、背景や設計意図を簡潔に書いてもらう。

情報が届く仕組みづくり

担当者がプルリク投稿しただけで終わらせず、「Slack連携」や「リマインドボット」を活用して、プルリクを可視化。
特に定時の自動リマインドで「このプルリクが承認待ちです！」と全員に通知し、モチベーションを維持させる。

時間を作る：レビュー会など

週3回、30分程度みんなで集まる「レビュー会」を設定。
同期的に質問・説明ができるので、コメントのやり取りが最小限で済む。
タイミングは昼食前後を避け、集中できる時間帯を活用。

「レビューがなかなか終わらない原因」は、人間のモチベーション不足か、やり取り往復回数の多さにある、と端的に指摘。こうした仕組みで“プッシュ型”かつ“短時間で完結させる”体制を整えることで、日々のPRがスムーズに進む事例を示してくれました。

全体を踏まえた感想

「チームやフェーズによる柔軟な運用」と「レビューへのモチベーション設計」が鍵

4名の登壇者はいずれも、「レビューは単なるコードチェックにとどまらず、チームの学習やプロダクトの成長を促す場」と捉えていました。その一方で、“最適解”は存在しないことも強調されています。同じメンバー構成でも、事業フェーズや担当ドメイン次第で必要なフローが変わるため、　「今の自分たちに必要な仕掛けを作る」　という姿勢が重要です。