品質と速度を両立する、並行開発のためのコードレビュー

多様な開発組織のコード／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チームにおけるレビューのメイン目的は「チームでメンテナンスしていくための品質担保」です。具体的には、長期的な運用を見据えた設計の妥当性や、実装理解の促進、属人化の軽減が目的です。レビューを通じて仕様や設計を共有し、担当者以外も引き継げる状態をつくることを重視しています。