はじめに
こんにちは。Ubie のテクノロジープラットフォーム部で Web エンジニアをやっている highwide といいます。Ubie には今年の 10 月に入社しました。
これは Ubie Tech Advent Calendar 2025 の 16 日目の記事です。
さて、いきなり前職の話をするのですが、最後に所属していたチームで「最初は面食らったものの、最終的にめちゃくちゃ良かったなと思うチームの Working Agreement」として 「コードレビューの優先度をできるだけ高める」 というものがありました。
当初は社内ドキュメントでこの慣習を紹介しようと思ったのですが、インターネットに公開した方が便利と思いここに書きます。
Tier とは
「Tier」とは「段」や「層」という意味ですが、昨今ではゲームなどにおける強さや優先度のランク付けの言葉としてよく見かけるようになりました。
Ubie では「会議・仕事の優先順位」という概念があり、社内で「Tier」として表現されることが多いです。たとえば、「全社月次 Sync」は「チームのプロジェクト開発」よりも上位 Tier なので、予定が重複しそうなときは前者を優先すべきことが自明...といった具合です。
優先度が明確にランク付けされていることによって、考えるべきことや調整コストが減るという利点があります。
ということで明示的に、コードレビューという業務の Tier を相対的に上げようというのがこの記事の趣旨です。
「コードレビューの業務 Tier を上げる」とは
さて、コードレビューの業務 Tier を上げるとはどういうことでしょうか。
単純に「自身の業務における優先度を上げよう」ということですが、特に自身が推したいのは 「自分がコードを書くことよりも、Pull RequestのコードレビューのTierを上げる」 ということです。
(以下Pull Requestは「PR」と略します)
たとえば具体的な行動としては、「コードを書いているときに PRのReview Requestの通知が来たら、コードを書く手を止めて、即時でレビューを始める」 ということになります。
これは、控えめに言っても"議論の余地のある"約束事と言えるとは思います。
たとえば、Ruby の生みの親である Matz(まつもとゆきひろ)さんが「10 分話しかけられるだけで、半日無駄になる」「元の集中状態に戻るのに半日くらいかかる」と言及した記事が最近話題になっていました。
コードを書く手を外部要因で止めることが、フロー状態にあるプログラマーにとっての大きな"損失"になるケースがあるというのは、よく語られる話かと思います。
コードレビューの Tier を上げるメリット
このように、一見受け入れがたくも思えるコードレビューの Tier を上げるという約束事ですが、自身がレビューをしてもらう立場にまわると得られるメリットの多さに気がつきます。
- 「これ、そろそろレビューお願いします」と リマインドするコストが減る
- いまレビューに出したコードが前提になる変更をしたくて、ブランチを多段にして開発しているうちに大本の PR にクリティカルな指摘が入って 多段で rebase することが少なくなる
- 「レビュー待ち」に時間がかからない分、 「リリース」というアウトカムの実現までがスムーズに行える 感覚がある
...というのは、気持ちのいいものでした。
また、先ほど挙げたようなレビュー依頼をもらう立場での"損失"と思えることも、やってみると意外にも以下のようなことに気が付かされます
- 「AI エージェントを待つ」ことも多い開発の中で、 コードレビューの通知や実施がそこまで強烈なコンテキストスイッチにならない ことも
- 同僚のやりたいことを早めにキャッチアップできる ことで、チーム全体の方向性の議論に繋がることも
- 本当に難しいこと考えているときや納期が迫っているときは、GitHub からの通知に限らず Slack を見ないようにしているのでセーフ
- つまり 「コードを書く」という行為の中にも実は Tier がある
コードレビューの Tier を上げるための工夫
前提として、Slack に GitHub のアドオンを入れて Review Request の通知が即時に飛ぶようにするなどの環境面での準備が必要です。
それでも Slack に気づかなかったり、通知の瞬間はレビューができなかったりすることは決して珍しくありません。
おすすめなのは、 GitHub の機能によるスケジュールリマインダー を定時に設定して、即時の通知と併用することです。
詳しくはこちら:
さらに、 GitHub の /pulls/review-requested の画面から業務を始める こともおすすめです。
また、そもそもレビューのコストを適切に下げることも、当然ながら重要です。たとえば以下のような Tips が考えられるでしょう。
- 適切な粒度での PR 作成をルール化する
- CODEOWNERS の設定で適切にレビューできる人が自動でアサインされるようにする
- dependabot/Renovate などの Dependencies Update における自動マージのルールを決める
- AI レビューツールを有効に活用する
- Ubieでは Cursor Bugbot と Coderabbitai を活用しています。
最後に
さて、最後に玉虫色のことを言うようですが、「コードレビューのTierを上げる」ということがフィットするかどうかはチームや個人に依存します。
フロー状態が求められるタスクの多寡、人それぞれのコンテキストスイッチへの強さという点は想像に難くないでしょう。また、スキルレベルやドメイン知識の偏りが強く、レビューコストが特定の人に集中しやすい場合は特に注意が必要といえます。
「何人の Approve を必要とするか」という点もチームやビジネスの特性によって千差万別でしょう。
また「コードを書くことよりもレビューが絶対に優先度上なんだ！！！」という金科玉条とするよりは、上述したような「それでも今は集中したい」という余地を残しておいた方がサステナブルと思います。
(僕も偉そうなことばかり書いてますが、実践できてないときは結構あります...)
ただ、めんどくさいと言われがちなコードレビューを 「どうせやらなきゃいけないことなんだからさっさとやってしまおう」という取り決めがチームでできたなら、思わぬ体験の良さがある よ...ということを紹介したくて記事を書きました。
チームでの話題の一つにでもなればうれしいです。
Discussion