must｜コードレビューにおける「must」の意味と適切な使い方

概要

コードレビューで「must」と書かれたコメントを見たことがある方は多いはずです。
この言葉は、単なる表現ではなく、「レビュー通過には修正が必須である」という強い意思表示を伴います。
しかし、安易な使用はコミュニケーションの摩擦やレビュー文化の硬直を招く可能性があります。

コメントの分類とmustの立ち位置

多くの開発チームでは、レビューコメントを重要度で分類しています：

技術的背景｜なぜ「must」は重く受け取られるのか

「must」という語は、命令形に近い響きを持ちます。そのため、レビューアーが安易に使うと次のような摩擦を生む原因になります：

• 開発者が反論しにくくなる（心理的ブロック）
• 技術的に議論の余地がある内容でも、命令と誤解される
• チーム全体のレビュー文化が「上意下達」型に偏る

使用例と運用判断

不適切なmustの例

must: この関数、名前が長すぎるので短くしてください。

このような表現は、改善提案にすぎないにもかかわらず、強制力のある命令として誤解されかねません。

適切なmustの例

must: この変数はユーザー入力をそのまま使っており、XSSリスクがあります。エスケープ処理を追加してください。

セキュリティ・仕様逸脱・動作バグなど、「修正しないと運用に支障が出る」レベルの指摘に限定すべきです。

会話例：レビューコメントの温度調整

Reviewer: ここmustでお願い。未処理例外が起きそうです。
Author: 確認しました、確かにその可能性ありました。修正します。
Reviewer: ここ命名変えてほしい。mustで。
Author: 命名ルールと矛盾してますか？
Reviewer: いや、読みづらくて…。shouldに変えますね。

must/should/nit コメントの流れ

よくある誤解とその解消

チーム運用での対策

• mustは「仕様違反」「セキュリティリスク」「即バグ」のみに限定
• 「must多用レビューアー」はリーダーが適宜フィードバック
• GitHubテンプレートやレビューポリシーに明文化しておく

持ち帰るべき実務視点