ideson_hondaお勧めのレビュー方法のご紹介レビューfacebooktwitter今回は、お勧めのレビュー方法を具体的に解説します。ソフトウェアの領域や特性にかかわらず適用できます。レビューチェックリストなどの事前準備も不要です。それでもかなり効果を発揮すると思います。お勧めのレビュー方法とは今回ご紹介するのは、レビューの方法(前々回)で解説した「チームレビュー」と、レビューのリーディング方法(前回)で解説したPBR(パースペクティブ・ベースド・リーディング)を組み合わせた方法です。チームレビューは、チームで実施するレビュー方法で、インスペクションほど公式でなく、「軽インスペクション」とも呼ばれる方法です。PBR(パースペクティブ・ベースド・リーディング)は、レビューアに特定の視点を割り当てて読むリーディング技法です。想定するチームレビューの参加者チームレビューの参加者は、5人を想定します。各参加者の役割は以下の通りです。レビューアの3つの視点は、必ず入れたほうがよいので省略しないでください。一人で複数の視点を兼ねるのはお勧めしません。したがって最低3人のレビューアを準備してください。チームレビューの参加者と役割レビューアによるレビュー方法レビューア1~3のレビューのポイントを以下の表に挙げます。各レビューアは、割り当てられた視点からそれることなく、常に視点を定めて読んでいきます。視点を定めて読むことにより、レビュー対象物を体系的にチェックすることができます。PBRでお勧めの視点は表に挙げた設計者の視点、テスターの視点、顧客の視点の3つですが、これに加えてレビュー対象の特性に合わせて必要な視点を追加すると、さらに効果がでると思います。レビュー視点ごとの読み方チームレビューの手順チームレビューの手順は、以下の通りです。No.3の「レビューアによる事前レビュー」は、上記の表の「レビュー視点ごとの読み方」を適用してください。チームレビューの手順さいごに今回紹介した方法は、レビューをしたいけれどレビュー方法がわからなくて困っている方や、高スキル者がいなくてレビューできないという現場では、効果を発揮すると思います。集まってアドホックにレビューするよりも、ずっと効率的にレビューできます。効果が上がったら、ぜひその成果内容を教えてくださいね。V&Vの意味は理解していただけたでしょうか、V&Vの2つの視点は、レビューなどでの重要な確認視点となります。この2つの視点でソフトウェア開発の成果物の正しさを確認することが、品質のよいソフトウェア開発につながるはずです。コメントをキャンセルコメントを投稿するにはログインしてください。イデソンソフトウェア開発の品質・生産性向上に関わるあらゆるサービスを提供します。今や社会基盤を支える存在となった、ソフトウェアの品質を通して、幸せをお届けするのがイデソンの使命です。