レビュータイプってどんなのあるの?3分で理解する

IT知識全般

JSTQBのFLシラバスでも紹介されていますが、レビュータイプには色々なものがあります。

JSTQB FLシラバスで主に紹介されているのは

  • 非形式的レビュー
  • ウォークスルー
  • テクニカルレビュー
  • インスペクション

上記の4つですが、他にも様々なレビュータイプがあり、それぞれに目的ややり方・ルールがあったり、無かったりします。

細かいことは置いておいて、ざっくり各レビュータイプについて一言で解説したいと思います。

様々なレビュータイプを一言解説

IEEE標準1028で定義されているレビュータイプは以下の5つがあります。

  • ウォークスルー
    • 一言で言うと、作業成果物の作成者がレビューミーティングを主導して行う
  • テクニカルレビュー
    • 一言で言うと、技術的な部分をレビュー
  • インスペクション
    • 一言で言うと、一番公式なレビュー。ルールが色々ある
  • ソフトウェア・マネジメントレビュー
    • 一言で言うと、プロジェクト全体の進捗などをレビュー
  • 監査
    • 一言で言うと、国際的な標準や規制や規則、チーム内の開発ルールなどに沿っているかレビュー

カール・ウィーガーズという人が「ピアレビュー 高品質ソフト開発のために」で定義しているレビュータイプは以下の5つです。

  • 教育レビュー
    • 一言で言うと、関係者の教育の為のレビュー
  • マネージメントレビュー,準備レビュー,ゲートレビュー
    • 一言で言うと、プロジェクトの進捗や進め方などの方針のレビュー
  • ピアレビュー
    • 一言で言うと、チームメンバー、同僚などにレビューしてもらう
  • プロジェクト終了後レビュー
    • 一言で言うと、プロジェクトが終了した後に、「で、どうだったの?」と今後の為にレビュー
  • ステータスレビュー
    • 一言で言うと、マイルストーンに合わせて進捗、発生した問題やリスクの確認を行う

というようなレビュータイプがあります。

もちろん上記に記載した事以外にもルールややり方はありますが、細かい事はここでは割愛します。

また、レビュータイプではありませんが、レビューをする際の原則として、カール・ウィーガーズの論文「Improving Quality through Software Inspections」で、以下の原則が定義されています。

  • まず、自分のエゴをチェックする。 – Check your egos at the door
  • 作成者ではなく、作成物そのものを批評する。 – Critique the products, not the producers
  • レビューで問題を見つける。ただし、見つけた問題をレビューの場で解決しようとしない。 – Find problems during the review; don’t try to fix them
  • レビューの時間は最大2時間に制限する。 – Limit inspection meetings to a maximum of two hours
  • 作成物の理解に影響がないのならば、スタイルに関する問題は避ける。 – Avoid style issues unless they impact performance or understandability
  • 公式だろうと非公式だろうと、早期に点検を行い、また頻繁に点検を行う。 – Inspect early and often, formally and informally

とのことです。レビューをする際の心構えとして覚えておきたいですね。

というわけで以上。レビュータイプを3分で理解する説明でしたー

未経験からプログラマーへの転職率95.1%

参考文献