はじめに
社会人として年数を重ねるにつれて、設計をする側だけでなく、レビュータスクも増えてきました。
しかし、うまく問題検出ができる時と、脱線しっぱなしになったりする時とがあったりしました。
設計レビューのノウハウを学ぶために読んだ書籍から、ノウハウ集的な感じにまとめようと思います。
ここでのレビューはエンジニアが実施する「ピアレビュー」にターゲットを合わせています。
レビューは必要な形態を選ぶ
レビューには「ウォークスルー」「インスペクション」「テクニカルレビュー」があります。
それぞれのレビュー形態と、目的を知って、今するべきレビュー形態を選択します。
ウォークスルー
設計者が主導する、必要なレビューアのみを招集したカジュアルなレビューです。
目的は、設計における設計者の悩みの解消と、チーム内の認識合わせです。
ドキュメントは完成していなくても構いません。認識齟齬は早い段階で減らしていきましょう。
カジュアルであるため、話が脱線したりして無駄に時間がかかりがちです。
ゴールは明確にしておきましょう。
インスペクション
ウォースルーの対極の、フォーマルなレビューです。
観点や、レビューア、進行役、記録係などを事前にがっちり決めて行います。
レビューアに役割（プログラマだったり、顧客）を持たせたりする場合もあります。
レビューアは事前にドキュメントを確認し、問題を検出しておく必要があります。
網羅的なレビューをしたい場合は選択を検討します。
デメリットとして、準備が多いので工数負荷が高まりやすいことです。
テクニカルレビュー
ウォークスルーとインスペクションの間くらいのレビューです。
リーダー（進行役）、レビューア、設計者で開催します。
インスペクションほどではないですが、観点は事前に決めておいて、問題検出をしておきます。
インスペクションより自由度が高いのはメリットでもありますが、レビューア間の話題に任せてしまいがちなので、
話の脱線には注意しましょう。
レビューのステップを知る
レビューには4つのプロセスがあります。
基本的なこの4つのプロセスを守ることで、型化したレビューを行う手助けをします。
テクニカルレビューを元に、リーダー、レビューア、設計者を登場人物としていますが、
状況によってはレビューアや設計者がリーダー（進行役）を担ったりすると思うので、適宜読み替えてください。
準備
リーダーは検出すべき問題を把握しておき、観点を出してレビューアに観点を割り振ります。
リーダーは、レビューの場とメンバーを確保しましょう。
レビューアは与えられた観点で、優先度を決めます。優先度は、後工程での問題発覚による修正工数が多いものが高くなります。
設計者は、ドキュメントを作成します。レビューアの負荷を減らすためにも品質が高くなるよう努めましょう。
問題の検出
レビューアは、与えられた観点から、問題の検出を行います。どうやって検出したかを説明できるようにしておきましょう。
問題の指摘
レビューアは検出した問題を設計者に指摘します。
設計者は、指摘された問題を理解し、記録します。
修正・フォロー
リーダーは、レビューでドキュメントの問題が解消されたかを判断します。
必要があれば、再レビューの場を用意します。
設計者は、指摘された問題を早めに修正します。指摘内容を忘れないためです。
レビューアは、修正されたドキュメントを確認します。指摘内容について設計者から相談があればフォローしましょう。
レビューのべからずを知る
レビューでついついしがちなことの中で、気を付けたほうがいいことみたいなのを紹介します。
レビュー対象者のべからず
誤字脱字をするべからず
当たり前っちゃ当たり前なんですけど、レビューア目線だと誤字脱字が多いとレビューのモチベが下がります。
また、誤字脱字の指摘に追われて重大な問題の検出が疎かになったりすることもあります。
レビューまでに近くの人に軽くチェックして頂くだけでも効果があります。不安であれば実践しましょう。
指摘を文句と勘違いするべからず
指摘を受けると、文句を言われた気分になり、頭にきたり、逆に落ち込んでしまったりしていませんか？
指摘は自分に対しての批判ではなく、ドキュメント・設計の品質向上を願ってしています。
感謝をもって受け入れられるとよいと思います。
レビューアのべからず
私情を持ち込むべからず
キライな人にはきつい言葉で、無駄に指摘出したりしてませんか？
そこには価値は生まれないので、システムの価値に照準を合わせるようにしましょう。仕事ですよ。
作成者気分になるべからず
例として、「ミスばかり目に付くな。。。全部指摘するより自分が作り直した方が早いわい」みたいな。
自分が作ったら誰がレビューするの って話もあります。
重大な問題を説明する力をつけるチャンスと思いましょう。
本当に作り直しが必要なら打ち合わせを設けましょう。
脱線するべからず
レビューをしていると、別の問題が浮かんで話が脱線することがあります。
重大な問題のための脱線もあると思いますが、本来のシナリオがないがしろになることを避けるようにしましょう。
重大な問題でないならなおさら脱線は避けるようにしましょう。
個人を責めるべからず
「こんな設計だなんて、基本ができてない」とか。
どちらもモチベや雰囲気悪くなっちゃうので、生産的な話をするようにしましょう。
意図的な見逃しをするべからず
設計者が技術力高い時に起こりがちな、信頼しているから大丈夫だろうという見逃しです。
協力して品質高くしていきましょう。
振り返りを行う
プロジェクトなどは振り返りを行うことがありますが、レビューについても振り返りを行いましょう。
振り返る内容は、後工程で発生した問題はレビューで検出できたかと、再発防止策です。
レビューの質を継続的に高めていくことで、レビュー負荷は下がり、システムの価値は高くなります。
観点を減らす
観点を増やすだけではなくて、減らすことも考慮に入れましょう。
重大な問題を検出できない観点を減らすことで、重大な問題を検出できる観点に費やす時間が増えます。
結果として、より精度の高いレビューができるうえ、観点が減る分レビュー負荷が減ります。
おわりに
正直インスペクションみたいなかしこまったレビューはあまり経験ないのですが、
どのレベルで何をレビューされたいか、するべきかを考えると、どういったレビューを開催すべきかも選択すべきと思いました。
以上です。お疲れ様でしたー。