JaSST'12 Tokyo

Ｗモデルとは何か
鈴木三紀夫

2012/01/25

はじめに• セッション
– 本セッションでは、Ｗモデルに関する解説と、ミニパネルを行います。

• 対象者

４０～５０分の予定– Ｗモデルとは何かを知りたい人– Ｗモデルを導入しようとしている担当者• 目標– Ｗモデルとは何かを説明できるようになる。
1© 2012 Mikio Suzuki All rights reserved.

目次• 現場の状況• Ｗモデルとは• 実践した人の話• Ｗモデルの導入方法

2© 2012 Mikio Suzuki All rights reserved.

現場の状況

3© 2012 Mikio Suzuki All rights reserved.

ある人の悩み• いきなりですよ。年が明けたら「Ｗモデルをやれ」ですから。
• どうやら、業界団体の賀詞交歓会で聞いてきたらしいんですけど。
• うちのチームだけじゃなくて、全社に対して言っているらしい。
• まあ、Ｗモデルという名前ぐらいは聞いたことありますよ。
• でも、何をやるかは知りません。
• テストを先にやるぐらいしか。どこかに本とかあります？
• まだＷモデルの説明会とかやってくれればいいんですけど、当面やる予定はないとか。
• プロセス改善を推進している部署に問い合わせたら、逆に「Ｗモデルって何だ？」って聞かれまして。
• そう言えば、テストに詳しいって言ってたよね。
• 俺にも分かるようにＷモデルについて教えてくれよ。
4© 2012 Mikio Suzuki All rights reserved.

Ｂｅｆｏｒｅ講演を聴く前に、ＷモデルについてＡｆｔｅｒ知っていることを書いてください5© 2012 Mikio Suzuki All rights reserved.

Ｗモデルとは6© 2012 Mikio Suzuki All rights reserved.

Andreas Spillner のＷモデル
Requirements

ExecutingAccept. Tests

Specification

Executing
System Tests

Architectural
DesignExecutingIntegr. TestsDetailed
DesignExecuting
Unit Tests
Coding

ＤＥＶＱＡ
7© 2012 Mikio Suzuki All rights reserved.

Andreas Spillner のＷモデル
Requirements

Starting
Test Activities

ExecutingAccept. Tests

Debugging& Changing

Specification

Planning
System Test

Executing
System Tests

Debugging& Changing

Architectural
DesignPlanning
Integr. Test

Detailed
DesignPlanning
Unit Test

ExecutingIntegr. Tests
Executing
Unit Tests

Debugging& Changing
Debugging& Changing

Codingon the basis ofcycle: testing, debugging, changing, re-testing

http://www.stickyminds.com/sitewide.asp?ObjectId=3572&Function=DETAILBROWSE&Object Type=ART8© 2012 Mikio Suzuki All rights reserved.

activity
requirements
review

T0

T1

T2

T3

T4

T5

T6

T7

T8

T9 T10 T11 T12 T13 T14 T15 T16 T17 T18 T19

T0

T1

T2

T3

T4

T5

T6

T7

T8

T9 T10 T11 T12 T13 T14 T15 T16 T17 T18 T19

architectural design
review

Ｖ-Ｍｏｄｅｌdetail design
reviewcodingunit test
integration test
system test

http://www.informatik.hs-bremen.de/spillner/WWW-Talks/Valencia.html
activityrequirements
reviewarchitectural design
review

Ｗ-Ｍｏｄｅｌdetail design
reviewcodingpreparationunit test
preparation
integration test

© 2012 Mikio Suzuki All rights reserved.

preparation
system test

9

日本では

http://ja.wikipedia.org/wiki/日本地図© 2012 Mikio Suzuki All rights reserved.

10Ｗモデルの様々な定義• Ｗモデルとは– テストのアクティビティを前倒しで実行すること– テスト仕様書を設計書とほぼ同時に作成すること– テスト技術者を上流工程から参画させること– テストチームまたは第三者検証会社を上流工程から参画させること– テスト技術を上流工程に適用すること– 要件定義や設計時にデータバリエーションを作ること– テストの知見を早い段階から開発にフィードバックさせること
11© 2012 Mikio Suzuki All rights reserved.

Ｗモデルに期待する様々な効果• Ｗモデルに期待することは– 短納期開発– 手戻り防止によるコスト削減および利益率向上– 要員の最適配置– ISO9000、CMMIの次のテーマ– お客様への提案テーマ– 技術者の単価向上

12© 2012 Mikio Suzuki All rights reserved.

実践した人の話

13© 2012 Mikio Suzuki All rights reserved.

某社の話 １－１
• 今日は何を聞きに来たの？
– 最近、Ｗモデルを導入したという話を人づてに聞いたので。

• Ｗモデル？ 何を聞きたい？
– ズバリ、聞きます。上手くいきましたか？

• 大きな混乱もなかったから、上手くできたんじゃないかな。
– 何か成果とかありましたか？

• 成果と言えるかどうか分からないけど、バグが３割減った。
– 凄いじゃないですか。どんな工夫をされたのですか？

• 普通よ、普通。別に変わったことやっていないし。
– どの工程から着手されましたか？

• 要件定義！
– お客様は何か言いませんでしたか？

抵抗されたりとか。

• お客様には別にＷモデルをやるなんて言っていないし、特に変わったことは無いわ。
14© 2012 Mikio Suzuki All rights reserved.

某社の話 １－２
– 要件定義からＷモデルに取り組まれたということは、テストに関わる作業が増えたわけでしょう。何か無かったんですか？

• あれかな。業務シナリオを作るじゃない。
– はい。

• 今までも作っていたんだけど、具体性が違うというか。
– 具体的なシナリオを作るとなると、今まで以上にお客様のご協力が必要になりますね。
いろいろ言われませんでしたか？

• それがね。意外だったんだけど、お客様の方がどんどん入り込んで。
– お客様の方が積極的に取り組まれたと。

• 今まで業務フローに基づいてシナリオを説明していたんだけど、儀式というか、全然身が入っていないレビューというか、分かる？
– 何となく分かります。

• テストで使うシナリオとなると、具体的なデータまでイメージするじゃない。そうしたら「あのとき、このとき、あの商品、この商品、代理店で、インターネットで」と、ヒアリングで聞けなかったこと、次々に明らかになって。

15© 2012 Mikio Suzuki All rights reserved.

某社の話 １－３
– まるで、システムテストのときのように• そうそう。システムテストのときのように（笑）
システムテストのときに発覚すると、仕様かどうかというよりも、「対応しないと業務が回りません」って言われてね。
– はい。

• 全部システム対応になるじゃない。
– そういうケースが多いかもしれません。しんどい交渉もありますしね。

• うちは立場が弱いから全部対応になるの。
– でも、今回は違ったと。

• そう、要件定義で分かったから、システムで対応するところと、業務で対応するところをきっちりと区別できて。
– 無駄な機能を作り込まなかったし、無理矢理な対応も無かったと。

• 結果的にそうなるのかな。
仕様変更の胃が痛くなる交渉も少なかったし。

16© 2012 Mikio Suzuki All rights reserved.

某社の話 １－４
– じゃあ、利益率も良かったのでは。

• まぁ、想像にまかせるけど。（笑）
– まとめますと、要件定義からＷモデルを導入し、バグが３割も削減できて、利益率も向上したと。
納期はいかがですか？ 予定よりも早くリリースできましたか？

• そんなことは無いけど、いつもよりも余裕があったのは事実ね。
– 本日はお忙しい中、インタビューを引き受けていただいてありがとうございました。

17© 2012 Mikio Suzuki All rights reserved.

某社の話 ２－１
• まぁ、俺の話を聞け。
– はい。

• お前、Ｗモデルをあちらこちらで言って歩いているらしいな。
– いや、その、Ｗモデルという言葉は使っていないんですけど。

• テストケースの作成を前倒ししろとか言っているんだろう。
– 前倒しとは言っていませんが、似たようなことは言っているかも。

• お前、逃げようとしている？
– そんなこと無いです。そもそも逃げる気なら、ここに来ませんし。

• 俺のプロジェクトでＷモデルに取り組んだんだよ。
– 僕の知らないところで、そんなことやっていたんですか。

• めちゃ、後悔している。
– はい？

18
© 2012 Mikio Suzuki All rights reserved.

某社の話 ２－２
• プロジェクト上手くいかなかったんだ。赤だよ真っ赤。
最後まで言わせるな。
– 何やったんですか？

• だからＷモデル。お前、俺から離れて馬鹿になっていないか？
– まぁ、馬鹿になったかもしれませんけど。それはそれとして、Ｗモデルにはバリエーションがたくさんあるんです。
もう少し具体的に聞いていいですか？
要件定義から始められたということでいいんですよね。

• 要件定義。テストに関わる人間の工数は計画に入っていないから持ち出しだ。
– お客様から費用いただいていないんですか？

• 当たり前だろ。そんなことも分からないなんて、お前現場離れすぎ。
いいか。提案書にテスト作業の工数を上乗せしたら失注するぞ。
厳しいんだよ。最近は。
– よく、あの部長が許しましたね。

19© 2012 Mikio Suzuki All rights reserved.

某社の話 ２－３
• Ｗモデルってあれだろ。開発全体でみると工数が変わらない。
– データが無いので本当かどうか分かりませんが、そういう話を聞きますね。

• お前もそういう説明するだろう？
– う～ん。するときもあるかなぁ。

• トータルで工数が変わらないなら、メリットの方が多いと思うだろ。
– メリットって？

• 上流工程でバグが減るんだろう？！ 俺はそう聞いたぞ。
テストを前倒しするから、それが実現できるんだって。違うのか。
– そうですね。

• バグ減らねぇんだよ。これが。詐欺だろう。
– はい？

• バグは減らねぇは、仕様変更でドキュメントを二重に修正するし、今まで以上にコストがかかるんだ。おい、聞いているか。
– 聞いていますって。

20© 2012 Mikio Suzuki All rights reserved.

某社の話 ２－４
• Ｗモデルは駄目だ。
– えっと。要件定義のときに作ったテストケースって今も残っていますか？
修正する前のがあるといいんですけど。

• 要件定義のときに成果物を一回Fixしているから残っているよ。
– それ見せてもらえますか。ちょっと持ち帰って分析してみます。

一週間後• 何か分かったのか。
– 分かったというか。ちょっと確認したいことがありまして。

• 確認？
– はい。このテストケースですが、どんな方が作られましたか？

• 二年目。それがどうした。
– 作る前に研修とか教育とか行いましたか？

21© 2012 Mikio Suzuki All rights reserved.

某社の話 ２－５
• そんなことはしてねぇよ。何か遠回しな言い方をしているな。
俺はそういうのが嫌いなんだよ。
– はい、えっと、「失礼ながら、先輩の目は節穴でございますか？」• あ”～ !!
– すいません。ちょっと言ってみたかったんです。
言い直します。○○さんは、Ｗモデルのアンチパターンをやっているんです。

• 何だ。そのアンチパターンってのは。知らねぇぞ。そんなの。
– テストケースを見ますと、要件定義書に書かれている内容のコピペなんです。

• それがどうした。テストってのはそういうもんだろ。
だから二年目の奴に任せたんだし。
– そういう○○さんの認識がプロジェクトを失敗に導いたのです。

• 俺に喧嘩売ってる？
– そうじゃ無いんです。いいですか。コピペのテストケースしか作れないメンバで構成されたテストチームの場合、Ｗモデルをやらない方がいいんです。

22© 2012 Mikio Suzuki All rights reserved.

某社の話 ２－６
• そんなこと誰も言ってねぇじゃんか。
– 当たり前すぎて、誰も言わないだけです。

• ・・・なんだ。その。テストケースというのはコピペじゃないと。
– はい。

• そういう二年目をアサインした俺の責任だと。
– はい。

• 耳の痛いことを言うね。
– それが僕の役目ですから。だから僕を呼んだんでしょう。

• まあな。
– ＷモデルってＶ字の反対側のテストケースを書けばいいっていう単純なものでは無いんです。
テスト要求を検討したり、テスト設計することで、ベースとなる要件定義書や外部設計書の弱いところをあぶり出すんです。

• 難しい話になりそうだな。酒飲みながらじゃ、正直しんどい。
今度の部会で喋ってくれよ。
– 分かりました。いつ頃にしましょうか？

23© 2012 Mikio Suzuki All rights reserved.

どちらの話も要件定義からＷモデルを導入しています。

成功と失敗を分けたものは何だと思いますか？

24© 2012 Mikio Suzuki All rights reserved.

Ｗモデルの導入方法

25© 2012 Mikio Suzuki All rights reserved.

やっぱりアジャイル

Ｗモデルはバズワードと結論

どうやったらよいのか分からない
シンポジウムに参加する

現場混乱

上流工程でテストケースを作成する

仕様変更の嵐

各社の事例を集める

期待する効果がでない
同じことをやってみる© 2012 Mikio Suzuki All rights reserved.

26

闇雲に取り組んでいませんか？

27© 2012 Mikio Suzuki All rights reserved.

目的
４．課題解決に向けたゴールの抽出

Ａｓ-Ｉｓ

３．課題の抽出と原因分析

２．現状の理解と見える化© 2012 Mikio Suzuki All rights reserved.

５．ゴールを達成する手段の抽出

１．ステークホルダーの識別

手段

Ｔｏ-Ｂｅ

６．改善状況と施策の計画

28

「２．現状の理解と見える化」（As-Is）

29© 2012 Mikio Suzuki All rights reserved.

Policy

PeopleProcess

ScopeProductManagementSkill
StandardTarget

Think
Style

TechniqueTool30© 2012 Mikio Suzuki All rights reserved.

People、Process
Style、Standardを取り上げます31© 2012 Mikio Suzuki All rights reserved.

People 経営

ユーザ部門

請負の範囲ならなんでもＯＫ

やり方にこだわり無し
早い、安い、美味い

今まで以上に進捗報告の駆り出されるのは 内容が変わるのは勘弁して嫌だなぁ

Ｗモデルの導入
ＷモデルをやるＷモデル知らない

利益率アップアジャイル対応
したばかり

経営スタッフ
適用基準
決めなくちゃ© 2012 Mikio Suzuki All rights reserved.

システム部門ユーザ
企
業

テスト先にやるっておかしい

導入のコストは本部持ちね

ベン
ダ
企
業

現場
32

Process

テスト
計画
テスト
報告

テスト
実装

テスト
実行
33
© 2012 Mikio Suzuki All rights reserved.

Style導入前なので、Styleはありません34© 2012 Mikio Suzuki All rights reserved.

業務
要件定義

Standard

システム
要件定義

基本設計

詳細設計

実装

コンポーネ
ントテスト

受
け
入
れ
テス
ト

コン
ポー
ネン
ト
テス
ト
© 2012 Mikio Suzuki All rights reserved.

システム
テスト

計画

実装

受け入れ
テスト

実行
報告

シス
テ
ム
テス
ト

統合テス
ト

統合
テスト

計画

実装

実行
報告

計画

実装

実行
報告

実装

実行
報告

35

「６．改善状況と施策の計画」（To-Be）

36© 2012 Mikio Suzuki All rights reserved.

People 経営

ユーザ部門

仕様変更が減っている

やり方にこだわり無し
早い、安い、美味い

リリース後のごたごたが少ないぞ。

Ｗモデルの導入
トータルでみると利益率がアップしたな
上手くいかない
ところの原因を把握しよう

経営© 2012 Mikio Suzuki All rights reserved.

システム部門Ｗモデル教育大変
従来の品質指標が使えなくなる

スタッフ
ＰＭ教育の見直しも必要

バグが減っている

ユーザ企
業

バグは減るけど、手間かかりすぎリリース前の混乱は少なくなった

ベン
ダ企
業

現場
37

Process
テスト
アーキテクチャ
設計

テスト
評価

テスト
詳細設計

テスト
計画

テスト
要求分析

テスト
報告

テスト
実装

テスト
実行

38
© 2012 Mikio Suzuki All rights reserved.

Style
要件の定義

システムテストのテスト設計

要件定義でテスト設計

要件定義工程要件の定義© 2012 Mikio Suzuki All rights reserved.

要件定義工程システムテストのテスト設計

基本設計工程39

業務
要件定義Standard
受
け
入
れテス
ト

システム
要件定義

基本設計

詳細設計

実装

コンポーネ
ントテスト

統合
テスト

詳細設計

計画

システム
テスト

実装

要求
分析

実行
報告

アーキ
設計
シス
テ
ム
テス
ト

受け入れ
テスト

評価
詳細
設計

計画

実装

要求
分析

実行

評価

報告

アーキ
設計
統合テス
ト

詳細
設計

計画

実装

要求
分析

実行

評価

報告

アーキ
設計
コン
ポー
ネン
ト
テス
ト
© 2012 Mikio Suzuki All rights reserved.

詳細
設計

計画
要求
分析
アーキ
設計

実装

実行

評価

報告

40

As-IsTo-Be

PeopleProcess

Style
Standard

Think

As-IsとTo-Beを整理して、まとめます41© 2012 Mikio Suzuki All rights reserved.

３．課題の抽出と原因分析

問題
課題４．課題解決に向けたゴールの抽出

目的
期待効果

生産性の向上

品質の向上

短納期の実現コストの削減

スタイル

標準
プロセス

工数
配分

リソース
配分

５．ゴールを達成する
手段の抽出

プロセス
プロジェクトマネジメント
人材担当者

教育

基礎

Ｗモデルの定義© 2012 Mikio Suzuki All rights reserved.

課題、目的、施策
ＰＭ
経営層の関係を明らかにして導入ストーリーを作ります

テスト
プロセス

テスト
計画

テスト
設計

仕様化
42

Ｂｅｆｏｒｅ

講義を聴いた後でＷモデルについて、Ａｆｔｅｒ
どのような感想を持ちましたか。
気づきを書いてください。

43© 2012 Mikio Suzuki All rights reserved.