Software Developer's Think IT

技法とテンプレート！

第1回：インスペクションとは何か？

なぜインスペクション／レビューが必要か？

　「テストは品質を確認する場である。さらなる品質向上を望むならば、設計品質をはじめとした作りこみの段階での品質向上も必要だ」というような話を聞かされたことのある技術者は多いでしょう。

　ソフトウエアインスペクション／レビューは、テストよりも早い段階で実施できる品質向上技法であり、やり方さえ間違わなければその効果は絶大です。ウォータフォールモデルでの開発の通過イベントと考えられていることもありますが、特定の開発モデルに依存したものではなく、繰り返し型開発、オープンソース開発でも使われています。また、ペアプログラミングの代替手段として位置づけている組織もあり、実は広く使われている技法なのです。

　ソフトウエア開発は要件定義、設計、コーディング、テストの順番でコーディングまでは段階的な詳細化が進められます。期待どおり詳細化できたかどうかはテストでプログラムを動作させながら確認します。テストで誤り（欠陥）がみつかれば、必要な段階まで戻って（例えば設計ミスであれば設計書の改変、コードの修正）欠陥を直します。その後、期待どおり直されているかどうかを確認するために再度テストします。

　あわせて、これまで正しく動いていた部分も動作を確認するために追加のテストをします。これは、ウォータフォールモデルに限定されるものではなく繰り返し型開発でも同様です。テスト駆動開発であってもテスト設計やテストコードに対するインスペクション／レビューを実施しておかなければ、同様の手戻りが必要になることがあります。

　段階的な詳細化を間違うと誤ったプログラムが作られてしまいます。図1はその様子を表しています。設計書でサブシステム間のインターフェース定義を読み間違えて誤ったソースコードを書き、結合テストで発見される場合（図1（a））もあれば、そもそも実現できない性能要件を要件として定義している場合もあります（図 1（b））。その誤りがテストでみつかれば、誤った部分の修正、修正の確認、その修正による副作用の確認が必要になります。

　ソフトウエアインスペクション／レビューは段階的な詳細化の途中で（プログラムが完成する前に）ドキュメントやソースコードを目視でチェックし、欠陥や矛盾を早期発見し、その場で対応（修正）することを目的とした活動です。目視でチェックできるので、プログラムが動作する前に実施することができます。

　誤りを早期に発見することができれば修正にかかるコストが小さくて済みます。このような修正コストの傾向を報告した文献もありますので、興味を持たれた方にはお勧めします（詳細は参考文献を参照）。

インスペクション／レビューの具体的活動

　インスペクション／レビュー活動へのインプットは、ドキュメント（企画書、プリセールスの提案書、プロジェクト計画書、要件定義書、各種設計書、ソースコード、バグ票、テスト計画書などあらゆる文書）です。アウトプットは、対象ドキュメントに含まれていると指摘された欠陥のリストです。

　インスペクション／レビュー活動の中での参加メンバの役割は次回以降で詳述しますが、一般には作成者以外のメンバ（インスペクタ、レビューア）が対象ドキュメントに含まれる欠陥、現段階では欠陥にならないが将来的に問題の原因となる部分を指摘します。

　インスペクションのスペシャリスト（プロジェクトや開発対象に関して一般的な知識しか持たないが、インスペクションの豊富なノウハウにより欠陥を指摘する）によって欠陥指摘するものもあります。法務やセキュリティーの専門知識をもっている他部門に仕様書のチェックをお願いした経験のある方もいるでしょう。第三者によるインスペクション／レビューはこれをイメージすればわかりやすいでしょう。ありがちな欠陥や見落とされがちな矛盾に関する専門的ノウハウに基づいて欠陥を指摘します。