コードレビューにラベルを付けるルールで心理的安全性を向上

2022/12/17

はじめに

【全部俺】 Webフロントエンドエンジニアのメモ Advent Calendar 2022 17 日目の記事です。

プルリクエスト(マージリクエスト) コメントにラベルを付けるルールだけで、心理的安全性が向上し、生産性を改善させることができます。

レビューする側もされる側もドキドキ

プルリクエストを作成する時、レビュワーから何言われるかドキドキした経験はないでしょうか。一方、プルリクエストをレビューする時、レビュアーとして上から目線になってしまい相手を傷つけないかドキドキした経験はないでしょうか。

本来、ピアレビューは対等な関係であるはずなのに、レビューする側の方が上になってしまいお互いに恐縮してしまいがちです。「勘だと怪しいと思うけど間違っていたら怖いから言えないな」や、「将来的に辛くなりそうな実装だけどわざわざ指摘するほどでもないな」など自分を守る行動に走り、積極的なレビューが交わされなくなります。

このちょっとしたチリが積もっていくことで、リリース後や数年後にプロダクトの品質が大きく低下する原因となります。

しかし、シャイな我々が対等な関係でレビューを依頼し、レビューをされるためにはどうすれば良いのでしょうか。

ラベルを付けるルールを決めよう

私のチームでは Working Agreement (チームのルール) として、レビュー時のコメントには基本的にラベルを付けることを定めました。

具体的には下記のようなラベルを設定しています。

そのまま使用しても良いですし、チームの特性に合わせてカスタマイズしていくのもおすすめです。 (絵文字を使うチームはラベルを絵文字にする等)

ラベル	意味	意図
Q	質問 (Question)	質問。相手は回答が必要
FYI	参考まで (For your information)	参考までに共有。アクションは不要 (確認事項を残す場合などに使用)
NITS	あら捜し (Nitpick)	重箱の隅をつつく提案。無視しても良い
NR	お手すきで (Not rush)	今やらなくて良いが、将来的には解決したい提案。タスク化や修正を検討
IMO	提案 (In my opinion)	個人的な見解や、軽微な提案。タスク化や修正を検討
MUST	必須	これを直さないと承認できない。修正を検討

ラベルを付けることにより、このような利点があります。

すべてのコメントに対して修正が必須でないので、対等な関係性となる
するべきアクションが明確に伝わるため、認識の齟齬が起こらない
コメントに重み付けがされるので、優先順位が明確になる
後でやるべきタスクを、タスク化し忘れない
コメントの敷居が下がることより、議論の活性化

結果として、心理的安全性と開発効率が向上し、プロダクトの品質向上に寄与することができます。

使用例

レビュアー

q: ここって、こうで良いんでしたっけ？追えきれておらず...
FYI: PO に口頭でサクっと確認しましたが、このままで OK とのことでした。
NITS: ここの条件難しいですよね。こう書くとよりシンプルになりそうだと思いました！
NR: ここのテスト漏れていますね。。一旦タスク化しておきますか！ (ClickUp のリンク)
IMO: レアケースですが、このパターンをエラーにするとより強固になりそうです。
MUST: 引数が反対になっているので修正お願いします。

レビュイー

えっ、レビュイーがコメント？と思ったかもしれませんが、意外と重要です。下記のように使用できます。

q: ここの実装不安なんですが、あっていますかね...?
FYI: デザインと違いますが、PO の確認済みです (Slack のリンク)
NITS: 以前のコードなのですが、わかりにくかったのでついでに直しました

まとめ

コードレビューにラベルを付けるだけで、心理的安全性と開発効率が向上し、プロダクトの品質向上に寄与することができました。

ルール決めさえすれば、ツールも不要で簡単に導入でき、効果てきめんなので、ぜひお試しください。