# プルリクエスト作成

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

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

プルリクエストを作成する際は、下記の観点を含めて作成します。  
[プルリクエストサンプル](/3.実装/プルリクエストサンプル)と併せて確認しましょう。  

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

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

**例**

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

### 変更内容

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

### 変更理由

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

### 期待値

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

### エビデンス

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

### コーディング確認

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

### 動作確認

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

## レビュー依頼について

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

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

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