はじめに
私は十年近く前、レビューで大量の指摘を登録することが何度かありました。
当然、大量の指摘修正をしてもらうという行為は、手戻りであり、それだけプロジェクトの進捗を遅らせることになりました。
とても恥ずかしい話ですが、当時の私は、レビューで大量の指摘で手戻る原因が、レビューイにあると思い込んでいました(本当にごめんなさい)。
しかし、今、振り返ってみると、__手戻りの原因はレビューアである私にあった__と思います。
そのような恥ずかしい自分の行動を戒めるために、__どれだけ当時の自分が残念だったのかを紹介__します。
要するに反省文のようなものです。
今回対象とするレビューの前提条件
今回紹介するレビューは、以下の条件を満たすものでした。
- レビュー対象の成果物は、以下のいずれか。
- 外部仕様書
- 設計書
- テスト仕様書
- ソースコード
- レビューイは、レビュー対象成果物を作成した経験が浅い(数回の経験)。
- レビューアは、レビュー対象成果物を作成した経験が十分にある。
- レビューアは、自分がその成果物をレビューする役割であることを事前に知っている。
- __1時間くらいのレビューで20件以上の指摘が検出__された。
レビューでどんな指摘をしたか
大量のレビュー指摘を登録する時は、以下のような指摘がいくつか散見されました。
- 以前のレビュー時に指摘した内容と同じ観点での指摘。
- 成果物を作成する前に方針を説明済みであるが、その方針通りに作られていないという指摘。
- この成果物の目的をちゃんと理解しているのかな？と思えるような指摘。
- 「なぜこのように作ったのか？」と質問すると「なんとなく」と回答される箇所の指摘。
- レビュー後に、指摘を修正してもらった後の確認時の差し戻し(例：指摘した箇所のみ修正し、類似の問題を横展開して修正できていない)。
__こういう指摘ばかりではありませんでしたが、レビューアからしたら「基本的なことができていない」と思えるような指摘があった__という意味です。
私が残念だったポイント
当時の私は、上記のような指摘があるのは「レビューイに原因がある」と思い込んでいました。
しかし、経験の浅い状態では、そもそもどういう考え方でどういうことに気をつけて成果物を作るのか、1度説明されたくらいでは、分からなくて当然__だと思います。
当時の私は「1度説明したからできるはず」という傲慢な考え方__だったと思います。
経験が浅いうちは、どのように考えて成果物を作るのか、__経験者の考え方を聞きながら体験しないと、なかなか実践できない__と思います。
だから、レビューアからしたら「基本的なことができていない」ということでも、__経験が浅いうちは「頭がテンパって落ち着いて考えられない」ため、基本的な見落としやミスが多発するのは仕方がない__と思います。
当時の私は「だったらレビューイから、事前に相談するなりすれば良いじゃないか」と言うかもしれませんが、それは難しいと思います。
経験が浅いうちは、とにかく自分で作ることにいっぱいいっぱいで、自分の考えが足りていないという自覚もないので、相談する必要性を当人が感じていない(ことが多い)と思います。
だから、経験のあるレビューア側が事前にフォローすることが必要だと思います。
それと、__心理学の面から言えば、レビューで「基本的なことができていない」という駄目出しばかりの指摘をするのは良くなかった__です。
そんなことされたら、誰だって嫌__だと思います。
有名な心理学の実験で「できていないことを叱咤する」より「できたところを称賛する」方が効果が高い__と言われているのに、その反対のことをやっていました。
駄目出しばかりでは、やる気が低下して、その後の生産性も下がると思います。
どうすれば良かったのか
今の私であれば、こういう前提のレビューイに対して、自分がレビューアであれば、まずペアプログラミングを実施します。
ペアプログラミングで、その成果物をどのように考えて作るのかを体験してもらって、その考え方をしっかり理解してもらいます。
(対象成果物がソースコードでも外部仕様書でも、同じようにペアプログラミングで考え方を理解してもらいます)
__そうすれば、上に挙げた指摘の多くは事前に除去できる__と思います。
当時の私は「ペアプログラミングをする時間なんてない」とか言うかもしれませんが、「レビューの時間＋修正確認で何度も差し戻す時間」と「ペアプログラミングにかかる時間」は、そんなに変わらないと思います。
忙しいなら、__最初の1時間だけでも一緒にやれば、それだけでも効果はある__と思います。
何より、一度ペアプログラミングで考え方をしっかり学んでもらった方が、その後の生産性は間違いなく上がると思います。
(当時の私はそれをしなかったため、その後も多数のレビュー指摘を繰り返していました)
__ペアプログラミングでメンバーが成長するというのは、おそらく世界共通の認識__だと思います。
参考までに、以下の記事には、私のチームで感じたメンバーの成長点をまとめています。
ペアプロ・モブプロでメンバーが驚くほど成長した話
また、心理学の面でも、ペアプログラミングなら、たくさん指摘して駄目出しすることもないので、レビューイのやる気は下がりません。
むしろ、__ペアプログラミングの大きなメリットは「楽しい」こと__ですし、ペアプログラミングなら__称賛するチャンスがたくさん__あるので、やる気を上げる方向の効果があると思います。
まとめ
当時の自分がどれだけ残念だったのかを紹介しました。
今後も、問題の原因が自分にあるのではないかという視点で、考えていこうと思います。
ちなみに私は、普段はエンジニアリングマネージャーとして、チームの皆で楽しく開発する施策を色々実施しています。詳しくは以下を参照ください。
1年以上かけて生産性倍増＋成長し続けるチームになった施策を全部公開
Twitterでも開発に役立つ情報を発信しています → @kojimadev