速く気持ちよくレビューサイクルを回すNOT A HOTELオーナーアプリWebチームの文化と仕組み

こんにちは。
NOT A HOTELのオーナーアプリでWebフロントエンドを担当している佐野です。
Webチームは現在3人で担当していますが、Pull Request（PR）のレビューがとにかく速いです。
小さな修正であれば、メンションしてから2〜3分でapproveされることもありますし、1日に10本以上のPRがopenされ、その日のうちにマージされることもあります。
これはレビューをする側が自身のタスクよりレビューを意識的に優先しているだけでなく、レビューされる側も、レビューの負荷を下げるための小さな工夫を積み重ねていることも大きいのではないかと思っています。
今回は、私たちのチームのレビューのやり方、速いレビューサイクルを支えているチームの細かい工夫などをまとめてみました。
単に「レビューを速く回す方法」ではなく、チームでどのようにコミュニケーションを取り、気持ちよく協働しているのか。
オーナーアプリWebチームの雰囲気や、日々の開発を支える文化を感じてもらえたらうれしいです。

レビューにおける基本方針

レビューにおいてチーム全体で共有している前提は、次の4つです。

責任の線引きを明確にする

• 動作確認や仕様の整合性は実装者が責任を持つ。

• レビュアーはコードの妥当性や設計意図の確認に集中し、Figmaや仕様書などとの突き合わせまでは行わない。

この線引きを共有していることで、レビューの目的が明確になり、スピードと安心感を両立できています。

AIが書いたコードと実装者本人のコードを区別しない

たとえAIがコードを書いたとしても、その質を担保するのは実装者の責任です。
生成されたコードはあくまで実装者本人の成果物とみなし、内容を理解したうえでレビューに出します。
実装者が見落としたAIのおかしなコードをレビュアーが気づくことも時々ありますが、基本的には「AI生成の有無にかかわらず、実装者が最終責任で理解・検証したうえでレビューに提出する」という意識で取り組んでいます。
（ちなみにオーナーアプリのAndroidチームでは、AIのコードに関しては別のアプローチをとっています。Androidチームの開発フローに関するこちらの記事も併せてご覧ください）

セルフレビューをしてからレビュー依頼

レビュー依頼の前に必ずセルフレビューを行うことを徹底しています。
前述のAIのコードもそうですが、PRを作成したタイミングでClaudeの自動レビューが走るようになっているので、そこでの指摘なども修正した後でメンバーにレビュー依頼するようにしています。

原則として1 approveでマージ

原則として1人のapproveでマージ可能としていますが、すでに1人がapproveしていても「自分も見ます」ということもありますし、「これは軽微なので任せます」など内容によって判断しています。
影響範囲が大きい変更や複雑な実装の場合は、実装者から2 approveをお願いすることもあります。
「1 approveでマージ」を基本とすることで、レビューが滞留しにくくなり、開発スピードが自然と上がります。

レビュイー（PR作成側）が意識していること

PR粒度：小さければ小さいほど良い

大前提として、PRはできるだけ小さく出すことを意識しています。
変更範囲が小さいほど、レビュアーは意図を理解しやすく、レビューがスムーズになります。

• 1つのPRには1つの内容を
  PR説明に複数のトピックが混ざると、「この変更はどの修正に関係しているのか」が読み取りづらくなります。
  軽微な修正をまとめる場合や、ついでに関係ない修正が入った場合は、行コメントで「これはこの件です」と補足します。

• 単体のメソッド追加や新規コンポーネントには、テストを一緒に入れる
  テストがあることで仕様が明確になり、レビュアーも「このコードはこう動くべき」と安心して判断できます。
  テスト追加は別PRに分けず、対象コードと同時に入れることで意図をセットで伝えます。

• 同じ変更方針が複数箇所に及ぶ場合は、最初に1つだけレビューしてもらい、論点を潰してから量産する
  最初に方向性を合わせておくことで、量産PRは一瞬で通るようになります。

PR説明：読めばすぐ理解できる構成に

PR本文には以下をセットで記載します：

• issue、仕様書、Figmaへのリンク

• 変更の背景・目的（なぜこの修正が必要か）

• 変更前後の挙動の違い

• スクリーンショットや動画

また、必要に応じて、

• 影響範囲や動作確認パターン

• 補足情報や参考リンク（仕様・設計の根拠など）

など詳細に記載する場合もあります。

こうして背景や目的をPR本文に明記しておくことで、レビュー時だけでなく後からのトラブル調査や仕様確認にも役立ちます。
後日、不具合対応などで過去の変更履歴を辿った際にも、「なぜこの時この変更が入ったのか」「この時点ではどう動いていたのか」がスムーズに把握でき、結果として、チーム全体の開発スピードと知識共有の質が上がります。
また、スクリーンショットや動画を添えることで、レビュアーが手元でブランチをチェックアウトしなくても挙動を確認でき、安心してapproveできるようになります。
単純な文言変更であっても、文字数が変わったことで見た目が不自然になる場合や、i18nのキーの参照を間違えてしまっている場合など、表示崩れにつながる要素はゼロではないので、スクリーンショットで動作確認を担保するようにしています。

行コメント：セルフコメントで補足する

コードのdiffだけでは分かりにくい変更は、PR作成者が行コメントで背景や意図を残すようにしています。
たとえば：

• なぜこの状態管理や条件分岐を追加したのか

• どんな仕様変更を反映しているのか

• 新しいコンポーネントの責務や命名意図

などです。

また、コードの変更が直感的に理解できるように、変更内容を補足する画像なども添えています。

• before/afterのスクリーンショット（CSSなど見た目の変更）

• 画面上のどの箇所を指しているのかが分かるキャプチャ

視覚的な補足があることで、レビュアーが変更の意図をより早く理解でき、手元でブランチを動かさずとも「なるほど、こう変わったのか」と納得できるレビュー体験になります。
1箇所変更しただけなのにdiffが見づらくなっている場合なども、「ここが変わっただけです」という補足があると、見なくてよいところは読み飛ばすことができます。

このような行コメントを入れることで、レビュアーがコードの変更内容を読む負荷を軽減します。
また、コメントを書く過程そのものがセルフレビューの再チェックにもなり、結果的にPRの品質も上がります。

レビュー依頼：Slackでの依頼もひと工夫

レビュー依頼はGitHub通知だけに頼らず、Slackでも共有します。
その際、以下のような情報を添えるのが定番です。

• 急ぎ具合

  • 「急ぎお願いしたいです」「後続作業のブロックになるので早めが助かります」「おてすきでいいです」など

• ボリューム感を伝えるスタンプ

  • 「めっ軽」だと見る方もハードルが下がってすぐ開いたり、「大盛」だとキリのいいタイミングで時間をとるなど調整できます

また、「このPRはちょっと複雑なので2人に見てほしい」など、レビュー観点が多い場合は明示的に伝えるようにしています。
これで、レビュアーが「今すぐ見るべきか」「後で時間をとるべきか」を判断しやすくなります。

レビュー中：わからないことはコメントで終わらせない

指摘の意図がよくわからなかったり、コメントのやり取りで認識がずれていると感じたら、コメント欄で延々とやりとりせず、ハドルや短い会話でサクッと解決します。
テキストよりもリアルタイムで話した方が早いケースも多く、これが結果的にレビューサイクルの短縮につながっています。
また、口頭で会話した場合も、結論はコメントにまとめるようにしています。PR上で後から見返したときに「結局どうなったのか」が分かりづらくなるのを防ぐためです。議論や経緯が残っていることで、後続の開発者も安心して判断できます。

レビュー修正：nits（軽微な指摘）も大事に扱う

nitsコメントつきでapproveをもらっていても、内容に同意であればなるべく修正し、対応不要と感じた場合はその旨を返信したり、「別PRで対応予定です」と返すようにしています。
軽い指摘を軽んじず扱うことで、コードベースの整合性が維持され、レビューのやり取りに対する信頼も醸成されます。

レビュアー（レビューする側）が意識していること

レビューを最優先にする

チームでは、レビューを自分の作業よりも優先することを心がけています。PRが滞留しないことが、チーム全体の生産性を最大化するからです。
すぐに対応できない場合は、その旨を伝えます。“放置しないこと”が、心理的な安心感にもつながっています。
この意識は、最初から明文化されていたわけではありません。
レビューの速いメンバーに「いつも速くて助かっている」とフィードバックをしたところ、「自分も〇〇さんが、自分の作業よりもレビューを優先している、と話していたのを取り入れた」と教えてくれました。
それを聞いて自分も意識するようになりましたが、新しく入ったメンバーは自分よりもさらにレビューへの着手が速く、その姿を見てまた自分も改善し、結果としてチーム全体のレビューサイクルがどんどん速く回るようになりました。
このように、他のメンバーの良いやり方を自然に取り入れてアップデートしていく文化も、チームのとても良いところだなと思います。

レビューコメントを仕組みに還元する

レビューの中で何度か同じ指摘をしている内容については、チームで共有してコーディングルールやLintルールに反映するようにしています。
そうすることで、AIによる自動レビューや静的チェックで防げる部分が増え、人のレビューはより設計や意図に集中できるようになります。
※コーディングルールやAI自動レビューの仕組みに関しては、こちらの記事で詳しく紹介されていますので、ぜひ併せてご覧ください

マージ後でも、気づいたことは遠慮せずに指摘する

レビューを一度通した後でも、設計や構成の観点で気づいたことがあれば、マージ後でも遠慮せずにフィードバックするようにしています。
コードを動かしたり別の開発を進める中で「こうした方がより良さそう」と思ったら、後追いでもコメントを残したり、朝会で共有して議論します。
こうしたやり取りがスムーズにできるのは、チーム全体に「指摘を歓迎する空気」や「アプリケーションをより良くしていくための建設的なフィードバック文化」が根づいているからです。
その共通理解があるからこそ、スピードと品質を両立できています。

4. おわりに

オーナーアプリWebチームのレビューが速いのは、単に効率を追っているからではなく、お互いを信頼し合える関係と、レビューしやすい工夫の積み重ねがあるからだと思っています。
これからもこの文化を磨きながら、開発体験そのものを楽しみ、プロダクトを進化させていくチームでありたいと思います。