ソフトウェアの世界においてレビューは既に一般的なツールとなってますが、（主に）社内を鑑みるに現状でこの力を十分に生かせてとは思えません。今日はこのレビューについて書きたい思います。

 そもそもレビューとは

 「レビュー」の意味をwikipediaで調べてみると以下となっています。

英語で評論、論評などを意味する。科学的研究の過程として、当該研究テーマに関する先行研究について文献の探索を行うこともレビューと呼ばれる。また、そうした先行研究を網羅的にまとめ、その当該テーマについての研究の動向を論じた展望論文をさすこともあり、そうした論文を掲載する学術雑誌のタイトルにも使われる。Psychological Review（心理学関係の展望論文誌）。カタカナ語としても使われる。 

一般的に使われているレビューとは少々異なるようです。一般的な「レビュー」の意味は 「ピアレビュー」の方が近いと思われます。ピアレビューいついてもwikipediaで調べました。

査読（さどく、Peer Review　ピア・レビュー、場合によっては審査（しんさ、Refereeing）ともいう）は研究者が学術雑誌に論文を発表する際、あるいは研究助成団体に研究費を申請する際にとりおこなわれる過程である。

そもそも私がレビューに興味を持ったのはある人から1冊の本を薦められたことがきっかけでした。それは、『ピアレビュー―高品質ソフトウェア開発のために』です。ソフトウェア開発におけるレビューの大切さについて書かれた本で、レビューがもたらす効能やプロジェクトにレビューを導入する手法などについて書かれた良書です。この本は恐らくほとんどの人が良書と判断すると思われるほど良質な内容が書かれており、かつ章立ての構成や話の流れ、例の引用など細部に渡ってよく練りこまれています。それだけだと単なる良書で終わるところですが、私がこの本に見せられたあるフレーズがありました、それは「ピアレビューはソフトウェアのみならず全ての分野で適用可能です。実際この本はピアレビューによって完成しました」というフレーズです。つまり筆者は「この本の品質が高いのはピアレビューを用いたからだ」と主張していました。同書籍は私としてはこの上ない良書であったためこの本を完成させたピアレビューは必ず高い効果を持っているに違いないと考え、同書籍に書かれているピアレビューについて学び始めました。

書籍の内容についてはいつか書籍批評として書きたいと思っていますので、今回はレビューをどのようにプロジェクトに導入したかについて書きたいと思います。プロジェクトにレビューを導入するに当たってやったことは以下です。

1. レビューの意味を定義する
2. レビュー対象物を定義する
3. レビュー方法を定義する
4. レビューフローを定義する

上記は凄く重要です。私はMTGを開いてメンバからレビューの導入可否についてヒアリングを行いましたがそこでわかったのは「レビュー」のイメージが人によって驚くほどバラバラだという事実です。ソフトウェア業界でレビューと言えばなんとなく、「皆で成果物を見て意見を交換すること」というコンセンサスがあると思い込んでいましたが、それは幻想であることに気付かされました。

そもそも何のために見るのか？

• え、勉強のためでしょ
• 品質を一定に保つためじゃないの？
• 抜けが無いかチェックするためでしょ？ 

何を見るのか？

• ソースコードに決まってるじゃん
• ソースコードより要件定義書でしょ
• 設計こそ重要なんじゃないの 

いつ見るのか？

• 成果物ができてからでしょ
• 成果物ができてからでは手戻りが多い、やるなら作業着手前だよ

どうやって見るのか？

• MTG開いてみんなで見るんじゃないの？
• それだと時間がもったいないし全員が見る必要あるの？
• 印刷物配布してペン入れすれば集まる必要ないよ
• 遠隔の作業者の場合どうするんですか？ 

上記など一部の例に過ぎず、ちょっと話しただけで意見の多様性が満載です。単純にレビューを取り入れようとしていた私は意識統一の重要性を痛感し、例によって法整備を行い始めました。結果、上述の４項目を決定すればメンバが迷い無くレビューに取り組めることがわかりました、私はこれをレビュー規約と呼んでいます。レビュー規約ができた後のレビューの実施は非常に簡単なものでした。PMである私がメンバにあるタスク依頼する際にセットでレビュアーを任命すればいいのです。この場合タスクを頼まれた人をレビュー依頼者（英語でなんていうのでしょう・・）、レビューを頼まれた人をレビュアーと呼ぶことにします。レビュー依頼者とレビュアーはそれぞれ以下の責任を持たせました。

レビュー依頼者

•  PMから依頼された作業に対する作業依頼書の作成（レビューを実施するにあたり補足資料が必要な場合はその作成）
• レビューターゲットの明確化
• レビューオーナーである場合はレビュー形態を含めたレビュー開催のアナウンス
• レビュー議事録の記載とアナウンス

レビュアー

• レビュー依頼者とレビュー形態と日程の調整
• レビュー依頼者によって準備された資料の事前確認
• レビュー（＝成果物、方針の査定）
• レビューを受けての改善アドバイス（可能であれば）

その他にも様々な取り決めがありますが骨子は上記のような感じです。このレビュー規約のおかげで今ではプロジェクトにレビューの文化が根付き始めています。実際にレビューの導入によって品質が向上したかどうかは、不具合・障害発生率が下がったことを計測する必要があるためもう暫くしないとわかりませんが、現場からは早くも「レビューを導入してよかった」、「成果物がすっきりして良かった」などの声が上がっています。今では皆さんにもレビューを進めたい気持ちでいっぱいです。