【ソフトウェア】レビューで効果的に誤りを見つけるために
ソフトウェアにおけるレビューの心構えについてまとめました。
結論、レビューする人が意識した誤りしか見つからないので、見つけたい誤りを事前に想定してレビューする。
レビューの定義
まず、ソフトウェアのレビューの定義は、Wikipediaには以下とあります。
ソフトウェア・レビューとは、『設計ドキュメントをはじめとした各種ドキュメントやソースコードを人が読み込んで、その問題点を見つける作業』です。ソフトウェアテストとの違いは、実際にプログラムを動作させるのではなく、人の頭の中で動かして見た結果を確認するという点です。
レビューの目的は、実際のプログラムを動作させる前に、誤りや改善点を見つけることで、手戻りや保守作業肥大を防ぐことによるコスト削減をすることです。他にも、教育の側面もあります。
レビューを実施しているのに、実際にはレビューで誤りが取れず、不具合が流出するという品質問題に直面しているプロジェクトはかなりあるはずです。
これは、レビューのやり方に問題があることがほとんどです。
レビューの質
プロセスで決まってるから、レビューをしている事実だけを作ったり、闇雲にレビューをしていませんでしょうか?
レビューの質が重要です。ただ、ドキュメントの誤記や簡単な誤りを除去(これも重要ですが)するのではなく、もっと本質的な誤りを除去することが重要です。
では、そのためにどのようにレビューの質を向上させればよいでしょうか?
先ほどのレビューの目的を振り返ると、レビューはコスト削減が目的でした。コスト削減するには、誤記や簡単な誤りより、もっと「コストのかかる誤り」を除去しておく必要があります。
では、「コストのかかる誤り」とは何でしょうか?
実は、これはソフトウェアの特徴によって変化するため、画一的に定義することは困難です。
例えば、複雑な状態遷移を持つソフトウェアでは、多くのパターンを試験せねばなりません。動作確認が容易な正常系などは、問題は見つかり易いです。しかし、準正常などの動作確認し辛いパターンは、確認されないまま不具合が残ります。よって、このあたりをレビューで潰す必要があります。
業務系のソフトウェアでは、状態遷移のような沢山のパターンはありませんが、同時に複数のトランザクションが実行される場合などで、よくトラブルが発生します。試験で潰せればよいですが、本当にリリース前の最後の試験で見つかるよりは、設計段階のレビューで検出して手戻りを防ぎたいものです。
この2つの例を見ても、レビューで見るべき観点というのが大きく違うことがわかります。
ということは、ソフトウェアの特徴ごとにレビューで除去すべき誤りを検討し、レビューに臨む必要があるということです。
見つけたい誤りしか見つからない
レビューの質を上げるには、それぞれのソフトウェア毎に、レビューで誤りを検出したいポイントを事前に検討し、そのポイントを重点的にレビューすることです。
よって、レビュー行為より前の段階で、レビューの質が決まると言っていいでしょう。
実際の開発現場では、計画の段階でレビュー観点(重点ポイント)を明確にしておく必要があります。
普段気づかなかった看板が、その看板の内容を意識してから目につくようになるということがあるように、意識しない誤りは見つけることはできず、意識することで誤りに気づくことができるものなのです。
目的意識を持ってレビューをすることの効果は大いにあると考えます。