コードレビューの略語一覧！NIT・NITS・IMO・LGTMなどの意味を解説！

GitHubなどでコードレビューをしていると、レビューコメントにNITやIMO、LGTMなどの見慣れない英語が書かれていることがあります。

例えば、次のようなコメントです。

NIT: この変数名はuserNameの方が分かりやすそうです。
IMO: この処理は関数として分けた方がよいと思います。
LGTM!

初めて見ると、「NITって何？」「IMOはどういう意味？」「修正しないといけない指摘なの？」と迷ってしまうこともあるでしょう。

これらは、コードレビューやPull Request（PR）などで、コメントの意図や重要度を簡潔に伝えるために使われる表現です。

この記事では、コードレビューでよく使われるNIT・IMO・LGTMなどの意味や使い方を、具体的なコメント例とあわせてわかりやすく解説します。

コードレビューで使われる略語・プレフィックスとは？

コードレビューでは、コメントの先頭にMUST:やNIT:、IMO:などを付けることがあります。

例えば、次のようなコメントです。

MUST: nullの場合にエラーになるため、チェック処理を追加してください。
NIT: この変数名はuserNameの方が分かりやすそうです。
IMO: この処理は別の関数に分けた方が読みやすいと思います。

このような文字をコメントの先頭に付けることで、レビューを受ける側は「必ず修正してほしい指摘なのか」「細かい指摘なのか」「単なる提案なのか」を判断しやすくなります。

ただし、MUSTやNITなどの使い方に統一された世界共通のルールがあるわけではありません。チームによって意味や重要度が異なる場合があるため、実際の開発ではチーム内のルールを確認することが大切です。

よく使われる表現を簡単にまとめると、次のようになります。

NIT・NITSとは？

NITまたはNITSとは、コードレビューで「細かい指摘」「些細な指摘」という意味で使われる表現です。

例えば、機能そのものには問題がないものの、変数名をもう少し分かりやすくしたい場合に次のように使用できます。

NIT: userという名前よりuserNameの方が分かりやすそうです。
NIT: この空行はなくてもよさそうです。
NIT: このコメントは不要であれば削除してもよさそうです。

この場合、「必ず修正してください」という強い指摘ではなく、「細かいところですが、こうするとより良さそうです」というニュアンスです。

NITやNITSは頭文字を取った略語ではなく、英語のnitpickに由来します。nitpickには「細かいことをあれこれ指摘する」「重箱の隅をつつく」といった意味があります。そのため、コードレビューでは、動作に大きな影響を与えない細かい指摘を表す言葉としてNITが使われています。

IMOとは？

IMOは、「In My Opinion」の略で、「私の意見では」「私としては」という意味です。

コードレビューでは、絶対に修正する必要がある問題ではなく、レビュアー自身の意見や提案であることを伝える場合に使用されます。

例えば、次のように使用します。

IMO: この処理は別の関数に分けた方が読みやすいと思います。
IMO: userDataよりuserの方がシンプルで分かりやすいと思います。

このコメントには、「必ずこうしてください」というよりも「私はこうした方がよいと思います」というニュアンスがあります。

コードレビューでは、設計や命名などについて複数の考え方がある場合があります。そのようなときにIMOを付けることで、「これは絶対的なルールではなく、自分の意見です」ということを相手に伝えやすくなります。

IMHOとは？

IMHOは、「In My Humble Opinion」の略で、「私の控えめな意見では」「私見ですが」という意味です。

IMOと非常によく似ていますが、humbleには「謙虚な」「控えめな」という意味があるため、一般的にはIMOよりも少し控えめな表現として説明されます。

例えば、次のように使用します。

IMHO: このクラスは分割した方が責務が分かりやすくなると思います。

ただし、実際のニュアンスは書き手や文脈によって異なります。IMOとIMHOをほぼ同じ意味で使用する人もいます。

MUSTとは？

MUSTは、「必須」という意味で、コードレビューで「必ず修正してほしい」という強い指摘を表すために使われます。

例えば、バグにつながるコードやセキュリティ上の問題がある場合に使用できます。

MUST: userがnullの場合にエラーになるため、nullチェックを追加してください。

セキュリティ上の問題などでも使用できます。

MUST: パスワードをログに出力しないように修正してください。

MUSTは強い表現なので、単なる好みや細かいコードスタイルの違いではなく、バグや仕様違反、セキュリティ上の問題など、修正が必要な明確な理由がある場合に使用すると分かりやすいでしょう。

WANTとは？

WANTは、「できれば修正してほしい」「修正してもらえるとうれしい」という意味で使われることがあります。

MUSTほど必須ではないものの、改善してほしい部分に使用します。

WANT: この処理は関数に分けると読みやすくなるので、できれば分割してほしいです。

MUSTと比較すると、次のようなイメージです。

MUST → 修正が必要
WANT → できれば修正してほしい

ただし、WANTを「マージ前に対応してほしい」という意味で運用するチームも考えられるため、修正の必須度はチーム内で決めておくことが重要です。

Q・QUESTIONとは？

Qは「Question」の略で、「質問」という意味です。QUESTIONとそのまま書かれる場合もあります。

コードレビューで実装の意図や仕様を確認したい場合などに使用します。

Q: この処理を非同期にしている理由はありますか？

また、次のように実装について確認するときにも使用できます。

Q: この値がnullになる可能性はありますか？

QやQUESTIONは基本的に修正を要求しているのではなく、コードの意図や仕様を確認するためのコメントです。

そのため、質問されたからといって必ずコードを修正する必要があるわけではありません。

ASKとは？

ASKは、質問や確認をしたい場合に使用されるプレフィックスです。

QやQUESTIONとほぼ同じ目的で使われます。

例えば、次のように使用します。

ASK: この処理をUserServiceに配置した理由を教えてもらえますか？

チームによってQを使用する場合もあれば、QUESTIONやASKを使用する場合もあります。

同じ意味のプレフィックスを増やしすぎるとかえって分かりにくくなるため、チーム内でどれを使うか決めておくとよいでしょう。

SUGGESTとは？

SUGGESTは、「提案」という意味で使用されます。

現在の実装でも問題はないものの、別の実装方法を提案したい場合などに使用できます。

例えば、次のようなコメントです。

SUGGEST: この処理はmapを使うともう少しシンプルに書けそうです。

IMOと似ていますが、IMOが「自分の意見」を示すのに対して、SUGGESTは具体的な代替案や改善案を提示する目的で使いやすい表現です。

DISCUSSとは？

DISCUSSは、「議論したい」「相談して決めたい」という意味で使用されます。

正解が1つに決まらず、設計や実装方針について話し合いたい場合に便利です。

例えば、次のように使用します。

DISCUSS: この処理をControllerとServiceのどちらに持たせるか相談したいです。

この場合、レビュアーが「Serviceに変更してください」と決めているわけではありません。

「どちらにするのがよいか一緒に考えたい」というコメントです。

FYIとは？

FYIは、「For Your Information」の略で、「参考までに」「参考情報として」という意味です。

基本的には修正を要求するための表現ではなく、知っておいてもらいたい情報を共有するときに使用します。

例えば、関連するドキュメントを紹介する場合に次のように使用できます。

FYI: このAPIについては公式ドキュメントにも詳しい説明があります。

また、将来的に役立ちそうな情報を共有する場合にも使用できます。

FYI: Node.js 22ではこの書き方も利用できます。

「今すぐ直してください」ではなく、相手に知っておいてもらいたい情報を共有するときに便利です。

TODOとは？

TODOは、「To Do」から来ている表現で、「やること」「今後対応すること」という意味です。

コードレビューでは、現在のPull Requestでは対応しないものの、あとで対応する必要がある課題などを示す場合があります。

TODO: この処理のテストケースは別のPRで追加する。

ソースコードのコメントでもよく使われます。

// TODO: エラー処理を追加する

ただし、TODOを残したまま忘れてしまう可能性もあるため、重要な作業であればIssueなどで管理する方法もあります。

LGTMとは？

LGTMは、「Looks Good To Me」の略で、「私には良さそうに見えます」「問題ないと思います」という意味です。

コードレビューでは、レビューしたコードに問題がなく、承認できるときによく使われます。

例えば、修正内容を確認して問題がなければ次のようにコメントできます。

LGTM!

日本語の感覚では、「確認しました。問題なさそうです！」というニュアンスに近い表現です。

LGTMはコードレビューでよく使われますが、MUST:やNIT:のようにコメントの先頭に付けて重要度や意図を示すプレフィックスとは少し性質が異なります。

MUST・WANT・NIT・IMOの違い

特にコードレビューで迷いやすいのが、MUST・WANT・NIT・IMOの違いです。

例えば、同じコードにコメントするとしても、意図によってプレフィックスが変わります。

ただし、WANTやNITをマージ前に対応必須とするかどうかなどは、チームによって異なります。

レビューコメントにプレフィックスを付けるメリット

レビューコメントにMUSTやNIT、IMOなどを付ける大きなメリットは、コメントを書いた人の意図が伝わりやすくなることです。

例えば、次のコメントだけでは、どの程度強い指摘なのか分かりにくい場合があります。

この変数名はuserNameの方がよいと思います。

レビューを受けた人は、「必ず変更しないといけないのかな？」と迷うかもしれません。

しかし、次のように書けば意味が分かりやすくなります。

NIT: この変数名はuserNameの方が分かりやすそうです。

NITが「細かい指摘」というルールをチームで共有していれば、「重大な問題を指摘しているわけではない」とすぐに判断できます。

反対に、次のようにMUSTが付いていれば、修正が必要な重要な指摘であることが分かります。

MUST: nullの場合にエラーになるため、チェック処理を追加してください。

このようにプレフィックスを利用することで、レビューコメントの重要度や目的を伝えやすくなります。

プレフィックスの意味はチームで統一する

MUST・WANT・NIT・IMOなどは便利ですが、最も重要なのはチーム内で意味を統一することです。

例えば、あるチームではNITを「修正しなくてもよい細かい指摘」としていても、別のチームでは「細かい指摘ではあるが、できればマージ前に修正する」という運用になっている可能性があります。

また、質問をQと書くチームもあれば、QUESTIONやASKと書くチームもあります。

そのため、新しくプレフィックスを導入する場合は、例えば次のようにルールを決めておくと分かりやすいでしょう。

MUST    : マージ前に必ず修正する
WANT    : できれば修正する
NIT     : 細かい指摘。対応は任意
IMO     : 個人的な意見。対応は任意
Q       : 質問
FYI     : 情報共有。対応不要
DISCUSS : 話し合って決めたい

重要なのは、「どの英単語を使うのが正解か」ではなく、レビューする側とレビューされる側で同じ意味として理解できることです。

コードレビューでよく使われる略語・プレフィックス一覧

特によく使われるのは、NIT・IMO・LGTMなどです。また、レビューコメントの重要度を分かりやすくするために、MUSTやWANTなどが使われることもあります。

本記事のまとめ

この記事では「コードレビューでよく使われる略語・プレフィックス」について、以下の内容を説明しました。

• NIT・NITSは、細かい指摘を表す
• IMOは「In My Opinion」の略で、自分の意見であることを表す
• MUST・WANTなどを使うと、レビューコメントの重要度を伝えやすくなる
• LGTMは、レビューしたコードが問題なさそうなことを伝える表現
• Q・ASK・SUGGEST・DISCUSSなどを使うと、コメントの目的を伝えやすくなる
• プレフィックスの意味や修正の必要性は、チーム内で統一することが重要

お読みいただきありがとうございました。