プルリクエスト作成

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

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

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

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

例

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

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

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

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

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

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

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

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

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