JaSST'12 Tokyo

JaSST’12 東京 Ｗモデルセッション～パネル形式の質疑応答～
モデレータ：
パネリスト：

西 康晴（電気通信大学）
鈴木 三紀夫（ASTER）
秋山 浩一（富士ゼロックス）
吉澤 智美（日本電気）
2012/01/25

会場の皆さんから、質問を承ります。
パネリストに答えてもらいます。

1

Ｗモデルは組込み系でも適用できますか？

2

組込み系でも、Ｗモデルは適用できると思います。
組込み系の人にＷモデルの話をすると、「それって、フロントローディング？」と言われます。

フロントローディング
front-loading / 作業前倒し
製品製造やシステム開発のプロセスにおいて、初期工程（フロント）に重点を置いて集中的に労力・資源を投入して後工程で発生しそうな負荷（仕様変更など）を前倒することで、品質向上や納期短縮を図る活動をいう。
＠ＩＴ情報マネジメント用語事典より

3

組込み系でも、Ｗモデルは適用できますし、開発組織の進化に合わせて、ダブルＶモデルになります。

第四段階：ダブルＶモデルの構築

初期段階：ＶモデルワイドＶから挟角のＶへ

設計・修正・テストプロセスが混合設計・テスト・修正＋審査・検査

品質保証のＶ
開発・テストのＶ

審査

検査

検証

要求分析

検証

仕様策定

Ｑ・Ｃ・Ｄの向上
基本設計

設計

戦略の道筋

修正

検証

詳細設計

受け入れテスト/
システムテスト
統合テスト
単体テスト

テストプロセスの分離テスト設計の前倒し（Ｗモデル）

テスト設計

品質保証による加速（ダブルＶ）

検査

テスト設計
設計

設計・修正モデル＋テスト設計・検査

設計

修正

修正
設計

第三段階：検査プロセスの確立

テスト

修正

第一段階： Ｖモデル＋／設計・修正・テストプロセスから
第二段階：Ｗモデルの構築 テストプロセスを分離
設計・修正＋テスト設計・テスト

組込み系の開発組織は、最初は少人数で開始することが多いものです。
開発とテストをする人が混成チームをなしています。
V字モデルで開発を始めますが、開発製品が次第に複雑化してくると行き詰まり感が出てくるようになります。

 初期段階： Ｖモデル
 その組織にとって開発規模は適切で上手く回っている Ｖモデルなどなんらかのプロセスモデルを採用している
 開発とテストは同じ人が実施していて効率がよい状態

5ある時、大きな不具合が発生し大問題が起こります。
そこで不具合を防ぐために、テストを一生懸命しようという考えがうまれます。
そしてテストを分離して専門家を作りテスト技術を高めていきます。

 第一段階： Ｖモデル＋／
 開発規模が増え、複雑度が増加し市場トラブルが出る 市場トラブルへの対策としてテスト技術が着目される
 初期段階ではデバッグとテストが混合しているためこれを分離することで第一段階に至る
 テストの専門組織ができる
 テストの専門技術が高まる
 デバッグ（＋修正）の専門技術も高まる

6

そのうちに、ふっと、上流工程で見つけられる不具合をわざわざテスト設計工程まで遅延して見つけていることに気がつきます。
テスト設計工程を上流工程で行うことによって、不具合の検出遅延を防ぐようになります。

 第二段階： Ｗモデル
 テストは上手く回るようになったがバグの総数は減らない
 テストでバグを指摘しても市場導入間際で直してもらえない テスト設計するだけでバグが見つかるのであればそれを前倒しすればよいということに気が付き第二段階に至る 上流工程にテスト設計工程が並行する
 バグの数が減ってくることが体感できる

7

Ｗモデルが進むと開発者もテストのことを考慮しながら要求定義・設計・実装を行うようになり、開発技術が進化してきます。
その結果、生産性が上がり、Ｗの角度が鋭角になっていきます。

 第三段階： 検査プロセスの確立
 テスト組織から設計やコードの知見が抜けてくる グレーボックス的なテストの方が効率が良いことに気が付く
 上流工程に近い単体テストから、開発にテスト作業を移管しだす
 テスト組織は、（探針などの）検査によりテストの質や量を決定する
 テスト組織は、テスト全体のアーキテクチャを考えるようになる

8

Ｗモデルが進むと、開発組織やテスト組織におけるテストの前に、ＱＡ組織がサンプリングで検査を行ってテスト量を決められるようになります。
ダブルＶモデルの内側のＶ字は、QA組織が外側のＶ字モデル（開発→テスト）に合わせてＱＡしていくという意味です。

 第四段階： ダブルＶモデル
 開発自身が、テスト設計技術を取り入れて、テストの観点を反映したソフトウェア設計ができてくるので、上流工程でのテストの専門家の指摘が徐々に不要となる
 テストエンジニアは、テスト以外の観点でも上流工程の中間成果物の出来栄えの評価ができるようになり第四段階に至る
 開発者とテストエンジニアの違いが無くなりＷは一本の線に戻る
 この段階においては、技術向上による組織成長活動を牽引する審査と検査による品質保証活動が重要となる
 ダブルＶモデルの下のＶは、Ｖモデルの下のＶと同じであることに気が付く（ただし、初期段階から大きく技術力が向上したため品質と9生産性は格段に向上している）

組込みの場合は、QA組織の位置づけが重要なのでしょうか？

従来のQA組織はプロセス監査が中心なので、テスト技術を用いてサンプリング検査活動を強化して、QA組織の能力を向上する必要があります。

10

組込みの場合は、CやDよりもQを優先することが多いようです。
また、検証を後段でなく、システム仕様を作るところでシミュレータを使い、論理的な部分のバグを潰します。
スモールＶ字モデルと言うこともあります。
テストをどう抜くかよりも、いかにテストをきっちりやるか、そこでテストの観点を設計段階に持ち込んで早めに不具合を潰すような活動をしていました。
でも、図に示してWになるかはわかりません。

スモールＶ字モデル
全体のＶ字の上流側の各工程で、シミュレータなどで検証するスモールＶが、全体のＶ字に付いているモデル

11

パネリストの皆さんは、自分なりのＷモデルというものを持っています。
そのため、質問に対する回答になっているか分かりません。

Ｗモデルの効果は定量的に測定できますか？

13

どんな技法でもそうですが、トライアルで効果を測定します。
トライアルで得られたものを従来のものと比較します。
施策になり、みんなでやる段階になったら、効果を測定しません。
例えば、2社に発注してやり方をそれぞれ変え効果を確認してみるなど。
費用はかかりますが効果を測定するのが目的であれば仕方がないことだと思います。
短期的に損をするかもしれないけど、技術投資と割り切ります。展開するかどうかは、経営判断になります。

２社に発注できる組織は限られてしまいますね。
会場が悲しい雰囲気になっています。

総バグ数を少なくしたいのなら、いつどこでバグがどう出ているのかを比較すればよいと思います。
中長期的に捉えるのならば、出荷後に無償サポートや無償バージョンアップをしなくて済んだコストの減少を見ることができます。

15

現場に適用するとテスト工程で検出されるバグ数が圧倒的に減ります。
定量的に示せるかどうかで、悩んだことはありません。

16

バグの傾向を特定し、特定のバグを防ぐ部分だけを前倒しにします。
バグのパターンごとに測定するとＷモデルの効果を測れます。

17

Ｗモデルは「要求の引き出し」に効果があるのでしょうか？

18

講演の中では、「要求の引き出し」に効果があった事例を紹介しました。
要件定義工程でＷモデルを採用したとき、一番効果が高いのは、「要求の分析」です。
要求をテスト技法で用いているモデルで記述し直すことで、曖昧であったり、抜け漏れが存在する要求があぶり出されます。

19

REBOKの要求工学プロセスを用いて説明すると、Ｗモデルは下記の要求分析に効果があります。
分析した結果、必要に応じて要求獲得に戻り、新たな要求を引き出します。
REBOK
共通知識カテゴリ要求の計画と管理
要求開発

要求獲得

獲得要求

分析要求
要求仕様化

REBOK
拡張知識
カテゴリ

システム構築

要求の源泉

要求分析

要求仕様化

エンタープライズ分析
要求の検証・妥当性確認・評価

プロダクト分析

要求工学プロセス
基礎知識

実践知識

実践の考慮点要求工学の基礎

20

Ｗモデルは、下流で検出できるバグを上流でバグを検出しているだけなので、バグそのものの数は減らないのでは？

21

誰に答えてもらおうか。

じゃあ、ミッキーさん。

「当てないで」というアイコンタクトだったのに。
このテーマ、短い時間で答えられる自信が無いんだ。(>_<)

22

開発のモデルとテストのモデルを同時に作成します。
開発の設計とテストの設計が、お互いに影響を与えるので、上流工程で、バグをカウントし辛くなります。

う～ん、分かり難いですね。
Ｗモデルを導入すると、上流工程で、バグは減るんですか、変わらないのですか。

・・・・・・

とりあえず、棄権ということで（笑）
23

Ｗモデルのスタイルによって欠陥数は変わるのになぁ．．．

１

要件の定義

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

システムテストのテスト設計②のようなスタイルを採用し、かつ、テスト仕様書に基づいてレビューする場合は（テストケース・ベースド・リーディング）、テストケースによる欠陥除去数を計測できます。
①のようなスタイルを採用した場合、開発とテストが両方に影響を与えるため、欠陥指摘による修正と試行錯誤による変更の境界が定めにくくなります。
24

テストの視点を上流に持ってくると、使う側の視点を前倒しできるので、要求や設計の質がそもそも上がります。
上流でバグを潰すと派生バグが減るので、作り込みバグは減ります。

25

開発が考えていない市場環境をテストの前倒しによってあらかじめ気付くので、開発の質（技術力）が上がります。
企画時には、要求の偏りが発生することがあります。
テストにはその偏りを是正する働きがあるので、企画の質が上がります。

26

バグのパターンを開発者が、あらかじめ気付いておくと、そのパターンのバグを作り込まないようになります。

27

もう少し質問を承りたいところですが、お時間が来たようです。
我々は今後もＷモデルについて研究していきます。
皆さんも一緒にやりませんか？

アンケートにも協力してください28アンケートへのご協力ありがとうございました

29

Ｗモデルに求めるもの（ロール別）

納期短縮よりも品質向上に関心が集まっています30

Ｗモデル導入にネックとなるもの（ロール別）

Ｗモデルとアジャイル開発は相性が悪そうだと感じている人が多いみたい31