コードレビューは品質向上のために欠かせないプロセスですが、テキストだけのコミュニケーションは時に冷たく感じられたり、意図した「重要度」が伝わらなかったりすることがあります。
そこで役立つのが、レビュー用の コメント略語（プレフィックス） です。
これらをコメントの冒頭につけることで、「これは絶対直してほしい」「これはただの提案だよ」という温度感を瞬時に共有でき、無駄なすれ違いを防ぐことができます。
本記事では、日常的によく使われる略語と、レビューの質をグッと上げるコミュニケーションの鉄則を紹介します。
1. まずはここから！承認と状況を伝える略語
レビューのステータスを相手にサクッと伝えるための基本用語です。
💡 LGTM (Looks Good To Me)
- 意味: 「良いと思います」「承認します」
- 解説: 単に「OK」と言うよりも、「私が見た限りはバッチリだよ！」というポジティブなニュアンスが含まれます。LGTM画像などを添えるとさらに場が和みます。
💡 ACK (Acknowledged)
- 意味: 「確認しました」「承知しました」「了解」
- 解説: 相手からの指摘やFYI（参考情報）に対して、「読んだよ」「把握したよ」とサインを送る時に使います。LGTM（承認）まではいかないけれど、意思表示をしたい時に必須の略語です。
💡 WIP (Work In Progress)
- 意味: 「作業中（対応中）」
- 解説: プルリクエスト（PR）のタイトルなどにつけて、「まだ完成してないけど、方針が合っているか早めに見てほしい」という時に使います。早期レビューの依頼に非常に便利です。
💡 NP (No Problem)
- 意味: 「問題ないよ」
- 解説: 指摘に対してレビュイー（レビューされる側）が「直しました！」と返してきた時に、「確認したよ、問題ないよ！」と返す時にサッと使えます。
💡 GOTCHA (I've got you)
- 意味: 「了解！」「やったぜ！」「わかった！」
- 解説: 相手の意図を完全に理解した時や、素晴らしいコードを見て「最高だね！」とテンション高く返したい時に使います。チームの雰囲気を明るくするのに効果的です。
2. 指摘の「重み」を明確にする略語
レビューで一番揉めやすいのが、「これは絶対直すべきなのか、どっちでもいいのか」という温度感のズレです。これを防ぐために以下の略語を使い分けます。
🔴 must
- 意味: 「絶対に対応してほしい（必須）」
- 解説: バグの原因になる、コーディング規約に明確に違反しているなど、マージ前に確実な修正を求める場合に使います。
🟡 want
- 意味: 「できれば対応してほしい」
- 解説: 「絶対ではないけれど、こうした方がパフォーマンスが良いよ」「今後の保守性を考えるとこっちが良いよ」といった、よりベターな提案をする時に使います。
🟢 nits (nitpick)
- 意味: 「些細な指摘（重箱の隅をつつくの意味）」
- 解説: 「タイポ（誤字）がある」「インデントが少しズレている」など、ロジックには影響しないけれど直しておいてほしい時に使います。これをつけることで、「細かいこと言ってごめんね」という配慮が伝わります。
3. 自分の意見を「柔らかく」伝える略語
コードに正解がない場合、自分の意見を押し付けるのではなく「あくまで一つの考え」として伝えることで、建設的な議論が生まれやすくなります。
💬 imo (in my opinion) / imho (in my humble opinion)
- 意味: 「私の意見としては」 / 「私のつたない意見では（控えめな意見）」
- 解説: 「こうすべき！」ではなく「私はこう思うんだけど、どうかな？」と議論の余地を残したい時に非常に有効です。
💬 imnsho (in my not so humble opinion)
- 意味: 「ハッキリ言わせていただくと」
- 解説: 謙虚（humble）の逆で、「ちょっと直球で言わせてもらうね」というニュアンスです。少し強いトーンになるため、チーム内の信頼関係がある程度できている状態で使うのが無難です。
💬 imao (in my arrogant opinion)
- 意味: 「私の大胆な意見（ぶっちゃけ）」
- 解説: 直訳すると「私の傲慢な意見では」ですが、フランクに「ぶっちゃけこうじゃない？」と提案する時に使います。こちらもカジュアルな表現です。
💬 FYI (For Your Information)
- 意味: 「参考までに」
- 解説: 「このライブラリの公式ドキュメントにこんな書き方があったよ」「似たような実装が別の機能にもあるよ」など、修正は強要しないけれど有益な情報を共有したい時に使います。
💡 補足
- imnsho (in my not so humble opinion): 「ハッキリ言わせていただくと」
- imao (in my arrogant opinion): 「私の大胆な意見（ぶっちゃけ）」
- GOTCHA: 「了解！」「やったぜ！」
これらは少しカジュアルな表現なので、チームの信頼関係が十分に構築されている場でのスパイスとして使うのが無難です。
4. 略語だけじゃダメ！質の高いレビューにする3つの鉄則
略語はあくまで補助ツールです。心理安全性を高め、スムーズなレビューを行うためには以下の3つのマインドセットが欠かせません。
① 「Why（理由）」をセットにする
must: 直してください とだけ書かれたら、結局冷たく感じます。「なぜ直すべきか（パフォーマンス低下の恐れがあるため 等）」のWhyを必ずセットで書きましょう。
② 指摘ではなく「質問（Ask）」にする
「〜すべきです」と言い切るのではなく、「〜にするのはどうでしょうか？」「〜という意図であってますか？」と質問形式でボールを投げることで、相手に反発を抱かせずに議論をスタートできます。
③ 良いコードは積極的に褒める
コードレビュー＝アラ探し、ではありません。
-
Nice!: 綺麗な実装ですね！ -
+1: このアイデア賛成です！
このように、良い実装にはポジティブなリアクションを積極的に残しましょう。
まとめ：略語は「思いやり」のツール
コードレビューにおける略語は、単にタイピングの手間を省くためのものではありません。「相手にどう受け取られるか」をコントロールし、チームの心理的安全性を担保するための思いやりのツールです。
チーム内で「nitsは対応しなくてもマージしてOK」「mustは絶対」といった共通認識（ルール）を作っておくと、さらにレビューが高速化・円滑化します。ぜひ明日のレビューから、少しずつ取り入れてみてください！