こんにちは、おのぽんです。
最近ダイエットをしているのですが、甘いものが大好きなので常日頃食べたい気持ちはあるものです。
そんな中でも、脂質を抑えられるけど食べれるおやつはなんだろう？と考えてたどり着いたものは「カステラ」でした。
カステラは脂質は低い一方でタンパク質や炭水化物の含有量も一定あるので、腹持ちが良く、スポーツの補食としても採用されています。
昔からカステラも大好きだったので、それに気づいてからコンビニのカステラを買い漁るようになってしまいました笑
さて、私ごとではございますが、2024年2月10日（日）に開催されたPHP Conference 関西 2024にて、
CodeRevieweeが求められることと題し発表させていただきました。
https://fortee.jp/phpcon-kansai2024/proposal/1ece99f8-82c3-4a87-a684-6649350fdf74
2023年10月8日（日）に開催されたPHP Conference Japan 2023では「CodeReviewerが求められること」を発表させていただいたのですが、
嬉しいことに満員になるほど聴衆の方々がお集まりくださいました。
その時の発表内容をまとめた記事はこちら。
今回の発表はその続編の内容となっております。
本記事では、「今日からできる！Reviewerから求められるレビュー依頼術」を紹介いたします。
Reviewee（=コードレビューを依頼する人）としての心構え
Reviewerの気持ちを考えてPR（=Pull Request。Github上で修正や機能追加を提案できる機能のこと）を出すことが必要です。
思いやりのないPRはチーム内での関係性の破綻を招いたり、結果的にレビューを出した人自身が傷つく恐れがあります。
では、Reviewerを思いやるためにはどうすれば良いでしょうか？
Reviewer（=コードレビューをする人）が求めているもの
インタビューを行い、Reviewerの想いを集める
Reviewerのことを理解するために、下記のインタビューを実行しました。
- 対象：20-30代の計10名の弊社のいろんな役職のPHPerエンジニア
- インタビュー時間：10分
- 内容：PRをReviewする際、
- レビューをする時にどのような点・内容に意識を向けているか？
- 指摘部分をコメントする際、気をつけている点はあるか？
- レビューしていて大変だなと思う時は？
- どのようなPRだと嬉しい？
- どのようなPRだと見たくない？（テンションが下がる？）
Reviewerのインサイトを探る
次に、KA法を使ってReviewerのインサイト（= 心の声）を探りました。
KA法とは、定性調査で明らかにした顧客の声や行動・体験などの「質的データ」を分析・モデリングし、本質的なニーズやユーザーのインサイトを明らかにしていく手法のことです。
KA法ではKAカードというものを作成していきます。
KAカードには、出来事・心の声・価値の3種類があり、
- 出来事：インタビューでの発言内容
- 心の声：出来事から考え得る心の声（=インサイト）
- 価値：行動の背景にある価値
をそれぞれ記載します。
例を紹介します。
あるエンジニアとのインタビューの中で、
他の人から見てもわかりやすくなっているか。という点。（に気をつけてレビューをしている）
という意見を伺いました。
こちらを出来事とし、心の声、価値をそれぞれ考えます。
心の声としては、「可読性が気になる」ことであると考えました。
また、この出来事の先にある価値は「運用のしやすさ・属人化防止」であると考えます。
これらをKAカードに落とし込むと下記のようになります。
KA法では、質問内容問わず得られた意見を全てカードに落とし込んでいき、心の声や価値を拾い上げます。
今回のインタビューをKAカードに落とし込むことで、実に140枚にも及ぶカードを作成することができました。
Reviewerの気持ちをグルーピングする
次にKJ法を利用して、先ほどのKAカードにより導き出した心の声や価値を見比べていき、似たような考えや感情をグルーピング、近しい考えを紐付けしていきます。
KJ法とは、書き出した情報（ローデータ）の断片的な要素を関連づけて、俯瞰しながらグループ化していく手法のことです。
KJ法を行ったところ、先ほどのKAカードは下記のようなグルーピングとなりました。
グループ名は、それぞれ
- プロダクトの質を向上させたい
- 迅速にレビューを終わらせたい
- レビューの質を向上させたい
- 組織を乱したくない
- 自他成長
としました。
これらをグルーピングしたグループ名でピックアップしてみると、Revieweeの想いは下記のようになります。
このうち、「RevieweeがReviewerの要望に応えることができるもの」という観点で見ていくと、
- 迅速にレビューを終わらせたい
- レビューの質を向上させたい
の2つであれば応えることができそうであることがわかります。
一見矛盾したように見える要望
先の章で、RevieweeはReviewerの
- 迅速にレビューを終わらせたい
- レビューの質を向上させたい
の要望に応えることができそうというお話をしました。
しかし、迅速なレビューとレビューの質の向上は一見矛盾したように見えます。
ここでそれぞれのKAカードの心の声を見ていくと
- 「迅速にレビューを終わらせたい」の心の声
- レビューにかけるパワーを抑えたい
- 理解しやすいコードを読みたい
- レビューの回数を抑えたい
- 「レビューの質を向上させたい」の心の声
- 概要を書いて欲しい
- 意図を素早く理解したい
- より適切なレビューを届けたい
ということが書かれていました。
このあたりからReviewerの気持ちを読み取っていくと、
- Reviewerは基本忙しいため、あまり自身の作業を中断したくない
- Revieweeの考えを理解した上でレビューを施したい
といったあたりがわかります。
Reviewerの求めるPRの出し方
Reviewerに求められているPRの出し方は意外とシンプルで、
- 忙しいReviewerでも手軽に見ることのできるような工夫を施す
- Reviewerに自分の考えや意図を伝える
と言ったあたりを満たすことができれば、先ほどの矛盾してそうな要望のどちらにも応えることができそうです。
忙しいReviewerでも手軽に見ることのできるような工夫
僕のプロジェクトで行われている工夫の仕方を2つほど紹介いたします。
1PRあたりのファイル数を10程度に抑える
Reviewerへのインタビューにより、1PRあたりのファイル数の多さの感じ方は下記の通りであるとわかりました。
1PRあたりにおけるファイル数が11~15あたりから、意見が分かれ始めました。
なので、1PRあたりのファイル数は10程度に抑えると良さそうです。
軽量なPRであることを伝える
僕のプロジェクトでは、レビューを依頼する際、SlackでgithubのURLを貼りながらReviewerへ声かけをしています。
その時によく見る声がけが、
- どれくらい軽量であるかを伝える
ex)- 差分少ないです！レビューお願いしますmm
- 1行のみの修正です！よろしくお願いします。
- どれくらい軽い気持ちで見ることができるかを伝える
ex)- このPRはすぐ見れるかと思います。よろしくお願いします🙏
- ◯◯な内容なので、さくっと見れるかと思います。よろしくお願いいたします！
のようなものです。
こうした一言を書くことで、ReviewerがGithubのURLを開くハードルを低くすることができます。
Reviewerに自分の考えや意図を伝える方法
- レビューを依頼する前に自らPR内にコメントを残しておく
- 処理を簡単にする（一目で理解できるようなコードを書く）
- 事前にReviewerと実装方針のすり合わせを行う
といった行動を取れば、Reviewerに対して自分の考えや意図を伝えることができそうです。
本記事はレビューの依頼方法に焦点を合わせているので、この中でも「レビューを依頼する前に自らPR内にコメントを残す」方法について触れていきます。
レビューを依頼する前に自らPR内にコメントを残すコメント例
コメント例①：第三者が見て疑問に思いそうなポイントには先回り
「なぜこのようなロジックになるのか」と質問されそうな点に対し、あらかじめ解答しておいたり、
理解に時間を要しそうなロジックには、図解するなどしておきレビュー時間の短縮を図っています。
コメント例②：Reviewerの質問内容が理解できない場合は素直に聞く
事前にコメントをしていると、そこから議論に発展することがあります。
その際発生した質問内容が仮に理解できなかった場合は、無理に解答しようとせず素直に補足内容を求めましょう。
そして、Reviewerの意図を理解してから解答することが良いと思います。
また補足内容の説明を受ける際は、チャット上でのやり取りだけでなく、オンライン通話や口頭で直接補足をいただいても良いです。
Reviewerの苦悩
Reviwerの想いでもう一つ大事な点として、
- プロダクトの質を向上させたい
- 組織を乱したくない
があります。
RevieweeはReviewerがいかにすごいことをやろうとしているかを理解しておくことも重要です。
こちらでも、それぞれのKAカードの心の声を見ていくと、
- プロダクトの質を向上させたい
- コードの質を落としたくない
- 属人化を防ぎたい
- 運用に耐えうるコードになっていてほしい
- 組織を乱したくない
- Revieweeへの気遣い
- ギスギスしたくない
- 度重なる指摘コメントはReviweeの気が滅入ってしまう、Revieweeのことを傷つけてしまう恐れにつながります
（人格否定、攻撃的なコメントは論外）
- 度重なる指摘コメントはReviweeの気が滅入ってしまう、Revieweeのことを傷つけてしまう恐れにつながります
と言ったことを考えながら、組織を乱さずにプロダクトの質を向上させることを考えています。
コメントをしなければプロダクトの質の改善につながらず、Revieweeを傷つけることもまたプロダクトの質の改善にはつながりません。
Reviewerはこういった苦悩を乗り越えながら、細心の注意を払いつつコメントをしております。
レビュー依頼の工夫点の1つとして、このようなReviewerの苦悩を理解しReviewerにとってコメントしやすい状況を提供することができるコメント例も存在するので、最後に紹介しようと思います。
Reviewerにとってコメントしやすい状況となるコメント例
こちらはcronの設定のレビュー依頼を出したエンジニアのコメント例です。（オレンジ：Reviewee、グレー：Reviewer）
最初のタイミングで、Revieweeは教えて欲しいというスタンスを取っています。これによりReviewerにとってコメントしやすい状況が生まれています。
またRevieweeが知りたがっている部分も明確であるため、Reviewerも適切なコメントを残すことができ、レビューの質・速度の向上につなげることができます。
少しレビュー依頼とは異なりますが、Revieweeの行動も素晴らしいと考えます。
ここでは「cronを設定しなければならないということはわかっているものの、どのようなルールで設定すれば良いかはよくわかっていない」という状況です。
しかし、RevieweeはとりあえずPRを出すところまで作業を進め、PR上で質問することで設定方法を解決しようと試みています。
このように、レビュー依頼のタイミングで疑問点を聞くことで他エンジニア（≒Reviewer）の作業を中断する回数を減らすことができるため、Reviewerから奪う時間を最小限に抑えることにつながります。
今日からできる！Reviewerから求められるレビュー依頼術
さて、本記事のゴールは「今日からできる！Reviewerから求められるレビュー依頼術」を紹介することでした。
今までの流れを踏まえてまとめていきます。
Reviewerへインタビューを行い、その結果を分析することで、Reviewerの気持ちがわかりました。
Revieweeがレビューの依頼方法を工夫することで、Reviewerの下記の2つの要望を満たせることがわかりました。
◯Reviewerが求めるレビュー依頼
①気軽に見ることができるもの
②Revieweeの考えや意図が伝わるもの
これに対して様々なレビュー依頼やPRでのコメントの仕方を通して、どう言った点が良いかを本記事内で記述いたしました。
それこそがレビュー依頼術となります。（下記にまとめます。）
◯レビュー依頼術
- 1PRあたりにおけるファイル数は10ファイル程度に抑える
- 軽量なレビューであることを伝える
- レビューを依頼する前に自らPR内でコメントをつけておく
- 第三者が悩みそうな点は先回りしてコメント
- Reviewerにとってコメントしやすい状況を作る
- 迷ったり相談したい点もあらかじめコメントしておく
- 処理を簡単にする（一目で理解できるようなコードを書く）
- 事前にReviewerと実装方針のすり合わせを行う
いかがでしたでしょうか？
今回はReviewerの気持ちを分析した上で、「今日からできる！Reviewerから求められるレビュー依頼術」を紹介させていただきました。
少しでもReviewee・Reviewer同士がお互いを理解し合いながら、プロダクトの質を改善していくことに繋がると嬉しいです！
本セッションの議論・質問はもちろん、
- 目標達成や事業の成長を一緒に感じたい
- チーム貢献に尽力できて、またその成果も評価してほしい
- 自由に企画・提案しながら社内にアクションを起こしたい
という方がいらっしゃいましたら、是非一度弊社社員とお話させてください！
最後までお読みいただきありがとうございました！！
