「インスペクション」とは― 組織全体の品質改善スキル向上に導入効果の高い「インスペクションレビュー」を紹介

ソフトウェア開発の各工程での成果物を評価し、欠陥がないか確認するための会議や査読といった活動や、関係者が成果物を評価・承認するプロセス全体を「ソフトウェアレビュー」といいます。
本記事では、さまざまなソフトウェアレビューのなかでも、組織全体の品質改善スキルを効果的・効率的に上げるための「インスペクションレビュー」を紹介します。

インスペクションレビューの特徴と品質改善スキルを上げるための工夫

インスペクションレビューについて、ソフトウェア開発における作業成果物のレビューについて定めた国際標準規格「ISO/IEC 20246」の「3 用語及び定義」にて次のように定義しています。

3.8　インスペクション（inspection）
定義されたチームの役割及びレビュープロセス改善のための測定を使用する、
要検討事項を識別するための作業生産物の形式的レビュー

「ISO/IEC 20246」の「3 用語及び定義」

つまり、次のようなレビューがインスペクションレビューというわけです。

特徴１「定義されたチームの役割」
誰が何をするか予め“役割”が決まっている

特徴２「レビュープロセス改善のための測定」
メトリクス（測定基準・尺度）を使って測定してレビューのプロセス（手順や手続き）自体を改善することが決まっており、関係者に認められている

特徴３「形式的レビュー」
どのように開催するのか関係者に認められており、レビューで指摘された要検討事項やその処理についての記録が残る

これらインスペクションレビューの３つの特徴が、どのように組織全体の品質改善スキルを効果的・効率的にあげることにつながるのかを説明します。

「定義されたチームの役割」で効率化Up

先に述べたようにインスペクションレビューでは、レビュー参加者の役割が定まっています。
各々の役割については後述しますが、“誰が何をしなければいけないか”があらかじめ決まっています。
このため、参加者は役割に応じた準備ができます。
また、役割の中にはレビュー対象についての技術的な深い知識が無くても行えるものがあります。そのような役割に対して専任者を設けたり、開催時に作業負荷の低い方を割り当てたりすることが可能なため、レビュー会議の運用効率化を図りやすくなっています。
レビュー対象と関りが薄い方でも“役割”を後ろ盾に依頼・要請したり、督促したりすることがやりやすくなるという点も効率化を図るためのメリットといえます。

「レビュープロセス改善のための測定」でプロジェクト内や組織全体へ効果を波及

関係者が認めたメトリクスで各々のプロジェクトを比較できます。また、プロセスの改善についても手続きや改善することについて関係者にあらかじめ認められているので、改善のアクションがとりやすくなります。
適切なメトリクスを使えば、改善施策の前後で実施効果が比較可能となるため、改善施策を次プロジェクトや他のプロジェクトへ水平展開する必要性の判断を下しやすくなるでしょう。

「形式的レビュー」で効率的に組織全体の品質改善スキルを上げる

ここでの「形式的」とは、あらかじめ決めてあり、関係者に認められていて、記録に残すことができていることを指します。合理的な効率化の方法も、プロジェクトの規模や特性に応じた部分適用の範囲もあらかじめ決めて、関係者の合意を得ているのであれば積極的に行っていいのです。
品質を向上させようとするあまり、やるべきことがどんどん増えて現場の負担感が増したり、まじめに品質改善に取り組むチームほど疲弊感に襲われたりといったことがあったかもしれません。ですが、効果のない施策やスキルが上がって不要となった施策は、手続きに従ってどんどん省略していけばよいのです。
記録や測定といった作業は、これまで実施していなかった組織にとって多少負担になりますが、適切なツールを活用したり現場以外の方を割り当てたりすることで解決できるでしょう。このような工夫で、組織全体の品質改善スキルを上げ、その成果を目に見える形で享受できるのが「形式的レビュー」のメリットです。

7STEPで進めるインスペクションレビュー

よい効果を得るためのインスペクションレビューの進め方を7つのSTEPで説明します。

《STEP1》準備・計画：インスペクションの範囲を決め、チェックリスト（またはシナリオ）、計画書（キックオフ資料）を作成する。
《STEP2》キックオフ会議：インスペクションの目的や狙い、手順、役割、スケジュール、ドキュメントの内容チェックリストについて周知する。
《STEP3》個別インスペクション：各個人でチェックリストに従って、担当範囲のドキュメントを確認し、不具合候補を記録していく。
《STEP4》インスペクション会議：各自で実施したインスペクション結果を持ち寄り、不具合候補について不具合かどうかを判定し不具合表に記録する。
《STEP5》ドキュメント修正：不具合表に基づき、作成者がドキュメントを修正し、修正した不具合は、不具合表に記録していく。
《STEP6》フォローアップ：進行役が、不具合表と修正されたドキュメントを突き合わせて修正内容を確認し、修正が完了したかを判断する。
《STEP7》原因分析：蓄積した不具合データを分析し、開発プロセス及び品質プロセスの両方を改善していく。

《STEP1》準備・計画

まずインスペクションの範囲を決め、チェックリスト（またはシナリオ）、計画書を作成していきます。

●インスペクションの範囲を決定
インスペクションの範囲、即ちレビュー対象によってインスペクションレビューの開催条件、合格条件、参加者に求める知見や情報の共有先なども変わりますので、最初に何をどこまで見るかを決めます。一般的に品質要件や規模、スケジュールに応じて強弱をつけます。

●チェックリスト（またはシナリオ）の準備
一般的にベースとなるチェック項目からピックアップする形でチェックリストを作成します。メインの要件や多くのエンドユーザー（利用者など）がご利用になる機能についてはシナリオに基づくレビューが効果的です。「どこまで見るか」で検討した強弱に応じてチェックリストとシナリオを併用したレビューを検討します。

●インスペクションレビュー計画書の作成
計画書は次のStep2でキックオフ資料として使用し、記載した事項について関係者に周知徹底します（記載事項の詳細は次Step2で説明します）。このため、インスペクションレビューの目的や狙い、手順、役割は必ず目立つように記載しましょう。

計画書の記載項目概要は次のとおりです。

A) 目的と狙い
インスペクションレビューを実施することでどうしたいかを記載します。「目的の達成＝成果」ですので、できる限り定量的な表現で記載しましょう。
時折、プロジェクトの目標をそのまま記載した計画書を見受けますが、ここに記載する目標はプロジェクトの品質目標(の一部)です。

B) 手順（実施プロセス）
実施プロセスには開催条件、合格条件、摘出された問題や欠陥の処置方法、収集データの種類や情報の共有方法、分析方法などが含まれます。
標準プロセスとして定めておいたものをプロジェクトの特性に応じて取捨選択したりアレンジしたりすると効率的でしょう。
計画書には、関係者全員が理解しておいて欲しいエッセンスと詳細についての参照先を記載します。

C) 役割
次のような役割別にインスペクションレビューの参加者を記載します。
部門や資格・役職で決めても構いませんが当事者の自覚を促すために代表者や責任者名はキックオフ資料にバイネームで記載しましょう。

役割が予め定義されていて、自分がどの役割を担うのか計画書にバイネームで記載されることで、インスペクションレビューの参加者は事前に自分の役割や責任について理解したうえでレビューに臨むことができます。

●オーナー（レビューイ）
レビュー対象の作成者。
インスペクションレビューを実施する際、他の役割を兼任できない

●モデレーター
インスペクションレビュー全体のマネージメントを担当する。
プロセスに則って参加者の選出からスケジュールの作成、チェックリストの作成・改訂、レビューの進行、指摘事項の対応フォローなどを行う

●インスペクター（レビューア、指摘者）
適切な観点を持ちプロセスに定められた基準で選出された（レビュー対象に直接関係しない）第三者が担当し、問題や欠陥を指摘する

●プレゼンター
レビュー参加者に対するレビュー対象や関連資料の説明を担当する。
レビュー中にオーナー（レビュー対象の作成者）が“レビュー対象に記載されていない”ことをその場で補足したり言い換えたりすることを防ぐために設ける

●レコーダー（記録者）
レビューで指摘された問題や指摘の記録を専任で担当する。他の参加者は話されている内容に専念でき、記録が確実に残るのでレビューの効率化につながる

D) スケジュール
計画書を見て個々のインスペクションレビューへの参加者が予定を確保できるような記載を工夫します。

E) ドキュメントの内容チェックリスト
チェックリストがキックオフ資料の１ページ程度にまとまった、項目が少ないリストならば全項目をキックオフ資料に記載します。
項目が３ページを超えるようであるなら、キックオフ会議の場で説明したい主要な項目とチェックリスト本体の参照先を記載します。なお、参照先には必ず最新版を置くようにしてください。

《STEP2》キックオフ会議

次に、Step1で作成した計画書を使ってキックオフ会議を開催します。

インスペクションレビューを実施する目的や狙い、記載事項について説明し、周知徹底を図ってください。インスペクションレビューの目的や狙い、誰がどの役割を担当するのかについて関係者に理解してもらうことは特に重要です。
なお、キックオフ会議を欠席したり後からプロジェクトに参加したりするメンバーのためにキックオフ資料やキックオフ会議の様子を関係者がいつでも参照できるようにしてください。

《STEP3》個別インスペクション

キックオフ会議が終了し、レビュー対象が作成され始めたらStep1で計画しStep2で関係者に周知徹底された「手順（実施プロセス）」に従って個々のレビュー対象に対するインスペクションを行います。
インスペクターに任じられた方は各個人でチェックリストに従って担当するレビュー対象を確認し、不具合候補があればそれを不具合表に記録します。
一般的に、テクニカルな観点でチェックできる知見を持ったインスペクターは自身が重要なドキュメントの作成者であり多忙な場合が多いと思われます。技術的な知見を必要としない書き方やトレーサビリティなどは別の方がチェックし、技術的な知見を持ったインスペクターは知見を必要とする観点のチェックに専念してもらうと効率的に進めることができます。

《STEP4》インスペクション会議

Step1で計画しStep2で公認となった「スケジュール」どおりにインスペクション会議を開催します。

インスペクション会議までに個別インスペクションが完了していない、ましてやレビュー対象の作成が完了していないなどといったことを発生させないため、モデレーターは事前準備や当日の会議運営に知恵と工夫を凝らしてください。
インスペクション会議では各インスペクターが実施した個別インスペクション結果（不具合候補が記載された不具合表）を持ち寄り、各々に対して不具合かどうかを判定し処置を決めます。インスペクション会議での判定結果や決まった処置、新たな指摘事項はレコーダーがすべて記録し不具合表を更新します。
指摘事項が0件の場合、レビュー対象の品質が優れていたのか、個別インスペクションが行われなかったのか不具合表の記録では分からなくなるため、個別インスペクション実施のエビデンスとして個々のチェックリスト（チェック結果）もインスペクション会議の記録として残すようにします。

《STEP5》ドキュメント修正

オーナーは、不具合表に基づきドキュメントを修正します。オーナーは修正した内容を指摘事項に紐づける形で不具合表に記録します。
品質改善スキルの高い組織では、修正内容が妥当であることを確実にし記録にも残すため、修正結果のエビデンスを不具合表に紐づけたり妥当性を確認する手続きや基準をStep2で周知した手順（実施プロセス）に組み込んだりすることが行われています。

《STEP6》フォローアップ

モデレーターは、定期的に不具合表と修正されたドキュメントかの修正箇所を突き合わせて確認し、個々の不具合事項の修正が完了したかを判断します。モデレーターは修正内容の妥当性までは確認しませんので、高い品質基準を求められる場合は上記「《STEP5》ドキュメント修正」で述べたように修正内容の妥当性を確認する手順をあらかじめ決めておいた方がよいでしょう。
モデレーターは週次、日次などの頻度で不具合表に基づく不具合修正状況を関係者に報告したり、オーナーにリマインドしたりすることで修正モレや対応遅延が起こらないよう努めます。

《STEP7》原因分析

モデレーターは不具合表に蓄積した不具合データを分析し、開発プロセス及び品質プロセスへ分析結果をフィードバックすることでその両方の改善を図ります。
分析はStep1で計画書に記載したインスペクションレビューの目的や狙いに対して効果が上がったかどうかを中心に行い、関係者へレポートします。組織全体の開発プロセスや品質プロセスが向上、効率化しているか他のプロジェクトと比較して深く分析するために組織共通の定量的なメトリクスを設けておくと良いでしょう。

各Stepを効率よく進めるためのヒント

各Stepを効率よく進めるためのヒントを、ここに共有します。ぜひ活用していただき、組織全体の品質改善スキルをグングンと上げていってください。

「《STEP1》準備・計画」でのノウハウ

「段取り八分、仕事二分」という言葉があります。「何につけても物事を上手く成そうとしたら、全体を10に分けたうちの8（個)分は段取り（準備・計画）に必要で、実際に手を動かす仕事は2(個)分程度ですよ」という意味ですが、インスペクションレビューも全くそのとおりです。
ですからこのStepにはノウハウが盛り沢山あり触りだけとなってしまいますが、皆さんが取り入れやすいと思われるノウハウをお伝えします。

1. 手順（実施プロセス）
手順はできる限りシンプルにを目標にしてください。本来の作業が滞っては本末転倒です。上手く回っているプロジェクトのプロセスをベースに、どうしても押さえないといけないこと以外は思い切って省略するなど、素早く立ち上げプロジェクトの開始時から関係者に周知徹底できるようにしましょう。

2. メトリクス
インスペクションレビューの目的や狙い、品質目標が達成できているか判断しやすいようにできる限り定量的なメトリクスを使いましょう。またメトリクスの数は極力絞り、短いスパンでも傾向が確認できる定量的なメトリクスを一つは用意しましょう。

3. 収集データ
本来の作業を進めるだけで自動的に入手できるデータが理想です。
いつ、どのように採取するかといった点の定義が難しいデータは粒度にバラツキが出たり、担当者が面倒になって収集が難しくなったりします。簡単に定義できるかどうかを目安に収集データを選んでください。
どうしても収集が大変なデータが必要となったら、それはメトリクスの変更を検討すべきというサインです。

「《STEP2》キックオフ会議」でのノウハウ

キックオフ会議の開催ノウハウは、一般的な会議のノウハウと同じです。ここではキックオフ会議固有のノウハウについて説明します。

1. 役割別担当者（担当責任者）からの宣言
実施効果の面から役割別の担当者は計画書にバイネームで記載した方がよいのですが、名前を書くだけでは当事者意識を持っていただけないことも多いようです。できれば各担当(責任)者ご自身からキックオフ会議の場でご自身の役割を説明いただき、「参加できない場合は責任をもって適任者をアサインする」と宣言いただくようにすると、インスペクションレビューへの参加率も当事者意識もぐっと高まります。

2. キックオフ会議での質問事項について
キックオフ会議は関係者全体に手順（実施プロセス）やドキュメントの内容チェックリストについて説明するので、出席者からたくさんの質問が寄せられると思います。

このため、キックオフ会議の冒頭で“会議の終わりに質疑応答の時間を設ける”ことやその場で回答できないことは関係者が閲覧可能な手段で“後日回答する”ことを宣言しておき途中で質問があった場合は「最後に答えます」とだけ答えるとスムーズに説明が行えます。
また、「説明内容に対する疑問・質問をキックオフ会議から2週間以内まで受け付け、それ以降は定期的にフォローします」など、質問できる期間を区切ることと、それ以降も質問できることを示すとその後のインスペクションレビューの運営が比較的スムーズに行えるようです。

「《STEP3》個別インスペクション」でのノウハウ

ドキュメント作成ツールのコメント機能や校正機能の活用
「《STEP3》個別インスペクション」で技術的なチェックとそれ以外のチェックを行うインスペクターを分けることを提案しました。その際、指摘はドキュメント作成ツールのコメント機能や校正機能を活用しレビュー対象ドキュメントに直接指摘を残すようにすると指摘の重複をある程度防げます。
不具合表にはレコーダーが転記するルールにしておくと、指摘の分類粒度が揃いやすく、Step7での分析もしやすくなるというメリットもあります。

「《STEP4》インスペクション会議」でのノウハウ

出席者
各役割の方が、開催前にはバイネームで決まっているようにするといっても、突然出席できなくなることもあります。このため、次のように工夫したルールで運用していたプロジェクトがあります。

A) インスペクターが出席できる時間帯を予め枠として確保しておき、出席者を決めてしまう

B) 開催前日までに空き枠にオーナー（レビュー対象の作成者）が予約を入れると“開催決定”とする
開催2日前までにレビュー対象や説明/引用資料を決まったフォルダへ格納する

C) 枠の調整はオーナー同士で行う

D) 枠に参加できない場合は、参加できない方が自身で代理の方をアサインする
途中交代もありとして、レビュー開催前に出席者へ交代があることを連絡する

会議終了時の不具合表確認
インスペクション会議の終了5分～10分前の時間帯で不具合表の記載事項を確認すると実施モレや進捗遅れが減少します。「短い時間では担当者や対応内容が決まらない」といった場合に備えて担当者（と確認者）を決めること自体を対応内容にとして良いことにし、後日決定した対応内容や担当者を追加できるよう枝番をつけたり、対応を移管できたりするような不具合表にしておくと不要な議論が減り、フォローアップがしやすくなります。

「《STEP5》ドキュメント修正」でのノウハウ

リアルタイム個別添削指導ノススメ
ドキュメント修正の内、技術的な知見を必要としない書き方やトレーサビリティなどについての不具合修正は、オーナーとインスペクターがリアルタイムでの個別添削方式で行うと指摘事項に対するオーナー側の理解も早く修正効率が上がります。
全てのドキュメントに行うのではなくオーナーが最初に作成するドキュメントに対してだけ行うだけで以降は指摘事項が激減しますので、最初だけ少し工数をかけてみてはいかがでしょうか。

「《STEP6》フォローアップ」でのノウハウ

修正作業のリマインド
不具合表に修正（対応）完了予定日を入れておくようにし、モデレーターは修正（対応）完了予定日の直前の定期確認日からフォローアップを始めるように決めておくと、フォローアップがリマインダとなり着手忘れや着手遅れが減るのでお勧めです。

修正（対応）完了の確認方法
フォローアップに時間を取られないようにするために、「対応したことを示すエビデンス（証拠）を直接参照できるように(リンク先などを)不具合表へ記載する」と決め不具合表に欄を設けておくと、確認者側の拘束時間が減ります。

「《STEP7》原因分析」でのノウハウ

息の長い品質改善活動としていくために
分析報告では、モデレーターから改善対策についても言及すると思われますが、例えば「品質改善効果の高かったチームは次プロジェクトでレビュー対象やレビュー項目を簡略化できる」などといった実施者に嬉しいルールを是非プロセスに組み入れてください。改善によって自分たちの作業負荷が低くなることを実感してもらえると、以後の改善活動がスピードアップします。

参考：
JIS X 20246:2021 ソフトウェア及びシステム技術―ソフトウェア及びシステム開発における作業生産物のレビューのプロセス
https://jis.eomec.com/jisx202462021/2
開発手法ガイドブック ガイドブック　2011年3月　ＩＰＡ独立行政法人 情報処理推進機構
https://www.ipa.go.jp/files/000005144.pdf
情報マネジメント用語辞典　インスペクション（いんすぺくしょん）
https://www.itmedia.co.jp/im/articles/1111/07/news208.html

関連コンテンツ