「このコード、なんでこう書いたの？」そんな一言に、ビクッとした経験はないだろうか。
コードレビューは本来、コードの可読性と安全性を高め、チームでより良いプロダクトを育てるための大切なプロセスだ。ただ、経験の浅い若手エンジニアの中には、「指摘が怖い」「テストみたいで面白くない」「何が正解か分からない」といった理由で、コードレビューをネガティブに感じてしまう人も少なくない。
コードレビューをポジティブに捉えるには、どのようなマインドセットや工夫が必要なのか。そのヒントを求めて話を聞いたのは、“納品のない受託開発”を掲げ、プロダクトと10年単位で向き合い続けるエンジニア集団・ソニックガーデン。
同社に所属するプログラマー・伊藤淳一さんと石崎海渡（ざっきー）さんに、「チームでコードを育て続けるためのレビュー文化」について話を聞いた。
株式会社ソニックガーデン
伊藤淳一さん（@jnchito）
1977年生まれ、大阪府豊中市出身。SIer、外資系半導体メーカーの社内SEを経て、2012年ソニックガーデンに入社。保守性、拡張性の高いシンプルなコードを追求するプログラマーであり、プログラミングスクール「フィヨルドブートキャンプ」でメンターも務める。ブログやQiitaなどでプログラミング関連の記事を多数公開している。将来の夢はプログラマーをみんなの憧れの職業にすること。主な著書に『プロを目指す人のためのRuby入門』（技術評論社）などがある
株式会社ソニックガーデン
石崎海渡さん｜ざっきー（@umikun_summer）
1997年生まれ、東京都足立区出身。大学でプログラミングの面白さや奥深さを感じ、卒業後にSIerを経て2023年にソニックガーデンに徒弟制度の弟子として入社。業務と並行して「いいコード研究会」のレビュアーとして出演中。「いいコード」とは何かを考え続け、奮闘の日々を送る
ーー「コードレビューが怖い」「面白くない」といった声について、伊藤さんは率直にどう思われますか？
伊藤：僕自身は「つまらない」と感じることはあまりないですね。もちろん、「ちょっと腰が重いな」と思うタイミングはありますよ。
よくあるのは、プルリクエストのDiff（変更量）が大きすぎる時とか。1000行以上の変更が一気に出てきたりすると、「これ、今から全部見るのか……」と気が重くなりますね（笑）
しかもそういう時に限って、ディスクリプション（説明文）がほとんど書かれていなかったりする。なので自分で上から全部読んで、「なるほど、こういう意図の変更なのか」と解釈しないといけない。
そういった手間が大きいと、さすがにしんどいなとは思います。
ーー大変さを感じることもあるけれど、つまらないわけではない、と。
伊藤：そうですね。まあ、だからといって「じゃあコードレビューが楽しいんですか？」と言われると、別に楽しいと言いながらやっているわけでもないというか……。
そもそもコードレビューって、ある意味「未来の自分を助ける行為」だと思っています。
特にソニックガーデンの開発は「納品のない受託開発」（※）というスタイルなので、プロジェクトが10年単位で続くこともある。その間、僕たち自身がずっとコードの面倒を見続けるんですね。
だから、今ここで適当にレビューして通してしまうと、数カ月後や数年後の自分、あるいは同じチームの仲間が困ることになる。逆に言えば、「分かりやすい」「きれい」「安全」なコードにしておけば、将来このシステムに関わるエンジニアたちが楽になる。
その“岐路”に自分が立っている意識を持つことができれば、レビューに対するモチベーションも自然と生まれてくる気がします。
（※）納品をせず、月額定額でシステムの開発・保守・運用を継続的に支援する、株式会社ソニックガーデンが提唱する開発スタイル。顧客のビジネスパートナーとして、長期的な関係を築くことを特徴とする
ーーなるほど。一方で、レビューされる側の感覚も気になります。
ざっきー：人によっては、「理解できないコメントが来たらどうしよう」とか、「コメントが多すぎたらへこんでしまいそう」と不安に感じるエンジニアもいると思います。そうした怖さから、「レビューは必要だけど、できれば最低限に済ませたい」と感じてしまう人もいるのではないでしょうか。
でも僕自身は、怖いというよりも「レビューがあるから成長できる」という安心感のほうが大きいです。
コードに込めた意図を問われたり、自分では気付けないケアレスミスを指摘してもらったりする中で、自分の知らない考え方や、もっといい命名を学ぶことができる。僕にとっては、すごく価値のある時間だと思っています。
伊藤：ざっきーが言うように、コードレビューを「成長の機会」と捉えられるかどうかですよね。
僕自身、以前はJavaやC#を使っていて、ソニックガーデンに入った当初はRubyの経験がほぼゼロでした。その中で先輩にレビューしてもらい、「ここはこう書けるよ」といったアドバイスをたくさんもらいましたが、「嫌だな」とは感じなかった。むしろ「ああ、なるほど」「確かにそのほうがきれいだな」と素直に納得できました。
そうやって少しずつ自分の書くコードが良くなっていくと、やっぱり嬉しいんですよね。「成長できたな」っていう実感があれば、レビューされることをポジティブに受け止められるはずです。
ざっきー：僕は、業務ではレビューを受ける側に回ることが多いのですが、運営している「いいコード研究会」というコミュニティーではレビューする側にも回っています。
人のコードを読む中で、「自分ならこう書くけど、こういう書き方もあるんだな」と気付かされることが多いです。自分の考えと比べながら、「これはたしかにスッキリしてるな」と納得したり、逆に「自分の選んだ書き方にも意味があったな」と再確認できたりもします。
そうやって、他の視点に触れたり、自分の思考を深めたりできるのが、コードレビューの面白さだと思っています。
ーーコードレビューに前向きに取り組む文化を根付かせるには、どうすれば良いのでしょうか。
伊藤：ソニックガーデンでは、どんなコードであっても、本番リリースする前に必ず他のエンジニアがコードレビューを行い、その上で「Approve（承認）」してからリリースするといったルールを徹底しています。
こうした前提があるので、レビューに対して素直に耳を傾けられない人や、指摘されるたびにケンカ腰になってしまうような人だと、そもそもやっていけない環境です。
ーー採用の段階から、コードレビュー文化へのカルチャーフィットを重視されているのですね。
伊藤：ええ。採用では「一緒に開発してみる」というプロセスを必ず挟んでいて、その中で「この人ならちゃんとレビューのやり取りができる」と判断できた人だけが入社するスタイルです。
ただ、個人の素養以上にもっと大事なのは、「コードレビューは人格否定じゃない」ことを、しっかりメンバーに伝えていくことですね。
ーーと、言いますと？
伊藤：コードはコードにしか過ぎず、「自分が書いたコード＝自分自身」ではありません。
でもエンジニアを始めたばかりの人は、「コメントが何もつかなければ百点」「何か言われたら減点」といった風に、コードレビューを学校のテストのようなものだと感じやすい。そうやって“減点方式”で捉えてしまうと、仮に指摘を受けた際、「自分は間違っていたんだ」「ダメ出しされた、自分はダメだ」とネガティブな気持ちになってしまいます。
なので、先輩が「そうじゃないんだよ」とちゃんと伝えてあげることが大事なんです。コードレビューはあくまでも「コードを良くするためのやり取り」であって、コーディングテストとは違います。
ざっきー：パッと見て少し変に見えるコードがあっても、「何か理由があるはずだ」という前提で「どうしてそうしたの？」と聞くことが大事ですよね。コードレビューを行う際には、まず「正しいか／間違っているか」という意識を切り離した方がいいと思います。
ーーそうした「お作法」は、ガイドラインとして明文化されているのでしょうか？
伊藤：いえ、ルール化は意図的に避けています。ドキュメント化すると形骸化しやすいですし、「ルールで決まってるからこうやってるんです」と、思考停止に陥りがちなので。
それよりも、一緒に仕事をする中で直接伝えたり、週一の振り返りを通じて伝えたりする方が、遠回りに見えて実はコストが低いんです。
ざっきー：それこそ入社したての頃は、プルリクの書き方やレビューのルールがあればいいのにと思っていました……（笑）
でも、もし最初にルールブックを渡されていたら、僕はそこで思考が止まってしまっていたでしょうね。「なぜこう書くんだろう？」と考える機会がなくなってしまう。ルールで決まっていると、きっとそう書いて終わりですから。
ーーではスムーズなコードレビューを実現するために、レビューイ（レビューを依頼する側）が気を付けておくといいポイントを教えてください。
伊藤：レビュアー（レビューをする側）の負担を減らす意識を持つことが、一番大事だと思います。
まずは何より、「プルリクエストのサイズをなるべく小さく保つ」こと。そして、ディスクリプションには「全体としてどんな変更を加えたのか」を丁寧に書くことが重要です。
それに加えて、「レビューの濃淡をリクエスト」してもらえるとすごく助かりますね。
「この部分はツールが自動生成したコードなので、ざっと見てもらえれば大丈夫です」とか、「AIの出力を参考に書いたので不安があり、しっかり確認してほしいです」といったように、見てほしいポイントの重み付けを伝えてもらえると、レビューの精度も効率も格段に上がります。
ざっきー：プルリクのサイズを小さくすることは、僕も意識しています。
大きな開発タスクだと、1件あたりのプルリクのサイズを小さくするために、プルリクを数回に分けて作成する必要があります。このとき、ディスクリプションに「まだやってないこと」、つまり「このあとのプルリクでやること」を明記しておくことも大事ですよね。
例えば、「アプリケーション側のコードは書き終わっているが、テストコードはまだ書いてない」という場合、その点を事前に伝えておかないと「あれ、テストコードがないぞ？」とレビュアーに余計な心配をかけてしまう。
そうなると、「テストコードがないですよ」「いえ、テストはこのあとのプルリクで書く予定です」といった無駄なコメントのやりとりが発生してしまいます。
ーー逆に、レビュアーが心がけておきたいポイントは何でしょうか？
伊藤：レビューする際に僕が一番注目しているのは、「読みやすさ」や「分かりやすさ」です。「凝ったコード」や「自分にしか書けないコード」が評価されるわけではなくて、誰が読んでもすっと理解できる、素直で端的なコードになっているかを最重視しています。
というのも、ソニックガーデンの開発スタイルでは仕様書を別途作らず、「コードこそがドキュメント」という前提があるからです。後から関わる人や未来の自分がコードを見たときに、意図や処理が自然と読み取れることが何より重要なんですね。
だからレビューでも、「パッと見て意味が伝わらないコード」には指摘を入れます。特に多いのが、変数名やメソッド名の命名。ここが曖昧だと、まるで主語と述語がかみ合わない文章のように、読む側にストレスを与えてしまいます。
ざっきー：あとは、レビューは基本的にテキストでのやり取りになるので、コメントの書き方や言葉のトーンも大事ですよね。
伊藤：確かに、「ベテランと新人」のような、少し上下の関係性があるときは特に注意が必要ですね。
単純に「どうしてこう書いたの？」と聞きたかっただけなのに、言い方次第では「聞いた＝間違い」だと受け取られてしまい、「すみません、すぐ直します」と恐縮されてしまうこともあるので。
ーー確かに、伊藤さんクラスの方に「これ、どういう意図なの？」って聞かれたら、一瞬背筋が伸びそうです（笑）
伊藤：だから僕も、「これはただの質問なんだけどね」と一言添えるなど、相手に安心してもらえる言葉を選ぶようにしています。
個人的に、レビューは「コードの質を上げる場」であると同時に、「関係性の質が問われる場」でもあると思っていて。信頼関係がある相手にはフランクに、まだ関係性が浅い相手には丁寧に。その場ごとの空気や距離感を見ながら、自然と言葉のトーンを変えています。
お互いが平等に議論できる場を心がけることが、何よりも大切ですね。
写真／ソニックガーデン提供 取材・文／今中康達（編集部）
タグ