対象別インスペクション攻略法！

要件定義書の攻略方法

　今回は、インスペクション対象ごとの攻略方法やコツに焦点を当て、解説していきます。

　まず、プロジェクトの上流フェーズで要件定義書や設計書をインスペクションする方法について解説します。要件定義書や設計書のインスペクションは、ダイアグラムや自然文で記載されることが多いため、以下の3つの難しさがもともとあります。

1．部分最適になりがち
2．目的と存在意義を忘れがち
3．内容を理解しようとして時間がかかってしまう

　要件定義書では、議論が詳細に入り込んでしまい、全体を見失いやすくなるということが往々にしてあります。1種類のドキュメントを見て全体をOK/NGと判定してしまう場合が最たる例でしょう。

　様々なドキュメントを総合的に判断して要件を表現できているか検証すべきですが、一般的に大量の要件定義書を目の前にすると「中心となるシナリオだけサンプリングしてインスペクションしよう」と間引いてしまう場合が少なくありません。これは、サンプリングの仕方を工夫することで対処するとよいでしょう。ルールとして以下のような基準を設定することです。

・全ての種類のドキュメントから均一にサンプリング標本を抽出する
・作成チームまたは作成者別に仕様書をサンプリングする

　偏在性の確認と均質化を目指すサンプリングですね。

　次に、2つ目の「目的と存在意義を忘れがち」というのは、インスペクションという方式を採用するほとんど全ての開発チームに当てはまります。一般的にインスペクションというのは要件定義書や設計書の特定のページを抜粋し、そこに大勢で注視・注目して内容を検査する手法です。従って、該当箇所が仕様書全体のどの位置づけなのか、プロジェクト全体の目的を満たすかどうか、という視点を忘れてしまう場合が少なくありません。

　特に要件定義書のインスペクションの際には、以下のような質問を何度も自問自答してみるとよいでしょう。

・これは要件か？
・これはプロジェクトの目的達成のために必須か？
・これが実現しなかったらどうなる？

　チェックリストなどのツールにこのような確認ポイントをたくさん列挙しておき、要件定義の目的を見失わないこと、完了基準を明確にしておくことなどが、要件定義書インスペクション攻略のコツになります。

設計書の攻略方法

　設計文書については、内容を深く理解しようとして、インスペクション作業そのものが遅々として進まないという現象も多く見られます。これも前述の要件定義と同じですが、微細な内容に注視しすぎないことがポイントになります。

　まず、最初に設計書をインスペクションするポイントは「定量的に表されるか」を確認することです。大規模開発になればなるほど、何をどれだけ作るのかが定量的に把握され、管理されていることが必須になります。例えば画面が何枚といった大雑把な内容だけでなく、それぞれの複雑度（例えば難易度が3段階程度）などが識別されていると、より正確な見積りとスケジュール設定が可能になります。

　もし詳細なインスペクションが必要な場合、簡単で効率的な方法からはじめるのがインスペクション速度を上げるコツになります。メソッド記述や処理機能定義のインスペクションを例に挙げましょう。筆者の所属組織に新入社員／新人が配属された際には、最初のインスペクション会議で次のように指示されます。

「まず『場合』と『時』を見つけなさい」

　これは、よくプログラムや処理の分岐を示す仕様に現れる「～の場合」や「～の時」といった文字列を探してもらうことを意味します。なぜなら「～の場合」や「～の時」の後ろには必ず「～でない場合、」「～でない時」が記述されていなくてはならないのですが、仕様書上は抜け落ちることがよくあるからです。つまり正常系だけでなく異常系（例外・エラー処理）も書いてあるかを確認するときのマジックワードとして「場合」と「時」を見つけるのです。前提知識が不要でエディタのFind機能だけで検査できるポイントとしては、最も単純で誰でも実施できる観点としてオススメです。

　最後に要件定義のところでも書きましたが「どこまで書いたら終了しますか？」という完了基準ですが、何よりもわかりやすい基準としてオススメなのが、以下を確認することです。

「その仕様書、設計書で、テストケースは導出できますか？」

　設計完了時点で重要なのは実現性の検証です。この実現性という品質特性は非常に保証が難しいため、覚悟してテストケースそのものを導出してみるのがよいでしょう。サンプリングでかまいませんので、当該テストケースは何ケース必要かを仕様書に書き込んでしまうことをオススメします。他の仕様書に比べて極端にケース数が少ない・多い場合等は、なぜ少ないか・多いかという根本原因を探ってください。考え方として、「システムの実現性は仕様書、設計書の試験性を確認する中で見えてくる」というアプローチが有効です。