品質をもう一歩向上させるレビュー技法

日本の開発現場では成果物(注)を作ることが命題である。そのため成果物のミスが命取りとなるのだ。例えば、どれだけ開発が進んでいたプロジェクトであっても、仕様書にミスが見つかれば大きな手戻りが発生してしまう。そうした事態を防ぐために重要なのが「レビュー」である。
しかし、レビューを時間がないからと省略したり、あるいは時間をかけ過ぎたりすると、形だけのレビューになってしまい本来の役割を果たすことができない。本記事ではレビューの技法についてより深く掘り下げ、レビューをどのように実施するべきか、改めて考察する。

(注)ソフトウェア開発やシステム開発において、プロジェクトの工程が完了した際に成果として提出するプログラム、仕様書、設計書などのこと。

レビューの目的

レビューを実施する目的について改めて考察する。上記でミスがないかチェックすると記載したが、決してそれだけでなくレビューには以下に挙げた様々な目的があるのである。

組織やプロジェクトのマネジメント
進捗状況の確認
成果物の改善、問題箇所の排除
関係者間の合意形成
参加者の教育

このように、レビューは成果物の確認だけでなく、多くの目的が含まれているのである。
管理者からレビューを考えると、正しい方向に進んでいるかという点やどれだけ進んでいるかという点を把握することができる。
また「参加者の教育」という点では、レビューがチームメンバーを育てる上で大きな役割を担っていることを示している。自身が提出した成果物を改善する以外に、他のチームメンバーの成果物を評価した場合、その評価点、問題点を学ぶことができ、成果物が洗練されていくという大きなメリットがある。
レビューを実施するにあたって目的を理解しているか、していないかで、レビューに対する意識やその効果が大きく変わってしまうだろう。

レビューを実施する際に注意すべきこと

レビューを実施するにあたって、注意しなければならないことがある。これはどのレビュー技法を採用したとしても共通して行うべきことである。

適切な参加者を選ぶ

レビュー対象の成果物に対して広く深い知識を持つレビューアを選ぶ必要がある。そうでなければ期待されるような指摘や意見は得られず、お互い徒労に終わってしまう。
事前に資料配布やスケジュール調整をする

レビューアも忙しいため、時間を有効活用できるような準備を行うと良い。難しいようであれば、後述するレビュー技法などを用いてうまく実施できるように調整すべきである。
レビュー中は問題点の指摘にとどめ、修正方法や修正内容まで議論しない

修正方法などを議論するとかなりの時間を要してしまう。レビューアは問題点の指摘のみを意識するとよい。これはレビューア全員が意識していなければならないため、司会者が毎回始めに宣言すると良い。
レビューで指摘された内容を議事録に残す。

レビューで指摘を受けたことを聞くだけでは忘れてしまう。議事録を残し、いつでも再確認できるようにするべきである。レビューは目の前の問題解決だけでなく、その後同じような問題を起こさないという意識を持つべきである。
レビューで指摘された箇所はすべて対応しなければならない

問題点の修正を自身の判断のみで対応するかどうかを決めてはならない。指摘された点は自分の判断ではわからなかった箇所であるため、きちんとすべて対応するべきである。

良く用いられるレビュー技法

レビュー技法とはレビューを効率よくかつ効果的に進めるためのものである。その内容は公式なものから非公式なものまで様々である。そのため、レビューを実施する際には目的に沿ったレビュー技法を選択する必要がある。
ここでは非公式なものから公式なものまでを順に列記した。実際にレビューを実施する際の順序とも対応している。

アドホックレビュー(最も非公式)

常時頻繁に実施されるレビューであり、即席レビューとも呼称される。アドホックレビューと名前はついているものの、近くの同僚などに質問するというような簡単な質問のことを指す。目前の問題を解決するために実施するものであり、客観的な意見や解決策を得るために実施する。個人の問題解決には適しているものの、チーム全体の問題解決には適さない。またレビューアが毎回当事者ほど事態を理解しているわけではないので、得られる意見や解決策の精度は低い。
ピアレビュー

ピアレビューの「ピア」とは、同僚を意味する。つまり、同僚と気軽に声をかけて実施するレビューの総称であり、上記のアドホックレビューもこれに含まれる。ピアレビューでは、技術的な問題の指摘に焦点を当て、成果物を対象に同僚によって実施される。その効果として、技術者間のスキル共有とコミュニケーションの促進が挙げられる。
成果物の問題発見に長けたレビューアがレビューを実施する場合はピアデスクチェックと呼称され、教育的効果も期待される。これらのレビューは作成者とレビューアの二名で実施される。
パスアラウンド

レビュー対象となる成果物を複数のレビューアに配布、回覧を行うことである。メールやグループウェアなどを活用し、同じ時間、場所に集まらないことが特徴である。レビューアとの距離が離れている場合や、忙しく時間が取れない場合に有効である。成果物にコメントを書きこんで返送することもパスアラウンドの一種である。
このレビューでは基本的にレビューアが複数名で行われる。しかし対面での意見交換が行えないため、可能であれば対面でのレビューを優先して実施するべきである。
ペアプログラミング

二人が並んで一つのPCを共有して交互にプログラミングを実施する方法である。メインでタイピングを行う人をドライバー、指摘や助言を行う人をナビゲーターやオブザーバーと呼称される。ドライバーと比較してナビゲーターの方がプログラミングのスキルが高くなければならない。教育的意味合いが強く、ドライバーはオブザーバーと対話しながらプログラミングを進めることで、新たな知識を取り入ることができ、技術向上につながる。また常に作業するコードをチェックするため、視認性の高いコードを作成する意識を持つようになる。
生産性に関しては、二人が別々でプログラミングを実施する場合と比較して１５%程度しか低下しないという研究結果が報告されている。しかし、作業能率が低下することに代わりがないので、実施するには顧客やマネージャーから理解を得る必要がある。
ウォークスルー（公式なレビュー）

ウォークスルーはもともと演劇用語で、「気楽に行う立ち稽古」という意味がある。ここから、チームメンバー自身が自主的に点検を実施することをウォークスルーと呼称されるようになった。これより下は公式なレビューとして分類される。
会議室などでレビューアが机上でシュミレーションする形式であり、成果物を元に問題を発見する。参加人数は数人で、時間は一回当たり三十分から一時間程度が望ましい。少人数、短時間でフットワーク良く問題発見を行うのが、ウォークスルーのメリットである。
ウォークスルーを実施する際は、対象の成果物に対して参加者が質問やコメントする形で進められる。このため、障害発見のためだけでなく、成果物に対する参加者の理解促進や、問題に対する解決策のアイデア提案にも活用される。実施方法や記録方法に明確な決まりはなく、様々な実施形態がある。
ラウンドロビンレビュー

回転式レビューとも呼称される。レビューのために発生する作業を分担し、参加者全員が順に司会者とレビューアの役を持ち回りで行う技法である。全員が司会者とレビューア両方の視点でレビューを実施することで、レビュー対象への理解を深めることができる。また、様々な異なる視点や技術を所持するレビューアが実施すると最も有効である。他のレビュー方法と組み合わせて用いられることもある。
チームレビュー

その名の通りチームで実施するレビューである。一般的にイメージされるレビューはこのチームレビューのことを指す。チームが担う機能やシステムの品質を確保するために、成果物を対象に実施する。障害や不明点の排除という目的のほかに、チーム内での知識共有、チームメンバーの教育などの効果が期待できる。
インスペクション(最も公式)

ソフトウェア中の問題を検出するために、事前に定められた観点で第三者が厳密に点検して、欠陥の指摘や認定を行う。標準や仕様から外れた例外、文書化された標準からの逸脱や仕様から見た障害を発見する技法である。最も公式なレビューであり、必ず完成された成果物に対して実施される。
手順が明確に決まっていることが特徴であり、チェックリストなど形式的な文書に基づいて実施される。また参加者の役割が明確に決まっていることも特徴の一つである。
成果物が完成して、すぐにインスペクションを実施し、その成果物が含んでいる障害を発見することで、少ない手戻り工数で修正することが可能となる。加えて、レビューを詳細に記録することで、障害の原因となった開発プロセスの改善することができる。