私が居るソフトウェア開発の現場の、設計やソースコードのレビューに関する話。
難易度、重要度が高い案件に対しては、特定のメンバーがレビューアとして割り当てられることが多いが、そこで選ばれるような信頼されるレビューアにどうすればなれるのか？という相談をチームメンバーから受けた。
相談してくれた方は、レビューをうまくできるようになろうという方向で、レビューに関するアクションを仮案として出してくれた（仮案を持ってきてくれるのとてもいい）のだけど、私の方でうまく行くイメージが浮かばなかったので深掘りして考えてみた。
そういった案件のレビューアを私が割り当てる時、レビューのうまさで選んでいるかというと、そうではなくて、
- 設計能力の高い人
- 問題検出能力の高い人
を選んでいるように思う。
設計能力
レビュー対象の成果物が作られた過程を想像する。脳内でその過程を追体験し、設計の選択の妥当性を確認していく。複数の選択肢が出てくる場面で、妥当そうな選択肢が複数思い浮かぶ場合は、判断理由を聞いてそれが納得できるものであるかを確認する。
問題検出能力
レビュー対象の成果物が利用されている様を想像する。脳内で利用シーンを思い浮かべ、もし良くないことが起きるとしたらどういうことかを考え、成果物にその要因となるような欠陥がないか確認する。
業務知識
対象領域の業務知識に詳しい人を、レビューアとして選ぶこともある。でもその時は、その領域での設計能力や問題検出能力に期待して選んでいる気がする。周辺の経験があり知ってるだけだと、難易度、重要度の高い案件の最後の砦的なレビューアとしては選ばない。知っていて、かつ、鼻が利く人を選ぶ。
そうなるには？って話に戻ると、業務の対象とする領域を絞ってまずはそこのエキスパートになる過程で、設計能力や問題検出能力を磨くというのはありだと思う。ただし、主題である信頼を受けているレビューアの方々は、複数の領域について詳しく、かつ、新たな領域に詳しくなるのもすんなりされている感じがある。対象領域の具体的な知識、経験から抽象的な理解を導いていて、他の領域に行く時は何らかのアナロジーを活用してるんじゃないかと想像する。ただの想像だけど。
強いレビューアになるには
レビューのうまい人というのは結果としてそう見えているのであって、そうなるには上で書いたような能力が必要そう。
レビューの結果として目に見えるのは見つけた欠陥くらいだし、もし過程を観察していたとしても、設計能力や問題解決能力が発揮されているのは脳内の思考がメインで、他の人には見えないところでの活動が多い。なのでレビュー工程だけに注目してうまくなろうと頑張るのは、周囲を見て学ぶことの効率が良くなさそう。それよりは、レビューの前工程である設計に習熟するとか、後工程である成果物の活用とそこでの問題検出に習熟するとかに力を掛ける方が、要求される能力を付ける事に対してより直接的で効果があると思った。
偏り
私がレビューアをどう選んでいるかを思い起こして、選ばれる条件を考えてみたが、自身がレビューする時のやり方が念頭にあって、それに引きずられている感じがする。他の人はどういう風にレビューを進めているのか、どういう風にレビューアを選定しているのかは気になる、知りたい。
学び
「〇〇ができるようになるには？」と聞かれて考えるとき、対象の「〇〇」という活動だけに注目して考えても、いい答えにはたどり着けないことがある。そういう時に、実際に「〇〇」ができている人の集団を考え、スコープを「〇〇」以外にも広げて、該当する人々の共通部分、出来てない自分との差分を考えることは一つの方法とわかった。
