ソフトウェア開発をされている方だとごくごく身近に感じる言葉、
レビューです。
聞きなれない方にレビューとは何かをすごく簡単に説明すると、
第三者による成果物の妥当性確認です。
ソフトウェア開発では仕様書やソースコード、デバッグ要項書など
様々な成果物を生み出すのですが、その成果物に対して事あるごとにレビューが必要になってきます。
レビューを受ける側をレビューイ、レビューをする側をレビュアーと言います。
どうやってレビューしてますか？
レビューの手法は様々で、企業やプロジェクト、チーム単位でもやり方はいろいろあると思います。
その中でレビュー会議、ウォークスルーと呼ばれるタイプのレビューをされている方はいませんか？
会議室なので、対面で成果物の作成者が説明を行い、レビュー参加者が発言して指摘を行うというやり方です。
個人的にこの手法が主流であればまずいと感じています。
その理由を以下に記していきます。
まずい理由①観点が作成者のものになってしまう
レビューとは第三者の観点で、誤りを見つけたり、伝わらない点を探したりすることに意味があります。
にもかかわらず、成果物の作成者が主導で「ここを見てほしい！」と先導することにより、
本来第三者が見るべき観点から外れてしまい、結局作成者と同じ観点になってしまうことがあります。
これではたとえ複数人の第三者を集めても、同じ観点でレビューすることになり、非常にもったいないです。
まずい理由②成果物より説明が先行する
成果物というのは仕様書であったり、ソースコードであったりするのですが、
果たしてそれら成果物は今後どういう扱いをされるのでしょうか？
おそらくどこかに保存されたり、バージョン管理システムで管理されたり、
ノウハウそのものとして管理されていることになると思います。
いずれ、その保存された成果物を参照する人が出てくるでしょう。
果たしてその時、その成果物を作成した人が改めて、その都度内容について説明してくれるのでしょうか？
恐らくそういったケースは少なく、参照する人間はその成果物のみで
内容を知るしかありません。
つまり、説明があってようやく理解を得られるような成果物であっては困るということ、
成果物単体で理解できるように作成されなければならないということです。
レビューのやり方を変えよう
では、どうすれば上記のまずい事象を防げるのか。
それは、まずはレビュアーが個別でレビューすることが大切です。
そうすることによって、第三者の観点が保たれたまま、成果物のみに対するレビューができます。
その上で、出た指摘を持ち寄って会議するなどは悪いことではないと思います。
レビュー会議の悪いところばかりあげましたが、もちろん良いところもあります。
主には教育的な部分で、複数人のレビュアーがいた場合、
独自の観点を持つ人の指摘などを説明を受けながら理解できるということです。
新入社員や、そのドメインの知識が無い方を参加させてレビューを行うというのは
教育的観点ではアリだと思います。
ただ、成果物としての妥当性やナレッジマネジメントを考えた場合、
レビュー会議が主体になっているプロジェクトなどは怪しい気がします。