【システム開発】正しいレビューの方法｜インスペクション・ピアレビューって？

システム開発演習を行うにあたり、同僚とペアになってレビュー実施する機会が何度もありましたが、毎回「このチェック方法で合っているのかな」と疑問を持ったまま進めていたので、この場で正しいレビューの方法についてまとめていきます。　レビューの種類を挙げたのちに適切なレビュー観点をご紹介します。

レビューの種類は細かく8つに分けられる

インスペクション：もっとも公式的なレビュー

チームレビュー：チーム全体で実施される

ラウンドロビンレビュー：是認が順番に司会者とレビュアーになる

ウォークスルー：形式的でなく、参加者が質問やコメントをする

ピアレビュー：作成者以外と気軽に行う

アドホックレビュー：近くの同僚に声をかける非公式なレビュー

ペアプログラミング：プログラミング時に他社観点を取り入れる

このように、状況やレビュー相手の違いにより名称がことなります。ひとことにレビューといっても色々な手法があるので、レビューを行う際にはこの違いを意識しておくとよいでしょう。

レビューを実施するタイミング

システムのプロセスが外部設計・内部設計・製造と進むとした場合を考えましょう。
前の工程で通過してきた欠陥は、次の工程でx倍に増幅されます。
これは当然で、誤った前提で作業を行えば当然、間違えますし、後の工程ほど作業量は多いので、欠陥は確実に増幅されます。
もし、後工程に渡す前にレビューをした場合、レビューが欠陥のフィルター機能として働き、後工程の欠陥の発生を抑止する事が期待できるのです。

レビューに必要な観点①スコープの妥当性

まず１つは、検討対象となるスコープが適切であるかどうかです。多くの場合、このスコープの認識に漏れや誤りがあるために、設計漏れなどが発生します。スコープをきちんと認識していれば、ほとんど設計漏れなどは発生しません。
　
なのでレビューの一番最初にこのスコープを確認します。ほとんどの場合、スコープが狭すぎて、更なる検討アイテムが増えることになります。そして、こうした指摘がレビューの指摘の半分以上を占めていると考えます。

レビューに必要な観点②網羅性

２つ目は、検討対象になっている機能やシステム要素を漏れなく設計・調査できているのか、という網羅性を確認します。
　
一番いいのは検討対象となる要素をすべてマトリクスに表記し、挙動について記載することです。何かの機能を設計する場合は、その機能に何らかの形で影響する他の機能やシステムの状態、他の装置などをリストアップします。
　
そしてそれらのバリエーションの全ての組み合わせをマトリクスで網羅します。バリエーションが多くて網羅するのが困難な場合は、事前に事由をつけて関係のないバリエーションを削除してから網羅します。
　網羅できていない資料は、その時点で手直し対象になりますが、それによって新たな設計漏れが必ず発見されています。

レビューに必要な観点③検討過程の妥当性

３つ目は、設計上の結論を導いた検討過程を証明させることです。「なぜその結論が妥当だと考えるのか、その過程を論述せよ」ということです。高度情報処理試験の小論文と同じですね。
　
具体的には、検討過程を資料として必ず残させるようにします。同じ結論を導くのでも、どこまで調査してその結論を導いたのかで、影響の有無もわかるからです。調査の範囲が狭いと考える場合は、調査範囲を広げさせます。
　
そうすることで、他への影響箇所を適切に調査した結果として導かれた結論なのかどうかが第三者にも明確になります。

最後に

いかがでしたでしょうか。持つべき観点の中でも、特に検討過程の妥当性に関しては、確かに今まで見落としていた部分があるとな感じました。このレビューの観点は、他者のレビューを行う際だけでなく、セルフチェックにも十分活かすことができます。この考えが身につくまで、実践の場での習熟は欠かせないようです。