シリーズについて：「職場の暗号辞典」は、エンジニアが職場で使う言葉の「本当の意味」を翻訳するシリーズです。
- Vol.1：設計レビュー編
- Vol.2：コードレビュー編（本記事）
- Vol.3：障害対応・振り返り編（近日公開）
- Vol.4：スプリント・スクラムイベント編（近日公開）
- Vol.5：1on1編
- Vol.6：採用面接編
- Vol.7：見積もり編
- Vol.8：技術選定編
はじめに
コードレビューは、エンジニアが毎日顔を突き合わせる（あるいはGitHub上で突き合わせる）コミュニケーションの場です。
しかしここにも独自の言語体系があります。nit: ひとつとっても、文字通り「細かい指摘」のこともあれば、「本当はもっと大きい問題なんだけど言い方を和らげた」のこともある。LGTM! も、「心からOKを出した」のか「とりあえずApproveしてしまった」のかは、GitHubのコメントからは読み取れません。
この記事では、コードレビューでよく見るフレーズを素直な日本語に翻訳します。PRを出す人にも、レビューする人にも、どちらにも使える辞典を目指しました。
翻訳辞典：コードレビュー編
「nit:」
翻訳： ① 本当に細かいこと、または ② 大きな問題だけど角を立てたくなかった
nit（ニット）は「nitpick（細かいことにこだわる）」の略で、本来は「直さなくても良いけど気になった」というレベルの指摘に使います。
しかし現実には振れ幅が広い。「変数名のスペルが1文字違う」という本物の nit から、「このロジック全体を見直してほしいんだけど、角を立てたくないから nit: とつけた」という事実上の必須対応まで幅があります。
見分け方は、nit: の後の文章量と内容です。1行で終わるなら本物の nit。その後に3行以上の理由が続くなら、実は本命の指摘です。
対処法： nit: がついていても「直さなくていいですか？」と確認するのが無難。レビュアー側は、必須か任意かを nit: / must: / optional: などで明示するルールをチームで決めると誤解が減ります。
「LGTM!」
翻訳： ① 本当にレビューしてOKを出した、または ② 時間がなかった・信頼して飛ばした
Looks Good To Me の略。コードレビューにおける最強の呪文であり、最も濫用される言葉でもあります。
LGTM! の品質には天と地ほどの差があります。全ファイルを読み込んで設計上の懸念まで確認した LGTM! と、タイトルとdiffの最初の10行だけ見た LGTM! は、見た目上まったく同じです。
「レビューのスループットを上げるため、信頼できる人のPRは軽めに見る」という文化のチームでは後者が多くなりがちです。それ自体は必ずしも悪ではありませんが、新人のうちは「LGTM!が来た＝完璧」と思わない方がいい。
対処法： PRの説明文に「特にここを重点的に見てほしい」という一文を入れると、レビュアーの注意が向きやすくなります。LGTM! の品質が上がります。
「お好みで」
翻訳： 直してほしいけど、強く言うほどではない（でも気にはなっている）
nit: の親戚ですが、より柔らかいニュアンスです。「こっちの方が読みやすいと思うけど、絶対こうしろとは言えない」という微妙なゾーンに使われます。
問題は、出した側は「直してほしいな」と思っているのに、受け取った側が「任意なら別にいいか」と流してしまうケースです。どちらも悪くないのに、認識がすれ違う。
対処法： 「お好みで」と言われたら「どちらが好みですか？」と聞いてしまう。大抵の場合、相手は明確な意見を持っています。
「ここ、テスト書けますか？」
翻訳： テストがないのは問題です（断言）
疑問形ですが、疑問ではありません。「テストを書く能力があるかどうか」を聞いているのではなく、「テストがない状態でマージするつもりですか？」という確認です。
まれに本当に「このコード、テスタビリティが低すぎてテストが書けないですよね？」という技術的な問いかけのこともあります。しかしほとんどの場合、答えは「書いてください」です。
対処法： PRを出す前に「テストが書けていない理由」を説明欄に書いておく。「〇〇の理由でこのPRではスキップし、Issueを起票しました」という一文があると、この質問がほぼ来なくなります。
「変数名、もう少し意味のある名前にできますか？」
翻訳： tmp2 はさすがに困ります
コードの可読性に関する指摘の中で最も穏やかな言い方です。data、result、tmp、flag、x……命名に困ったときについ使いたくなる言葉たちへの、やんわりとしたNOです。
「意味のある名前」というのは、コードを読む次の人（＝3ヶ月後の自分）が「ああ、これが何を表しているかわかる」と感じられる名前のこと。getUserById は良い。getU はダメ。getUBD は論外。
対処法： 自分で書いた変数名を見て「この変数が何か、コメントなしで説明できるか？」と自問する習慣をつける。できなければ改名する。
「このロジック、整理できますか？」
翻訳： 読めないです
婉曲表現の中でもトップクラスに丁寧な言い方です。整理できますか？ は「あなたならできるはずですよね」という期待を込めた疑問形に見えますが、実態は「このネストの深さは人間が読める限界を超えています」という告白です。
ネストが4階層を超えたとき、条件分岐が10行以上続くとき、同じような処理が3か所以上にコピペされているとき——これらはすべて「このロジック整理できますか？」が飛んでくるサインです。
対処法： 「整理する」の具体的な方法は、早期リターン・関数分割・ガード節の導入など。どれも小さな変更から始められます。「まずここだけリファクタしてもいいですか？」と聞くと、前向きな印象を与えられます。
「確認なんですが、これ動きますか？」
翻訳： 動かなかったです（報告）
質問形式の障害報告です。「動きますか？」という問いに「動きます」と答えたら終わり……ではなく、「なぜ動くと思うのか説明してください」という続きが来ます。
ローカルで試してみたら動かなかった、テスト環境で確認したら落ちた——そういう場合に、真っ向から「動きません」と言うより柔らかい表現として使われます。
対処法： PRの説明文に「動作確認済みのこと」を書いておく（スクリーンショット、ログ、テスト結果など）。「これ動きますか？」という質問は、動作確認の証拠がないPRに来やすいです。
「ここ、以前も似たような議論があったような気がします」
翻訳： 過去に同じ結論が出ていて、それと違う方向に進もうとしています
「気がします」という曖昧さに惑わされてはいけません。このフレーズを言う人は、大抵「確実に覚えている」か、「検索すれば出てくる」状態です。
アーキテクチャの決定事項、技術選定の経緯、過去のリファクタの理由——チームに歴史があるほど、この言葉が出やすくなります。
対処法： 「確認してみます」と言って、Slackのログ・過去のPR・ADR（Architecture Decision Record）を掘る。見つかった場合は「〇〇のPR #123 で議論があり、〇〇という結論でした。今回はその判断が変わる理由が〇〇です」と文脈付きで返す。
「レビューお願いします 🙏」
翻訳： ① 普通のレビュー依頼、または ② 早めに見てほしい（絵文字に圧が込められている）
絵文字の数と種類で強度が変わります。🙏 が1個なら標準的な依頼。🙏🙏🙏 や 🙇 になってきたら「締め切りが近い」か「長い間レビューが来ていない」か「本当に困っている」のどれかです。
また、本文に「お手すきの際に」とありながら絵文字が3つ以上ついている場合は、「お手すきではなく今すぐ見てほしい」という本音を絵文字が代弁しています。
対処法： レビューを依頼するときは「いつまでに欲しい」を明記する。「今週金曜マージしたいので木曜中に見ていただけますか？」のように書くと、期待値のずれが起きにくいです。
なぜコードレビューに暗号が生まれるのか
コードレビューは技術的なフィードバックの場であると同時に、人間関係が直接影響する場でもあります。
「このコードはダメです」と言えば確かに明確ですが、書いた人を傷つけるかもしれない。だから「このロジック整理できますか？」という言い方になる。これは悪意ではなく、摩擦を減らそうとする人間的な配慮です。
問題は、配慮が過剰になると「伝わらない」ことです。nit: と書かれた必須対応を「任意か」と思って流してしまう。LGTM! を信頼して出したのに実はざっくりしか見ていなかった。こういったすれ違いは、どちらも悪くないのに起きます。
コミュニケーションのコストを下げるには、「言外の意味を読む」能力を上げるか、「言外の意味を込めない」文化を作るか、どちらかです。両方やるのが理想ですが、まず自分でできる方から始めるしかない。
暗号を減らすためのコードレビュー文化の作り方
PRを出す人として：
- 説明文に「何を・なぜ・どう変えたか」を書く（レビュアーの推測コストが激減する）
- 「特に見てほしい箇所」をコメントでハイライトする
- 動作確認済みであることを証拠つきで書く（スクリーンショット・テスト結果）
レビューする人として：
-
nit:/must:/optional:などのラベルをつけて強度を明示する - 「整理できますか？」より「早期リターンを使うと読みやすくなります」と具体的に言う
-
LGTM!の前に「ここを重点的に見ました」と一言添えると信頼度が上がる
おわりに
コードレビューの言葉を翻訳すると、実はほとんどが「もっとこうしてほしい」という建設的な意図から来ていることがわかります。暗号を使うのは相手を傷つけたくないからであって、意地悪からではない（大抵の場合）。
だとすれば、翻訳する能力と同時に「暗号を使わなくていい関係性」を少しずつ作っていくことが、長期的には一番効果的です。
次回はVol.3：障害対応・振り返り編。「影響範囲を確認します」「暫定対応を入れました」「人為的なミスでした」——障害対応の場に独自の言語体系を翻訳します。
株式会社なかのひとカンパニーでは随時エンジニアを募集しています。詳しくは採用情報ページをご確認ください。