ちょっとした気配りで皆を幸せにする GitHub の使い方

TL;DR

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

初めに

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

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

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

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

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

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

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

これは、

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

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

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

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

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

開発体験を良くする方法: PR レビュー編

全員

GitHub の通知を設定する

reviewer として設定しあなたのレビューを待っているにも関わらず、何も反応がなく時間が経つと reviewee はそわそわしてしまいます。
反対に PR レビューをしてもらったのにも関わらず、中々修正されない場面もあります。

通知は GitHub に備え付けられている Inbox でも良し、Slack や Discord に通知をするよう設定するも良し、他のツールを使うも良しです。
タスクを見逃さない、忘れない手法をしっかりと身につけましょう。

Inbox は右上の自身のアイコンの所に設定されています。

Slack と GitHub を連携すると、GitHub で自身に関係する何かしらのアクションがあった場合に DM に通知が届きます。

Discord では Webhook を用いてチャンネルに通知することができます。

（参考記事）

reviewee （レビューをお願いする側）ができること

迷った実装コードはアピールする

ゆめみでは職務標準に15分ガイドラインというものがあり、何かに詰まっている状態が15分以上続く場合、他の誰かに質問したり壁打ちしてもらうというものがあります。

私はこのルールに従って15分以上詰まった & 結果として誰にも相談しなかったものに関しては、GitHub の PR 上で何かしらのアピールをすることが多いです。
また、設計に関して疑問を持った場合や複数の実装がありどちらでも良さそうな温度感がある場合などを書くこともあります。

基本的には実装で詰まった部分や分からない箇所があれば PR で詰まった内容や自分が分からない箇所、参考にしたものなどをコメントしたり PR の説明文に記載すると良いと思います。
何も分からんってなったら、最悪「ここら辺分からないです！」って言ってくれれば、相談しないよりは全然良いと思います。

どの程度コードを確認してもらいたいかをしっかりアピールする

リファクタであればバグを生んでしまう可能性があるからロジックに問題がないかなどしっかり見てもらいたいし、ドキュメントの変更のみであればぱっと見てもらう温度感など、PR レビューにかかる工数や温度感は異なります。

Files Changed を見れば分かるやん！となるとは思いますが、reviewer は Files Changed を確認するよりも前にレビューをする腰が上がらないので、細かい事ですがアピールしましょう。
PR の説明に PR レビューの温度感を書けば OK だと思います。細かい箇所だと温度感が伝わるタイトルを書けばより良いねって感じです。

以下のように PR のテンプレート項目にあると良いかもしれないです。

コミット履歴は綺麗にしよう

PR は実現したい大きなこと、コミットは実現をするために必要な過程をログ形式でアピールできると良いと思います。
コミットに対して prefix を付け、今回のコミットで実現したかった内容をしっかり書きましょう。

またコミットはコードをセーブする機能ではありません。
コードを追加・変更・削除する理由は絶対にあるので、コミット内容が fix ないしは wip になる事は絶対にやめてください。
wip として保存したいなら stash を使用することをおすすめします。

（参考記事）

悩みが解決せず Approved されたら、理由を添えて Dismiss Review する

PR を作成する過程で出た疑問や悩みはなるべくその PR で解決するようにしましょう。
そこで設計の議論をしていたり自分が悩みを提示しているのにも関わらず、そこに何のコメントもなく Approved される事はコミュニケーションが成立していません。
嫌味のような形になってはしまいますが、この機会を逃したらその悩みを解決する場は中々ない（というか議論したい事を忘れる）ので、PR が存在している内に悩みを解消しましょう。

Dismiss Review （レビューの取り消し）を行う際は、なぜレビューを取り消したかの理由はしっかり伝えましょう。

（参考記事）

reviewer （レビューをする側）ができること

reviewee が提示したコメントに対しては何かしらのアクションを行う

悩みが解決せず approved されたら理由を添えて dismiss-review する で述べた内容と関係しています。
コメントがある場所は reviewee が不安に思っている箇所なので、そこに対してはしっかりと寄り添って一緒に解決しましょう。
確認のコメントの場合でも などでリアクションを行うだけでも良いと思います。

最後は LGTM

思想の違いで沢山揉める事もあるかもしれないですが、これはコード品質をより良くしていくには起こりうる出来事だと思います。
そうしてできた PR と実装者に対してはちゃんと LGTM をしましょう

最後に

GitHub は「技術者同士がコミュニケーション」を取る1つの場である事を忘れないようにして頂きたいと思います。
GitHub のだけに留まらず、お互いを思いやれるような環境作りを自ら提言し行い、皆さんが思っている開発者体験に近づいていけばと思います。

開発体験をより良くして皆で幸せになろう！

その他に参考になる記事

【追記】この記事が果たしてほしい役割について

※ 筆者の個人的な意見ですので、「そんな考え方もあるのね」くらいの感じでこのセクションを見て頂けると助かります

沢山のいいねありがとうございます！
私が一番訴えたい事： PR がレビューされない環境を作らない について、色々な SNS で意見や感想がありました。
中には同感して頂ける声もあり大変有難いです。

この記事に同感して頂いた方や新しい発見があった方は、今の開発ワークフローを振り返ってみて、必要に応じてチームメイトに提案してみるのも良いと思います。
もしかしたら同じ悩みを持っているチームメイトもいるかもしれません。そこで気が合えば一緒に改善案を考えてみてください。

改善案を考える際に問題の原因を「この人がやらないから悪い」という結論に至る場合もあります。
この記事で出てくる意見だと、「PR レビューが遅いのは reviewer としてリクエストを行ったのに反応がない人が悪い」だと思います。

論理的に考えればその意見は正解かもしれません。ただ論理が通っているからといって、人の行動や気持ちを変えるのは難しい事です。
何でも怒って解決するのはその時の効果にしか過ぎない場合が多く、またチームメイトという関係性を構築するにあたって積極的に取りたい行動ではありません。

開発体験を良くする方法: PR レビュー編 で示した内のいくつかは、開発環境を変える内容を提示しています。
このように、人を変えるのではなく環境を変えてみるのも一つの手という認識の上で、チームメイトと話し合い改善策を見いだせればとても素敵だと思います。

この記事に記載している事以外にも解決策を考えて実践してみたら、LT で発表したり Qiita に記事を書いてみてください。
この記事がそのトリガーとなれたのであれば、大変嬉しく思います。