プルリクエスト作成

プルリクエストの質を高めることで、将来発生しうるバグの回避やバグの早期発見・改修につなげることができます。
当社ではプルリクエストの質を高め、標準化するため、プルリクエストに記載する観点を明確にし、標準的な確認項目リストを定めています。

プルリクエスト作成の際の行動指針

プルリクエストを作成する際は、下記の観点を含めて作成します。
プルリクエストサンプルと併せて確認しましょう。

  • タイトル
  • 変更内容
  • 変更理由
  • 期待値
  • エビデンス
  • コーディング確認
  • 動作確認

タイトル

プルリクエストのタイトルには、対応するBacklogチケットのタイトルをコピー&ペーストします。
フロントエンド(=FE)なのかバックエンド(=BE)なのか、画面実装なのかAPI結合なのかなど、スコープが明確に伝わるタイトルにしましょう。

- FE/デザイン/ログイン画面
- FE/ロジック/ログインAPI結合
- BE/API/ログイン

変更内容

修正した不具合や追加した新機能など、変更内容を説明します。
レビュー不要なソース(自動フォーマットによる差分など)がある場合はその旨も記載しましょう。
レビュー不要箇所の記載方法として、該当するソースの箇所へコメントでもOKです。

変更理由

変更が必要になった経緯について記載します。
その際、変更によってどのようなメリットがあるのかがレビュアーに伝わる説明にしましょう。

期待値

変更後のあるべき状態について記載します。
仕様がわかるデザインファイル(figmaなど)への参照リンクも併せて添付し、期待値が一義的に伝わるように工夫しましょう。

エビデンス

変更内容が適切であることがわかるエビデンスとして、UI/ログの動画/キャプチャなどを添付しましょう。

コーディング確認

観点リスト(プルリクエストサンプル参考)にもとづいて確認し、チェックボックスにチェックします。
未チェックがある場合、レビュアーはレビュー結果NGで返信することになります。
もしチェック不要な項目がある場合は「その他」で理由とともに補足しましょう。

動作確認

観点リスト(プルリクエストサンプル参考)にもとづいて確認し、チェックボックスにチェックします。
未チェックがある場合、レビュアーはレビュー結果NGで返信することになります。
もしチェック不要な項目がある場合は「その他」で理由とともに補足しましょう。

レビュー依頼について

一般的にレビューはエンジニアが行いますが、当社では品質確保の観点から、UI変更がある場合はデザイナーもレビューに参加します。
レビュー時点で仕様の実装不備を検出することにより、後工程でバグ検出するよりも工数の抑制が期待できます。

具体的なレビュー依頼時の作業は以下の通りです。

  • GitHub
    • Reviewers: デザイナー1名以上、エンジニア1名以上を設定
    • Assignees: 実装者自身を設定
  • Mattermost(チャット)
    • レビュアーに対してGitHubリンク付きでレビュー依頼をコメント