こんにちは、おのぽんです。
急に寒くなり、夏が一瞬でいなくなったように感じます。じめっとした暑さも嫌ですが、突然寒くなるのもびっくりしてしまいますね。
さて、私ごとではございますが、2023年10月8日（日）に開催されたPHP Conference Japan 2023にて、
コードレビュワーが求められること改めCodeReviewerが求められることと題し発表させていただきました。
https://fortee.jp/phpcon-2023/proposal/25891e6c-7762-47b5-8cb3-e3db7f056abc
レビューに関する考え方は一度社内でdocbaseを活用して発信したところ、ありがたいことに多くの反響をいただきました。
また嬉しいことに、他部署のディレクターがその記事を読んで他のエンジニアに伝えてくださるといったアクションもありました。
PHP Conference Japan 2023では、そんな考えを共有すべく、Revieweeの気持ちや考えを実際に分析していきつつ、どのような観点でレビューを進めると良いかを考察していきました。
本記事では、その時の発表で皆様にお伝えした「今日からできる！Revieweeから求められるコードレビュー術」を紹介いたします。
なぜコードレビューを行うのか
コードレビューをなぜ行うのかを考えます。
- 作ろうとしているものが合っているかを確認するため
- コードの質を担保するため
- 属人化を防ぐため
- 知識共有や認識合わせのため
- チーム内のスキルアップのため
コードレビューの目的は様々であるため、一概に「どのようなレビューが正解である」と定めることはできません。
Reviewee（=コードレビューを依頼する人）が求めているもの
次に、Revieweeが求めているコードレビューを考えてみましょう。
みんなはどんなことを考えながら他エンジニアにレビューを依頼しますか？Revieweeの気持ちになって考えてみましょう。
- もっといい書き方があるか教えてほしい
- コード設計や方針を理解してもらいたい
- 思想や方向性を共有・議論したい
- 想定外の影響範囲がないか確認してもらいたい
- 可読性を担保できているかどうか客観的に判断してもらいたい
このように、Revieweeは色んな思いや考えを持っています。
それらの思いや考えを尊重しながらコードレビューを行うためには、どのようなことに注意することが良いのでしょうか。
インタビューを行い、Revieweeの想いを集める
まずはいろんなエンジニアのRevieweeとしての想いを知るために、下記のインタビューを実行しました。
- 対象：20-30代の計10名の弊社のいろんな役職のPHPerエンジニア
- インタビュー時間：10分
- 内容：Reviewを依頼する際、
- どのようなレビューを求めるか？
- レビューを出す際に意識していることは？
- どんなコメントが残ってると嬉しい？
- こんなレビューが助かった
- こんなレビューは嫌だった
Revieweeのインサイトを探る
次に、KA法を使ってRevieweeのインサイト（= 心の声）を探りました。
KA法とは、定性調査で明らかにした顧客の声や行動・体験などの「質的データ」を分析・モデリングし、本質的なニーズやユーザーのインサイトを明らかにしていく手法のことです。
KA法ではKAカードというものを作成していきます。
KAカードには、出来事・心の声・価値の3種類があり、
- 出来事：インタビューでの発言内容
- 心の声：出来事から考え得る心の声（=インサイト）
- 価値：行動の背景にある価値
をそれぞれ記載します。
例を紹介します。
あるエンジニアとのインタビューの中で、
「これもいいと思うけど、こういう書き方もできるよ」みたいな+αを教えてもらえると嬉しい。
という意見を伺いました。
こちらを出来事とし、心の声、価値をそれぞれ考えます。
心の声としては、「良い実装を知りたい」ことであると考えました。
また、この出来事の先にある価値は「Revieweeのスキルアップにつながる」ことだと考えます。
これらをKAカードに落とし込むと下記のようになります。
KA法では、質問内容問わず得られた意見を全てカードに落とし込んでいき、心の声や価値を拾い上げます。
今回のインタビューをKAカードに落とし込むことで、実に100枚にも及ぶカードを作成することができました。
Revieweeの気持ちをグルーピングする
次にKJ法を利用して、先ほどのKAカードにより導き出した心の声や価値を見比べていき、似たような考えや感情をグルーピング、近しい考えを紐付けしていきます。
KJ法とは、書き出した情報（ローデータ）の断片的な要素を関連づけて、俯瞰しながらグループ化していく手法のことです。
KJ法を行ったところ、先ほどのKAカードは下記のようなグルーピングとなりました。
グループ名は、それぞれ
- 楽しく働きたい
- 気づきや学びが欲しい
- 実装や意図を理解して欲しい
- 自信を持ちたい
- Reviewerへの心遣い
- 利用ユーザに早く価値を届けたい
- 属人化を防ぎたい
としました。
これらをグルーピングしたグループ名でピックアップしてみると、Revieweeの想いは下記のようになります。
このうち、「ReviewerがRevieweeの要望に応えることができるもの」という観点で考えると、
- 気づきや学びが欲しい
- 実装や意図を理解して欲しい
- 自信を持ちたい
の3つが、RevieweeがReviewerに求めることであると捉えることができます。
Revieweeが求めているレビュー例
先の章で、RevieweeはReviewerに対して、
- 気づきや学びが欲しい
- 実装や意図を（Reviewerに)理解して欲しい
- 自信を持ちたい
といったことを求めていることがわかりました。
本章では、僕の現場でのコードレビューを例にあげ、どのようなレビューであればRevieweeの気持ちを汲み取ったレビューを行えるかを紹介していきます。
気づきや学び・実装や意図を理解していることを伝えるレビュー
こちらのReviewerは、
- 実装や意図を理解した上で、ブラッシュアップ（学び）のためのコメントを記載
- 物腰柔らかい口調
- Revieweeの修正後、感謝を伝える
といったコメントをしています。
これは、
・PHP特有のメソッドや、ロジックの代替案は気づきや学びとして伝えられるので、気づきや学びを与えることができている
・また、実装や意図を理解していなければ、気づきや学びのコメントができないので、実装や意図を理解していると言える
であると考えられます。
ナイスレビューですね！
このように、気づきや学び、実装や意図の理解などは何となく想像しやすいかな？と思います。
では、自信につながるレビューとは一体どんなものでしょうか？
自信につながるレビュー
どういったレビューを行うと、Revieweeは自信につながるのでしょうか？
それは、先ほど行ったKAカードの中にヒントが潜んでいます。
先ほど「自信を持ちたい」にカテゴライズしたKAカードの一部を下記に取り上げてみます。
これらの心の声をみると、安心感や褒めてもらいたいといった欲求を満たすことができれば、自信を持つことができると言えそうです。
また、レビューの場では満たすことはできませんが、自分が作ったものを使ってもらえると嬉しいという声も上がっていました。
確かにReviewerが別のタイミングで、以前レビューしてもらったコード（機能）を使ってくれていたら嬉しいですよね！
それでは、安心感が増すレビューや、褒めるレビューを見ていきます。
安心感が増すレビュー
例1)
こちらは、僕（=onopon)がRevieweeの様子です。
一通りレビューをした上でわからなかった点を質問していただけているので、実装や意図を理解しようとしてくれているように感じます。
そして、補足説明に納得した上でLGTM（=LookGoodToMeの意。レビューOKを表します）とコメントしてくださっています。ただLGTMをもらうより安心感があり、自信にも繋がるレビューとなっているのではないでしょうか？👏
例2)
こちらでは、登場人物全員Reviewerです。
書かれたコードを読んで理解したことをそのまま書いているだけですが、他の人のレビューの手助けになる可能性があります。
また、実装や意図を理解できていないと書けないコメントを書くことで、Revieweeに「ちゃんと読んでるよ！」ということを伝えることができます。
2人目のReviewerも僕のコメントを読んで理解した旨を被せて伝えているだけなのですが、ただコメントを残すだけでもRevieweeにとっては安心に繋がるコメントとなり得ます。
例3)
「LGTMです！」や「👍です！」のようなコメントだけでは、「Reviewerが本当に読んだのかどうか」までを伝えることはできず、Revieweeの安心感に繋げることができません。
修正範囲がある程度のファイル数に及ぶものであれば、
- そのファイルの構成
- ロジックを読んだからこそ書けるようなコメントを添える
のようなコメントをすることで、Revieweeに安心感を与えることができます。
褒めるレビュー
例1)
補足コメントへのリアクションは「読んでもらえている」という安心感につながりますね。
ただ褒めるだけでも、Revieweeにとって自信に繋がりますし、❤️のような肯定的なリアクションもGoodです💡
例2)
この例では、ReviewerはRevieweeに対して「ピラフを奢りたくなるほど感謝している」という喜びが表現されていますw
このように感謝の気持ちと共にどれくらい喜んでいるのかを大げさに伝えると、Revieweeは「修正の方向性は間違えてなかった」と感じ自信を持つことができます。
また、2件目のコメントのように手法やプロセスを褒めるのも良い手法です！
今日からできる！Revieweeから求められるコードレビュー術
さて、本記事のゴールは「今日からできる！Revieweeから求められるコードレビュー術」を紹介することでした。
今までの流れを踏まえてまとめていきます。
Revieweeは下記の3つを求めていることがインタビュー結果を分析することで見えてきました。
◯Revieweeが求めるレビュー
①気づきや学びを与えることができているか
②実装や意図を理解しているように見せられているか
③Revieweeに自信を持たせることができているか
→ 安心したいというインサイト
これに対して様々なレビューを通して、どう言った点が良いかを本記事内で記述いたしました。
それこそがコードレビュー術となります。（下記にまとめます。）
◯コードレビュー術
- 代替案を伝えるコメントは、①②を満たせる
- わからない点は質問することで、②を満たそうとする姿勢を伝えることができる
- ロジックを読んだからこそ書けるコメントは②を満たすことができる
- 何かしらを褒めるだけでも③を満たすことができる
- それがプロセスや手法であっても良い
- 肯定的なリアクションスタンプは安心につながり、③を促す
- 感謝の気持ちを伝える上での大げさな感情表現は③を満たすことができる
いかがでしたでしょうか？
今回は、Revieweeの気持ちを分析した上で、「今日からできる！Revieweeから求められるコードレビュー術」を紹介させていただきました。
少しでも誰かのレビューの質の向上に繋がると嬉しいです！
書いてて思いましたが、Reviewerから求められるPR作成術も気になりますね🤔
（余力があればまとめます笑）
最後までお読みいただきありがとうございました！！
