2022.10.12

IT業界のレビュー方法ソフトウェアインスペクションとは？

株式会社SHIFT「ヒンシツ大学」クオリティエヴァンジェリスト坂元広史

Introduction

一般的にソフトウェアテストと聞いて思い浮かべるのは、一通りコーディングまで開発工程が進んでから行う単体テストや統合テストなどではないでしょうか。しかし、上流段階で実施できる「テスト」も存在します。その一つがこのコラムで取り上げる「ソフトウェアインスペクション」です。いわゆる「レビュー」の一手法ですが、これを実践することで、品質向上やコスト削減など、下流で行うテストとはまた違ったさまざまな効果が期待できます。
ここでは、そんなソフトウェアインスペクションについて、その定義や他のレビュー手法との違い、実施方法についてご紹介したいと思います。

インスペクションとは？～IT業界とそれ以外の比較～

IT業界でインスペクションというときは、主にソフトウェア開発のドキュメントなどをレビューするソフトウェアインスペクションの意味で使用します。そもそも「インスペクション」は「調査」「検査」「視察」「査察」などの意味がある言葉ですが、「下見」「第三者検証」といったニュアンスをもち、IT業界以外でもさまざまな場面で使われる言葉です。例えば不動産業界では「ホームインスペクション」という用語があり、これは住宅を販売する際に住宅の状態・品質・価値などを評価することを言います。また、スキーなどの競技の前にコースを事前確認することは「コースインスペクション」と言われます。
本コラムのテーマは「ソフトウェアインスペクション」ですので、ここでは「ソフトウェアインスペクション」のことを単に「インスペクション」と記述いたします。

標準化機関ANSI/IEEE標準による定義

「インスペクション」という言葉は標準化機関ANSI/IEEEでも定義されています。
※ANSI/IEEE 標準 1028-1998 IEEE Standard for Software Reviews

定義

まず定義ですが、「ソフトウェアの異常(エラーと、標準や仕様からの逸脱を含む)を検出し認識する目視検査」とあります。「目視検査」とは言い換えれば「レビュー」のことです。このレビューには後述の通りいくつかの種類がありますが、「訓練されたファシリテーター(議長)が主導し、第三者が検査」するものをインスペクションと呼びます。また、「修正や調査のアクションを決めることはソフトウェアインスペクションの義務であるが、解決方法はインスペクション会議で決めるべきではない」とも定められています。つまり、インスペクション会議の場では、個々の解決方法にとらわれず、参加者全員の合意が必要な問題点の指摘や修正方針を決定することに注力しましょう、ということです。

目的

インスペクションの目的は、上述の定義にもある通り、「ソフトウェア製品の異常を検出し認知する」ことです。

活動

インスペクションで行われる活動としては、以下のようなものが挙げられています。

・ソフトウェア製品がその仕様を満足していることの確認
・ソフトウェア製品が指定された品質特性を示すことの確認
・ソフトウェア製品が規約、標準、ガイドライン、計画、手続きに従っていることの確認
・上記項目に対する逸脱の特定
・ソフトウェア工学データの収集(たとえば欠陥数や工数データなどのメトリクスデータ)
・そのデータをインスペクション自体や支援ドキュメント(チェックリストなど)の改善のために提供
・責任範囲における標準違反の要請または放棄承認
・マネージメント判断(インスペクションとテストのトレードオフなど)へのデータの利用
※ 表現法の良し悪しや文体に関する問題の検査は行わない

これらの活動を行うにあたって、いずれもファシリテーターが中心になり計画的に行うことが大切です。また、表現や文体チェックなどは対象外とし、限られた時間で本質的な議論を手際よく進めることも必要となります。

テストの分類

ISTQBの定義によると、ソフトウェアテストは大きく分けてプログラムを動作させないで行う「静的テスト」と、プログラムを動作させて行う「動的テスト」に分けられます。先にインスペクションはレビューの一手法と書きましたが、そのレビューは「静的テスト」に分類されます。

4つのレビュータイプと他のレビューとの違い

レビューには4種類の技法がありますが、それぞれどう違うのか見ておきましょう。
厳密な定義ではありませんが、「有識者の参加有無」と「計画性の度合い」という2軸の4象限マトリックスで分類すると、このようになります。

左下の「非形式的レビュー」から順番に見ていきましょう。

非形式的レビュー

非形式的レビューは、一番くだけたやり方です。

特徴	・非形式的であり決まったプロセスなし。・レビュー結果をドキュメント化することもある。
主な目的	お金や時間をかけずに、ある程度の効果を出すこと。
進行者	特に決まっていない。
レビュアー	同僚、特定の技術やバックグランドをもつ人
運営	決まったプロセスはない。

ここでいう「形式的」とは、規定のプロセスに則り、スケジュール調整などの手続きを踏み報告書などの成果物を作成することを指します。したがって「非形式的」レビューは、何もルールが決まっておらず、いつどのように始めても構いません。例えば同じチームの同僚などに、フランクに「ちょっと見てください」「時間があったら確認して」というような形で声をかけて、すぐ始まりすぐ終わる。そういったものを非形式的レビューと呼びます。そのため、時間や工数をかけずに簡易に実施できる技法ですが、進行者不在で、運営プロセスなどもない状態で行われるのが特徴です。

ウォークスルー

ウォークスルーとは、作成者がレビューしてほしいタイミングで自らレビュアーを集めて実施するレビューのことです。

特徴	・作成者が進行を主導。・レビュー結果をレポートする場合がある。
主な目的	ソフトウェアの内容を学習、理解し、欠陥を見つけること。
進行者	作成者
レビュアー	同僚、特定の技術やバックグランドをもつ人
運営	シナリオを基に、同僚のグループが机上で処理をたどる形式をとることがある。運営により、きわめて非形式的なものから高度に形式的なものまである。

レビュー対象となるドキュメントの作成者が進行を主導する、というのがウォークスルーの特徴です。

テクニカルレビュー

テクニカルレビューは、レビューを取りまとめるモデレーターが進行役となり行われます。

特徴	・技術のエキスパートが参加。・レビュー結果をレポートする。
主な目的	ディスカッションすること、判断を下すこと、ほかの方法を評価すること、欠陥を見つけること、技術的な問題を解決すること、仕様や計画、規定、基準に準拠していることをチェックすること。
進行者	経験を積んだモデレーター*が理想とされる
レビュアー	同僚、技術のエキスパート
運営	チェックリストを作ることがある。運営により、きわめて非形式的なものから高度に形式的なものまである。

技術エキスパートがレビュアーとして参加し、レビュー対象のドキュメントについてディスカッションを行い、技術的な問題や解決策を見出していくレビュー手法です。

モデレーター: ドキュメントのレビューを取りまとめる人。取りまとめには、レビューの計画、レビューの運営、ミーティング後のフォローアップも含む。

インスペクション

そして、インスペクション。テクニカルレビューと同様モデレーターが進行役となりますが、他の3つのレビューよりも厳格にルールやプロセスが定められており、多くのメンバーが参加し、時間をかけて実施します。

特徴	・モデレーターが進行を主導し、各人の役割が決まっている。・規則/チェックリスト/形式や開始/終了基準に基づいたプロセスで実施し、メトリクスを収集した上でレポートや指摘一覧をアウトプットする。また、フォローアッププロセスももつ。
主な目的	欠陥の摘出
進行者	経験を積んだモデレーター
レビュアー	同僚、特定の技術やバックグラウンドをもつ人
運営	規則やチェックリストを用い、形式に基づいたプロセスで進める。

ご紹介したレビュー技法のなかで最も厳格で、非常に時間も費用もかかる手法と言えます。

インスペクションの実施方法

インスペクションには6つのステップがあります。ここからは、計画からフォローアップまでのステップに基づいて、どのようにインスペクションが成り立っているのかをご説明していきたいと思います。

1.計画

まず、計画のステップです。計画においてはどのようにインスペクションを行うのか、その内容を決めていきます。レビューの基準を定義し、どういった人が必要なのかという人選、そしてどの役割をそれぞれに割り当てるのかということを考えます。また開始条件、終了条件というものを定義し、今回のレビューターゲットがドキュメントのどの部分であるかというところを決めていきます。

2.キックオフ

次のステップはキックオフで、計画で選ばれたメンバーを集めてミーティングを行います。計画での決定事項をドキュメントにして配布し、その内容をメンバーに説明します。「あなたは○○に詳しいから、このドキュメントのこの部分について○○の観点でしっかり見てほしい」などというように、メンバー一人ひとりにどのような役割が与えられているのかを明確に把握してもらうことがキックオフの大切なポイントです。

3.個々の準備(個人レビュー)

つづいて行うのが個々の準備(個人レビュー)です。ここがインスペクションならではの特徴的なところですが、キックオフで示された役割に則って一人ひとりが個々にレビューを行い、欠陥や疑問点などを洗い出します。

4.レビューミーティング

そしていよいよレビューミーティングです。レビュー自体は先のステップでメンバー一人ひとりが実施済みなので、このミーティングでは個々に洗い出された指摘事項それぞれについての修正方針を議論します。

5.再作業

つづいて再作業ですが、これはドキュメントの作成者が、レビューミーティングで決まった方針通りにドキュメントに修正を加えるステップです。

6.フォローアップ

最後がフォローアップ。これは作成者による修正が決定した方針通りになされていることを確認し、計画で定めた終了基準を満たしているかどうかを判定します。

インスペクションの対象例

インスペクションの対象となるドキュメントにはどういったものがあるのか、例を挙げてみましょう。

インスペクション対象例: ・ソフトウェア要件定義書; ・ソフトウェア設計書; ・ソースコード; ・ソフトウェアテストのドキュメント; ・ソフトウェア利用者のドキュメント; ・保守マニュアル; ・システムビルド手順; ・インストール手順; ・リリースノート; ・ソフトウェアモデル; ・仕様書; ・開発プロセス説明書; ・ポリシー、戦略、計画; ・マーケティング、広報; ・ソフトウェアアーキテクチャー説明書　など

このように設計書や仕様書、ソースコードは言うまでもなく、マニュアルや説明書なども含め、その対象は多岐にわたります。

インスペクションについて体系的に学ぶなら

ここまでインスペクションについて、その定義や目的、他のレビュー技法との違い・実施方法についてご説明してきました。より詳しくインスペクションについて学んでみたい方は、ヒンシツ大学の「仕様書インスペクション」講座をご受講ください。
この講座では、まずインスペクションの目的と効果を理解したうえで、計画の立て方を学びます。そのうえで、SHIFT独自手法であるテスタビリティー(試験性)の観点をインスペクション技法に適用した方法論で、演習の実技を通して習得します。最後には手法の活用方法についてのディスカッションを行い、現場で実践できるスキルとして身につけることができます。
「品質保証」というとテストに頼りがちになってしまう、テストをはじめてからだと時間の制約によりできることが限られている、そんなお悩みをおもちの方にオススメの講座です。

資料ダウンロード/動画視聴

仕様書インスペクション講座

ソフトウェアテスト入門動画

テスト計画入門動画

SHIFTサービス資料

この記事を書いた人

株式会社SHIFT「ヒンシツ大学」クオリティエヴァンジェリスト坂元広史

大手ネットワーク機器メーカーにて、組込みソフトウェアやネットワーク監視システムの開発に従事。欧州での現地通信事業者とのパイロット試験に立ち合うなど、国内外の顧客向けに設計から導入まで幅広く品質向上の取り組みに携わる。のちに事業会社にてシステム導入／運用責任者としてキャリアを重ね、2021年にヒンシツ大学講師としてSHIFTに参画。教育系メディア運営やWebマーケティングの経験を活かし、外部発信にも尽力している。

担当講座

ソフトウェアテスト、基本の「き」
ソフトウェアテスト入門
テスト設計（機能テスト）

など多数

前のページへ

次のページへ

コラム一覧に戻る

IT業界のレビュー方法ソフトウェアインスペクションとは？

Introduction

インスペクションとは？～IT業界とそれ以外の比較～

標準化機関ANSI/IEEE標準による定義

定義

目的

活動

テストの分類