JaSST 2013 Tokyo – Project Fabre

過失に着目した欠陥のモデリング－バグ分析はなぜうまくいかないのか？－Nobuhiro Hosokawa, Yasuharu Nishi,
Aya Ureshino, Makoto Nonaka, Yukiko Hara

Quality Engineering for the futureProject Fabre

Project Fabre セッション コンテンツ
11. バグ分析（具体例）
１． Project Fabre メンバー
12． 欠陥モデリング（定義）２． バグ前提社会
13． 欠陥モデリング（具体例）
３． Project Fabreの役割
14． 欠陥の抽象度と展開幅
４． バグ分析のレベル
15． 本日のまとめ
５． 本日のポイント
６． バグ分析の失敗要因
７． 「なぜなぜ分析」の注意点と「なになに分析」の勧め
８． バグ分析のアンチパターン
９． バグ分析のまずまず良いパターン
10．バグ分析ができない事例の特徴

Copyright © 2013 Project Fabre All Rights Reserved.

1

Quality Engineering for the futureProject Fabre

１．Project Fabre メンバー

細川 宣啓 （日本IBM）

野中誠 （東洋大学）< CARVIN@jp.ibm.com >< nonaka-m@toyo.jp >西 康晴 （電気通信大学）

原 佑貴子 （日本IBM）< Yasuharu.Nishi@uec.ac.jp >< HARAYUKI@jp.ibm.com >嬉野 綾 （ワークスアプリケーションズ）< ureshino@worksap.co.jp >Copyright © 2013 Project Fabre All Rights Reserved.

2

Quality Engineering for the future

Project Fabre

２．バグ前提社会「バグのない社会」を我々は目指すのか？
－ 人は全知全能の神ではない－ 脳はバグるし、人はよく間違える－ 全然間違えない、失敗しない日はありますか？
－ お客様の求めるものの多様化・複雑化とソフトウェアの進化・複雑化が加速度的に発生－ 止めるべきは、バグそのものではなく、ビジネス上の実害Copyright © 2013 Project Fabre All Rights Reserved.

3

Quality Engineering for the future

Project Fabre

２．バグ前提社会「バグ前提社会」での考え方－ 開発エンジニアは、どのようにしてバグを埋め込む罠にはまったのか？
開発プロセスで何があったのか？
－ 品質エンジニアは、どのようにしてバグを見逃す罠にはまったのか？
テストプロセスで何があったのか？
－ 間違えたくないが、間違えない開発やテストはできない－ 同じバグを繰り返さないよう、モデル化が必要
Copyright © 2013 Project Fabre All Rights Reserved.

4

Quality Engineering for the future

Project Fabre

３．Project Fabreの役割

ー ソフトウェアの欠陥そのものに関する研究ー ソフトウェアの欠陥を「悪さの知識」と位置づけ
ー 欠陥を汎用的な欠陥マスタとして共有／蓄積
ー 欠陥を伝承・移転可能にし、学術界・産業界で資産化
ー 欠陥に関する構造等を定義
ー 欠陥エンジニアリングという技術分野を確立
ー 欠陥に強いエンジニアの育成に貢献（ http://aster.or.jp/business.html#fabre より）

Copyright © 2013 Project Fabre All Rights Reserved.

5

Quality Engineering for the future

Project Fabre

４．バグ分析のレベル

バグ分析自体を「実施してない」

バグを検出して除去すればよい、分析などしたくない。

バグ分析をしても「効かない」

バグ分析を実施しても、あまり効果が得られない。

ある程度効くことは理解している。効能を「体感済」

バグ分析を実施し、効果あり。でも、同じバグに遭遇。

Copyright © 2013 Project Fabre All Rights Reserved.

6

Quality Engineering for the future

Project Fabre

５．本日のポイント－ 「バグ分析をしていない、うまくいっていない」⇒うまく分析するためのコツを伝授－ 「バグ分析はやって、ある程度効果はあったが、プロジェクトやリリース毎に同じようなバグは出る」⇒モデル化で、一歩進んだバグ分析へ－ 「欠陥（ライフサイクル）のモデル化」⇒バグが埋め込まれた時、どんな状況だったのか？
バグを防げなかったのは、どんな状況だったからなのか？
Copyright © 2013 Project Fabre All Rights Reserved.

7

Quality Engineering for the future

Project Fabre

６．バグ分析の失敗要因

Q.バグ分析は、なぜ失敗するのか？
■ 本当にバグを分析しているか？

■ バグ分析そのものが目的になっていないか？
■ 事実確認が甘すぎないか？

■ 「なぜなぜをやるとよい」と聞いたから■ 失敗事例が共有されていない

Copyright © 2013 Project Fabre All Rights Reserved.

8

Quality Engineering for the future

Project Fabre

６．バグ分析の失敗要因

A. バグを偏った側面で捕らえている。
■ 人、設計、プロジェクト、プロセス、手法等「だけ」に答えを求めている。原因と対策が表と裏「だけ」になっている。
例）人→人、設計→設計■ なぜなぜの方向が違う。

■ コントロール出来る範囲を考えていない。

バグ分析の本質は、バグの存在を確かめ、バグの資産化のため、獲得・記録・抽象化・保存・移転する点にあります。バグそのものと周辺の状況を捕らえ、原因分析や対策立案をしなければ、同じようなバグが再発します。
Copyright © 2013 Project Fabre All Rights Reserved.

9

Quality Engineering for the future

Project Fabre

７．「なぜなぜ分析」の注意点と「なになに分析」の勧め「なぜなぜ分析」の注意点「なになに分析」の勧め■ 他者に対して問い詰め、否定■ ポジティブに考えやすい形になりやすい－ なぜバグを出してしまったんだ？
■ 一つの答えに帰結しやすい－複数、複雑なものに対処しづらい■ バイアスにより、新たな発想－なにがどこで起こったの？
その前には、なにかあったの？
■ バグ票の必須要素を含む－現象・期待結果・起動経路を明確化■ 可能性が広がる、選択肢がが生まれにくい

想像しやすくなる－限られた範囲の原因追求や自分自身への問いかけには有効－俯瞰的・多角的に観察しやすい

Copyright © 2013 Project Fabre All Rights Reserved.

10Quality Engineering for the future

Project Fabre

８．バグ分析のアンチパターン（原因編）－ 現象と原因がごっちゃになったバグ票を使っている⇒「なぜなぜ」以前の問題－ うっかりしてた、しっかりやってない、きちんとできてなかった⇒たまたまであれば、その時どんな状況だったの？
－ 決めつけ、犯人捜し、うやむや⇒本気で解決する気ありますか？
－ 製品設計の問題⇒設計のどこでどういう問題が起きている？
－ テスト漏れ⇒何がどこで漏れた？テスト網羅された状態とは何？
Copyright © 2013 Project Fabre All Rights Reserved.

11

Quality Engineering for the future

Project Fabre

８．バグ分析のアンチパターン（対策編）－ すでに項目数が多いチェックリストへチェック追加⇒どこまで増やせる？トレードオフ考えている？
－ 全体会議で周知（注意喚起）する⇒来月の新規配属、異動してきた人には伝わる？
－ 教育・研修の充実⇒範囲は？対象者は？起こすのは新人だけ？
資源は確保できる？
－ 文化醸成・属人化排除・エライ人投入⇒コントロールできる問題？

Copyright © 2013 Project Fabre All Rights Reserved.

12Quality Engineering for the future

Project Fabre

９．バグ分析のまずまず良いパターン（原因編）－ 「どんなバグを減らしたいか？」⇒バグ分析の目的の共有・合意、優先順位付け－ 担当者・関係者へヒアリングして、状況を明らかにする⇒関係する情報の質と網羅率を上げる－ ありがちだが実は不適切なことから離れて考える⇒原因追求は「なぜなぜ」、対策は「なになに」－ 自責（自分、自チーム）と他責（他人、他チーム）の両方で考える⇒開発プロセスで埋め込んだ原因とテストプロセスで発見できなかった原因
Copyright © 2013 Project Fabre All Rights Reserved.

13

Quality Engineering for the future

Project Fabre

９．バグ分析のまずまず良いパターン（対策編）－ 多くの仮説を立てる（あらゆる方法を想像）⇒あとの選択肢を広げる－ 分けて考える⇒実害の影響度、コントロール可能範囲、除去難易度、テスト難易度、 コストのかからない方法など－ 実行しやすい範囲や対象から始める⇒自分のチーム、近所のチーム－ 合わせ技⇒注意喚起と継続的解決、アナログとシステム化、短期と中長期、開発フェーズとテストフェーズ
Copyright © 2013 Project Fabre All Rights Reserved.

14

Quality Engineering for the future

Project Fabre

１０．バグ分析ができない事例の特徴

多くの場合、下記ができていない事例が多い→できるようにすれば、解決へ近づける■バグを楽しむ■バグを表現する■バグを比較する■バグを移転する■バグを蓄積する■バグを資産とみなす

過失に着目！
Copyright © 2013 Project Fabre All Rights Reserved.

15

Quality Engineering for the future

Project Fabre

参考：昨年のワークショップ資料．インスタンス情報の切り離しと追記情報

インスタンス情報「固有」部分を切り出し・プロジェクト固有の背景

汎化
情報・プロジェクトの前提条件汎化された情報

・制約条件

追記情報
・検出方法

・キーワード／名前所見を追記して欠陥マスターDBへ・予防策

Copyright © 2013 Project Fabre All Rights Reserved.

16

Quality Engineering for the future

Project Fabre

参考：昨年のワークショップ資料．欠陥の情報分類： #1 「病理学」風の整理
医学の視点で、定義と用途を重視した永続的・長期的な情報整理を行います。
 定義・基礎情報
1.
2.
3.
4.
5.

 検出情報

名前・別名
欠陥の定義・分類
一般的な推定原因と発生確率併発症・合併症
特記事項

1. どのように検出するか？
2. 何をキーワードに検索すれば、欠陥がある場所を特定／狭めることができるか？
3. 定性情報？定量情報？

欠陥の情報
 兆候情報1. どうやったらその欠陥に気付くか？
2. 何をきっかけにすると、欠陥兆候を捉えることができるか？
3. 定性情報？定量情報？

 除去方法・予防方法
1.
2.
3.
4.

関連する欠陥・連鎖欠陥除去時の注意点
副作用・除去リスク
再発予防方法Copyright © 2013 Project Fabre All Rights Reserved.

17

Quality Engineering for the future

Project Fabre

１１．バグ分析（具体例）ー例題のバグ票ー「なぜなぜ」分析「なになに」分析■ Currencyを使わなかった■ Currencyを使わなかった⇒Currencyの使い方を知らなかった⇒Currencyの使い方を知っていたが、その時は使わなかった⇒Currencyを正しく使えるように教育する⇒既存ソースがdoubleだったので、派生開発時にdoubleを使った⇒該当部分修正に加え、静的チェックで新規発生を防ぐ、他の浮動小数点型の定義は後に修正
Copyright © 2013 Project Fabre All Rights Reserved.

18

Quality Engineering for the future

Project Fabre

１２．欠陥モデリング（定義）
誘発因子(InductionTrigger)

成果物の中に含まれる、人間の思考の誤りを誘発する“トリガー”となる要素のこと。
誘発因子が存在すれば、開発者能力・経験・技術力と関係なく過失が引き起こされやすくなる。

人間の思考や判断の誤りそのもののこと。
過失因子(Negligence Factor) 欠陥は過失因子の集合（=連続）として生み出される。
増幅因子(Amplifier)

過失の連鎖を助長し、欠陥の混入確率を増幅させる要素。
多くは定量的に測定可能である。外乱・環境特性ともいう。

欠陥(Defect)

成果物に含まれた、人間の思考の過ちが具現･表出化したもの。不具合・障害等の「現象」を発生させる。

表出現象(Incident)

欠陥によって引き起こされる不具合・障害。
多くは定量的に測定／加算可能。
Copyright © 2013 Project Fabre All Rights Reserved.

19

Quality Engineering for the future

Project Fabre

１３．欠陥モデリング（具体例）ー例題のバグ票ー
Currencyの存在は知っていた<過失因子>
型選択が周囲に引きずられた

Currencyを選択しなかった
設計<欠陥>

Currencyを使わなかったコード<欠陥><誘発因子>
母体は全部Doubleで設計<増幅因子>
データ型の標準ルール無し<増幅因子>
対応時間がない（緊急ﾘﾘｰｽ）<増幅因子>
チェック体制の不備

丸め誤差<表出現象>

Copyright © 2013 Project Fabre All Rights Reserved.

20

Quality Engineering for the future

Project Fabre

１３．欠陥モデリング（具体例） ー例題のバグ票を汎用化ー<増幅因子>
対応時間不足（緊急時）<誘発因子>
ﾃﾞｰﾀ型の誤用が慣習化・修正不可能<増幅因子>
データ型の標準ルール無し<過失因子>
理由なき型選択（周囲に引きずられる）

開発者知識： 充足
適切なデータ型の知識は持ち合わせているが、適切に選択できない。

<増幅因子>
チェック体制不備・不足（緊急時）

最適な型を選択しなかった設計<欠陥>

データ型起因の障害<表出現象>

最適な型を選択しなかったコード<欠陥>

Copyright © 2013 Project Fabre All Rights Reserved.

21

Quality Engineering for the future

Project Fabre

１３．欠陥モデリング（具体例）ーおまけｰ<誘発因子>
戻り値をチェックしない慣習<増幅因子>
開発期間
不足

戻り値のチェックが仕様書に記載なし〈過失因子〉<誘発因子>
異常値が戻されることは「ありえない」という思い込み<増幅因子>
テストレベル浅い

ソースコードに戻り値のチェックがない<欠陥><増幅因子>
PJスケジュールがタイト

呼出先から異常値が戻され、想定外の例外発生／落ちる<表出現象><増幅因子>
レビュー
範囲外

Copyright © 2013 Project Fabre All Rights Reserved.

22

Quality Engineering for the future

Project Fabre

１４．欠陥の抽象度と展開幅■ 欠陥保存時の情報抽象度の高さに依存して、横展開幅（＝欠陥情報の適用範囲）が決定される■ 逆に広範囲な展開を狙わない場合は、抽象度を高めなくてもよい？
抽象度

元欠陥

同システム

同企業

同業ドメイン

エンプラ／組込

普遍的適用・展開幅
Copyright © 2013 Project Fabre All Rights Reserved.

23

Quality Engineering for the future

Project Fabre

１５．本日のまとめ■アンチパターン脱却⇒まずまず良いパターン実践⇒モデル化して議論■人間が陥る「罠」に注目し、バグ知識と合わせて横展開幅を広げる

バグ分析をうまく行い、実害を回避・軽減

バグ前提
社会

分析目的
明確化

人間の過失に着目

欠陥モデリング

Copyright © 2013 Project Fabre All Rights Reserved.

24