多様な開発組織のコード／PRレビューを“図鑑”のように紹介する連載「コードレビュー図鑑」。NOT A HOTEL株式会社 Sanoさんに、並行開発を行う上でのレビュー体制や工夫を紹介いただきました。
また、読者のみなさんの声を執筆者にお届けするフォームを試験的に設置しています。記事最後のフォームより、読後のひと言をお寄せいただけると嬉しいです。
[1]
NOT A HOTEL株式会社でWebフロントエンドを担当しているSanoです。
NOT A HOTELは、「世界中にあなたの家を」というコンセプトのもと、新しい暮らしの形を提案している会社です。特徴的な建築の別荘を年10泊単位からシェア購入できる仕組みを提供しています。私が担当しているのは、オーナー向けアプリのWebフロントエンドです。宿泊予約や食事予約、チェックインや鍵の解錠、滞在中のチャットサポート、精算までトータルで宿泊体験を提供するアプリです。
今回は、そのオーナーアプリにおけるWebフロントエンドチームのレビュー体制についてご紹介します。
並行開発が前提のチーム構造
まず、チームの前提として、開発は1スプリント3週間です。タイトなスケジュールの中で、多くの新機能や改善を継続的にリリースしています。クライアントはiOS、Android、Webの3つがあり、同時開発・同時リリースを行っています。
機能ごとに、各職種から1〜2名ずつアサインされる横断チームで開発しています。キックオフでは全員が機能概要を把握しますが、開発が進むと細部の仕様は担当者中心のやり取りになりやすいです。
レビューは職種ごとの縦のラインで行っています。また、リリースする機能はすべてQAを通しており、PdMと連携し、詳細なテストケースを作成した上で検証しています。Webメンバーは3名で全員が1年以上在籍しており、それぞれが1機能をサポートなしで担当できる状態です。
このように、常に複数の機能が並行して進み1人ずつ担当している状況では、全員がすべての機能仕様を同じ精度で把握するのは難しくなります。
こういった状況の中、Webチームにおけるレビューのメイン目的は「チームでメンテナンスしていくための品質担保」です。具体的には、長期的な運用を見据えた設計の妥当性や、実装理解の促進、属人化の軽減が目的です。レビューを通じて仕様や設計を共有し、担当者以外も引き継げる状態をつくることを重視しています。
責任の線引きでレビューを効率化
レビューの効率化を図るため、実装者とレビュアーがそれぞれ担保する範囲を明確にしています。
実装者の責任
実装者の責任は仕様に沿って正しく実装することで、仕様書やFigmaと突き合わせ、細部まで漏れなく実装します。
そして、挙動を担保した状態でレビューに出します。機能の動作確認を行い、確認パターンを列挙したり、キャプチャや動画を添付したりしています。最近はAIがコーディングを行う場面も増えていますが、冗長な書き方や不必要な複雑化が含まれることもあります。そのため、AIが書いたコードも実装者が検品し、自分のコードとして責任を持ってレビューに出しています。
レビュアーの責任
レビュアーは、実装者が共有した仕様を前提に品質を担保します。仕様に対して設計が自然か、担当者以外でもメンテナンスできるか、将来の変更に耐えられるかを見ます。
一方で、やらないことも明確にしており、すべてのPRの動作確認や仕様書との網羅的な突き合わせは行いません。それらは実装者とQAで担保されている前提です。ただし、インタラクションや状態遷移が複雑な機能では、必要に応じて手元で挙動を確認する場合もあります。
レビューを仕組み化するフロー
レビューの流れは次の通りです。
まず、Pull Request（PR）を作成し、テンプレートに沿って説明を記載します。次に、コーディング規約やレビュー観点に沿った一次レビューとして、CIでClaudeによる自動レビューが走ります。
そこで指摘された内容を確認し、妥当なものは修正します。その後、セルフレビューも兼ねて、行コメントでレビュアー向けの補足や解説を追加します。ある程度ブラッシュアップした段階で、Slackでレビュー依頼を出します。基本は1 approveでマージしますが、仕様共有や複数観点が必要な場合は全員に見てもらいます。
人間は何を見るか、レビュー負荷を下げる工夫
大きな機能では、レビュー段階で長い議論や手戻りが発生するのを避けるために、実装前に設計方針を共有します。
レビュアーの負荷を下げる工夫
特に意識しているのは、レビュアーの負荷を下げることです。具体的には3つあります。
1つ目は「PRを小さくする」ことです。基本は1PRに1つの主題として、新機能は観点ごとに分割します。
コンポーネント構成だけのPR、ロジックを中心に見るPR、UI作り込みのPRなどに分けますが、テストコードと実装は分けません。同一PRに含めたほうが仕様が明確になり、レビューしやすくなります。
2つ目は「わかりやすいPR説明」です。Issueや仕様書、Figmaへのリンクを貼るだけではなく、PRのスコープに絞って背景や目的をまとめます。変更内容のサマリーや、スクリーンショットや動画も添付します。
3つ目は「行コメントでの補足」です。仕様のどの点に対応するか、どの部分を読み飛ばしてよいかを明示します。設計意図も書いておくことで、やり取りを減らしています。
一見すると実装者の負荷が高いように見えるかもしれませんが、PR分割はAIコーディングとも相性が良く、検品もしやすくなります。行コメントはセルフレビューにもなり完成度が上がるため、結果的にはマージまでのスピードが速くなります。
全体を通してレビューサイクルが速くなり、長期的なデリバリースピードも向上していると感じています。
レビュアーが意識すること
続いてレビュアーが意識することですが、まず自分の作業よりレビューを優先しています。レビュー待ちが長いと、チーム全体のロスになります。また、コードは引き継ぐつもりで理解し、現在の文脈を知らないメンバーに渡してもメンテナンスできるかを意識しています。
細かなミスなどはAIの一次レビューで担保できているので、人間が重点的に見るのは「読みにくさの正体」です。負債になっていないか、運用面での懸念はないかを確認します。なぜ読みにくいのかを掘り下げると、責務分割の不自然さや冗長な状態管理が見えてきます。
バグにつながりそうな初期値や、型で正しく表現できていない箇所も注意します。また、実装の違和感から仕様の不自然さに気づくこともあります。その場合は、仕様をシンプルに調整できないかを検討します。
コミュニケーションの工夫
コミュニケーションの工夫もしており、レビュー依頼では急ぎ具合やボリューム感をスタンプなどを用いて伝えています。例えば、「めっ軽」というスタンプがついているとレビューのハードルが更に下がり、1~2分でApproveされていることも多いです。
まとめ
並行開発の中で、開発速度とコード品質を両立させるためには、チーム全体の効率を意識することが重要です。
実装者はレビュー負荷を下げる準備を徹底し、レビュアーは作業よりも優先して確認します。責任範囲を明確にすることで、無駄な重複を減らせます。レビューを通じて仕様と実装を共有することで、並行開発や柔軟な担当変更が可能になります。
また、開発体制やメンバー構成、AIの精度によってレビューの最適解は変わります。状況に合わせてやり方を更新し続けることが大切だと考えています。
アーカイブ動画・発表資料
本記事は、2026年2月6日に開催されたイベントでの発表をもとに編集したものです。
イベントのアーカイブ動画・資料は以下のリンクからご覧ください。
アーカイブ動画：「コードレビューどうしてる？各社のTips共有会」
※動画の視聴にはFindyへのログインが必要です。
執筆者へのお便り
-
本記事は、2026年2月6日に開催されたイベントでの発表をもとに編集したものです ↩