ソフトウェアテストシンポジウム2010東京(JaSST’10 Tokyo)

Ｏｐｅｎｉｎｇ＜自己紹介＞
・(株)日立システムアンドサービスで、主にパッケージソフト および
ソリューションサービスの品質保証業務に従事中。
・JaSST’09 Kansaiで「レビュー眼」と称して、レビュアーの持つ暗黙知(勘・経験・度胸)の解明について考察。
http://www.jasst.jp/archives/jasst09w/pdf/A2-4.pdf
・JaSST’10 Tokyoでは、JaSST’09 Kansaiの内容を、より具体化し かつ 応用可能なノウハウを含めて紹介する。

レビュアーの３Ｋ（勘、経験、感性）を活発化させる発想術「レビュー眼」のご紹介
２０１０年
２０１０年１月28日
28日

株式会社 日立システムアンドサービス
品質保証部

Kadoguchi Yoshitaka

角口 勝隆

角口 勝隆

y-kadoguchi@hitachi-system.co.jp
1
All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

◆本発表の、対象とする方◆本日の流れ・いつも納期直前にバグが多発し、もっと早くバグに気づけないものかと、悩んでいる方・仕様誤りによる、作り直しや再テストを軽減させたいと考えている方
・テスト設計で「検討漏れや不足がある」と悩んでいる方・「仕様書の行間を読め」と言われたが、見えないものをどうやって見れば良いのか、まじめに悩んでいる方・「レビューって、なんだろう？」という方・レビューで指摘されるのが、うんざりという方・レビュアーとして、ステップアップしたい方
・上述するような部下を抱えている方？

１．レビューって、なんだろう？
どこが、ポイントなんだろう？

！
３．実際の要点をつかんで、
ステップアップ！
（音符の、半音上がるという意味でステップアップ）

２．そうか、ここがポイントなのか！

＃◎

４．今日は、良い時間を過ごせた。
即、現場で役立てよう！
2

3

All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

◆「レビュー眼」とはＣｏｎｔｅｎｔｓ

・観点、着目点・心得
・考え方、思考内容（勘、経験、感性）はじめに
１．レビューの一般論
２．現状のレビューの問題点

本発表では、
優れたレビュアーの持つ３Ｋ（勘、経験、感性）を活かす発想術を３．レビュアーの思考プロセスの分析「レビュー眼
レビュー眼」と称し、その内容について、考察を述べます。

４．レビュー向け発想術の考察
５．レビュー向け発想術のまとめ
６．今後の展望
3-1
All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

4
All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

◆「レビュー眼」を極めれば、◆「レビュー眼」の位置づけ①プロジェクト全体
プロジェクト全体の全体の品質リスク
品質リスクを
リスクを、事前に事前に予測できる予測できる。
できる。
テスト設計技術
設計技術が
向上する
する。
②テスト
設計技術
が向上
する
。

レビュー眼：発想術
├ 観察法
└ 発想法

プロセス
インスペクション、
ウォークスルー、
パスアラウンドレビュー、
ピアレビュー など

規格,規則
技法・ツールBUG

パーソナル・
スキルウォーターフォール、
スパイラル、
アジャイル など

計画、方針

BUG

5

6

All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

◆QCDについて
Case

品質

費用

納期

Ｃｏｎｔｅｎｔｓ

事例

評価

費用の限界と、納期が近づいたので、ある程度の品質(最低限の動作が可能)状態で、完了させた。

必ずしも、お客様にとっての品質が良いとはいえない。
納品後のクレーム対応の損
失あり。

はじめに
１．レビューの一般論

１

△

○

○

２

△
↓
○

○
↓
△

○

納期直前で品質に問題があることが判明。短期間で品質を確保するために、人員をかなり投入した。

プロジェクトとして、必ずしも成功とはいえない。

３

×
↓
△

×

×

品質が悪く、デグレードが多発。後戻り作業が多く、修正／見直しに人員と期間を費やした。

最悪の事態

３．レビュアーの思考プロセスの分析

４

◎

○

○

品質が早期に確保され、後戻り作業や追加作業が無く、予定通りの費用と納期で完了した。

理想形

４．レビュー向け発想術の考察

２．現状のレビューの問題点

５．レビュー向け発想術のまとめ
６．今後の展望6-1

7

All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

1-1 レビューの定義について

All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

１-２ レビューの重要性

レビュー（Review）：批評、再検討、再確認「ソフトウェア開発 201の鉄則(日経BP社)」では、原理41で要求仕様誤りの修正コ
ストについて述べられている。
要求仕様誤りを「１」とした場合の修正コスト
設計段階..........5倍
コーディング時...10倍
テスト段階.......20倍
納入時点........200倍

レビューの目的①埋め込まれた不具合の摘出②埋め込まれる不具合の予防※修正コスト以外に、日程遅延や信用失墜などの損失あり

上流工程から、発生する不具合を除去することで、「品質を作りこむ」ことを目的とする。

要求仕様

8
All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

設計段階

コーディング

テスト

納入時点

9
All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

1-3：レビュー技法の一例について
主な目的

技法

Ｃｏｎｔｅｎｔｓ

概要

対象の合否判定 インスペクショ 専門チームによるレビューを行うとプロセス改善 ン（または、レビューを受ける）
不明点や、間違い/勘違いの発見

ピアレビュー

はじめに
１．レビューの一般論「同僚によるチェック」の意味合い。
※幅広い意味があるが、ここでは狭義に捉える。

成果物のエラー ウォークスルー 役割を決めて、実際の処理流れに沿って、抜の発見
けや検討漏れがないか確認する。

多数の意見を収 パスアラウンド 「回覧・回し読み」などで、たくさんの人の集
意見を集める。(多重同時進行)

２．現状のレビューの問題点
３．レビュアーの思考プロセスの分析
４．レビュー向け発想術の考察
５．レビュー向け発想術のまとめ
６．今後の展望9-1

10

All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

２－２ レビューで問題を見逃す主な原因

２-１ レビュー効果が上がらない現場の例①着眼漏れ（見ようとしない、気付かない）
機能仕様レビュー結果報告：②思考の偏り（思い込み、思い違い）・100ページあたり、30件の不具合を指摘しました。
（指摘内容は、誤字脱字，様式不正などばかり）
・40項目のチェックリストに従い、全て確認し、問題はありませんでした。

・ソフトウェアに対する「要求」や「仕様」は、
目に見えない。
・仕様書があるといっても、完全な情報を得る／伝えることは難しい。

社外不良反省会：
・そのような使われ方は想定していませんでした。
・テストケースが思い浮かびませんでした。
・仕様書に記載がなく、テストが漏れました。

11

12

All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

例えばですが、、、Ｃｏｎｔｅｎｔｓ

隣の部屋にいるなど、右の図が見えない人に、ウサギの詳細を伝達する場合。
見た目だけではなく、様々な観点で観察をし、情報を得る必要がある。

はじめに
１．レビューの一般論
２．現状のレビューの問題点
３．レビュアーの思考プロセスの分析
４．レビュー向け発想術の考察
５．レビュー向け発想術のまとめ
６．今後の展望13

All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

14
All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

３-１ レビュー時の思考プロセス

契約との齟齬
提案書との整合性

新機能の仕様概要について：

携帯電話から、画像データをWebサーバへアップする機能を備える。ただし、関連者のみ利用可能。

新機能の仕様概要について：
携帯電話から、画像データをWebサーバへアップする機能を備える。ただし、関連者のみ利用可能。

＜レビュー時の思考プロセス＞
1)関心を持つ（感性）2)ヒラメキ、勘が働く（勘）3)仮説を立てる（経験）4)指摘する（度胸）(詳細は、仕様概要を説明後に実施されるという前提で実施)

気になるキーワードを
捕らえる。

15

16

All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

関連者って、誰？

関連者って、誰？

新機能の仕様概要について：

新機能の仕様概要について：

携帯電話から、画像データをWebサーバへアップする機能を備える。ただし、関連者のみ利用可能。
＜レビュー時の思考プロセス＞
1)関心を持つ（感性）2)ヒラメキ、勘が働く（勘）3)仮説を立てる（経験）4)指摘する（度胸）

携帯電話から、画像データをWebサーバへ・”関連者”の定義は？
アップする機能を備える。ただし、関連者
・認証の仕組みは大丈夫？
・関連者の登録は、どのように行う？
のみ利用可能。
・関連者以外がアクセスすると、どうなる？

＜レビュー時の思考プロセス＞
1)関心を持つ（感性）2)ヒラメキ、勘が働く（勘）3)仮説を立てる（経験）4)指摘する（度胸）キーワードから、
何か、ヒラメキが生じます。

この内容で正しいのか、仮説を立てた上で、検討する。

17
All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

３-２ 優れたレビュアーの指摘内容を分析

関連者って、誰？

1)優れたレビュアーは、
怪しいポイント(着眼点)を押さえている！
2)優れたレビュアーは、的確に不具合を摘出できる！
3)優れたレビュアーは、仕様の矛盾・抜けを見破れる！
4)優れたレビュアーは、不具合を予防するための、
適切なアドバイスを行うことができる！

新機能の仕様概要について
携帯電話から、画像データをWebサーバへ・”関連者”の定義は？
アップする機能を備える。ただし、関連者
・認証の仕組みは大丈夫？
・関連者の登録は、どのように行う？
のみ利用可能。
・関連者以外がアクセスすると、どうなる？

＜レビュー時の思考プロセス＞
1)関心を持つ（感性）2)ヒラメキ、勘が働く（勘）3)仮説を立てる（経験）4)指摘する（度胸）18
All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

仮説に基づいて質問・指摘を行う。
19
All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

20
All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

3-4 レビューにおける改善課題のまとめ

３-３ エラーを作り込む箇所の分析
レビュー時の思考プロセス：・怪しいポイント
しいポイントを
ポイントを押さえるコツ
さえるコツとは
コツとは？
とは？
・的確に
的確に不具合を不具合を摘出できる摘出できるコツ
できるコツは
コツは？
そして、
そして、
仕様の
仕様の矛盾，
矛盾，抜けを見破
けを見破る
見破るコツは
コツは？

1)関心を持つ（感性）2)ヒラメキ、勘が働く（勘）3)仮説を立てる（経験）4)指摘する（度胸）・対象物を
対象物を見る目(観点)観点)を体系化
・思考の
思考の偏りをなくす（陥りやすい死角
りやすい死角をなくす
死角をなくす）をなくす）
・蓄積された
蓄積された勘された勘や経験を経験を、スムーズに
スムーズに引き出す
21

22

All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

レビュー向け発想術「レビュー眼」
Ｃｏｎｔｅｎｔｓ

ここでは、レビュー向け発想術を、レビュー眼と称します。

はじめに
１．レビューの一般論

レビュー眼・怪しいポイント・秘訣（心得）・思考フレーズ

├ 観察法
└ 発想法
├ ①定型連想型├ ②エラー推測型└ ③自由発想型

２．現状のレビューの問題点
３．レビュアーの思考プロセスの分析
４．レビュー向け発想術の考察
５．レビュー向け発想術のまとめ
６．今後の展望23
All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

24
All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

4-1-2 怪しいポイントの身近な例

4-1-1 怪しいポイントを押さえるコツとは？

怪しいポイントの共通点

車の運転で、見通しの悪い角を曲がる場合。

優れたレビュアーは、バグのありそうな箇所を狙っている。
あるかも知
れない」。
そのときの意識は「バグがあるかも
あるかも
知れない
BUG

トム・デマルコ と ティモシー・リスターの著書「熊とワルツを ～リスクを愉しむプロジェクト管理～」では、「…かも知れない」というフレーズが多数出てくる。

25
All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

26
All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

4-1-3 優れたレビュアーの秘訣(心得)

4-1-4 思考フレーズ
怪しいポイント発見のコツ(心構え)１

不良を不良を見つけようとするから、つけようとするから、見つかる。
つかる。(第三者検証は
第三者検証は効果あり
効果あり)
あり)

２

実際にその
実際にその仕様にその仕様に仕様に基づいて次工程
づいて次工程で次工程で作れるのか、れるのか、想像する
想像する。
する。

３

「How(どのようにHow(どのように)どのように)」の議論よりも議論よりも「よりも「Why(なぜWhy(なぜ)なぜ)」「What(」「What(なにWhat(なに)
なに)」が大事。
大事。

４「こうあるべき」こうあるべき」という姿という姿を思い浮かべて対比
かべて対比する
対比する。
する。(価値感を価値感を持つ)

５

後から仕様
から仕様を
仕様を付け加えたような、えたような、「ただし」ただし」で始まる箇所
まる箇所が箇所が怪しい。
しい。

６「Ａ」でなく「Ａ」でなく、「Ｂ」
でなく、「Ｂ」でないなら、「Ｂ」でないなら「Ｃ」
でないなら「Ｃ」とは「Ｃ」とは限とは限らない。（
らない。（論理的。（論理的に論理的に考察）考察）

７「○○○のはず○○○のはず」のはず」という発言という発言は発言は怪しい！（しい！（曖昧
！（曖昧さを
曖昧さを排除
さを排除）
排除）

８

「絶対」
絶対」という言葉という言葉は
言葉は「絶対」絶対」にない。（にない。（「絶対安全!
絶対安全!」って、って、ホント？
ホント？）

９

設計者が
設計者が面倒臭がるようなところに面倒臭がるようなところに、がるようなところに、バグがある
バグがある。
がある。(ある意味
ある意味、意味、執念！
執念！)

よく観察して「的確に情報をキャッチ」
レビュー時は「かもしれない」推論

先入観を
先入観を
持たない

もし、○○が××すれば×××になるかもしれない□□を△△だったら（または、どうなるの？）

27

28

All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

レビュー向け発想術「レビュー眼」

4-2-1 発想メカニズムの考察

ここでは、レビュー向け発想術を、レビュー眼と称します。

ベテランのレビュアーは、無意識に【ヒラメキ、勘】で不具合を連想している。
いわゆる「アナロジー」が働いている状態。

レビュー眼・怪しいポイント・秘訣（心得）・思考フレーズ

├ 観察法
└ 発想法
├ ①定型連想型├ ②エラー推測型└ ③自由発想型

アナロジー：「類推する」という意味。

だれしも無意識に、キーワードから類推される知識・経験を連想している。
経験
キーワード

認知結果
知識

29

30

All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

バイアスの一例

4-2-2 アナロジーとバイアスについて
キーワード

経験

All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

正しい
認知結果

知識

はやとちり
焦り
慣れ
怠慢
堂々巡り
(あきらめ)

思い込み
・
思い違い

誤った
認知結果
性能についてCPUは早いし、問題ないはず

思い込み
・
思い違い

31
All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

はやとちり
焦り
慣れ
怠慢
堂々巡り
(あきらめ)
32

All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

レビュー時のバイアス排除例

4-2-3 的確な仮説や推論を産み出すには？
レビューのポイントは、先入観を取り除いて、・多角的に仮説を考察する。そして、

CPUは早いし、問題ないはず

性能について何秒以内で処理？

・仮説と検証を繰り返す。

処理能力を確認

要件定義との矛盾を指摘

どこにも書かれていない

性能設計の
抜けを指摘

大量データで
どうなる？

それで
いいの？

33

34

All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

レビュー向け発想術「レビュー眼」

4-2-4 レビュー向け発想法の形式について
レビューの目的は、不具合の発見と予知。
不具合を摘出する指向で考察を行う場合、下記３種類の発想形式があると考える。

定型連想型
（勘）

正常、異常、境界、限界など、定型的な単語と組み合わせて考える。

エラー推測型（経験）

着目点から、想定されるエラーを推測し、該当するか否かを、確認する。

自由発想型
（感性）

ある程度の方向性を与えつつ、自由な発想で考える。

もし、○○が□□を××すれば×××になるかもしれない△△だったら（または、どうなるの？）

All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

ここでは、レビュー向け発想術を、レビュー眼と称します。

レビュー眼・怪しいポイント・秘訣（心得）・思考フレーズ

├ 観察法
└ 発想法
├ ①定型連想型├ ②エラー推測型└ ③自由発想型
35

36

All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

①定型連想型発想法について

All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

その他の、定型連想型発想法について
発想法の発想法の例：SCAMPER

考察フェーズにおいて、定型的なパターンを当てはめて、推論を導く。

もし、○○が××すれば×××になるかもしれない□□を△△だったら（または、どうなるの？）

Substitute（代える、代用する）
Combine（組み合わせる）■テスト設計テスト設計の設計の定石（定石（セオリー）セオリー）パターン

Adapt（適応させる）「正常」「異常」「境界」「限界」「状態遷移」「組合せ(マトリクス)」

Modify（修正する）
もし、
画像データ
画像データがデータ

異常値(画像以外
異常値 画像以外)
画像以外
だったら

不正データ
不正データを
データを登録する登録するかもしれない限界値(極大限界値 極大サイズ
極大サイズ)
サイズ
だったら

性能が
性能が遅くなるかもしれないPut to other uses（ほかの使いみち）
Eliminate（省略する、除去する）
Rearrange（再調整する）
37

All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

38
All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

その他、使えそうな定型連想パターン（１）その他、使えそうな定型連想パターン（２）■テンプレート■ソフトウェア品質特性
X 0129)
ソフトウェア品質特性ISO/IEC9126(JIS
品質特性

規格、規則類類似システムなど、過去の成果物
観点リスト など

■トランザクション

特性

品質副特性

機能性

合目的性,正確性,相互運用性,セキュリティ,標準適合性

信頼性

成熟性,障害許容性,回復性,標準適合性

使用性

理解性,習得性,運用性,魅力性,標準適合性

効率性

時間効率性,資源効率性,標準適合性

追加(作成)

競合

保守性

解析性,変更性,安定性,試験性,標準適合性

更新

排他

移植性

環境適応性,設置性,共存性,置換性,標準適合性参照(検索)

中断

削除■非機能要件の非機能要件のパターン

復元

非機能要件（
非機能要件（10個10個の主特性）
主特性）
機能性，信頼性，使用性，効率性，保守性，移植性，障害抑制性，効果性，運用性，技術要件■データ組合データ組合せ組合せ

詳細は、JUAS(日本情報システム・ユーザー協会)発行の「非機能要求仕様定義ガイドライン」で述べられている。

ＡはＢと同じＡにＢを含む■システムテストのシステムテストのカテゴリ

ＢにＡを含む

機能部分テスト，ボリューム，ストレス，有用度(ﾕｰｻﾞﾋﾞﾘﾃｨ) ，セキュリティ，効率(ﾊﾟﾌｫｰﾏﾝｽ) ，ストレージ，構成，互換性/構成/変換，設置，信頼性，回復，サービス性，文書，手続き

ＡとＢの一部が重なっている
ＡとＢは一致しない

参考：Glenford J.Myersは、著書「ソフトウェア・テストの技法

ＡおよびＢでないけれど、Ｃとは限らない第２版」で、システムテスト実施内容について詳細を述べている。

40

39

All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

レビュー向け発想術「レビュー眼」②エラー推測型発想法について着目点から、想定されるエラーを洗い出し、該当するか否かを確認する。

ここでは、レビュー向け発想術を、レビュー眼と称します。

レビュー眼

All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

・怪しいポイント・秘訣（心得）・思考フレーズ○○に×××の不具合が

□□が

├ 観察法
└ 発想法
├ ①定型連想型├ ②エラー推測型└ ③自由発想型

あるかも知れない。

▲▲▲は大丈夫？
△△△しても大丈夫？

BUG

新システムにシステムに脆弱性がある
脆弱性があるかも知かも知れない・OSのセキュリティ脆弱性
・プログラムの不具合
・通信の傍受移行に移行に失敗する
失敗するかも知かも知れない・移行作業の手順ミス
・データ移行プログラムの不良・インタフェース不良

41
All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

不具合を考察する時の問題点

42
All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

「モクシィ」で発生した不具合事例
現象：画像データが流出してしまった。
発生条件/手順：クロスサイトスクリプティングによる被害
原因：実装漏れ(特殊文字のサニタイジング(無害化)漏れ)
要因：考慮不足
動機的要因：(1)仕様書に記載されておらず、検討漏れ(2)フレームワークで実装済みと、思い込み
作りこみ工程：詳細設計
見逃し要因：テスト観点欠落(フレームワークで実装済みと誤解)

BUG

BUG
情報

不具合の発生手順を分析し、レビューへ応用させる一連の手法を、ここでは「FM2R」と称する。（FM2R：Failure Mode To Reviewの略。）

43

All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

44
All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

原因から結果までの経過を考察

不具合を、レビュー観点として利用可能なように分析するには
不具合事例
・現象
・発生条件/手順・原因・要因・動機的要因・作りこみ工程・再発防止策

結果
(現象)

行動

(発生条件/
発生手順)

結果の
原因・
要因

レビューに
レビューに再利用【不具合の発見・予知】
どのテストケースで見逃し／摘出したのか?
テストケースを抽象化し、概念化
上位分類して整理

45※「発生条件／手順」の明確化により、デバッグ時および修正確認
作業の精度向上も期待することが可能。

All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

上位分類からの、エラー推測例

エラー推測のための、不具合分析例

Webシステム

脆弱性

クロスサイトスクリプティング

Webシステム不具合

47
All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

要因１

脆弱性

クロスサイトスクリプティング

不具合１

インジェクション

不具合２※筆者としては、発生した現象（不具合）と発生契機から、原因箇所の特定へ結びつける、
トラブルシューティングにも応用が可能と考える。

48

All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

不具合事例をマインドマップで整理した例

不具合の上位分類化による効果について

原因
１

46

All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

顕在契機
１

要因２
要因３

仕様書

仕様書
要因１
原因
２

上位
分類

要因２

顕在契機
２

顕在契機
３

要因３

上位分類は、用途(レビュー目的)に合わせて、類推辞典(シソーラス)として整理するのが良いと考える。

49
All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

50
All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

③自由発想型発想法について

レビュー向け発想術「レビュー眼」

発想法の発想法の例：飛び石

ここでは、レビュー向け発想術を、レビュー眼と称します。

レビュー眼

誇張:極端な条件や状況を設定する

・怪しいポイント・秘訣（心得）・思考フレーズ

願望:現実や実現可能性などを一切考えずに理想形を思い浮

├ 観察法
└ 発想法
├ ①定型連想型├ ②エラー推測型└ ③自由発想型

かべる

歪曲:組織や人、モノなどの関係をねじ曲げてみる
逆転:関係を逆転させるもし、○○が××すれば□□を△△だったらどうなるの？

51

52

All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

「モクシィ」
モクシィ」における、「における、「飛、「飛び石」での発想例
での発想例

All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

その他、使えそうな、自由発想例を取り上げる。
■情報の情報の構造化

誇張:極端な条件や状況を設定する「分類」：類似点を分類整理する→ システム利用者が10倍になったら…

「関連」：相反、相互作用、影響範囲「配列」：時間や量で並べる→ 10年後も正常稼動させるには…

■ペルソナ

願望:現実や実現可能性などを一切考えずに理想形を思い浮かべる

仮想ユーザを定義し、それぞれの仮想ユーザの立場から、利用方法（用い方）や、利用される場面を検討する。 （ 例：日立花子 25才
才、うっかりミス）
うっかりミスがミスが多い、 etc…）→ 誰でも、ワンボタンで操作可能な、使いやすさ■発想を
発想を変える４
える４つの視点つの視点

歪曲:組織や人、モノなどの関係をねじ曲げてみる→ 利用者が、他社のスパイだったら…

逆転:関係を逆転させる→ アップロードができるなら、ダウンロードは？

視点
（立場）

いまの位置・立場そのままでなく，相手の立場，他人の視点，子供の視点，外国人の視点，
過去からの視点，未来からの視点，上下前後左右，表裏等々

見かけ
（外観）

見えている形･大きさ･構造のままに見ない，大きくしたり小さくしたり，分けたり合わせたり，伸ばしたり縮めたり，早くしたり遅くしたり，
前後上下を変えたり等々

意味
（価値）

分かっている常識・知識のままに見ない，
別の意味，裏の意味，逆の価値，具体化したり抽象化したり，まとめたりわけたり，喩えたり等々

条件
（状況）

「いま」「ここ」だけでのピンポイントでなく，5年後，10年後，100年後，1000年後あるいは5年前，10年前，100年前，1000年前等々

53

54

All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

発想法における心得(コツ)など

自由発想を成功させるポイント
レビュアーが、思いついたことを述べるだけでは、話が発散するだけ
で、的を得た協議を行うことはできない。
以下の事項をレビュー開始時に明確化し、レビュアーが共有することで、ベクトルを合わせることが大事と考える。

定型連想型

正常、異常、境界、限界など、定型的な単語と組み合わせて考える。

エラー推測型

着目点から想定されるエラーを推測し、該当するか否かを、確認する。

自由発想型

ある程度の方向性を与えつつ、自由な発想で考える。

【ヒラメキはヒラメキはキラメキ】
キラメキ】

１．レビュー方針、進め方の明確化

一瞬のヒラメキ（インスピレーション）を得るには、“一度は一度は見直す見直す” というクセが大事。

（例：検討すべきポイントや、アジェンダの明確化）

２．成功条件の明確化【ミラーに
ミラーに死角あり
死角あり】
あり】
車線変更する際、ミラーには死角死角があることを死角があることを認識があることを認識した上で、認識［バックミラー］ → ［サイドミラー］ → ［目視確認］の３つを確認しなければならない。
多角的な（レビューも同様に、多角的
多角的な確認が確認が必要）
必要（例：ピーク時でも、５秒以内のレスポンス 等）

３．反目標の明確化（例：15分以上のシステムダウンは回避 等）

今日はもう帰って、明日考えよう。
55
All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

（キーワードキーワードをキーワードを詰め 込んでおくと、んでおくと、
翌朝の翌朝の通勤中に通勤中に思いつくこと多数）
いつく56
All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

5-1 レビュー眼のまとめ（１）Ｃｏｎｔｅｎｔｓ
はじめに・よく観察して「的確に情報をキャッチ」
・レビュー時は「かもしれない」推論

１．レビューの一般論
２．現状のレビューの問題点
３．レビュアーの思考プロセスの分析

先入観を取り除いて、・多角的に仮説を考察する。そして、・仮説と検証を繰り返す。

４．レビュー向け発想術の考察
５．レビュー向け発想術のまとめ

着目点

仮説

６．今後の展望

検証
検証

矛盾を
指摘

仮説

抜けを
指摘

検証

仮説

57

58

All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

5-2 レビュー眼のまとめ（２）Ｃｏｎｔｅｎｔｓ

定型連想型
(勘)

レビュー向
レビュー向け発想術に
発想術に
求めた要件
めた要件
対象物を
対象物を見る目(観点)観点)の体系化○

エラー推測型
(経験)

自由発想型
(感性)

△

○

はじめに
１．レビューの一般論
２．現状のレビューの問題点

抽象化と分類が必要

思考の思考の偏りをなくす(陥りやすい死角
りやすい死角をなくす
死角をなくす)をなくす)
蓄積された
蓄積された勘された勘や経験を経験を、スムーズに
スムーズに引き出す

○

○
リスク予測
予測
リスク

抜け・誤り防止△○※現在の知識以上のものは得られない

キーワードをもとに、知識を増やせる

既成概念に捕らわれない発想が可能

○

○

△

的確な
的確な仮説と仮説と推論を推論を導き出す３．レビュアーの思考プロセスの分析

○
新たな気付
たな気付き
気付き

４．レビュー向け発想術の考察
５．レビュー向け発想術のまとめ
６．今後の展望「反目標」を検討することで、的確性が増す

59

60

All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

６－２ 今後の展望について（１）

６－１ レビュー観点の、現場での活用例
レビュー担当者は、
Ａ機能は○○くん、Ｂ機能は△△くん。
よろしくね。

○○くんは、この観点で、△△くんは、こちらの観点で、機能を横断的に見てね。

・知識,経験が少ないと、指摘できない問題あり。 ・知識,経験が少なくても、観点に基づく質問や仮説
で、問題を摘出しやすくなる。
・仕様書に書いてあることしか、思い浮かばな・仕様書に書いていないことも、見破りやすい(洞察しい。
・機能ごとに、レビュー結果のバラツキあり。
・機能間にまたがるような問題は気付きにくい。
・観点漏れによる見逃しリスクあり

All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

やすい)

チェックリストによるレビューでは、「一元的品質要素」の確保までが実現可能な範囲であった。レビュー眼での発想法「自由発想型」は、「魅力的品質」についての議論を活発化させる要素となる。これにより、真のお客様価値の実現を図ることが可能
と考える。
品質要素

品質の定義

チェックリスト

発想法

当たり前
品質要素

それが充足されれば当たり前と受け取られるが、不十分であれば不満を引き起こす品
質要素。
（実現されない場合、プロジェクトの失敗を意味する）○：定性的な要素はチェックリストで対応可能。

◎：「エラー推測型」発想法により、過去の障害情報を有効活用し、より確実な不良摘出／
障害予防が可能一元的
品質要素

それが充足されれば満足、○：「要件定義」に不十分であれば不満を引き起こす品質要素。
従った検証で、対（要求、要件の実現）
応可能◎：「定型連想型」発想法により、要件の曖昧さや、機能を実現をする上での品質リスクを早期に検討可能魅力的
品質要素

それが充足されれば満足を与えるが、不十分であってもしかたがないと受け取られる品質要素。
（安全性、使いやすさ、利便性等）◎：「自由発想型」発想法に基づき、「真のお客様価値」

・機能ごとの、レビュー内容が一定する。
・機能間にまたがるような問題も発見しやすい・観点が明確。（見逃し漏れが少ない）

60-1
All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

×：真の「要求」を捉えた検討が必要だ
が、チェックリス
ト化は難しいについて検討可能

61
All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

６－２ 今後の展望について（２）６-３ 最後に「上流工程で品質を作りこめ」と言われるが、これは単に「不具合をレビューで除去すること」だけではない。

・各種テスト技法や、高額なツールも、“観点”が無ければ実施されないし、不良も発見されない。何ごともレビュー眼のような“観点”を持つことが大切と考える。

品質を「お客様の満足度」と定義した場合、「品質(お客様の満足度)を創造する」タイミングは、「デザイン・
レビュー」が最適であると考える。
今一度「デザイン・レビュー」を活発化させることが、真のお客様価値の実現を図る要点と考える。
「デザイン・レビュー」の活発化により、より高度なお客様価値の実現を期待することができると考える。

・どんなにコンピュータが発達しても、何かを創造できるのは、人間だけの取り柄。
・レビューは問題発見だけではなく、お客様にとっての、真の品質(満足)を創造できる場でもある。
「品質(満足)を作りこむ」タイミングは、デザインレビューが最適。
・今一度、ものづくりの大切さ・素晴らしさを振り返ろう。

62

63

All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

Cｌosing－謝辞－
・当プレゼンテーション資料を作成するあたり、
JaSST Kansai実行委員、TEF関西の皆様、
ならびに 弊社の諸先輩方に“多大な”ご協力を頂
きましたことを、この場をお借りして、御礼申し上げます。
・また、予稿集作成 ならびに シンポジウム開催準備，会場運営にあたられた方々にも、この場をお借りして、御礼申し上げます。
64

69

All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

付録１－１ 場面に応じた、レビューの視点について

All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

付録１－２ 場面に応じた、レビューの視点について

Ostrandの4つのビュー

発想法・
目的

定型連想

エラー推測

自由発想

抜け・誤り防
止

リスク予測

新たな
気づき

ユーザービュー

○

△

◎

仕様ビュー

◎

○

○

単体テスト

設計・実装
ビュー

◎

○

×

コードインスペクション

バグビュー

○

◎

△

ユーザービュー、仕様ビュー、設計・実装ビュー、バグビュー

ビュー

ユーザービュー

適格性確認テスト

要求分析
仕様ビュー

方式設計

バグビュー

結合テスト

詳細設計
実装

設計・実装ビュー・機能テストAll Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

付録３ レビューツールの一例

付録２ レビューの実施種類
代表的なレビュー実施方法

レビューツール

概要

レビュー方法ブレーンストーミング

テーマに基づく、複数人数での自由発想により、思いつきや気になる事項を挙げていく。

５Ｗ１Ｈ ＋ １Ｄ

Why,Whatなどの質問で詳細を具体化する。
さらに、Dｏ（動作）を検討することで、より具体化される。

テンプレート／ワークシート

品質特性や、過去事例など、テンプレートになるものを活用する。

チェックリスト

想定する出来事や過去の経験を一覧化しておき、対比させる

マインドマップ

連想するキーワードを増やす、メモ技術

FMEA/FTA

不具合の可能性から仕様を検討する

概要

利点

難点

アドホック・リーディ 特にやり方を決めず、レビュ 準備は不要
ング
アーの勘や経験で内容を考察する

レビュアーのスキルに依存するチェックリスト・ベー チェックリストの内容に従い、 精度の高いレビュース・リーディング
内容を確認する
を実施可能

対象物に適合した
チェックリストが必要

シナリオ・ベース・リーディング

対象物に適合したシ
ナリオを準備する必要があり、事前準備が大変

予め定めたシチュエーション 勘や経験に依存すや、不具合/問題発生の可 る部分を一般化し能性で検討するやすい72
All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

付録４ レビュー技術を磨くのに有効なコミュニティのご紹介• TEF（Testing Engineer's Forum: ソフトウェアテスト技術者交流会）
http://www.swtest.jp/wiki/index.php?swtest.jp/wiki/forum

・SQiPコミュニティ（日科技連：Software Quality Profession）
http://www.juse.or.jp/software/sqip_community.html
・ソフトウェアレビュー/
ソフトウェアレビュー/インスペクションを議論する
議論するコミュニティ
するコミュニティ（奈良先端科学技術大学院大学 情報科学研究科 ）http://se.naist.jp/html/review/ml.html

All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.

73
All Rights Reserved. Copyright © 2010, Hitachi Systems & Services, Ltd.