Qiita

TL;DR

読むのが面倒な人は PR がレビューされない環境を作らない を読んでください。
その他のものは、周りの開発者体験をより良くするための手法について提示しています。

はじめに

この記事は GitHub での開発者体験をより良いものとするため、チームメイトにこの記事を見せて GitHub 上での開発手法を合わせたいという意図があります。
より良い開発体験を見つけたり躓いた部分があった場合は適宜更新されます。

また記事を見ている方の意見も募集しております
皆でより良い開発者体験を得られる環境を考えられたらと思います。

私が一番訴えたい事： PR がレビューされない環境を作らない

Git を使った開発をした事なら誰にでもある、PR が全然レビューされない問題 は開発者体験を下げる大きな要因です。
そこが タスクを止めている明確とした要因 にも関わらず、誰もレビューしない環境がいつの間にか出来上がります。

レビューが中々されないとして考えられるのは、開発者はみんな目の前にある自分のタスクを早く消化したいからです。
他人のタスクで自分のタスクが長引くのは嫌でしょう。気持ちは分かります。
しかし、コミュニケーションでこの旨を伝えず、暗黙の了解として PR レビュー依頼が来ているにも関わらず後回しにするのはおかしいと思います。
渡されたバトンに対してはしっかりとリアクションを取るべきです。
（レビューが遅くなるのであれば、遅れる旨を伝えるだけでも大分違うと思います）

この問題を解消するために、各プロダクトで意識して取り組んでいるところもあるでしょう。
これから示す項目を実施するのも1つの解決策になります。

例として、コンテキストが高いもの（要件が複雑なもの）は、ペアプロ・モブプロをするという手もあります。

これは、

• reviewer が複雑な要件を理解するのに時間がかかる
• チャットベースだと要件の理解にすれ違いが起こりやすい
• チャットベースだとやり取りが何回も行われるため時間がかかる
• レビューの敷居が高くモチベーションの低下が起こる

といった、様々な問題を解決する手法のひとつでもあります。

話を戻すと、レビューが中々されない事による開発体験の低下は経験したことがある人が多いものの、ほとんどのプロダクトではこれらの議論は行われず、ストレスを感じる場面が発生する のではないかと思います。

そしてタスクが回らなくなり、その理由を探します。
「タスクがスムーズに進まない理由が目の前にあるのに」

これらから、私はレビュをする側・される側の意識を共有する場があっても良いと考えています。
この記事がきっかけで、チームメイトと改めて議論し、認識を共有し、環境を用意してより良い開発体験を得られたら幸いです。