コードレビューにラベルを付けるだけでチームの心理的安全性を高めた話
ハコベルシステム開発部の大石貴則です。普段はフロントエンドエンジニアとして物流 DX SaaS プロダクトの開発を行なっています。
この記事ではハコベルの開発チームが心理的安全性の向上を目的に採用した、プルリクエスト (マージリクエスト) コメントにラベルを付ける手法についてご紹介します。
背景
プルリクエストをレビューする時、レビュアーとして上から目線になってしまい相手を傷つけないか緊張したり、ちょっとした確認のつもりで書いたコメントが修正必須と捉えられてしまったりした経験はないでしょうか。
本来、ピアレビューは対等な関係であるはずなのに、レビューする側の方が上になってしまいお互いに恐縮してしまいがちです。「勘だと怪しいけど間違っていたら怖いから言えないな」や、「将来的に辛くなりそうな実装だけどわざわざ指摘するほどでもないな」など荒波を立てずに 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 つとして、コードレビューにラベルを付ける手法をご紹介しました。
ルール決めさえすれば、ツールも不要で簡単に導入でき、効果が高いのでぜひお試しください。
最後に
私たちは「物流の次を発明する」をミッションに掲げ、荷主と運送会社をつなぐマッチングプラットフォーム事業と、荷主向けのオペレーション DX を支援する SaaS 事業を運営しています。
2022 年 8 月に、ラクスルの事業部からハコベル株式会社として分社化し、第二創業期を迎えました。
そのため、さらなる事業拡大を目指し、エンジニアを始めとした全方向で一緒に働くメンバーを募集しています。面白いフェーズなので、興味がある方はお気軽にご応募ください！
いきなりの応募はちょっと...という方は大石個人へ DM やメールして頂ければざっくばらんにお話することも可能です！
ぜひお気軽にご連絡ください。
Discussion
心理的安全性を高める他の取り組みも個人記事で紹介しているのでぜひご覧ください。