忍者ブログ

東からの放浪者

様々なソフトウェア開発を経験してきた視点から、開発、マネジメント、経済などについて書いています。
タイトルは、あるレトロゲームからのオマージュ。

ツイッターアカウントはこちら。

ピアレビューの勧めと注意点(レビューの種類)

ソフトウェア開発におけるピアレビューとは、
同僚同士や同じプロジェクトの開発者同士で行うレビューのことです。

プロジェクトは規模が大きくなるに従い、ドキュメント量、コード量、要求の量が増え、
また、情報の伝達、把握が難しくなるため、レビューの重要性は増していきます。

しかし、レビューに慣れていない組織だと、以下の二択になってしまいがちです。

  • レビューをせず、余計な手戻りコストを払う
  • レビューにコストをかけすぎて、効率を落とす

レビュー文化のない現場に、レビューを持ち込むのは意外と難しいのです。

レビューの種類を知ろう

レビューと聞くと、堅苦しい印象を受けるかもしれませんが、
「人の目によるチェック」は、簡易的なものも含めて、
すべてレビューになると思ってください。

種類も、簡易的で低コストな方法から、厳密で時間をかけて行う方法まで色々あります。
レビュー対象物の性質を判断して、適切な方法を選べば、
余計なコストを掛けずに、最大の効果を得ることができます。

アドホックなレビュー

ミーティングの最後に

書記「今日の議事録は、こんな感じでいいかな?」

などと、参加者全員で議事録をチェックすることがあると思います。
これも、一種のピアレビューになります。

大きな誤り、認識の間違いなどがないか、簡易的にチェックする方法です。
計画も、事前準備も、ほとんど不要なため

みんな、ちょっと10分ほど時間もらえるかな?
見てほしいものがあるんだけど。

と言って、急遽開催することも可能です。

アドホックなレビュー

どんなときに使う?

最も低コストなレビューですが、
当然、厳密さがあまり要求されない文書などにしか使えません。

ただし、開発時に作成する文書には、
開発者同士でしか共有しないものが多くあると思います。

細かな間違いがあっても、訂正が素早く行える、もしくは影響範囲が小さい場合には、
このような簡易的なレビューでも十分効果を得られます。

デメリットは?

このようなレビュー方法は、「レビューされたか否か?」「誰がレビューしたのか?」
という情報を基本的に残しません。

ですので、長期的に利用される資料(引継ぎ資料など)、
顧客や部外の人に見せる資料などには、不向きであることが多いです。

パスアラウンド

多数または不特定多数の人に成果物を配布し、レビューを求める方法です。

私は、紙の文書でこの方法を行ったことはないのですが、
電子化された文書では、よく行われる方法だと思います。

本日、話し合って決めた内容を ~~ に記載しました。
もし間違いがあれば、X月X日までに訂正コメントをお願いします。

といった感じの通知が、開発現場では、よく飛び交っていました。

パスアラウンド

どんなときに使う?

この方法はレビューされない可能性もあることから、
品質によるリスクが低い文書などが対象になります。

また、厳密なレビューが必須になっている組織でも、
(すでにレビュー済みで)簡易的な修正をした文書には、利用してもよいと思います。

ただし、レビュアーが不特定であることから
「誰でもレビュー出来る内容」であることが条件になります。

デメリットは?

先にも書きましたが、レビューされない可能性があるという点です。

あとから間違いが見つかっても

あのとき、レビューしなかったお前らが悪いんだ!ε=( ̄ロ ̄メ

などと、言ってはいけません。

あくまでも成果物の品質は、製作者の責任であり、
レビュアーは時間を割いて、お手伝いをしてくれているだけですので。

ピアデスクチェック

パスアラウンドとは違い、特定の人に成果物を配布し、レビューしてもらう方法です。

この方法では、レビュアーの何人か、もしくは全員のレビュー完了を
成果物の完成の条件のひとつにすることが、よくあります。

ピアデスクチェック

どんなときに使う?

この方法を使うときは、確実にレビューをしてほしいとき(レビューが必須の成果物)、
そして、レビューに専門的な知識が必要な場合です。

コードレビューでは、ほとんどの場合が、この方法になると思います。

デメリットは?

特にコードレビューの場合は、レビューの量が多くなるため、
ツールの導入レビューのプロセス化をして効率化を図る必要があります。

また、この方法は特定の人にレビュアーとしてのコストが集中してしまうことがあります。
(その人にしかレビュー出来ない成果物が多い場合)

レビュアーを育て、負荷を分散することにもコストを払わなければいけません。

ウォークスルー

会議形式のレビュー方法です。

レビュアーからの指摘なども含めて、議事を取ることが多く、
今までの方法と比べても厳密なレビュー方式です。

ウォークスルー

どんなときに使う?

顧客、マネージャ、部外・社外の人、他職種の人など、
レビュアーが開発者でない場合に、この方法を取ることが多いです。

逆に言えば「成果物+説明(および質疑応答)」が必要な場合に、採用される方法です。
(成果物を渡しただけでは、レビュアーがレビュー出来ない)

また、「レビュアーはレビューのみ行い、合否判定は行わない」というのが基本なのですが、
顧客の合意を得たいとき、マネージャの判断を仰ぎたいときなどに使われたりもします。

デメリットは?

コストがかかる方法のため、しっかり計画を立て、
レビューも進行役がしっかりと時間管理をして進める必要があります。

「事前に成果物を配布し、読んでおいてもらう」などして、
時間を余計にかけない工夫をしなければいけません。

また、他の方法に比べて、
レビュアーを長時間拘束してしまうため、何度も行うことはできません。

従って、成果物の完成度が高くないといけません。
「事前に開発者同士でピアレビューを行っておく」などの工夫が必要です。

レビュー完了後に成果物を修正する場合の手順なども定めておく必要があります。
開発者が勝手に修正してしまっては、レビューの意味がなくなってしまいます。

インスペクション

より厳格で、組織ごとに決められたプロセスに従って体系立てて行われるレビューです。

ウォークスルーは、基本的に成果物の作成者が主催者となるのに対して、
インスペクションは、専門のレビュアーたちがいて、

君たちの成果物をレビューするから、準備したまえ(・∀・)

と、レビュアーが主催者になるのが特徴です。

指摘された欠陥数などを記録し、成果物の品質の判断をしたり、
レビュー自体の品質も、その記録をもとに判断したりします。

インスペクション

どんなときに・・・?

残念ながら、管理人はインスペクションを採用している組織で働いたことがないため、
経験談を話すことができません。。。m(_ _)m スイマセン

ただし、

うちの会社でも、レビューをしっかりやった方がいいと思うんだよな(*'-')

というくらいのモチベーションであれば、
ウォークスルーまで抑えておけば十分かと思います。

逆に言えば、インスペクションは、開発現場の活動のみで導入できるものではありません。

レビューに関して書かれている書籍自体が少ないのですが、
インスペクションについて知りたい場合は、以下の本が参考になると思います。


ピアレビュー - 高品質ソフトウェア開発のために』(Karl E. Wiegers 著)

インスペクションについてだけでなく、レビュー全体について分かりやすく書かれた本です。

次回に続く

今回は、レビュー方法の紹介で終わってしまいましたが、
次回は、レビューの導入、開催、そして教育(レクチャー)に関する注意点などを
私の経験を交えて書いてみたいと思います。

⇒ ピアレビューの勧めと注意点(よくないレビュー)
⇒ ピアレビューの勧めと注意点(レビューと投資)
記事を気に入っていただけた方は、クリックしていただけると励みになります。
↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓


PR

コメント

プロフィール

HN:
なかば
性別:
男性
職業:
元ソフトウェアエンジニア
自己紹介:
東京のゲーム会社でゲームプログラマ。
家電メーカーで組み込みエンジニア。
その後、京都に移動して観光を楽しみながら
製品開発、業務改善、QA管理などを経験。
今は東京に戻って暮らしています。

詳細な自己紹介は、こちら

カレンダー

01 2020/02 03
S M T W T F S
1
2 3 4 5 6 7 8
9 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29