株式会社K.Platinum 清水洋太
「レビュー、怖くないですか？」
面接や社内の1on1で、ときどきこう聞かれます。自分の書いたコードが人の目にさらされて、赤字で指摘が返ってくる。しかもフルリモートだと、相手の表情も声色も見えません。文字だけが飛んでくる。身構えてしまう気持ちは、私自身よく分かります。
ただ、レビューが怖くなるのは「指摘されること」そのものより、なぜその指摘なのかが分からないまま直させられるときではないでしょうか。理由まで書いてあれば、指摘は攻撃ではなく引き継ぎになります。
だからK.Platinumでは、レビューを「合否を出す関門」ではなく「社内で一番よく読まれる場所」として運用しています。承認の「LGTM（Looks Good To Me＝自分は問題ないと思います）」だけで終わらせない。指摘には必ず理由を添える。プルリクエストは小さく出す。この記事では、社員十数名・フルリモートの現場でそれが実際にどう回っているのかを、できるだけ具体的に書いてみます。開発の進め方が気になっている方の判断材料になれば嬉しいです。
「LGTM」の前に、必ず一言を書く
K.Platinumのレビューには、ゆるやかな決めごとがあります。承認するときに「LGTM」だけで終えない、というものです。
たとえば「この関数、責務が2つに割れてるので分けたほうが後で読みやすいと思います」「ここはあえてまとめてるんですね、理由が分かったので大丈夫です」「このエラーハンドリング、自分は思いつかなかったので次から真似します」。修正が要らないときでも、何を見て何を判断したのかを一行残す。良いと思った箇所を書くのも、指摘と同じくらい大事にしています。たったそれだけのことですが、これがあるとレビューが「チェック」から「会話」に変わります。
指摘を書くときも、「直してください」ではなく「なぜそう思ったか」まで書くことを大事にしています。「命名を変えましょう」だけだと、受け取る側は言われたとおり直して終わりです。でも「このメソッドは呼び出し側が結果を捨てているので、動詞より状態を表す名前のほうが誤読されにくいと思います」まで書けば、次に似た場面が来たとき、その人は自分で判断できます。
実際、レビューコメントで一番多いのは指摘ではなく質問です。「ここ、こういうケースだと落ちませんか？」「この分岐、仕様書のどの条件に対応していますか？」。質問は相手を責めませんし、答えるうちに書いた本人が仕様の穴に気づくこともあります。私自身、質問に答えようとして「あ、これ考慮漏れてました」と自分で見つけたことが何度もあります。
コードは直せば直りますが、判断の基準は書き残さないと伝わりません。だからレビューコメントは、私たちにとって一番小さな社内ドキュメントでもあります。
顔が見えないぶん、判断の理由がテキストに残る
フルリモートだと、隣の席で「ちょっと見てもらえます？」ができません。一見すると不利ですが、実際に働いてみると、悪いことばかりではないと感じています。
口頭で伝えた設計の意図は、その場にいた人の記憶にしか残りません。一方でレビュー上のやりとりは全部テキストで残ります。半年後に同じ箇所を触る人が、「なぜこの実装になっているのか」をコミット履歴から辿れる。新しく入ったメンバーが過去のプルリクエストを読んで、チームの判断の癖を掴んでいく。フルリモートは、それを強制的にやらせてくれる環境でもあります。
以前、ある業務システムの改修で「この一覧、なぜ更新日ではなく登録日で並んでいるのか」という質問がレビューに書き込まれたことがありました。実装した本人も理由を知らず、調べてみると数年前の運用ルールが背景にあると分かった。結果として仕様そのものを見直す話になり、顧客に確認したうえで並び順を変えました。ちょっとした質問がプロダクトの改善につながる。テキストで残るレビューには、そういう副産物があります。
もちろん、文字だけだと冷たく見えるという難しさはあります。そこは工夫していて、指摘は必ず「コードに向けて」書き、人に向けて書かない。「なぜこう書いたんですか」ではなく「この分岐、こういう入力が来たらどうなりますか」と、主語をコードのほうに寄せる。断定より提案の形にする。文字で2〜3往復しても噛み合わなければ、15分だけオンラインで話す。このあたりは全員が意識しているところです。
入社直後のプルリクエストほど、コメントの数が多くなる
新しく入ったメンバーのプルリクエストには、正直かなりの数のコメントが付きます。ここだけ聞くと厳しく見えるかもしれませんが、意図は逆です。
弊社は顧客のビジネス課題に提案段階から入り、業務整理・システム開発・リリースまで一気通貫で支援しています。そのため、コードの良し悪しだけでなく「この仕様は誰のどんな業務を楽にするためのものか」まで含めて話が及びます。レビューの中で「この項目、現場では入力されないことが多いので必須にしないほうがいい」といった業務側の話が出てくるのは、この一気通貫の体制ならではだと思います。
だから最初の数か月は、コードの書き方と同じくらい「背景の共有」にコメントが割かれます。逆に言えば、入社直後に一番たくさん学べる場所がレビューということです。分からないまま実装して、分からないままマージされるのが一番もったいない。
面白いのは、質問する側にも学びがあることです。「なぜこう書いたんですか」と聞かれて答えられなければ、レビュアー側も一緒に調べます。少人数のチームでは、全員が全領域に詳しいわけではありません。フロントエンドが得意な人がインフラのプルリクエストを読み、分からないところを素直に聞く。その往復が、そのままチーム全体の底上げになっています。
未経験や異業種から入ったメンバーも、この往復を繰り返すうちに、半年ほどで指摘する側に回っていきます。教える・教わるの関係が固定されないのが、少人数のチームのいいところです。
こういうレビューが回っている環境で書いてみたい、という方へ。K.Platinumはエンジニアを募集しています。募集職種と働き方の詳細を見る
レビューが止まる原因は、能力ではなく段取り
理想を掲げても、レビューが放置されたら意味がありません。私たちが続けているのは、かなり地味なことばかりです。
ひとつは、プルリクエストを小さく出すこと。数千行の変更が一度に来ると、レビュー側は細部しか見られなくなります。機能単位で分けて出せば、設計の議論ができます。
もうひとつは、レビュー待ちを一人で抱えないこと。フルフレックスで働く時間帯が人によって違うぶん、「◯◯さんしか見られない」状態を作らないようにしています。分からない領域でも、まず読んで質問を書く。質問はレビューとして立派に機能します。
止まっているレビューを掘り下げると、原因はたいてい3つのどれかです。「誰が見るか決まっていない」「変更が大きすぎて手が出ない」「急ぎかどうか分からない」。どれもスキルの問題ではありません。だから私たちは、プルリクエストの説明欄に「何を解決したいのか」「どこを重点的に見てほしいのか」を数行書くようにしています。書く側が1分だけ手間をかけると、読む側の負荷はその何倍も下がります。
そして、レビューは業務時間の中でやる仕事だと全員が認識していること。空いた時間にやる雑務ではなく、開発の一部として時間を確保する。当たり前のようで、意外と崩れやすい部分です。
レビューのやり方には、その会社の開発観が出る
関門として使うのか、学びの場として使うのか。そこには、その会社が開発をどう捉えているかが素直に出ます。私たちは後者でありたいと考えていますし、少人数だからこそ、一人ひとりの書いたコードにきちんと向き合える環境があります。
弊社では、実力が正当に評価される環境を大事にしています。年次や経歴ではなく、書いたもの・出した成果で見てもらえること。それは日々のレビューのような、小さな積み重ねの上に成り立っています。
「もっと踏み込んで開発に関わりたい」「作って終わりではない仕事がしたい」。そう感じている方にとって、K.Platinumは面白い場所だと思います。まずはカジュアルにお話しするところからで構いません。
清水洋太（しみず・ようた）
株式会社K.Platinum所属。エンジニアが力を発揮できる環境づくりを大切にしている。
K.Platinumでは一緒に働くエンジニアを募集しています。「実力で正当に評価される環境」に興味がある方は、ぜひ採用ページをご覧ください。