GitHubのプルリクエストはレビュアーの視点を想像して伝え方を工夫する

この記事は Gaji-Labo Advent Calendar 2019 23日目です。
HTML＋CSSコンポーネント・Javascript・Rails viewまわり等フロントエンドのチーム開発に不慣れな人へ向けて、GitHubのプルリクエストを題材にレビュアーの視点を想像すると伝え方の工夫ができたことを紹介します。

レビュアーの視点を想像して伝え方を工夫する

チームの中で進捗を誰かに共有することは、相手の時間を使うということ。
GitHubのプルリクエストを開発の進捗共有という側面でとらえたとき、共有される側であるレビュアーの立場になると、開発側のちょっとした工夫でレビューの負荷が大きく変わることが分かります。
レビュアーとしてこのことを実感し、自分が開発側でもレビュアーの視点を想像することで

• なにを目的とした共有か
• 共有した報告・課題に対し、相手に何を期待するのか

を明確にして、レビュアーにできるだけ負担をかけず内容を把握してもらえるような伝え方を探るきっかけとなりました。

以下はGitHubのプルリクエストで自分が心がけていることの一部です。

依存関係やマージ順序の指定を伝える

レビュアーとして人のプルリクを Approve したら、ほかのページが表示できなくなったり崩れたりしていたことがあります。

タスク間やページ間の依存関係、開発の影響範囲は必ず把握しておき、自分のプルリクエストがマージされてもほかの開発や範囲外へ影響しないことを大前提に作成し、プルリクエスト同士で依存関係やマージ順序の指定があるときは、その旨を明記するようにしています。

レビュアーが把握しやすい量と内容を意識する

レビュアーとして人のプルリクを見たとき、変更ファイル数や変更箇所があまりに多いと気が重くなります。

レビュアーが把握しやすい変更箇所の量と内容を意識して、できるだけプルリクエストの粒度を小さくしています。レビュアーはチェッカーではないので、必ずしもタスクの詳細や変更した箇所すべてを細かく確認したうえで、意図を把握してくれるとは限らないからです。

タスクはひとつでも開発範囲が広いときはプルリクエストを複数に分割することもありますし、単一の変更であればファイル数が多くてもいっぺんに確認できた方がレビューしやすいかと考えたり、レビュアーの視点を想像した粒度の分解は自分のタスクの整理につながっています。

プロジェクトごとのお作法に倣ったコミュニケーション

すでに稼働中のプロジェクトにジョインするときは、そのプロジェクトのお作法やルールに従います。これに外れた行動をとると、チーム内コミュニケーションのクオリティやパフォーマンスが乱れるので、はじめに必ず確認しています。

定型フォーマットやルールがある場合はその通りに、明示的にない場合でもチームメンバーのプルリクエストを観察して、ブランチのきり方やコミットログの書き方から、どんな情報をどんな粒度でどこに記載しているのか、表記方法など含めて倣います。
初めてプルリクエストをたてるときは、 この作り方で問題あればご指摘ください 等のアナウンスを入れることもあります。

フィードバックが必要な場合は相手に求める回答の質まで伝える

プロジェクトのお作法に従い、そのプルリクエストで優先的にレビューしてもらいたい箇所や補足が必要な箇所にコメントを入れています。場合によってはキャプチャを添付したりマークダウン記法を駆使して、必須の情報をできるだけ簡潔に、そのコメントだけ読めばレビュアーが Approve の可否を判断できるように心がけています。

相手にフィードバックを求める場合は、現状・クリアにしたい点・課題を明記し、いつまでにどんな粒度で回答がほしいかコメントするようにしています。課題によってはプルリクエストから派生してissueやSlackでコミュニケーションが必要となることもあります。

まとめ

レビュアーの視点を想像した伝え方の工夫をすることで、自分自身の作業効率や品質もあがり、コミュニケーションがスムーズとなってチーム開発への貢献につながります。
今後もレビュアー視点の想像力と工夫を高めていきたいです。

関連リンク

• こまめな進捗の共有から始めるチーム開発
• チーム開発では自分の現状を実況せよ