1.
ソリューション・サービス開発本部
秋山 浩一
分解について
© 2016 Fuji Xerox Co., Ltd. All rights reserved.
～ テスト要求分析の基本となる、分解の実践的な考え方と演習 ～
2016年6月19日（日） WACATE 2016 夏
1
 各種SNS、ブログ、ご自由に
 Twitter: @akiyama924
 上記にスライド（PDF）へのリンク張りました
 演習は紙でもパソコンでもご自由に
 個人演習のみでグループ演習はありません

2.
自己紹介
2
 1985年4月 富士ゼロックス入社
 HAYST法のコンサルティング業務に従事（テスト上流系）
 D-Caseを用いた「機能安全ケース」等の合意形成手法
 NPO ソフトウェアテスト技術振興協会（ASTER） 理事
 JaSST東京実行委員（2003～、今はアドバイザ）
日本最大のテストシンポジウム1600名の動員
 JSTQBステアリング委員（2006年～）
テスト技術者資格認定を行う国際組織（ISTQB）の日本支部
 日科技連 SW品質管理（SQiP）研究会 委員長（2011～2013年）
 テスト分科会主査・副主査（2008～）
 ISO/IEC JTC 1/SC7 WG26委員（2009年～）
ソフトウェアテストの国際標準「ISO/IEC/IEEE 29119」の策定
 共著書『ソフトウェアテストHAYST法入門』（2007年）
日経品質管理文献賞受賞
著書『ソフトウェアテスト技法ドリル』（2010年）
『事例とツールで学ぶHAYST法』（2014年）※いずれも日科技連出版社
 博士（工学）：信頼性情報システム工学専攻、日本品質管理学会代議員
© 2016 Fuji Xerox Co., Ltd. All rights reserved.

3.
ウォーミングアップ問題（3分×2回） 都道府県名
3© 2016 Fuji Xerox Co., Ltd. All rights reserved.
二回目（ヒントつき）一回目（ノーヒント）

4.
ウォーミングアップ問題（3分×2回） 都道府県名
4© 2016 Fuji Xerox Co., Ltd. All rights reserved.
二回目（ヒント）
1. 北海道・東北(7)
2. 関東(7)
3. 中部（東海・中部・北陸）(10)
4. 関西(6)
5. 中国（山陰・山陽）(5)
6. 四国(4)
7. 九州(8)
1都1道2府43県＝47都道府県

5.
分解できるようになるとうれしいこと
5
 要求が分かる（「走りきるテスト設計」の『テスト（要求）分析』が上達）
 要求するほうも分かっていない（分解して聞き出す＝分解の意図大事）
 例） 「自動販売機がほしい」
← 要求が大きすぎる（小さく分解すると分かるようになる）
← 「どんな自動販売機がほしいの？」と聞かれても困る（答えられない）
← だから分解する（たとえばUSDMでは次の4つの方法を紹介している）
 時系列に分解（コインを投入、商品を選択、商品とおつりを受け取る）UC的
 構成で分解（コイン投入口・金庫＋金額計算、商品格納ラック＋温度制御）、
 状態で分解（販売員が商品をセット、購入待ち、購入中、ルーレット動作中）
 共通部分をくくりだすことで分解（エラー処理、ログ、本部との売上情報通信）
 要求を説明できる（1ページにまとめなおす←無視する人が多いが大切）
 上手く分解すると仕事が何十倍も楽になる
 共通理解（ステークホルダー全員で1枚を共有）
 部分理解で済む（他との相互関係がないから）
 仕事が分担できる（場所・時間・人）
 小さいものは理解しやすいし、作りやすいし、テストしやすい
（場合が多い、、、反例はGoogle検索とか自由度が高いもの）
© 2016 Fuji Xerox Co., Ltd. All rights reserved.

6.
分解の極意１ 分解
6
 分解の意図が大事（自然に分かれるはウソ）
→ 思い付きで分割してもうまくいかないので既存フレームワークを使う
 USDM（清水吉男氏）： 時系列、構成、状況、共通部分
 VSTeP(※1)のCBIFW： 条件、振る舞い、テスト対象、失敗、魅力
 Ostrandの4つのビュー(※2) ： ユーザ、仕様、設計・実装、バグ
 オブジェクト指向： ビジネスの視点、仕様の視点、実装の視点
 品質特性： 機能適合性、性能効率性、互換性（共存性、相互運用性）、
使用性、信頼性、セキュリティ、保守性、移植性（ISO 25010より）
 区分原理（＝分解の意図、QCの7つ道具で言えば、層別）
→ 分解には原則が4つある（Wikipediaより引用）
 一貫性の原則 - 各段階における区分原理はただ1つでなければならない
 相互排除の原則 - 区分肢は互いに排他的でなければならない
（MECE：次ページ）
 一致の原則 - 区分肢は全ての場合を網羅する（枚挙：次ページ）
 漸進の原則 - 区分は順序通りに上位概念から下位概念に進むべきで、飛躍
してはならない
© 2016 Fuji Xerox Co., Ltd. All rights reserved.
※1： VSTeP: http://qualab.jp/vstep/
※2： 情報処理 Vol.49 No.2 Feb. 2008 pp.127-132

7.
分解の極意２ 枚挙
7
 MECE
→ （ミッシーもしくはミーシー： Mutually Exclusive and Collectively
Exhaustive の略）とは「モレなし、ダブリなし」の意味
 漏れなく（重要）
 個人が一気に作る（スピードが必要）
 対称を考える（Aと非Aなど、補集合、意地悪漢字←ググってね）
 ダブりなく（個人作業では神経質にならない、組織間では注意）
 他組織との間のダブり： 開発とテストで同じテストをしないように
 工程間のダブり： 統合テストとシステムテストで同じテストをしない
ように
 一致の原則
→ 区分肢は全ての場合を網羅する（レビューしてみんなの知恵を集める）
 兄弟ノードは同じ粒度にすること
 ツリーを下から追って、子ノードをまとめて「～だから（So what ?）
」親ノードになっているといえるか（論理の飛躍はないか）
 ツリーを上から追って、親のノードを展開すると子ノードは「なぜなら～
（Why so ?）」の関係でしっくりくるか（前提条件の抜けはないか）
© 2016 Fuji Xerox Co., Ltd. All rights reserved.

8.
分解の極意２ 枚挙の図
8© 2016 Fuji Xerox Co., Ltd. All rights reserved.

9.
分解の極意３ 綜合
9
 要素を出してまとめる方法
→ たくさん思い付きを挙げてからグルーピングする
 要素はインスタンス、グループはクラス（次ページ演習）
 綜合のステップ
1. 例を挙げる
2. 綜合する
3. 構造がわかる
4. （自分がソレを）理解する
5. （他人にソレを）説明できる
 KJ法
 ポストイット
 モデレータ大切
© 2016 Fuji Xerox Co., Ltd. All rights reserved.

10.
問題（10分） 綜合 「木戸に立てかけし衣食住」（雑談）
10© 2016 Fuji Xerox Co., Ltd. All rights reserved.
 木 気候や季節の話
 戸 道楽（趣味）の話
 に ニュースの話
 立 旅の話
 て 天気の話
 か 家族の話
 け 健康の話
 し 仕事の話
 衣 ファッションの話
 食 食べ物の話
 住 住まいの話
 上記をグルーピングしツリーを作り、グループに名前をつける
（脳の中のモヤモヤネットワーク → 階層構造 → シリアル）
衣食住
衣
食
住

11.
「ちゃんとテストした？」に答えられますか？
11
 従来のテストはちゃんとしているか？
① 仕様書を順番に動作確認する（仕様書がなければマニュアル、
マニュアルもなければ画面上の一つ一つのメニュー）
→ 単機能の問題は全て見つかる （※ 開発者テストと重複）
→ 市場導入後に「条件」の漏れが見つかる
（「〜と同様」という仕様書、「〜の場合」が漏れる）
② テストの終了基準
→ リリース日から逆算して終わる
→ 信頼度成長曲線で95%のバグ収束（誰も信じていない）
→ 客観的網羅（C0，C1，MC/DC：制御フローカバレッジ）
 例） HAYST法
 目的で分解 → 2～3機能間組合せで綜合
 条件との組合せをテスト（ｘｘ動作中、ｙｙの環境下）
 組合せ網羅率で品質を確認（枚挙結果の数値化）
© 2016 Fuji Xerox Co., Ltd. All rights reserved.

12.
問題（10分） 自動車
12© 2016 Fuji Xerox Co., Ltd. All rights reserved.
派生開発時のテストを分解道路を分解（自動運転）