レビュー指摘が多い原因がレビュアーにもある事を共有する(#14)

この記事の初出は、Software Design 2023年5月号です。

はじめに

みなさんは開発経験が少ないメンバーが作った成果物(ソースコードやドキュメント)に対して、レビューで大量の指摘をした事はないでしょうか。
私は十年以上前、駆け出しのチームリーダーの頃、そういうことが何度もありました。
大量の指摘を修正してもらうという行為は、手戻りであるため、それだけプロジェクトの進捗を遅らせることになりました。
また、指摘されたメンバーも、そういう事が何度もあると、レビューされる事に対してマイナスなイメージを持ち、開発があまり楽しく感じていなかったかもしれません。

恥ずかしい話ですが、当時の私は、レビューで大量の指摘で手戻る原因が、成果物の作成者にあると思い込んでいました。
しかし、今、振り返ってみると、手戻りの原因はレビュアー(レビューする人)である私にもあったと思います。

今回はその時の私の失敗談を紹介した上で、開発経験の少ないメンバーが楽しく開発するために、現在のチームでどのように取り組んでいるかを紹介します。

レビューの指摘内容

当時のレビューは次のようなものです。

• レビュー対象の成果物は、ソースコードもしくはドキュメント(テスト仕様書など)。

• 作成者は、類似の成果物を作成した経験はあるがその回数が少ない。

• レビュアーは、類似の成果物を作成した経験が十分にある。

• レビュアーは、自分がその成果物をレビューする役割であることを事前に知っている。

• レビュー時間は1時間程度。

このようなレビューにおいて、私は20件以上の指摘をしたことが何度かありました。 そのレビューで挙がった指摘がどんなものだったのか一例を紹介します。

• 以前のレビュー時に指摘した内容とほぼ同じ間違いをしている

• (事前に対応方針を説明済みであるにもかかわらず)方針通りに作られていない

• 成果物の目的を理解できていないような間違いをしている

• 判断理由があいまい（「なぜこのように作ったのか？」と質問すると「なんとなく」と回答される）

• 前回指摘した箇所のみを修正し、他の箇所で同じ原因の問題を修正できていない

上記の例の通り、レビュアーからすると「基本的なことができていない」と思えるような指摘が多くありました。

私のレビューの反省点

前述のように当時の私は、多くの指摘が検出されるのは「作成者に原因がある」と思い込んでいました。
自分のやり方に原因がある可能性を考えていませんでした。
しかし、よくよく考えれば、経験が少ないときは、説明した通りにできなくて当然です。
どのような考え方で作業するのか、何に気をつけて成果物を作成するのか説明されても、経験がないので具体的にイメージすることができないからです。
また、レビュアーからすると「基本的なこと」と思うことでもミスをするのは仕方がありません。
作業に慣れていないと、焦ったり慌てたりして落ち着いて考えられなくなるからです。
そのため、うまくできないことを前提にして、経験から効率よく学ぶことをサポートした方が良いですが、私はできていませんでした。

また、当時の私は「分からない事や困った事があれば、成果物を作り切る前に相談すること」を作成者に求めていました。
しかし、これも作成者からすれば難しいことです。
経験が少ない時は、とにかく成果物をなんとか作ることで頭がいっぱいとなり、自分の考えが足りていないという自覚が持てず、相談する必要性を感じていないことが多くあります。
作成者が若手であれば、手戻りを減らすために適切なタイミングで相談するという仕事のやり方に慣れていないこともあります。
そのため、レビュアーが適切なタイミングで状況を確認する機会を作ることが必要ですが、私はそれもできていませんでした。

それと、当時のレビューでは、悪い点ばかりを指摘して、良い点に対するポジティブフィードバックをしていませんでした。
「できていないことを叱咤する」より「できたところを称賛する」方が教育効果が高いと言われていますが(エンハンシング効果など)、その反対のことをやっていました。
駄目出しばかりを受けては、モチベーションが低下して、その後の生産性も下がる可能性が高くなります。
その上、当時は「レビューは育成するために最適の機会」と思っていたので、今後どういう考え方で取り組むと良いかなども合わせて指導していました。
それは作成者の成長のために良かれと思ってやったことですが、作成者の立場からしたら、何十件も指摘された上で、そんな指導をされても、もはや頭に入らず、説教のように聞こえる可能性が高いでしょう。
育成目的で指導するのであれば、作成者のモチベーションを高めて主体性を発揮させた方が良いですが、私はできていませんでした。

現在のチームでの取り組み

現在のチームでは、同じ前提で成果物を作成してもらう際は、ペアプログラミング(以下、ペアプロ)もしくはモブプログラミングを実施しています。
ペアプロで、その成果物をどのように考えて作るのかを体験してもらって、その考え方をしっかり理解してもらうことが重要だからです。
これは、対象成果物がソースコードであってもドキュメントであっても、同じようにペアプロで考え方を理解してもらうことを優先しています。
そうすれば、先に挙げた指摘内容の多くは事前に除去できます。
分からない事や困った事があっても随時質問してもらって解消できます。

もしかしたら当時の私は「ペアプロをする時間なんてない」と言うかもしれませんが、「大量の指摘をするレビュー時間＋修正確認で何度も差し戻す時間」と「ペアプロにかかる時間」は、そんなに変わらないと今は感じています。
また、すべてペアプロで作らなくても、最初の1時間だけでもペアプロをする効果はあります。

何より、ペアプロで考え方をしっかり学んでもらった方が、その後の生産性は上がります。
かつての私はそれをしなかったため、その後も大量のレビュー指摘を繰り返していました。
ペアプロでメンバーが成長に大きな効果があるのは間違いないです。
参考までに、私のチームで感じたペアプロでのメンバーの成長については『ペアプロ・モブプロでメンバーが驚くほど成長した話』を参照ください。

また、ペアプロなら、大量の指摘で駄目出しすることもないので、作成者のモチベーションを下げません。
むしろ、ペアプロの大きなメリットは楽しいことであり、相手を称賛するチャンスがたくさんあるので、モチベーションを上げる効果もあります。
ペアプロの会話の中で、楽しく感じてもらえる指導のやり方については、本連載の第4回の『コーチングプログラミングで楽しく成長する』を参照ください。

そして、もう1つ大事な事は「レビューで大量の指摘がある場合、その一因はレビュアーにもある」ということをチームで共有することです。
それを共有していれば、チームの誰がレビュアーになっても、私と同じ失敗を回避できます。

今回紹介した考え方が、開発経験の少ないメンバーがレビューを恐れずに楽しく開発するための参考になれば幸いです

---

連載「ハピネスチームビルディング」の次回の記事はこちら↓

前回の記事はこちら↓