ソフトウェアのレビュー

ソフトウェアの開発において、レビューが品質の確保をするために有効であることは私達は直感的、経験的に理解しています。
人は間違いを犯しますし、間違った本人よりも他人のほうが誤りを見つけ易いものです。

ここまでは、認識を共通できるものでしょう。
しかし、レビューと一言で言った場合に、その実態にかなりのギャップが生じます。

ある人にとっては、気の合う同僚とコーヒーでも飲みながら成果物をチェックしてもらう事かもしれません。
しかし、別の人にとっては会議室で衆目の前で細かい所を吊るし上げられる苦行のことかもしれません。

ある人にとっては、口で簡単に説明するだけかもしれませんし、メールやツールでコメントを書くだけかもしれません。
しかし、別の人にとっては、準備の為に大量の資料を作り、終わった後にも大量の報告書を書く事かもしれません。

プロジェクトを初めて、レビューといった場合、注意しなければいけない点として、人によって、組織によって、レビューというものに大きい差があることです。

なので、私達は最初に確認し合わなければなりません。「あなたのおっしゃるレビューってどのことかしら？」と。

レビューの種類

ジェラルド・M・ワインバーグの述べるレビュー

ワインバーグの書籍にはよく「技術レビュー」という単語が出てきます。
彼は、「パーフェクトソフトウェア」で技術レビューを次のように紹介しています。

システムのテストに知力を集結する最も単純な方法は技術レビューである。技術レビューとは、仲間がみなで集まって、コード、設計、仕様書、ユーザマニュアルといった技術製品の長所や欠点を分析し、文章化することである。

技術レビューは「情報を何らかの目的に使えるようにするために、製品に関する情報を収集する」プロセスだからである。

これらの説明を読む限り、ワインバーグの考える技術レビューを行う場合は、レビューした結果を残さなければなりません。同僚とコーヒーを飲みながら雑談まじりにやる、レビューはレビューとして認めてもらえないのです。

カール・E・ウィーガーズの述べるレビュー

次に、Karl E.Wiegersが「ピアレビュー高品質ソフト開発のために」で述べている定義を紹介します。

まず、プロジェクトでレビューと言った場合、欠陥の発見を目的としたもの以外があり、それを次の表で紹介します。

レビューの種類	目的
教育レビュー	プロジェクトに関係する技術的トピックスについて他の関係者の知識レベルを引き上げるために行う
マネージメントレビュー,準備レビュー,ゲートレビュー	上級の管理者に情報を提供して、製品のリリース、プロジェクトの継続・中断、提案の採用・却下、リソースの調整などのコミットメントの変更を決定する
ピアレビュー	作業成果物の欠陥と改善の機会を探す。
プロジェクト終了後レビュー	完了直後のプロジェクト、フェーズ終了の反省を行い、将来のプロジェクトのための教訓を得る
ステータスレビュー	プロジェクトマネージャおよび他のメンバーでマイルストーンに対する進捗、発生した問題、リスクの確認を行う

私たちがソフトウェアのレビューで想像するのは、ここで言うピアレビューのことだと思います。
Peer:ピアは同僚の意味で、同僚が作成した成果物を評価するということになります。
（成果物を評価するのであって、同僚の作業実績をみるものではありません!!)

このピアレビューは、公式度によって次のように区分しています。

公式度	名称	説明
最も公式	インスペクション	最も体系的で厳格です。作成者以外の参加者はミーティング時に役割が与えられます。モデレーターがミーティングを主導し、読み手が資料を提示して自分の解釈で説明します。そしてレビュワーが指摘した問題点などは、書記が記録します。発見された欠陥はデータとして収集して、分析をおこないます。
	チームレビュー	公式なレビューですが、インスペクションほど厳格ではありません。作成者がモデレーターを兼ねてかまいませんし、読み手の役割は存在せずモデレーターが資料を説明していきます。記録はしますが、そのデータの収集、分析は必要とされていません。
	ウォークスルー	非公式なレビューです。作成者が成果物を同僚に説明してコメントをもとめます。インスペクションがチームの品質の満足にあるのに対して、ウォークスルーは作成者の満足を求めるものです。通常、定義された手順も存在せず、記録もしません。
	ペアプログラミング	ペアプログラミングも一種の非公式なレビューといえます。
	ピアデスクチェック	机上チェック。自分で書いたものを自分で丹念に調べる
最も非公式	アドホックレビュー	即席のレビュー。つかまえにくいバグをつきとめるのに同僚にチェックを頼む行為があたります。プロセスとして組み込まれておらず、目下の問題の解決以上の成果はないです。

「ピアレビュー高品質ソフト開発のために」では当然、それぞれの詳細について記述してありますが、ここで述べるには余りにも量が多いので割愛します。
ただ、レビューという概念が一つではないということが理解いただけるかと思います。

レビューの種類のまとめ

今回は２つの解釈を紹介しました。
おそらく、ここで紹介したモノ以外の解釈や言葉の定義はあるでしょう。
本稿では、簡潔にするため、レビューの種類を次のように定義します。

・公式のレビュー: チームを主体としたレビュー。チーム内で合意した手順で実施して、記録を取ります。
・非公式のレビュー: 作成者を主体としたレビュー。特定の手順はとりません。

公式レビューの実施方法の考察

ここでは、どのような手順でレビューを行うとチームにとってメリットがあるか考えます。

いつレビューするか？

ソフトウェアのプロセスが概要設計、詳細設計、実装と進むとした場合を考えましょう。
前の工程で通過してきた欠陥は、次の工程でx倍に増幅されます。
これは当然で、誤った前提で作業を行えば当然、間違えますし、後の工程ほど作業量は多いので、欠陥は確実に増幅されます。
もし、後工程に渡す前にレビューをした場合、レビューが欠陥のフィルター機能として働き、後工程の欠陥の発生を抑止する事が期待できます。

なにをレビューするか？

理想をいうなら「全て」でしょう。
しかし、それは工数的に難しいかもしれません。

ワインバーグは「最悪を最初に」を基本としてレビューすべきだと述べています。
たとえば、アルゴリズムに欠陥があるのに、スペルミスにこだわってもしょうがありません。
なにが最悪かを考え、それを防ぐための物からレビューをします。

また、カール・E・ウィーガーズは「誤りが製品全体に影響し、手戻りのコストが高くつく、あるいは失敗するようなリスクがないかを考慮にいれてインスペクションの対象を選択してください」と述べています。
たとえば、基本的な初期フェーズの文章（要求仕様書）や、クリティカルな決定の基礎になる文章、繰り返し使用されるコンポーネントなどです。

他の選択基準として、「Code Craft」では次の例を上げています。

複雑度を分析して、複雑度の高いコード
バグの発生率が高いコード
中心となるコンポーネントの中核コード
信頼できないやつの書いたコード

レビューミーティングの開催

少なくとも、作者、書記、そしてミーティングを主導する司会（インスペクションでのモデレーターの役割）は必要です。
参加人数は、最小限にしておいたほうがよいでしょう。船頭が多いと山を登ることになりますし、リソースの無駄使いになります。
参加者は事前準備が必要ですが、一人２時間を超えないようにしたほうがいいです。
ミーティング自体の開催時間も２時間以内がいいでしょう。

ミーティング自体が不要ではないかという意見もあります。
たとえば、メールですませたり、Reviewboardなどの支援ツールを使用する事でミーティングを行わなくてすむかもしれません。
開発メンバーが時差のある場所に点在している場合は、魅力的な選択にみえるかもしれません。

しかし、ミーティングは開催したほうがいいと思います。
なぜならば、ミーティングには、相乗作用があります。
１人の観察が他の人の思考を刺激する格好で、ミーティングの最中にレビュアー間に相互作用が働き、その結果新しい問題が発見されることがあります。
インスペクション手法を開発したMichael Faganは、この相乗作用を「Phantom Inspector」と呼びました。

レビューの心得

作成者は、恐れないでください。
レビューは罰ゲームではありません。
レビューをしてもらうことで新しい知識を学ぶチャンスであります。
同僚は貴方の敵ではないです。彼らが指摘しているのは、共に解決すべき問題であり、貴方自身ではありません。

レビュー担当者は人ではなく成果物を批評してください。
そして、自身に謙虚になり、作成者に敬意を持ちましょう。

１からつくるより、批評する方が楽です。
できあがってしまえば、簡単にみえますが、実際やるのと、見るだけでは違います。
（ホラ、野党の時、威勢のよかった政治家が、自分の政権でどうなったか、私たちは知っているはずです！）

どんな酷いコードにみえても、相応の苦労があったので、そこは敬意を払うべきです。
そして毎回、建設的で有意義な意見を述べるように努力してください。

レビューの記録

発生したレビューの結果は記録する必要があります。
指摘事項はRedmineやTracのチケットとして登録し、議事録をWikiに記述するのもいいでしょう。
あるいは、ReviewBoardなどの専用のツールを使用するのも選択肢の一つです。
これらのツールについては下記を参照してください
コードレビューのツールについての調査
http://qiita.com/mima_ita/items/150043dea467c5842b49

可能であれば、レビュー対象の情報（複雑度やステップ数）、レビューに使用した工数と、検出した欠陥数は記録しておきましょう。
今後の見積もりや、レビュー自体の見直しに利用できます。

しかし、レビューの欠陥報告を個々の開発者の業績評価のデータとして利用するのは避けてください。
自分が報告したデータのために、自分あるいは同僚が罰せられたが最後、管理者に正確な情報を報告しなくなります。
可能であれば、プロジェクトメンバー間だけの共有情報として扱うべきです。
もし、それが難しいなら、データの集計をサボったほうがマシです。（データはなくても製品は作れますが、チームメンバーが正しい報告をしないと製品は作れません！）

レビューのガイドラインの作成

レビューを行う際は事前にガイドラインを作成し、メンバーの同意を得た上で行うべきです。
ここではガイドラインの例を紹介します。

「実践ソフトウェアエンジニアリング」でのガイドライン

ロジャー・S・プレスマンは「実践ソフトウェアエンジニアリング」で、最低限のガイドラインとして次のものを上げています。

人ではなく成果物をレビューすること。
議題を設定し守ること
議論と反論を制限する事。（全員の同意が得られない時に、その場で議論しないで別の機会に討議するべき）
問題は明確にするが、すべて解決しようとしないこと。
ノートをとること
参加者を制限し、事前の準備を義務づけること
レビューする成果物毎にチェックリストを作成する事
公式技術レビュー実施するためのリソースとスケジュールを割り当てること
レビュー担当者全員に教育訓練を実施すること
初期のレビューはレビューすること。（ガイドライン自体レビューしろ）

レビューとインスペクションの指針となる原則

カール・E・ウィーガーズは「ソフトウェア開発の持つべき文化」でレビューとインスペクションの指針となる原則として次のことを提唱しています。
・エゴは入り口で預けてしまうこと
・作者でなく成果物を批評する事
・インスペクション中に問題を修正しようとはしないこと
・インスペクションの会議は最長２時間までにすること
・パフォーマンスやわかりやすさに影響を及ぼさない限り、スタイルの問題は差し控えること
・早い時期から頻繁に、公式でも非公式でもレビューを行うこと。

考察

ここであげたガイドラインや原則は一例でしかありません。
他の書籍を見れば別の例が出てくるでしょう。

しかし、残念なことに私や貴方の組織にピッタリと適用できるガイドラインは存在しないでしょう。
第一、他人が作った基準やガイドラインに喜んで付き従える人は中々いません。

ここは面倒でも、自分自身の組織と文化にあったガイドラインを自分たちで合意を得ながら作り、保守していくしかありません。

レビューの文化

ここまで、公式のレビューについて考えました。
しかし、多くの場合、レビューの文化自体がない事があります。

その場合は、レビューを行う文化を築くことが優先になります。
先にあげた項目を一気に適用するのは、無理です。
非公式で十分なので、レビューを行う文化を作りましょう。

まずは、自分の成果物を人に見てもらいましょう。
次に、他人の成果物をチェックしましょう。
この時は、クールなコードは賞讃したり、新しいことを伝授したりして、レビューを受ける人間がレビューが自分にとってメリットであると認識させましょう。

参考文献

ソフトウェア開発の持つべき文化
http://www.amazon.co.jp/dp/4798108715

ピアレビュー　高品質ソフトウェア開発のために
http://www.amazon.co.jp/dp/489100388X

実践ソフトウェアエンジニアリング
http://www.amazon.co.jp/dp/4817161485

Code Craft
http://www.amazon.co.jp/dp/4839921946

Perfect Software
http://www.amazon.co.jp/dp/B00EQ25B1Q