バグが激減？ 手間が倍増？ Wモデル導入成否の分かれ道 ―― ソフトウェアテストシンポジウム 2012東京（JaSST'12 Tokyo）（2）

●成功するWモデル，失敗するWモデル

　このように，一言で「Wモデル」といっても，その定義は人によって異なっている．関係者間のWモデルについての認識を合わせて施策に取り組むかどうかで，Wモデル導入は成功と失敗とに道が分かれる．ここで，Wモデル導入に取り組んだ「成功事例」と「失敗事例」の特徴が，ストーリ仕立てで紹介された．

［Wモデル導入に成功した例］

　あるプロジェクトでは，要件定義の段階から，テストの準備を始めた．要件定義と並行して，テストのシナリオを考えたことにより，かなり早い段階で業務で用いる具体的なデータ・イメージを持って顧客と会話できた．これにより，通常よりも詳細な要件を引き出すことができた．その結果，適確な要件獲得に成功し，システムで対応するべき要件と，業務で対応するべき要件の切り分けもできて，システム開発の手戻りが減った．そして，システム開発が進み，予定通りのリリースができ，開発後半はいつもよりも余裕があった．また，バグの発生も3割削減でき，プロジェクト全体の利益率も向上した．

［Wモデル導入に失敗した例］

　別のプロジェクトでも，やはり要件定義の段階から，テストの準備を始めた．このチームは，「Wモデルで取り組め」と上司から言われ，今までのテスト・ケース作成をそのまま要件定義と並行して進めることでWモデルを実施した．また，テスト・ケース作成担当は，過去のプロジェクト実施時と同様に，経験の浅いテスタであり，テスト・ケースは仕様書をそのままコピー＆ペーストして作成するようなものであった．システム開発が進んだ後工程では，今までと同じように顧客から変更要求が発生した．その結果，仕様書の変更と作成済みのテスト・ケースの変更が必要になった．ただ手間が倍増しただけで，良い成果は全く得られなかった．

　これらのストーリは，鈴木氏が実際に見てきた現場で起こったことである．いずれも，要件定義の段階からWモデルを導入している．しかし，失敗例はテスト・ケースの作成（いわゆるテストの実装）を前倒しにしただけで，その前に行うべきテストの計画・分析・設計を何も行っていない．これは，Andreas Spillner氏の定義したWモデルですらない．

　同氏はこれらの事例について，「成功した方のプロジェクトは普通のプロセス改善を行ったと思っており，Wモデルを導入したとは言っていない．しかし，結果としてWモデルをうまく適用しており，圧倒的にプロジェクト後半で検出されるバグが少なくなった」と語った．

　また，「Wモデルにやみくもに取り組んではいけない，現状（As-Is）の理解と見える化をまず行い，その上で課題に対する目標（To-Be）を抽出し，ゴールを達成する手段の抽出・改善施策の計画を行わなければならない」と説いた．そのような検討の過程として，Wモデル導入時に，リッチ・ピクチャ^注1を使って，ステーク・ホルダ間の利害関係を表現して検討する方法が紹介された（図3，図4）．

注1：リッチ・ピクチャとは，概念や状況をイラストなどを交えた図（絵）として表現したものである．SSM（Soft System Methodology；ソフト・システム方法論）のツール（道具）として用いられている．なお，今回提示した例は，鈴木氏によって，オリジナルの使い方 からかなりカスタマイズされている．

図3　ステーク・ホルダの利害関係図：現状の把握（鈴木 三紀夫氏の発表資料より）

図4　ステーク・ホルダの利害関係図：目標の抽出（鈴木 三紀夫氏の発表資料より）