こんにちは。 STORES ブランドアプリのチームで iOS エンジニアをしている榎本( @enomotok_ )です。これは STORES Advent Calendar 2023 の記事です。私が普段仕事をしていて感じるPull Request (以下 PR )を迅速にマージすることの効用について、日々の取り組みと考えを言語化してまとめます。

なぜ Pull Request を早くマージしたいか

私たちは日々多くの仕事に忙殺されています。 PR を完成させたら、基本的には次のタスクに取り掛かります。 PR の生存期間が長いと、次のタスクとのマルチタスクが増え、それが長引くことになります。マルチタスクにおけるコンテキストスイッチが生産性に悪影響を及ぼすというのはよく言われる話です。

また PR が大きなタスクの一部であった場合に、 PR をマージできないことが次の仕事をブロックする可能性があります。 PR がボトルネックであった場合、プロジェクト全体の進行、ひいてはエンドユーザーに価値を届けるためのボトルネックになるということです。

このように、 PR をいかに迅速にマージできるかがチームの生産性に大きな影響を及ぼすことは議論の余地がないと言えるでしょう。

Pull Request を早くマージするために何ができるか

それでは PR を迅速にマージするために私たちにできることとは何でしょうか。

チームとして

私が在籍しているチームではスクラムを採用しています。スクラムではスプリントの初日に計画（スプリントプランニング）を行ないますが、計画の中であらかじめ設計と実装方針についてチーム全員で議論を行ない、合意をとるようにしています。こうすることで実装段階での大きな手戻りが起こりづらくなります。

また私が過去に在籍していたチームでは、 PR のレビューが滞りがちになることがありました。仕様自体の複雑さや、チームメンバー各員の忙しさ、単純に PR が出ていることをの見落としといった理由からです。この時はいくつかの取り組みをすることで、ある程度解消することができました。

Slackチャンネルに毎日コードレビュー依頼スレッドを自動生成する

毎日、朝会のタイミングでSlackのチャンネルにコードレビューを依頼するためのスレッドを自動生成する取り組みです。このスレッドにチームメンバーがレビューしてもらいたい PR の URL を貼ることで、緊急度の高い PR を見落とすことがないように意識合わせをしていました。

モブレビュー

仕様自体が難しかったり、周辺のコードに関する土地勘がない PR は、レビュアーとしてレビューをしたい気持ちがあってもなかなか手をつけづらいものです。そういった時にはモブレビューを行なっていました。

モブレビューは、複数の開発者が集まり、一緒にコードレビューをする手法です。まとまった時間をあらかじめ確保した上で、画面共有を行いながら、実装者がコードの内容をチームメンバーに説明し、レビュアーが質問とコメントをします。全体としては多くの工数がかかるやり方ではありますが、結果的に短い時間でコードをマージできる感覚がありました。

また自分がいままで在籍したチームでは恒常的にモブプログラミングをやっていたことはありませんが、モブプログラミングを取り入れられるチームであれば、コードレビュー自体が場合によっては不要になるので検討することもできそうです。

レビューが必要な PR に関しては遠慮なく Slack でメンションしあったり、 Meet や Zoom で気軽に相談できる関係性をチームとして築くことも大事なことでしょう。チームの Working Agreement としてコードレビューについての約束事を決めておくのも良さそうです。

実装者、レビュイーとしてできること

PR を作成し、コードレビューしてもらう立場としてできることは何でしょうか。

Draft Pull Request の活用

実装方針に不安がある PR については、 GitHub の Draft 機能を活用して、下書き状態の PR を見てもらえるといいでしょう。チームとして大まかな方針が決まっていたとしても、実際にコードを書き始めると迷うことはどうしても起こります。 Draft の段階でチームメンバーと実装方法に合意が取れると、予期せぬ手戻りが防げます。余談ですが、ソフトウェアエンジニアリングにおいては「最後の10％の実装に全体の90％の時間がかかる」という逸話がある¹ くらいなので、 Draft PR を用いるのは良いアイディアではないかと思います。

Pull Request の description への記述、テンプレートの利用

コードレビューをすみやかに実施してもらうために PR の Description についても気を配っています。 Description に背景情報やスクリーンショット、実施した動作確認方法を載せることで、コードレビューの前提となる知識をレビュアーに伝えます。多くの開発チームと同様に、私がいるチームでは GitHub の Pull Request Template を活用しています。この記事では今のチームで実際に使っている Template を紹介します。

# Issue

closes: 

# 概要

# やったこと

# やっていないこと

# 動作確認手順

# スクリーンショット

| before | after |
|--------|-------|
| <img width="300" src="">  | <img width="300" src=""> |

# ToDo

- [ ] [CHANGELOG](https://example.com) に記入する
- [ ] デザイン変更がある場合は　design ラベルを付与してデザインチームにレビュー依頼する

シンプルな内容ですが、各項目は PR の変更の大きさに応じて、詳細に記載します。

Issue にはこの PR が解決する Issue のリンクを貼ります。関係するやりとりが他にあれば Slack の URL を貼ったり、モバイルアプリの UI に関係する変更の場合はデザイン Figma のリンクを貼ったりもしています。

動作確認手順は、煩雑な手順が必要な場合、特に詳しく記載しておきます。別の開発で同じような動作確認手順が必要になった場合でも、過去の PR を見返すことで容易に動作確認ができます。動作確認手順を詳しく記載することは PR を迅速にマージすることに必ずしも寄与するわけではありませんが、生産性に効いてくる取り組みであると考え、実践しています。

スクリーンショットには、必要に応じて UI の差分が一目瞭然でわかるようにマーカー（Skitch や Mac のプレビューアプリ）で印をつけています。ちょっとした UI 変更の PR の場合に、この一手間でレビュアーが PR を把握するまでの負荷が下がります。

レビュアーとしてできること

レビュアーとしてできることもいくつか考えられます。

レビューの優先度を上げる

私の場合は始業して一日のタスクを確認したら、朝会までの1時間ほどの時間をコードレビューに充てています。午前中の集中力が一番高い時間をコーディングに使いたい気持ちはあるものの、自分がコードを書くよりもコードレビューの方が相対的に顧客へのデリバリーやチームの進捗のために重要であるため、優先的に進めるようにしています。

PR 上でのコミュニケーションを明瞭に

レビューコメントに MUST, IMO, Q, nits といったプレフィックスをつけることで、コメントの意図と自身の温度感を伝えます。また変更が必要な Pull Requst に Request Changes のコメントをつけることでも意図を率直に伝えることができます。コメントをする際も、なるべく曖昧性のないコメントをするように心がけています。変更の提案がある場合は具体的な改善案や実装例を提示します。実装方針に大まかな合意が取れていれば、工夫次第でコードレビューのコメントの往復回数は減らすことができるはずです。

また率直なコミュニケーションはコードのデリバリーを早めますが、前提としてレビューのコメントはあくまでもコードに対するコメントであり人格攻撃ではないという共通認識をチームとして持つことや、率直なコミュニケーションができる信頼関係を構築することが大事だと言えそうです。