レビュー/インスペクション/ウォークスルーについて私の業務経験上での所感とともに概要（一般論）を述べ，私が研究テーマとして取り組みたいことを書くことにする．（現在，埋めていこうとしているところでありまだ完成していない）

レビューの概要（一般論）

一般に，ソフトウェアの不具合や矛盾は早く発見されたほうが修正コストが小さくなるといわれており，不具合や矛盾を早い段階で検出することがレビューの目的である．コードレビューであれば，テストよりも早く不具合や問題を検出すること，設計レビューであれば，コーディングよりも早く不具合や問題を検出することが目的となる．また，実際に修正コストが小さくなることがいくつも報告されている．

国内でレビューというとSIerでは設計書のレビューが，組込み系ではコードレビューを指していることが多いように思う．学術分野ではコードレビューの割合が高いように思う．以下はその代表ではあるが，障害時の対応フローやプリセールス用の資料もレビューの対象となりうる．

• 要求仕様
• 設計書
• ソースコード
• テスト仕様，設計書，テストケース

IEEEやCMMIにも定義があるが，これらの定義は厳密には使われていないことのほうが多いというのが私の感触だ．また，インスペクション，レビュー，ウォークスルーと区別して呼ばれることがあるが，特定の企業での定義であることが多く，個々にばらばらであるようだ．一般には，インスペクションが最も公式なものであり，ウォークスルーがもっともカジュアルな形で実施されることが多いようである．きちんと解釈が必要な場合には，これら3つが同一の意味を表していると考えた上で，実施内容や方法をみてから判断したほうがよさそうだ．

取り組みたいこと

以下の有効性を検証したいと考えている．収集コストが小さいことと，それなりの効果が得られることが期待されるからである．

1. レビュー前に実施しておくべき作業の定義と実施の有無
2. レビューのperspective数（役割分担数）とperspectiveに沿った指摘の数
3. 指摘重要度の分類（軽微、重大、どちらでもない）
4. 指摘内容の分類（正常系、異常系、非機能）
5. 指摘対象機能
6. 指摘の順番
7. ソフトウェアFMEA

1はレビューをはじめる前に実施しておくべき内容がある程度定義されているかどうかを確認するための作業定義の有無と定義に基づく検証を実施したかである．たとえば，レビューの範囲をきちんと定義しているか，フォーマットに従って書かれているか，用語の統一はできているか，コミュニケーションルールに従って作成されているか，未確定の仕様に対する懸案事項は列挙されているか，が含まれる．

2は参加者毎に観点(perspective)を決め，それどおりの指摘ができているかを記録する．たとえば、パフォーマンス，メモリリーク，セキュリティ，業務フロー，ハードウェア，ノイズ，運用フロー，導入/移行，ユーザビリティ等の観点から設計の不備を指摘をする．

3はいわゆる分類である．軽微なものばかりであったり重大なものばかりであったりすると再度実施する必要があるかもしれない．

4は手動テストをするならばどの類のテストで検出されるものなのかを記録する．異常系が多く指摘できるということは正常系についてはある程度固まったものがあることを示す可能性がある．正常系ばかりであれば，指摘反映後に異常系や非機能に関するレビューを再度実施する必要があるかもしれない．

5は時間，コストに制限がある中でもっとも優先して製造，テスト/リリース，レビューすべき機能を選択する際の判断基準になる．指摘が十分であるものは早めに次の工程に移ることができるだろうし，最低限，再レビューが必要なものがどれかを決める判断基準にもなるだろう．

6はレビュー指摘の優先順位を指す．複数人で実施するレビューであれば，レビューのミーティングはそれなりに高コストのものになる．レビューではそれに見合う指摘を優先的に実施すべきであり，テストで発見したとしても修正コストがそれほど高くないものについては，指摘の優先順位が低いことが求められるだろう．みんなで集まって実施するレビューならば，それに見合う指摘をすべき，というものだ．

7ではハードウェアの手法であるFMEAをソフトウェアへの適用を試みる．FMEAはFailure Mode and Effect Analysis（故障モード影響解析）の略である．類似の不具合を発見できる抽象度で起こりうる不具合を故障モードとして列挙し，深刻な故障モードから順番に開発物の欠陥を指摘する．