Software Quality.com

■前提となる考え方■
レビューは、ソフトウェアテストと同様に欠陥を除去する手段の一つです。
しかも、ソフトウェアテストよりは上流で実施されるものなので、有効な欠陥除去手段となり得ます。
ただし、間違って欲しくないのは、「レビューで欠陥を出せばよい＝設計はほどほどに仕上げて、レビューに出せば欠陥は除去できる」という誤った考え方です。
この考え方では、いい加減な作業はそのまま残るため、設計品質を向上させることにはならないでしょうし、手戻りが多くなるため生産性も上がりません。
最終的にはレビューに頼るのではなく、むしろ、設計作業時に「欠陥を作り込まないようにすること」に注力するべき です。
そのためには、設計作業時に十分なコミュニケーションを取り、レビュー開始前までにほとんどの欠陥が作業者によって除去されている状況を実現することが必要になります。
「設計時の十分なコミュニケーション」には、設計作業者や関係者による「非公式なレビュー」の積み重ねも含まれます。
若手作業者とベテラン作業者による、コミュニケーションが有効であれば、設計品質の向上につながるばかりか、若手作業者の育成にもつながり、相乗効果が期待できます。

 

■効果を高める要因はありきたりのこと■
雑な仕事、やっつけ仕事に多いのは、自らの作業を自分ではほとんど確認せず、表面的に出来ていると思ったらすぐに承認者や了解を得るべき管理者に持ち込むことです。
結果的に大きな手戻りが毎回発生します。
「もし何かフィードバックがあれば、指摘されたところ、言われたところだけ直せばいいんだ。そうすれば俺は楽だし。」的な当事者意識のない方が良くやる手口ですが、この方法を続けている限りその本人の能力向上や一人立ちはありえませんし、それよりも最悪なのは、寄りかかられた管理者や承認者の負荷が高まり、その技術者は一人立ちしないまま手戻りが繰り返され、大きな手戻りばかりで自らやる気をなくし・・・・結果として組織のトータルパフォーマンスが低下してしまうことです。

そういう意味で「入念な自己確認、机上チェック＝自分の仕事に責任を持つこと」はありきたりのことですが非常に大切です。
もちろんこれは、自分で作業結果を確認できるだけの「切り口」をたくさん持っている状態（能力が高い状態）にならなければ実現しません。
これがしっかり出来ていればレビューは最も効率的になります。
このことを過小評価しないことが大事ではないでしょうか。
デバックツールでちょっとずつ動かしていくよりも、プリントアウトされたリストを自ら細心の注意を払って調べる方が多くの欠陥が見つかるものです。
特に自ら欠陥を発見する技術の高い同僚がいる場合や、時間とリソースの制限が厳しい場合、低リスクの作業成果物である場合には自己チェックが有効な手段となりえます。

補足：最初の事例において少々厳しい見方かもしれませんが、そもそもやる気のない要員はチームに入れるべきではありません。
当事者意識のない、周囲の人たちにもたれかかるだけの技術者は周囲の迷惑のことも考え、自立する努力が不可欠です。

 

■レビューの種類と目的■
レビューは、その目的によって対象物や実施内容が異なります。
大きく分けると「管理的側面のレビュー」と「技術的側面のレビュー」に分かれますが、両方を一度に確認する事もあり得ます。

・主な目的

対象となる成果物に求められる要求事項が満たされているかを確認すること
　　存在する欠陥や問題の除去
　　欠陥・問題の混入予防

 

副次的な目的として
　　関係者間で成果物への理解度向上
　　レビュー対象物の内容に対する認識の共有
　　エンジニアの検証力向上

 

・管理的側面のレビュー
進捗状況（スケジュール・コスト・リソース使用実績等）確認や工程終了確認、管理ポイントや問題事項対応に対する意志決定に資する

・技術的側面のレビュー
成果物（計画書・設計書類・コード・プロトタイプ等）を対象とし、品質向上に資する（設計の考慮漏れをなくす）
その他に、共通設計の中味を参加者に理解させる、若手の教育などの副次的な目的が含まれている場合もあります。

 

■レビューでの禁止事項■

・レビューでの指摘事項を個人の能力評価の参考にする
→評価対象は「人」ではなく「成果物」。特に技術的なレビューでは管理者をレビューアにしないこと　と言われている。

・レビューで議論する
→レビューは議論の場ではない。
　作業過程で議論をした結果が成果物に反映されて、レビューの対象となるようなプロセスを踏むことが必要。

・レビューを責任の追及の場にする
→問題外

・レビューアには身近な仲間だけを選ぶ
→好き嫌いでレビューアを選択すると、指摘されるべき問題点が出なかったり、傷のなめあいになることが多い。目的を果たさない可能性が高い。

 

■レビューへの誤った認識■
・レビューとは、「技術的側面」だけに対して行うもの。
・レビューはとにかくやればいい。
・沢山の人が集まればレビューは効果が出る。
・決着が付くまで何時間でもレビューを実施する。
・レビューの観点は、作業者が決めると良い。
・すべて一人で作業をするのだから、第三者によるレビューはやってもムダ。
・ちょっとした修正対応であれば、レビューは必要ない。

 

■レビューで目指す効果は状態で異なる■
レビューをほとんど実践できていない組織が、レビューに取り組み始めて最初に起こることは、レビュー対象の成果物に多くの欠陥が組み込まれていることに関係者が気がつくことです。

ですので、まずレビューで目指すのは「対象成果物の欠陥をできるだけ検出し、除去すること」になります。

レビューを継続すると、関係者の目が肥えてきますので、レビューで検出できる欠陥数が増えていきます。

しかし、これを継続していくと、ある時期にレビューで検出できる欠陥数が伸びなくなり、最終的には減少することになると想定されます。

 

このような状態になってもあわてないでください。

落胆する必要もありません。

このような状態はむしろ喜ぶべきですし、レビューで目指すものを変える時期に来たと考えてよいはずです。

 

レビューを継続して実施することを通じて、「レビューで欠陥を指摘する能力」が向上するだけでなく「作業過程で成果物に欠陥を作り込まない能力」も向上していきます。

ですからレビューで検出される欠陥数が減少してくるのです。

 

では、このような状態になったら何を目指してレビューを実施すればよいのでしょうか。

いろいろな考え方があるとは思いますが、いくつかの指標を示しますので参考にしてください。

 

・単位時間あたりの欠陥検出数を向上させる

・開発全体の中でレビューの欠陥検出比率を向上させる

・より内容の濃い欠陥指摘件数を向上させる

 

■レビューの本質的な意味

(1)レビューとは、異なるメンタルモデルを持つレビューイとレビューアのモデルのすりあわせである。

言葉を換えると、成果物に対して作成担当者＝レビューイが持つ視点とレビューアが持つ視点を提示し合い、最終的に統合するための場である。

(2)成果物の内容に対して、レビューイとレビューアが同じ認識、同じイメージを共有するための場である。

(3)レビューの本当の対象物は、成果物ではなく、成果物を作成した担当者＝レビューイの（成果物作成時の）思考、イメージ、認識、理解の度合いである。

 

■レビューの対象物（例）■
「○○を対象にしなければならない」というモノは一律決められていないと思います。
下記は一般的な例です。

　・見積結果
　・プロジェクト計画内容
　・プロジェクト進捗状況
　・プロトタイプ（実現可能性調査結果の評価）
　・各種設計書類
　・コーディング結果
　・テスト計画
　・テスト仕様
　・操作説明書類

他にもあるでしょう。
ここで大事なのは、「対象物」を直接持ち込んで確認することです。
設計作業者へのＱ＆ＡだけでOKを出すのではなく、対象物の内容（記述・表現された内容）で確認します。
また、レビュー対象物の内容確認の際に比較元情報を使用する場合があります。
これは「設計へのインプット」情報を指していますが、これらの情報もレビュー現場に持ち込んで、実物同志を直接比較することが必要になります。人（作業者）の記憶や考え方に頼るのではなく、その人の考えに過不足や思い違いがないか？　そしてその考えがレビュー対象物に確実に反映されていることを、「実物」で確認するのです。

 

■レビューで検出しやすい事項■
レビューは、実際にマシン実行によって確認するテストにくらべて以下の事項を検出しやすいものです。つまり、テストではこれらの事項を検出し難いということになります。
少なくともテストを実施する前にこれらの事項をレビューで検出し対応しておくことが開発作業で必要になります。

　・要件・機能・処理の抜け
　・コーディング規則の不遵守
　・要件・設計の欠陥
　・インターフェース仕様の不正

 

■レビューの開始基準■
レビューの効果を確実に獲得するために、レビューの開始基準を満たした場合にのみレビューを実施することが必要です。
一般的なレビュー開始基準事例を示します。

・レビュー対象物のソース、仕様の先行作業成果物は、前工程のレビューに合格済みでベースラインが設定されていること
・テキスト文書はスペルチェック＋誤りを修正済みであること
・レビューのモデレータが事前確認した際に著しい品質問題や誤りがないこと
・初期作業成果物は関連する標準、テンプレート、書式の要求（があれば）に合っていること
・文書またはコードにはページ、行番号等の識別子が設定されていること
・参加者全員がレビューの訓練を受けていること

レビューを開始してみたが、レビュー対象物の質が著しく悪い場合には途中で取りやめにする、などの工夫も必要です。
メンバーに「開始基準を守らないとだめなんだ＝自分でしっかり仕上げてこなくちゃ」という認識を獲得でき、さらにレビューに参加してくれている要員の無駄時間を浪費しないで済む、などの効果も期待できます。

 

■レビュー参加者■
レビューへの参加者は、レビューの目的や対象成果物によって適切な人を選択する必要がある。　
　・成果物を作った作業者（必須）
　・プロジェクトメンバー
　・管理者（進捗管理中心）
　・特定分野の専門家、有識者

　　（業務知識・特定のアプリケーションドメイン等）
　・顧客、エンドユーザ
　・営業担当者　　　　　　　　他　

 

 

レビューを成功させるために、これまで発表されてきた実績指標（＋数値）の代表的なものを記載しておきますので参考にしてください。

・レビュー時間：1回2時間以内にする
　それ以上になるレビューは数回に分けて行う
・レビューアが疲れているときは実施を避ける
・参加者は3～5名（多くても7名まで）程度に抑える
　それ以上ではロスだけが多くなる
・文書類なら１時間に3~4ページ程度
　コードなら１時間に150～200LOC程度
　　　　の速度でレビューするのが適切

 

※これらの数値は参考にするのまではよいですが、絶対視しないように。数値だけで判断できるような機械的な対応は避けるべきです。数値では表現できない”内容”が重要ですのでご注意ください。