今日は、プロダクトチームで使っているGitHubのPull-Request(以下PR)テンプレートについて紹介したいと思います。
プロダクトチームでは、「ミスは個人の問題ではなくチームの問題」と取られ、 ミスした個人を責めるのではなく、「同じミスが起こらないようにするにはどうすればいいか？ 」と考える文化が根付いています。
そのため、「気をつける」「教育する」「ミスしないように周知する」といった精神論ではなく、 そもそもミスしない仕組みを作り、ブラッシュアップすることを日常的に行っています。
プロダクトチームでは、2週間のスプリントの終わりにスプリントの振り返りを行う会を開いています。 スプリントの振り返り会では、KPT（Keep Problem Try）を議論する時間があり、 Tryの一環としてGitHubのPRテンプレートの更新を行ってきました。
今回は、我々が運用しているPRテンプレートについて公開し、 どんな風に使っているか紹介します。
PRテンプレートの解説
📝確認すべき項目
レビュアとPMがわかるように「どのURLの」「どのパーツが」「どうあるべきか」 を書く 例: `/mypage/applications` の絞り込みパネルでステータスで絞り込みができること） 必要に応じてスクショも貼っておく。
この項目は、PRのレビューするひとがPRを動作ベースで確認するときに必要な情報を書きます。 この情報を埋めることで余計な情報交換を減らし、スムーズにレビューできるように心がけています。
🛠️リリース時作業
あれば - PRタイトルに `[作業有]` をつける - 手順をここに書く。2行以上あるならesaに書いてリンクを貼る
この項目は、リリース時に手動での作業が必要な場合について記載します。
リリースはCIにより半自動化していますが、DBの値を書き換えたり、環境変数を変更するなどの作業がリリース前後に必要な場合があります。 そういった場合は、ここに詳細を記載し、PRのタイトルにも[作業有]という文字列を追加します。
PRを作った人とリリースする人が別になることもよくあるので、 「誰でもリリースできる」「抜け漏れを起こさない」ためにこの項目を作りました。
😎ユーザーに伝えること
機能の使い方が変わった場合や新機能など、新しい使い方の説明を書きましょう。
これはプロダクトオーナーからの要望で追加しました。
弊社のプロダクトは、カスタマーサクセスチームや営業チームも仕様を理解している必要があります。 うっかり伝え漏れがあると、「いつの間にか使い方が変わってる」「お客さんに間違ったことを教えてしまった」といった問題が起こってしまいますので、 漏れのないようこちらに記載するようにしています。
✅PR前のチェック項目
- [ ] PRのタイトルの先頭に必要に応じて`[プロジェクト名]`または`[影響無し]`を付けた
PRのタイトルを工夫することで、PRの詳細を開かなくても必要な情報がわかるようにしています。
[影響無し]がついたPRは、リリース時にユーザー影響がないPRを意味しています。 通常はリリース前にプロダクトマネージャを含めた動作チェックを行っていますが、[影響無し]なPRは簡易的な確認だけでスピーディにリリースできます。
- [ ] PRのタイトルに「どのツールの」「なんの機能が」「どうなるか」が分かるように書いた
こちらもPRのタイトルについてのリマインドです。
プログラミングもそうですが、名前はとても重要です。 適切な名前であれば、わざわざPRの詳細を確認する必要がなく、プロダクトマネージャやリリース担当の負担を軽減できます。
- [ ] PMへの事前仕様確認 or 仕様はもう明確になっている
プロダクトマネージャと仕様のすり合わせが終わってるかの確認を促しています。
プロダクトマネージャと仕様の認識がずれていていると、リリース前の開発環境での動作確認のタイミングで仕様変更が発生し、 リリースが伸びたり、HotFixで追加のリリースが必要だったりと、手間が増えてしまいます。 そういった問題を軽減するためにPR作成の段階で、その仕様で大丈夫か？と確認するようにしています。
- [ ] テストを書いた or すでにある or 不要なほど軽微な修正
テストちゃんと書いてねという確認です。
- [ ] 動作検証した
動作確認は大事です。
開発中はもちろん全員動作確認はしているはずですが、 PRを投げる直前にゴミが混入してしまったり、リファクタでぶっ壊れたりしてる可能性もあります。
レビュワーに「動かない」と報告されるケースが何度かあったので、テンプレートに追加しました。
- [ ] ユーザ影響度: 高ならラベルをつける or 無し - `高`の定義: 注意深いレビューが必要（コードの仕様理解と動作確認）。サイト外に影響して取り返しのつかないもの（メール送信など）や、ユーザ行動に影響する部分（登録フォームや打診フォームなど）の改修。
ユーザー影響度についてラベルをつけようという確認です。
ユーザー影響度:高のPRはレビューと動作確認で入念なチェックを行うようにしています。
🌐インフラ影響がある場合（不要な場合は削除）
- [ ] PRのタイトルに`[インフラ]`を付けた - [ ] 作業者は影響範囲を可能な限り説明できる - [ ] 確認会・共有会（15~30min）をスケジュールに設定する
インフラ系の変更を行うPR向けの確認事項です。
インフラ系の変更は、予想外の影響が起こることが今までに多々ありました。 そこで、同じ問題を起こさないために、私達のチームでは出来るだけ「確認会」を実施しようと決めています。
(関連: workerインスタンスを追加したら障害が発生した話 https://tech.macloud.jp/entry/advent_calendar_2019_12_17 )
📊効果測定
機能の効果を測定できるRe:dashのURLを貼ってください。
Re:Dashはプロダクトの分析ツールです。 ここには、リリース後にプロダクトにどういった影響が出たかわかるようなRe:Dashのページを作成して追加します。
プロダクトチームでは6月から OODAループに基づく開発を行うことにしています。 そのため、プロダクトの新機能開発や機能改善を行うときは、その効果が現れたのかどうか効果を測定できるように、分析ページの作成も同時に行っています。
ℹ️issue
close: #
関連するIssue番号を入力できるようにしています。
close: #123と書けば、PRがマージされた時に#123も同時にCloseしてくれます。
以前、よくIssueの閉じ忘れがあったのですが、このテンプレートを追加してから閉じ忘れることは減ったように思います。
まとめ
今回は、うっかりミスを防ぐ方法として、PRのテンプレートについて紹介しました。 プロダクトチームでは、他にも「CircleCIを使ったリリースの自動化」や、「リリースのためのリリースタグ作成作業の自動化」、「リリース時の作業内容のテンプレート化」など、ミスを起こさない仕組みを随時取り入れていいます。
私達のPRテンプレートはかなり「ごった煮」な具合になっていますが、組織の数だけPRテンプレートはあってもいいと思います。 プロダクトの性質やチーム、文化に合わせて、自分達にぴったり合うPRテンプレートに熟成させていけたらと思います。
以上、参考になりましたら幸いです。
付録（PRテンプレートファイル）
Pull-Rquestテンプレートファイルはプロジェクトディレクトリに特定のパスで格納してあります。
.github/PULL_REQUEST_TEMPLATE.md
詳しくはこちらをご覧ください。
### 📝確認すべき項目 レビュアとPMがわかるように「どのURLの」「どのパーツが」「どうあるべきか」 を書く 例: `/mypage/applications` の絞り込みパネルでステータスで絞り込みができること） 必要に応じてスクショも貼っておく。 ### 🛠️リリース時作業 あれば - PRタイトルに `[作業有]` をつける - 手順をここに書く。2行以上あるならesaに書いてリンクを貼る ### 😎ユーザーに伝えること(CX等社内向けも含む) 機能の使い方が変わった場合や新機能など、新しい使い方の説明を書きましょう。 ### ✅PR前のチェック項目 - [ ] PRのタイトルの先頭に必要に応じて`[プロジェクト名]`または`[影響無し]`を付けた - [ ] PRのタイトルに「どのツールの」「なんの機能が」「どうなるか」が分かるように書いた - [ ] PMへの事前仕様確認 or 仕様はもう明確になっている - [ ] テストを書いた or すでにある or 不要なほど軽微な修正 - [ ] 動作検証した - [ ] ユーザ影響度: 高ならラベルをつける or 無し - `高`の定義: 注意深いレビューが必要（コードの仕様理解と動作確認）。サイト外に影響して取り返しのつかないもの（メール送信など）や、ユーザ行動に影響する部分（登録フォームや打診フォームなど）の改修。 ### 🌐インフラ影響がある場合（不要な場合は削除） - [ ] PRのタイトルに`[インフラ]`を付けた - [ ] 作業者は影響範囲を可能な限り説明できる - [ ] 確認会・共有会（15~30min）をスケジュールに設定する ### 📊効果測定 機能の効果を測定できるRe:dashのURLを貼ってください。 ### ℹ️issue close: #
