レビュー、キライ、そして今。「ここだけ見ました」から始めるコードレビュー

多様な開発組織のコード／PRレビューを“図鑑”のように紹介する連載「コードレビュー図鑑」。Recustomer株式会社の開発エンジニア・前田さんが語った「コードレビューが嫌いだった自分が、少しずつ嫌いではなくなってきた」変化と、その背景にある取り組みをご紹介します。^[1]

Recustomer株式会社で開発エンジニアをしている前田です。今回は、私が「レビューが嫌いだ」と感じていた理由と、考え方が変わってきた背景を紹介します。

私はレビューが嫌いです

突然ですが、私はレビューが嫌いです。レビューに必要な前提情報が揃っていないことが多かったからです。実装の背景や設計思想が見えないと、コードの意図を追うことができません。

つらかった思い出もあります。例えば、ファイル変更以外の情報がまったくない、Descriptionが空白のPR。あるいは、目的や期待する結果が分からないPRもありました。

「開発が速い会社」のレビューは雑ではなかった

そんな中で、私が所属するRecustomerは2年連続の受賞^[2]など、開発生産性を評価されているスタートアップです。開発スピードが速いと聞くと、「レビューは雑なのでは」と思われるかもしれません。

しかし、私の体感は逆でした。レビューは丁寧で、むしろレビューが強く意識されていました。レビューされていないPRがSlackで通知され、1日に数回「誰のPRが、誰に見てほしくて、何時間待っているか」が流れてきます。

レビューされないと仕事が進みません。だからこそ、レビューの優先度を実装よりも高く置く、という思想が根付いていました。

レビューを支える取り組み

ここからは、そんな弊社で実践しているレビューの取り組みを紹介します。

設計思想を揃え、差分とコンテキストを小さくする

まず取り組みとして大きかったのが、設計思想を揃えることです。Recustomerでは「DDD（ドメイン駆動設計）＋ヘキサゴナルアーキテクチャ」を採用しています。詳細は本筋から外れてしまうので、ここでは特徴だけ説明します。

1つは、上位モジュールが下位モジュールに直接依存せず、インターフェースに依存する点です。インターフェースが変わらなければ、内部実装の変更が影響しにくくなります。例えば、PostgreSQLからDynamoDBへデータベースを変更した場合でも、ビジネスロジックまで見る必要が減り、差分が小さくなりやすいと感じています。また、単体テストが書きやすいというメリットもあります。

もう1つは、各モジュールが単一の責務に集中する点です。レビュワーが把握すべきコンテキストが減るので、責務外の変更が混ざったときも指摘しやすくなります。全員が同じ設計思想で書くことで、誰が書いても大きく揺れない統一されたコードになり、迷いや考え事を減らしてくれます。

社内で「良いルール」を共有する

次に、社内で「良いルール」を共有しています。Recustomerでは「Python Coding Rules」を早い段階からMarkdownで作り、社内に共有してきました。正解が複数ある中で、「こういう思想でいこう」を言語化して揃える狙いです。

ルールの追加や改訂には、全員の承認（Approve）が必要です。全員が同意した変更だけが反映されるので、ルール自体がチームの合意として積み上がっていきます。

これは副次的に、AI活用にも効きました。弊社ではClaude Codeを使っているのですが、Python Coding Rulesを読ませた上でコード生成すると、精度の高いコードが返ってくる印象があります。

PRを小さくする

設計思想とルールが揃うと、PRの出し方にも一貫性が出ます。弊社ではPRを細分化し、レビュー範囲を限定することを意識しています。アダプター、ドメイン、ユースケースといった層ごとにPRを分け、見る側のコストを下げます。

例えば、あるPRの本筋とは別に「エラーハンドリングのリファクタリング」が必要だと気づいても、あえて別PRに切り出します。そうすることでPRが小さくなり、目的がぶれにくくなり、レビューの質も上がると考えています。

実装前に認識を合わせる

そして、弊社では「実装前の認識合わせ」を特に重視しています。

まず、毎週金曜日にスプリントプランニングがあります。EMの言葉として「何かを達成したときに『誰がやった』ではなく『チームで達成した』を目指したい」という思想があります。ここで大まかなタスク内容が共有されるので、全員が要点を把握でき、まったく認識していないタスクが突然出てくる状況は起きにくくなります。

次に、ドメインモデルレビュー会があります。全ての層がドメイン層に依存するため、ドメインは後から変更するコストが高い領域です。要件を共有しつつモデルレビューを先に行うことで、手戻りを減らします。実装PRが上がる頃には、ドメインへの理解が深い状態でレビューに入れます。

テーブルレビュー会も実施しています。テーブル追加やカラム変更といった小さな変更でも対象になります。DBは特に気を使うべきものなので、管理スコープを全員で考えることが大事だと捉えています。そのため、開発メンバー参加必須の設計レビュー会として運用し、明確な答えがない中で「一番いい設計」を共有しています。

Descriptionのフォーマットを決める

PRのDescriptionにもフォーマットがあります。まだ改善の余地はあると感じつつ、現状は「最低限に、シンプルに、分かりやすく」を意識しています。

Descriptionにはバックログへのリンクや変更の意図・変更の概要などを載せています。UI変更がある場合はスクリーンショットも載せ、レビュワーがローカルで環境を立ち上げなくても把握できるようにしています。

レビューに迷ったときは「ここだけ見ました」から始める

ここまで整っていても、「どうレビューしていいか分からない」という方はいると思います。特に、駆け出しの頃はそう感じやすいと思いますし、私自身もそうでした。

そこでおすすめしたいのが、着眼点を絞るやり方です。私が入社したての頃にCTOから言われたのは、「ここだけ見ました」と宣言してレビューすることでした。

例えば、次のような観点は機械的に見やすいと感じています。

• 関数名・変数名が動作を表現できているか
• 1つの関数に複数の処理を詰め込む「スーパー関数」になっていないか
• エラーハンドリングが適切か
• 型定義が適切か

自分が見た範囲を明確にしたうえで、分からない部分は他の担当にパスしても構いません。それでも「十分レビューした」と言える、というのがCTOの考え方で、これは私にとっても救いになりました。

心理的安全性が、レビューを文化にする

レビューを続けるには、心理的安全性が欠かせないと思っています。これがないと意見が言いづらくなり、”No-look approve” のような状態になりがちです。

そういった文化づくりにおいて、弊社で良いと感じたのは質問ベースのコメントでした。要望を伝えつつ、角の立たない言い方をしてくれるので議論が起きやすくなります。さらに、「こういう考え方で、ここはこう変えた方がいい」という判断の背景がレビューに残る点も良いところです。

もう1つは、感謝の言葉です。簡単なリファクタリングや軽微修正のような作業でも、「いい仕事ですね」「ありがとうございます」とコメントがあると、やって良かったと思えます。この雰囲気は今後も続いてほしいと感じています。

レビューは文化をつくるためのもの

弊社のCTOは「コードレビューは文化をつくるためのもの」だとよく言います。

レビューはLGTMを書くためだけのものではなく、考え方を共有する場です。「こういうコードを流行らせたい」「こういう考えを共有したい」という意思が、議論を通じてレビューに残っていきます。チームの文化形成に役立つ、足がかりの1つとしてレビューを捉えています。

弊社ではこのような取り組みを通じて、コードレビューの文化を育ててきました。

そして、こうした積み重ねの中で、今の私はコードレビューが以前ほど嫌いではなくなってきました。

アーカイブ動画・発表資料

本記事は、2026年2月6日に開催されたイベントでの発表をもとに編集したものです。
イベントのアーカイブ動画・資料は以下のリンクからご覧ください。
アーカイブ動画：「コードレビューどうしてる？各社のTips共有会」
※動画の視聴にはFindyへのログインが必要です。