この記事ではハコベルの開発チームが心理的安全性の向上を目的に採用した、プルリクエスト (マージリクエスト) コメントにラベルを付ける手法についてご紹介します。
※ この記事に記載の内容は当時の情報です。最新の状況を反映していない可能性があるため、ご了承ください。
背景
プルリクエストをレビューする時、レビュアーとして上から目線になってしまい相手を傷つけないか緊張したり、ちょっとした確認のつもりで書いたコメントが修正必須と捉えられてしまったりした経験はないでしょうか。
本来、ピアレビューは対等な関係であるはずなのに、レビューする側の方が上になってしまいお互いに恐縮してしまいがちです。「勘だと怪しいけど間違っていたら怖いから言えないな」や、「将来的に辛くなりそうな実装だけどわざわざ指摘するほどでもないな」など荒波を立てずにApproveしてしまい、積極的なレビューが交わされなくなります。
このちょっとしたチリが積もっていくことで、リリース後や数年後にプロダクトの品質が大きく低下する原因となります。
ラベルを付けるルールを決める
そこで、私たちのスクラムチームではWorking Agreement (チームのルール) として、レビュー時のコメントには基本的にラベルを付けることを定めました。次のようなラベルを使用することにしました。
| ラベル | 意味 | 意図 |
|---|---|---|
| Q | 質問 (Question) | 質問。相手は回答が必要 |
| FYI | 参考まで (For your information) | 参考までに共有。アクションは不要 (確認事項を残す場合などに使用) |
| NITS | あら捜し (Nitpick) | 重箱の隅をつつく提案。無視しても良い |
| NR | お手すきで (No rush) | 今やらなくて良いが、将来的には解決したい提案。タスク化や修正を検討 |
| IMO | 提案 (In my opinion) | 個人的な見解や、軽微な提案。タスク化や修正を検討 |
| MUST | 必須 (Must) | これを直さないと承認できない。修正を検討 |
ラベルを付けることにより、このような利点があります。
- すべてのコメントに対して修正が必須でないので、対等な関係性となる
- するべきアクションが明確に伝わるため、認識の齟齬が起こらない
- コメントに重み付けがされるので、優先順位が明確になる
- 後でやるべきタスクを、タスク化し忘れない
- コメントの敷居が下がることより、議論の活性化
結果として、以前に比べプルリクエスト上で行われるコードレビューのコメントが増加し、積極的に議論が交わされるようになりました。チームの心理的安全性と開発効率を向上できました。
使用例
レビュアー
- q: ここって、こうで良いんでしたっけ？追えきれておらず...
- FYI: POに口頭でサクっと確認しましたが、このままでOKとのことでした。
- NITS: ここの条件難しいですよね。こう書くとよりシンプルになりそうだと思いました！
- NR: ここのテスト漏れていますね。一旦タスク化しておきますか。 (タスクのリンク)
- IMO: レアケースですが、このパターンをエラーにするとより強固になりそうです。
- MUST: 引数が反対になっているので修正お願いします。
レビュイー
レビュイーも、事前にコードに対してコメントを入れておくとレビュアーがよりレビューしやすくなります。次のように使用できます。
- q: ここの実装不安なんですが、あっていますかね...?
- FYI: デザインと違いますが、POの確認済みです (Slackのリンク)
- NITS: 以前のコードなのですが、わかりにくかったのでついでに直しました
- NR: このレアケースに対応できないので、タスク化して別途実装します。
GitHub の Saved replies を活用する
GitHubでは、コメントのテンプレートを設定して、キーボードショートカットやツールバーから呼び出すことができるSaved repliesという機能が存在します。
運用し始めたばかりのタイミングではコメントのラベルの意味を忘れてしまうことも多いので、各自でSaved repliesを設定するのがおすすめです。
今後の展望
今回の記事を執筆するにあたり、同様の取り組みを調べたところConventional Commentsという規約があることを知りました。
私たちは特にこの中でDecorationsに注目しています。
Blocking / Non-Blockingを明確にすることで、質問と作業への影響を分離して意図を伝えることができるのではないかと考えています。
チームメンバーとディスカッションしていきながら、今後も開発効率を向上するための改善を続けていきます。
まとめ
ハコベルで行っているチームの心理的安全性と開発効率の取り組みの1つとして、コードレビューにラベルを付ける手法をご紹介しました。
ルール決めさえすれば、ツールも不要で簡単に導入でき、効果が高いのでぜひお試しください。
「物流の次を発明する」をミッションに物流のシェアリングプラットフォームを運営する、ハコベル株式会社 開発チームのテックブログです！ 【エンジニア積極採用中】t.hacobell.com/blog/career
Discussion
心理的安全性を高める他の取り組みも個人記事で紹介しているのでぜひご覧ください。
チームで開発している OSS repo で採用しようかと思います．参考になりました．ありがとうございます．
OSSだとコンテキストが伝わりにくいので相性良さそうですね！
コメントありがとうございます！！