はじめまして、JJです。
今回はインスペクション初心者の私が、業務を体験して学んだことについて書いていこうと思います。
既にインスペクションというものをご存じの方からすれば何を基本的なことをと思われるでしょうが、IT業界に長年身を置いている私でもはじめて聞いた言葉でもあったので知らない方も多いと思われます。ですので、そもそもインスペクションとはなんぞや？というところから説明させていただければと思います。
1.インスペクションとは？
さて、あまり聞きなれない言葉ではありますが、デジタル大辞泉だと下記のようになっていますね
インスペクション【inspection】
引用元：コトバンク
１ 視察。検査。点検。監視。
２ アルペンスキー競技で、レース前のコースの下見。
３ ソフトウエアの開発工程において、不具合や問題点がないかどうかを第三者が検証すること。
デジタル大辞泉「インスペクション」の解説
今回業務として実施したのはもちろん３となります。もう少しちゃんと書くと
「（開発工程の早い段階で：Shift Left）明文化・規定されたルールに従って第三者視点でのチェックを行い、ドキュメントの精度を高める」
ということを実施しました。
これはソフトウェアインスペクションとも呼ばれています。
2.インスペクションの目的とメリット
ではなぜインスペクションを実施した方がよいのか？についてですが、開発現場に関わった事がある方であれば、
1．ドキュメントに基づいて開発を実施
↓
2．仕様などの変更によりドキュメントも変更される
↓
3．変更されたドキュメントに基づいて開発修正を実施
といった経緯で業務を行い、上記における１の段階や2～3のループにおいて、ドキュメントの不備により開発の手戻りが発生し、想定より修正コストが増加したという事を一度や二度は経験した事があるかと思われます。
インスペクションを実施する目的の一つは
「開発時の手戻りによる修正コストを抑制する」ことにあります。
設計工程での修正を1とするとテスト工程での修正は4倍のコストが掛かる※ともいわれているので、コストだけ見ても大きなメリットがあります。
※出典：JASPIC SPI Japan 2009
奈良隆正「ソフトウェア品質保証の方法論、技法、その変遷 ～先達の知恵に学ぶ～」P.31
また、ほかにもメリットとして、インスペクションを実施することで、
「手戻り、修正コストを未然に抑制する仕組み、体制が構築され、インスペクションを繰り返す事で長期的な開発コストの抑制及び開発品質向上につながる」
という事もあげられます。
3.インスペクションのカギ
インスペクションの目的の一つは「ドキュメントの精度を高めることで手戻りを抑制してコストを抑制する」ことと前の章で述べました。
ただ、実際にドキュメントの精度を高めるといってもドキュメントの内容は技術的な知見経験が必要なものが多く、正しい事/適切な事が記載されているか？については技術レビュアー（インスペクター）に判断を任せなければなりません。
技術レビュアー（インスペクター）に判断を任せるにあたって、スムーズに進めて貰うためには、一般的にみて個々の知識や経験により認識齟齬や誤解を生じやすい部分の排除、つまり「ドキュメントの曖昧さを可能な限り排除すること」が必要になります。
簡単な事ではあるのですが、曖昧さを可能な限り排除することで、読み手の解釈や判断に依存する表現がなくなり、それだけでもドキュメントの精度がかなり向上する事になります。
加えて、書き手の理解や認識、意図がより明確になるので読み手側の理解や認識との齟齬部分がはっきりしやすくなります。
実例としては、
・など ：条件や要素は読み手の経験や知識によって理解が異なる
・これら、それら ：何を指し示しているのか共通認識が無い場合が多い
・通常は～ ：「通常」に対する認識が人によって異なったり、時間が経つと変化したりすることがある
などがあげられます。実例の様な表現の曖昧さを排除する事がインスペクションのカギとなります。
4.対象となる主なドキュメント
開発においてドキュメントといっても様々なものがあります、その中でもインスペクションの対象としたい主なドキュメントとして以下のものがあげられます※。
※出典：日経BPソフトプレス Kari E.Wiegers著「ピアレビュー」P.12
・要件定義書、またはそれに類するドキュメント
・基本設計書、またはそれに類するドキュメント
・詳細設計書、またはそれに類するドキュメント
・マスタ定義書、またはそれに類するドキュメント
では、何故これらのドキュメントを対象とした方が良いのでしょうか？
大きくは2点の理由が挙げられます
・開発初期に作成されるドキュメントである
・一つの変更が及ぼすシステム全体への影響が大きいドキュメントである
インスペクションの目的の一つは開発時の手戻りによる修正コストを抑制することですから、コストへの影響が小さい早い段階で曖昧さを排除することが望ましいといえます。
5.インスペクションの役割
インスペクションと同様の他の一般的な内部レビューにおいては、下記のような問題が発生し、ソフトウェアの欠陥検出率の基準となるメトリクス（評価基準）が曖昧になる事があります。
・レビュー結果を記録しない
・修正結果が未検証のまま残る場合がある
・ドキュメント作成者のスキルにより重要な問題点がレビュー対象とならない事がある
インスペクションの役割はこれらの問題が起こらないよう、明文化、規定されたルールに従って第三者視点で厳密にチェックを行い、記録を残すことで、ソフトウェアの欠陥検出率の基準となるメトリクス（評価基準）を明確化する事にあります。
6.インスペクションの実施
では、実際にインスペクションを実施する場合どういった事を行っていくのかを説明していきます。
インスペクションを実施する際の各ロールと役割については以下となります。
ドキュメント作成者とインスペクション依頼者はインスペクションチームへの参加は出来ません。
○ロールと役割
| ドキュメント作成者 | 対象となるドキュメントを作成、修正する役割 |
| インスペクション依頼者 | インスペクションを依頼する役割 |
| 進行役 | インスペクションの狙い役割の説明、チェック内容の説明、チェックリスト修正、各会議の開催依頼及び全体の進行を行う役割 |
| インスペクタ | 各ドキュメントのレビューを行い、不具合判定する役割 |
| 読み上げ係 | 会議にてレビュー内容を読み上げる役割 |
| 不具合表記録係 | 会議での判定内容を不具合表への記録する役割 |
○実施手順
下記実施手順については弊社の標準ステップであり、プロジェクトによって手順をカスタマイズする事がありますが、標準の方法として下記の7つのステップを順に実施していく事となります。
○弊社の役割
弊社の役割としてはインスペクションがスムーズ且つ正確に行われるように全体的なサポートを行う事であり、具体的には下記のようなサポートを実施します
・インスペクションに必要な各草案作成
└不具合表FMT、チェックリスト、シナリオ、計画書など
・会議進行サポート
└開催依頼、進行サポート、読み上げ、記録など
・ドキュメント作成サポート
└書き方のコツ、チェック内容説明、FMT/リスト修正、完了確認/催促など
・分析、報告＆改善提案
└対応＆改善状況週次報告、分析結果&改善提案報告など
上記を前提として、ここからは各Stepにて何を実施していくのか？を説明していきます
Step1 準備・計画
概要：インスペクションの範囲、チェックリスト（またはシナリオ）、計画書（キックオフ資料）を作成
詳細：対象のドキュメントに対して、簡易なチェックを実施する事で現状を分析、PMとの打ち合わせにて、対象ドキュメントの選定、チェックリストの方針選定、スケジュールを含む計画書の作成を行う
Step2 キックオフ会議
概要：インスペクションの狙いや目的、手法、役割、スケジュール、ドキュメントの内容チェックリストについてPMと共有
詳細：実際にドキュメントを作成するドキュメント作成担当者やそのとりまとめを行う方に対して目的、チェックリストの記載方法、それぞれの役割と担当業務、スケジュールなどを共有、プロジェクトとして進める認識をもっていただく。
Step3 個別インスペクション
概要：チェックリストに従って、担当範囲のドキュメントを確認し、不具合候補を記録
詳細：レビュアー（の第三者）がドキュメントに対してチェックリストでチェックを実施、あくまで不具合候補の情報を集積するにとどめる、ただし、曖昧な記載がある場合はドキュメント作成者に対して修正を依頼する
Step4 インスペクション会議
概要：実施したインスペクション結果（不具合候補）を持ち寄り、不具合候補について不具合かどうかを判定し不具合表に記録
詳細：ドキュメント作成者を除いた関係者で不具合候補について技術的観点、影響の大きさ、事象の正誤を基準に判定、不具合であれば不具合表に記載する
Step5 ドキュメント修正
概要： 不具合表に基づき、ドキュメント作成者がドキュメントを修正 不具合表を更新
詳細：インスペクション会議で不具合と判定されたものについて、ドキュメント作成者が修正を行い、不具合表を更新する
Step6 フォローアップ
概要：不具合表と修正されたドキュメントから修正内容を確認し、修正が完了したかを判断
詳細：とりまとめ担当者がドキュメントの修正状況や修正確認状況をチェック、修正が未完了な場合はドキュメント作成者に、修正確認が未完了の場合は起票者や確認担当者に対して締め切りを指定して実行させる
Step7 原因分析
概要：蓄積した不具合データを分析し、開発プロセス及び品質プロセスの両面での改善点を抽出
詳細：不具合の傾向からドキュメントのフォーマット変更や文言集の作成、グループ毎の進捗状況などから人員配置や体制の強化などの改善点を抽出と提案を行う
7.インスペクションについてのおさらい
以上がインスペクション実施の流れとなります
繰り返しになりますが、
目的は開発時の出戻りによる修正コストを抑制する事
その為のカギはドキュメントの曖昧さを可能な限り排除する事にあります。
また、弊社が参画する上で留意点が一つあります、それは実施の際サポートしすぎないという事です。目的は上記の通りなのですが、一回きりで終わってしまってはあまり意味がありません
理想としてはインスペクションを定期的に行える体制、組織がつくられることです、その為にはPMやドキュメント作成者を含む開発にかかわる全てのメンバーにインスペクションの重要性とやり方を認識してもらう必要がありますので、実施する際、こちらはあくまでもサポートする立場であるということ忘れないようにしなければなりません。
8.考察
ここからは今回インスペクション業務を体験した結果からの考察を記載します
〇インスペクションの効果がある開発プロジェクト
昨今の開発事情は昔とちがい短期なものがほとんどです、中にはドキュメントを全く作成しない開発プロジェクトもあるかと思います、当たり前ですがそういった開発案件にはインスペクションは実施できません。
今回インスペクション業務の初回スタイルチェック、トレーサビリティチェックだけでもかなりの数の改善につながる指摘事項を検出する事ができました、このことから、インスペクションを複数回繰り返す事で評価基準がさらに明確になり、品質改善に大きく寄与できるものであると考えるようになりました。
上記により、インスペクションがより大きな効果として現れる開発プロジェクトとしては以下の条件を満たしたものが考えられます
・中大規模かつ中長期のドキュメント作成が必須となる開発プロジェクト
・定期的に改修が発生する（同システムに対して複数回追加、改修が発生する）開発プロジェクト
〇プロジェクトマネージャーへのメリット
マネージャークラスの方はプロジェクト全体を見て進捗や調整をかける役割ですが、その中でもドキュメント周りの調整業務にかなりの時間を使っているかと思います。
その中でもなんとなく、ドキュメントのトレーサビリティや精度が上がれば調整業務の時間も減るし、開発品質も上がるのではないか？と考えておられる方はいるのですが、改善予算をとる為の根拠となる数字について、何をどう出せばいいのか？がわからずそのままになっている事が多いようです。
今回インスペクション業務のトレーサビリティチェックやスタイルチェックによる曖昧さの排除を行えば、どれくらい手戻りが減少するのか？の予測値を算出、結果としてコスト削減の根拠となる数字を提示する事ができました。
このことからインスペクション実施していれば改善予算をとる為の根拠を作成しやすくなるのは、マネージャークラスにとってはメリットになるのではないかと考えられます。
〇開発担当者へのメリット
自身の開発経験が元になるのですが、実際開発を進めていると変更がとてもおおく、正直どこに影響がでているのか？どこを改修しなければならないのか？が把握できない、確認する時間がない事が多かったです。
端的にいうと「どの資料のどの部分をみればいい」といったトレーサビリティが確保されたドキュメントがあればもっと楽に開発できるのにと思ったことは一度や二度ではありません。
今回インスペクション業務のトレーサビリティチェックの過程にて、機能要件に対する項目の突き合わせ表（どの資料のどの部分をみればいいが分かる資料）を作成し、クライアントからはかなり喜ばれた経験から、やはりトレーサビリティについては重要だけど手をいれる時間がないと考えているクライアントは多いのではないかと考えられます。
インスペクションを実施すれば、トレーサビリティの強化と合わせてドキュメントの曖昧さの排除など、ドキュメント周りの精度が向上し開発負担の軽減につながるのでメリットは大きいと考えれれます。
9.最後に
最後になりますが、今日からでも始められる簡単なインスペクションについて記載しておきます。
表形式の資料って結構作成する場面があると思います、その場合、空欄を空欄のままにせず、必ず何かしらの記号（―など）やマークを記載してください。
見る方からするとこの空欄って何か変更はいるのか？背景色変更されているけど本当に見なくていいの？といった認識をすることがありますので、そういった曖昧さを排除する事ができます。
以上となります
お読みいただきありがとうございました、記事が何かの参考になれば幸いです。
