技術系TIPS
PR

LGTM(Looks Good To Me)とは?意味・使い方・NG例までぜんぶ解説

saratogax
記事内に商品プロモーションを含む場合があります

LGTM = Looks Good To Me(よさそうですね)

コードレビューやSlack/GitHubのやりとりで、変更に賛成・承認を示す省略表現として使われます。

レビューコメントの最後に「LGTM」と添えたり、承認時の短い補足とセットで使うのが一般的です。

PR

LGTMの基本:意味と使う場面

  • 意味
    • Looks Good To Me(自分の観点では問題なし/この変更で進めてOK)
  • 使う場面
    • Pull Requestの内容に目を通し、要件・安全性・スタイルがチーム基準を満たすと判断できたとき
    • 議論の末に合意した修正が反映されたことを確認したとき
  • 注意
    • LGTMは“レビューした上での承認”を表すべきで、レビューの代替にしてはいけません(形式的な“スタンプ”は逆効果)

具体例:良いLGTMコメント/悪いLGTMコメント

良い例(次の人が助かるLGTM)

  • LGTM
    • テストケース追加ありがとう
    • 境界値(0/1)までカバーされているのを確認しました
  • LGTM(nits only)
    • 命名だけ軽微に提案
    • merge前に userIduserID に統一で!
  • LGTM
    • 監査ログの出力が必須条件を満たしているのを確認
    • リリースノートへのリンク追記もOK

OKの根拠(何を見て、どこを確認したか)を1行でも添える。後から読み返した人にも価値が残ります。

悪い例(形骸化するLGTM)

  • LGTM だけ(根拠なし)
  • LGTM、詳細は見てませんが…(未レビューの宣言)
  • LGTM、急いでるのでマージお願いします(プロセス無視)

LGTMの運用ルール(レビュー文化を壊さないために)

  • チェックリストを共通化
    • 動作要件/セキュリティ観点/ログ・監視/テスト有無など、チーム標準の見方をテンプレ化
  • 軽微な指摘は nit と明記
    • nit: …(単数の軽微指摘)
    • nits: …(複数の軽微指摘)
      という書き分けで、任意度の高さを明確化。必須修正との線引きも最初に合意しておく。
  • 承認要件をツールに埋め込む
    • CIやGitHub保護ブランチで必須承認数・必須チェックを満たさないとマージ不可に
    • “LGTM待ち”フローを仕組み化します
  • 雑談ではSGTM、レビューではLGTM
    • チャットでの合意は SGTM(Sounds Good To Me)、レビュー承認は LGTM と使い分けて誤解を減らす

関連略語:SGTM・nit・+1 など

  • SGTM
    • Sounds Good To Me(提案・方針に同意)
    • 合意形成向けで、レビュー承認そのものではない
  • nit/nits
    • nitpick(粗探し=軽微な指摘)の略
    • 大文字ではなく小文字で書くのが一般的
    • nit: / nits: でコメント先頭に付けると意図が伝わる
  • +1
    • 賛同のショートハンド
    • レビューでは根拠とセットに

LGTMとLGTM.com(混同しがちな別物の話)

LGTM(コメント表現)と、かつての静的解析サービス LGTM.com は無関係

LGTM.comはその後GitHubに統合され、現在は GitHub Code Scanning(CodeQL) が後継の位置づけです。

導入検討時はCodeQL側を参照しましょう。

よくある質問(FAQ)

Q. 「LGTMだけ」でもOK?

A. 状況によりますが、根拠の一言を添えるのがベター。品質の共有知として残ります。

Q. 「LGTM」はビジネスチャットでも使う?

A. エンジニア文化では一般的。ただし職場の文化差があるので、最初は SGTM の方が通じやすい場合も。

Q. おもしろ表現「Let’s Get This Merged」って正しい?

A. 俗語的な言い換え。公式の意味は Looks Good To Me

まとめ

  • LGTMは“レビューを経た承認”の合図
    • 根拠を1行添えるだけで、価値がぐっと上がる
  • SGTM/nit/+1 などの略語と使い分けて、議論と承認を整理
  • LGTM.comは歴史的サービス名で、いまはGitHub Code Scanning(CodeQL)が実運用の選択肢

追記:用語メモ(nit/nits・IMO ほか)

  • nit / nits
    • nit単数の軽微指摘nits複数
    • 例:nit: 変数名は userID に統一をnits: 句読点・インデントの体裁
    • 任意(suggestion)/ 必須(must)の線引きはチームで事前に合意
  • IMOIn My Opinion
    • 「私見では」のクッション
    • 断定を和らげて提案する時に有効
    • 例:IMO, この責務は service 層に分離した方がテスト容易です
  • IMHOIn My Humble/Honest Opinion
    • IMOより柔らかい
    • 文化によっては冗長に感じられるので使い分けを
  • PTALPlease Take A Look
    • 「見てください」
    • 再レビュー依頼などで使用
    • PTAL @reviewer
  • RFCRequest For Comments
    • 実装前の方針レビュー
    • いきなりLGTMを求めず議論を集めたい時に
  • WIP / DraftWork In Progress
    • 作業中PR
    • どの観点を見てほしいかを明示すると効果的
  • FYIFor Your Information
    • 情報共有・注意喚起
    • 原則対応不要のニュアンス
    • 例:FYI: この件は別PR #1234 で対処予定。no action needed.
    • 受け手にアクションを求めるなら SGTM/LGTM/レビュー依頼など適切な表現へ
  • typo
    • 誤字・脱字・スペルミス
    • 客観的に修正が明確な場合に
    • 例:typo: pulll → pulls/pull requset/pull request/
    • nit(任意の軽微指摘)と混同しないように:誤記は typo、好みや微調整は nit
PR
ABOUT ME
saratoga
saratoga
フリーランスエンジニア
仕事にも趣味にも IT を駆使するフリーランスエンジニア。技術的な TIPS や日々の生活の中で深堀りしてみたくなったことを備忘録として残していきます。
記事URLをコピーしました