プロダクト開発におけるレビューの場：レビューイへの改善ポイント提案

はじめに

こんにちは、システム開発部の奥野です。
前回の投稿では、レビューを行う側がどのような事を考えて実施しているかをご紹介しました。
今回は、レビューを受ける側への改善ポイントをご紹介します。

前回の投稿はこちら tech.motex.co.jp

本記事も前回同様、これまでの経験と見解を整理し、言語化したものです。
私と異なる役割や立場の方にも、レビューに参加する際の一助となる気づきを提供できればと考えています。

また、成果物などに対してレビューを行う側をレビューアー、 レビューを受ける側をレビューイとして記載します。

より良いレビューにするために

私たちは、より良いプロダクトをお客様へ届けるために日々業務を行っています。
その活動の一環としてレビューがあります。

レビューはドキュメントやコードなどに対して実施しています。
それらはレビューイの方々によって、よく調査し、考え、設計された成果物です。
レビューアーとしても学ばせてもらえる場であり、尊敬や感謝の念に堪えません。
ありがとうございます。

その分、レビューを実施している中で「こうすればもっと良くなるのにな」と感じることも多々あります。

そこで今回の記事では、レビューアー側から見て改善に繋がると感じたポイントをまとめました。
レビューイに向けてまとめましたが、レビューアーにも当てはまる点があると思います。
ひとつひとつは小さなことでも、お互い積み上げていくことが、より大きな成果や成長に繋がるのだと信じ合える、そういう環境づくりが大切ですね。

改善ポイント

1. レビューに設定された目的の達成を目指す

   • 参加者が認識している目的を、最初から最後まで揃える
     • 例えば「課題の早期検出によって後工程での修正工数を削減する」が目的なのに「レビューアーからの OK をもらうこと」に変化してしまう
       • 小さな懸念があったが伝えず、レビューアーからも指摘されなかったので問題ないのだろう、という考えはやめる
       • レビューの場と、各工程での承認や合意を得る場が重なっていると、目的が曖昧になりやすい
   • 指摘されることを恐れすぎない
     • 申し訳ない、不甲斐ないとネガティブに捉える必要はない
     • 指摘によって、改善のための具体的な要素が明確に記録されるチャンスでもある
     • レビューアー側としては、ネガティブに感じさせない伝え方も大事

2. 指摘内容を理解して納得する

   • レビューアーの指摘は正しいだろう、で済まさない
     • レビューアーが上司やベテランであるほど、萎縮や過剰にリスペクトしてしまう傾向がある
     • 指摘の内容や根拠よりも、そのレビューアーが指摘したという点を重視してしまっていないか
   • その場では理解できたはずなのに改めて考えるとわからなくなる、なんてことはよくある
     • 遠慮せずにレビューアーに聞く
     • レビューアーは相手の理解度や疑問点を確認し、適切に伝える

3. 成果物などのレビュー対象の品質を高める

   • レビュー対象であるドキュメントやコードの品質が低くても、レビューを通せば高いレベルに引き上げてくれる、という考えはやめる
     • 細かな課題検出が重なり、レビューアーにかかる負担や時間も増え、重要な課題が検出しきれない可能性が高まる
   • 選択肢は提示するが選択はせずにレビューアーへ委ねる、という考えもやめる
     • それぞれの選択肢が一長一短で決めきれない気持ちはわかるが、意図や根拠をもって選択してほしい
     • その意図や根拠は、レビューアーが想像したものより鮮明であり、重要な判断材料になる
   • 完璧に仕上がるまでレビューに出さない、という意味ではない
     • 誤字脱字や文章自体の不備は、セルフチェックやツール活用で改善できるはず
     • 不明点や疑問、不安がある場合は、情報を整理した上で成果物に付加し、レビューや相談の場で共有することを検討する
   • 教育目的であれば、何が得意で何が苦手、どこを伸ばしたいなどを整理しておくと、後のフィードバックがより具体的になる

4. はじめに全体像や要点を簡潔に説明する

   • すべてのレビュー参加者が、同じイメージとゴールを見据えたレビューに臨む
     • レビューイは詳細に把握しているが、レビューアー側が必ずしも同じレベルで把握しているとは限らず、全体像を把握しにくい場合がある
     • 簡潔に説明できない場合は、まずは基本情報を整理して、ポイントをまとめるところから始めてみる
   • 対面レビューやコードレビューの依頼内容でも、レビュー効果に大きく影響する
     • 例えばコードレビューの場合、意図や背景を十分に説明せず「修正しました」だけでは伝わりにくい

5. 意図や背景、理由は省かない

   • レビューアーとの認識齟齬を解消するだけでなく、将来的な担当者への情報伝達でもある
     • なぜその手法を選んだのか、他の選択肢を採用しなかった理由は、レビューだけでなく、後の開発や検証、引き継ぎにおいても重要な情報となる
     • 当然と思われがちな理由や前提も、今後も全員に伝わるとは限らない
     • たとえ自身のみで作業を進めるから問題ないと思っても、3 日後の自分は他人と考えて省かないようにする
   • レビューアー側としても、指摘の意図や理由は明確に伝えることが、レビューの効果を高める鍵である

おわりに

前回と同様に、今回ご紹介した改善ポイントも、当たり前だと感じる事が多かったと思います。
前回でも述べましたが、レビューは、レビューアーとレビューイが協力して品質の向上などを目指す場のひとつです。
どちらか一方だけの頑張りだけでは実現できません。

執筆にあたって、自身が何を意識し、重視しているのかが洗い出せました。
足りていない、できていない点にもあらためて気づき、執筆者でありながら耳が痛いです。
それらを認め、改善し続けることが大事なのだと思います。

みなさまにとっても、レビューが単なる行事としての場ではなく、より良いプロダクトや環境をつくるための場にしていくキッカケとなれれば幸いです。