並行開発のためのコードレビュー

開発速度を維持しながらチームでメンテナンスしやすいコードにする

Transcript

1. © NOT A HOTEL, Inc. © NOT A HOTEL, Inc. 並行開発のためのコードレビュー 開発速度を維持しながらチームでメンテナンスしやすいコードにする 1 Miyuki Sano NOT A HOTEL株式会社 2026/02/06
2. © NOT A HOTEL, Inc. 2 自己紹介 Miyuki Sano NOT A HOTEL でWebフロントエンドを担当しています。 入社3年目。一児の母です。 X: @wtnb
3. © NOT A HOTEL, Inc. テキスト NOT A HOTEL株式会社 2025/10/20
4. © NOT A HOTEL, Inc. 4
5. © NOT A HOTEL, Inc. 5 NOT A HOTELの特徴 使いたい分だけ購⼊ 使わない時は ホテル貸し出し 全国の NOT A HOTEL も利⽤可能 メンテナンスフリー ホテル運営もおまかせ
6. © NOT A HOTEL, Inc. 6 オーナーアプリとは 宿泊者に予約から滞在中のサポート、精算まで宿泊体験を提供
7. © NOT A HOTEL, Inc. 7 今日お話しすること - オーナーアプリのWebフロントエンドチームのレビュー体制について - 並行開発を行うための役割分担とレビューの進め方 - レビューをボトルネックにしないための工夫 - アジェンダ - チームの前提 - レビューの目的 - 実装者・レビュアーそれぞれの責任範囲 - レビューのフロー - 実装者・レビュアーがそれぞれ意識すること - コミュニケーションの工夫
8. © NOT A HOTEL, Inc. 8 オーナーアプリチームの前提 - 開発フロー - 1 sprint = 3 week - タイトなスケジュールで多くの新機能・改善をリリース - 3 client 同時開発・同時リリース - 機能ごとに各職種1、2名アサインの横断チームで開発 - キックオフで全員が概要は把握するが、開発に入ると細部 の仕様は担当者しか把握していない状態になりやすい - レビューは職種ごとのチームで - QA - リリースする機能はすべてQA - PdMと連携してテストケースを作成 - メンバー - Webのメンバー3人は全員1年以上在籍 - 一人で一つの機能をサポートなしで担当できる 機能A 機能B 機能C 機能D
9. © NOT A HOTEL, Inc. 9 常に複数の機能開発が並行していて、一人ずつ担当 👇 開発中、全員が全ての機能の仕様を同じ精度で把握するのは難しい
10. © NOT A HOTEL, Inc. 10 Webチームでのレビューのメイン目的 今後もチームでメンテナンスしていくための - 品質担保 - 長期的な運用を見据えた設計レビュー - 実装理解、属人化の軽減 - 仕様や設計のキャッチアップ - 担当者以外も引き継げる状態を作る
11. © NOT A HOTEL, Inc. 11 実装者の責任 - 仕様に沿った実装 - 仕様書・Figmaとの突き合わせ - 挙動を担保する - 動作確認をした状態でレビュー依頼 - 確認のキャプチャを画像や動画でPR説明につけたり、確認したパターンを列挙したりする - AIの書いたコードをレビューして仕上げる - 仕様の理解と設計までやってコーディングはAIがすることも増えている - ただし冗長な書き方や変に複雑化させていることも多いので、実装者が検品した上で本人のコードとしてレ ビューに出す 責任の線引き
12. © NOT A HOTEL, Inc. 12 責任の線引き レビュアーの責任 - 実装者が共有した仕様を前提にした品質の担保 - 仕様に対して設計が自然か - 担当者以外もメンテナンスできるか - 将来の変更に耐えられるか やらないこと - すべてのPRの動作確認や、仕様書との網羅的な突合せはしない - 実装者とQAで担保できている - QAで出たバグも基本的に本人が担当するので、実装時から気を抜かない前提 - インタラクションや状態の変化、遷移が複雑な機能などは、手元で挙動も確認する場合もあるが、全部はしない
13. © NOT A HOTEL, Inc. 13 レビューのフロー 1. Pull Requestをopen - テンプレートに沿ってPR説明を記入 2. Claudeの自動レビューを確認し、指摘を修正 - コーディング規約、レビュー観点にそった一次レビュー 3. 行コメントでレビュアー向けの補足・解説 - セルフレビューも兼ねる 4. Slackでレビュー依頼 5. 基本は1 approveでマージ - 仕様共有のためや、複数観点ほしいときは2 approve要求
14. © NOT A HOTEL, Inc. 14 実装者が意識すること - 大きい機能は設計方針を実装前に共有して方針を合意しておく - レビュー段階で長い議論になることを避ける - レビュアーの負荷を下げるための工夫 1. PRを小さくする 2. わかりやすいPR説明 3. 行コメントでの補足
15. © NOT A HOTEL, Inc. 15 実装者が意識すること：レビュアーの負荷を下げる 1. PRを小さくする - 基本は1つのPRには1つの主題 - 新規機能は特に大きくなりがちなので、レビュー観点ごとに分割 - コンポーネントやファイル構成だけ追加するPR（命名やコンポーネントの分け方などを見る） - 全体の処理の流れを完成させるPR（ロジックをしっかり見る） - UIの作り込みをするPR（見た目が確認できていればそこまで指摘はない） - 必要なAPIリクエストだけ追加するPR（決まった書き方なのでほぼ指摘なし） - モック部分を実際のリクエストに差し替えるつなぎこみPR（動作していればほぼ指摘なし） - 逆にテストコードと実装は分けない方が、仕様も明確になり挙動の担保を補強するのでレビューのしやすさにつな がる - Jest: ロジックの重要な部分 - Cypress: UIの見た目、表示の分岐パターン
16. © NOT A HOTEL, Inc. 16 2. わかりやすいPR説明 - コードを読む前の前提知識の共有、仕様共有 - issue / 仕様書 / Figma へのリンク - 変更の背景・目的 - リンクすべては情報量が多いので、PRのスコープに 絞ってまとめる - 変更内容 - 具体的に何を変更したか - 行コメントのほうが理解できそうな場合はそちらで - スクリーンショット・動画 - 変更前との比較がわかりやすい場合は変更前のものも 実装者が意識すること：レビュアーの負荷を下げる
17. © NOT A HOTEL, Inc. 17 3. 行コメントでの補足 - レビュアーがコードを読み解く負荷を下げる - 仕様のどの点に対応するか？ - 画面のどこに対応するか？ - 読み飛ばして良い部分を明示 - 意図を明確にして質問のやり取りを減らす - なぜこの状態管理なのか - なぜこの責務分割なのか 実装者が意識すること：レビュアーの負荷を下げる
18. © NOT A HOTEL, Inc. 18 実装者が意識すること 実装者の負荷が高くかえってスピードダウンでは？🤔 - PR分割 - 作業のスコープを分割することはAIコーディングの作業精度も上がり実装者自身も検品しやすい - 1PRの議論ポイントが減るのでマージまでのスピードは速くなる - PR説明 - 実装者が動作確認したパターンを示すことで、レビュアーが二重で確認する手間を省ける - 丁寧な記述は、後からのトラブル調査や仕様確認にも役立つので、長期的なチームでの運用にはプラス - 行コメント - コメントする過程がセルフレビューにもなってコードの完成度も上がり、指摘事項が減ることで速くなる - スラスラ読めるようになっている信頼がレビューへの心理的ハードルを下げ、レビューサイクルが速くなる 👉トータルで見るとレビューサイクルは向上、長期目線でのデリバリースピードも上がる
19. © NOT A HOTEL, Inc. 19 レビュアーが意識すること - 自分の作業よりレビューを優先 - レビュー待ちが長いとチーム全体としては時間のロス - 引き継ぐつもりでコードを理解する - 言及されていない仕様の疑問点などもレビューの中で解消する - いまの文脈を知らないメンバーに引き継いだとしてもメンテしやすいようなコードにする - 意図や経緯が読み取りにくい、誤解を招くような箇所をつぶす - 何回か指摘していることはレビュー観点などに反映して、AIレビューで担保できることを増やす
20. © NOT A HOTEL, Inc. 20 レビュアーとして意識すること 重点的に見るところ👀 - 読みにくい箇所を見つけ、なぜ読みにくいのか？を掘り下げる - 責務の分け方が不自然、状態管理が冗長、命名が誤解しやすい、など - バグにつながりそう、仕様変更に弱そうな実装 - 怪しい初期値、型で正しく表現できていない部分、など - 共通化した方がいい箇所、逆にしない方がいい箇所 - 仕様への違和感 - 違和感のある実装や、やけに複雑、不必要に見える条件分岐など、仕様自体が不自然になっている場合もある - 仕様をシンプルに調整できないかも検討し、要件を満たしつつコードに複雑性を持ち込まないようにする - プロダクトとしてあるべき状態や運用面での懸念なども意識して、ときには仕様から調整することも自社開発で は重要
21. © NOT A HOTEL, Inc. 21 コミュニケーションの工夫 - レビュー依頼では急ぎ具合やボリューム感を伝える - レビュアーはすぐ見られない場合も伝えておく
22. © NOT A HOTEL, Inc. 22 まとめ 👉開発速度とコード品質担保を両立するために - チーム全体の効率を意識して相手の時間を尊重する - 実装者はレビュー負荷を下げるための準備をした上で依頼する - レビュアーは作業よりも優先ですぐ見る - 責任範囲を明確にして効率化 - 実装者は仕様や挙動を担保 - レビュアーは長期的な運用を考慮して設計・品質を担保 - レビューを通して仕様と実装の共有をすることで並行開発や柔軟な担当の入れ替えを可能にしている 👉開発体制、メンバー、AIの状況などでレビューの最適解は変わる - 状況に合わせて、やりかたを常にアップデートしていく
23. © NOT A HOTEL, Inc. 23 We are hiring! 現在、NOT A HOTELのSoftwareチームでは採用強化中です。 カジュアル面談も受け付けておりますので、お気軽にご連絡ください。 https://redirect.notahotel.com/software-jobs
24. © NOT A HOTEL, Inc. 24 ご清聴ありがとうございました。