様々なソフトウェア開発を経験してきた視点から、開発、マネジメント、経済などについて書いています。タイトルは、あるレトロゲームからのオマージュ。ツイッターアカウントはこちら。同僚同士や同じプロジェクトの開発者同士で行うレビューのことです。プロジェクトは規模が大きくなるに従い、ドキュメント量、コード量、要求の量が増え、また、情報の伝達、把握が難しくなるため、レビューの重要性は増していきます。レビューに慣れていない組織だと、以下の二択になってしまいがちです。レビューをせず、余計な手戻りコストを払うレビューにコストをかけすぎて、効率を落とすレビュー文化のない現場に、レビューを持ち込むのは意外と難しいのです。「人の目によるチェック」は、簡易的なものも含めて、すべてレビューになると思ってください。種類も、簡易的で低コストな方法から、厳密で時間をかけて行う方法まで色々あります。余計なコストを掛けずに、最大の効果を得ることができます。アドホックなレビューパスアラウンドピアデスクチェックウォークスルーインスペクションアドホックなレビューミーティングの最後に書記「今日の議事録は、こんな感じでいいかな?」などと、参加者全員で議事録をチェックすることがあると思います。これも、一種のピアレビューになります。大きな誤り、認識の間違いなどがないか、簡易的にチェックする方法です。計画も、事前準備も、ほとんど不要なためみんな、ちょっと10分ほど時間もらえるかな?見てほしいものがあるんだけど。言って、急遽開催することも可能です。厳密さがあまり要求されない文書などにしか使えません。開発者同士でしか共有しないものが多くあると思います。細かな間違いがあっても、訂正が素早く行える、もしくは影響範囲が小さい場合には、このような簡易的なレビューでも十分効果を得られます。デメリットは?このようなレビュー方法は、「レビューされたか否か?」「誰がレビューしたのか?」という情報を基本的に残しません。顧客や部外の人に見せる資料などには、不向きであることが多いです。パスアラウンド多数または不特定多数の人に成果物を配布し、レビューを求める方法です。電子化された文書では、よく行われる方法だと思います。間違いがあれば、X月X日までに訂正コメントをお願いします。いった感じの通知が、開発現場では、よく飛び交っていました。品質によるリスクが低い文書などが対象になります。厳密なレビューが必須になっている組織でも、(すでにレビュー済みで)簡易的な修正をした文書には、利用してもよいと思います。レビュアーが不特定であることから「誰でもレビュー出来る内容」であることが条件になります。デメリットは?先にも書きましたが、レビューされない可能性があるという点です。̄メなどと、言ってはいけません。成果物の品質は、製作者の責任であり、レビュアーは時間を割いて、お手伝いをしてくれているだけですので。ピアデスクチェックパスアラウンドとは違い、特定の人に成果物を配布し、レビューしてもらう方法です。この方法では、レビュアーの何人か、もしくは全員のレビュー完了を成果物の完成の条件のひとつにすることが、よくあります。どんなときに使う?この方法を使うときは、確実にレビューをしてほしいとき(レビューが必須の成果物)、そして、レビューに専門的な知識が必要な場合です。コードレビューでは、ほとんどの場合が、この方法になると思います。デメリットは?特にコードレビューの場合は、レビューの量が多くなるため、ツールの導入、レビューのプロセス化をして効率化を図る必要があります。この方法は特定の人にレビュアーとしてのコストが集中してしまうことがあります。(その人にしかレビュー出来ない成果物が多い場合)レビュアーを育て、負荷を分散することにもコストを払わなければいけません。会議形式のレビュー方法です。今までの方法と比べても厳密なレビュー方式です。どんなときに使う?顧客、マネージャ、部外・社外の人、他職種の人など、レビュアーが開発者でない場合に、この方法を取ることが多いです。逆に言えば「成果物+説明(および質疑応答)」が必要な場合に、採用される方法です。顧客の合意を得たいとき、マネージャの判断を仰ぎたいときなどに使われたりもします。デメリットは?コストがかかる方法のため、しっかり計画を立て、レビューも進行役がしっかりと時間管理をして進める必要があります。時間を余計にかけない工夫をしなければいけません。他の方法に比べて、レビュアーを長時間拘束してしまうため、何度も行うことはできません。従って、成果物の完成度が高くないといけません。「事前に開発者同士でピアレビューを行っておく」などの工夫が必要です。レビュー完了後に成果物を修正する場合の手順なども定めておく必要があります。開発者が勝手に修正してしまっては、レビューの意味がなくなってしまいます。インスペクションより厳格で、組織ごとに決められたプロセスに従って体系立てて行われるレビューです。君たちの成果物をレビューするから、準備したまえ(・∀・)と、レビュアーが主催者になるのが特徴です。指摘された欠陥数などを記録し、成果物の品質の判断をしたり、レビュー自体の品質も、その記録をもとに判断したりします。経験談を話すことができません。スイマセンただし、うちの会社でも、レビューをしっかりやった方がいいと思うんだよな(*'-')というくらいのモチベーションであれば、ウォークスルーまで抑えておけば十分かと思います。逆に言えば、インスペクションは、開発現場の活動のみで導入できるものではありません。レビューに関して書かれている書籍自体が少ないのですが、インスペクションについて知りたい場合は、以下の本が参考になると思います。著)インスペクションについてだけでなく、レビュー全体について分かりやすく書かれた本です。次回は、レビューの導入、開催、そして教育(レクチャー)に関する注意点などを私の経験を交えて書いてみたいと思います。ピアレビューの勧めと注意点(レビューと投資)記事を気に入っていただけた方は、クリックしていただけると励みになります。職業:元ソフトウェアエンジニア自己紹介:東京のゲーム会社でゲームプログラマ。家電メーカーで組み込みエンジニア。今は東京に戻って暮らしています。詳細な自己紹介は、こちら。