設計や実装、テストなどにおいて、その成果が正しいのかどうかを確認する作業がレビューです。
このレビューは、悪の根源とも呼ばれるほど、非常にやっかいな存在であることは、あなたもご存知だと思います。
本来レビューは、思い込みによる誤りや漏れなどを事前に見つけ、ユーザーの目的を達成させるために軌道修正を行うべき作業です。
しかし、そのほとんどが、軌道修正することなく、さらなる脱線を助長しているのです。
今回は、品質向上のためにはかかせないと思われている「レビュー」がいかに悪なのかについて考えてみたいと思います。また、どのような思考であれば、本来の役割を果たすことができるのかも考えてみましょう。
レビューはなぜ悪なのか？
レビューの目的は、ソフトウェアの品質を高めることです。
システム開発の工程やQCDとはどういうものかを理解するでも書きましたが、品質とは、QCDの「Quality」にあたるものです。
システム開発は、ユーザーの要望を目的として、Quality（品質）、Cost（予算）、Delivery（納期）をどの工程においても、意識させることが重要です。このどれかが逸脱しても成功はありえないのです。
ですので、品質を向上させることは、システム開発成功の鍵を握る根幹をなすものなのです。それほど、重要なものの一つです。
その品質向上を目的として行われる手段として、「レビュー」が存在するのです。
ですから、各工程でレビューをすれば、品質は向上すると勘違いをするのです。
システム開発の現場において、レビューによって、成功したというプロジェクトがどれほど存在するのでしょうか？
ほとんど聞いたことがありません。
確かに、レビューをしなければ、もっとひどい事態になるのかもしれません。
しかし、勘違いしないでいただきたいのが、レビューをするから品質が上がるわけではないということです。
なんでもかんでも、形式的にレビューの場を開き、レビューを行えば、品質が勝手に上がることなどないのですから。
さらに、レビューは、とても工数を消化してしまいます。
例えば、関係者が１０人いて、２時間くらいのレビューを行ったとします。そうすると、これだけで、２０時間分の工数が消化されます。ざっと、１人あたりの３日分を使ってしまうことになります。
そして、指摘が多数あり、再レビューをすることになれば、修正する時間と再レビューの時間でさらに工数が膨らんでいきます。
この指摘事項の大半が、誤記や字体、色の使い方などの書式レベルの指摘、分かりづらい表現などの改善等です。
明らかに、障害（バグ）であれば修正をしなければいけませんが、表現の修正などは、再レビューするほどではないはずです。
レベルの低い人たちは、誤記を指摘してかなり鼻高々になります。指摘してやったぜとふんぞり返る勢いです
。
このどうでもよいことに約１週間もの無駄な時間を消化ではなく、浪費してしまうことになるのです。
進捗が遅れるのは当たり前です。
これらのことから、レビューは何も生産しないということです。そして、ユーザーの目的を果たすためではなく、自分たちのプライドや威信をかけて戦うことが目的になっているのです。
はっきり言いますが、ユーザーの目的を果たすためのレビュー以外は行う意味はありません。無駄でしかないのです。それ以外のレビューは何もメリットがありません。つまり「悪」ということです。
誤記や表現の修正などは、テストが完了したあとに落ち着いたタイミングでゆっくり行えばいいだけなのです。あとで見返せば、レビューしなくとも、自分で気づくことも多々あるのですから。
品質を向上させるレビューとは？
それでは、ユーザーの目的を果たすためのレビューとはどういうものでしょうか？
ずばり、ユーザーが喜ぶかどうかをチェックするということです。
画面でデータを入力させる位置はここだとわかりづらいから、こっちのほうがいいのではないかとか、ボタンの色をもっと目立つ色にした方が誤操作しにくくなるのではないか、など。
ユーザーの視点に立ったチェックをしていくということです。ここでは誤記などは、問題にしていません。
もちろん、画面に表示されるメッセージが誤記で間違っていたなら、これは指摘されるべきものです。ですが、これは誤記ではなく、障害（バグ）になるものです。分かりますか？この違い。
例えば、画面項目にお客様番号と氏名の欄があり、両方入力したあと、確認ボタンを押下することで、確認画面へ遷移することを想定していたとします。
どちらか一方が未入力の場合、その項目名を表示させるものとします。
そこで、お客様番号が未入力、氏名は入力済で確認ボタンを押下したら「氏名が未入力です」と表示されました。これは誤記ではなく、障害（バグ）であることが分かると思います。
通常、設計書等で誤記と指摘されるレベルとしては、「エラーの場合、メッセージを画面に表示さる。」などのように、明らかにおかしな表現だというのが分かるものです。
これは、「エラーの場合、メッセージを画面に表示する。」が正しいです。
どうでもいいと思いませんか？最終的には当然、このままでよいわけではありません。これらも含めて最終的な品質につながりますので。
ですが、開発の途中で修正すべき内容の優先順位を見誤らないでください。誤記は優先順位は高いですか？
障害（バグ）は優先順位が高いのです。
ですから、この優先順位の高いものをチェックするのが品質を向上させるレビューになるのです。
優先順位の低いものをチェックするレビューは、時間を無駄にするだけで、何もメリットがありません。
忘れないでいただきたいのは、レビューは、その想定でユーザーが喜んでくれるか否かを基準にチェックすることが本来の目的です。この思考が優先順位の高いレビュー項目なのです。
ユーザーにとって、どうでも良いことに時間をかけることは、もうやらないでいただきたいものです。
カテゴリ：品質管理
