Quality Engineering, Services Quality

Quality Engineering, Services Quality

はじめにようこそ!
ようこそ! 欠陥エンジニアリング
欠陥エンジニアリングのエンジニアリングの世界へ
世界へ!
欠陥エンジニアリングは、一般的なあまり馴染みのない言葉ですが欠陥の記録／分類／活用を通じて品質管理活動全般へ貢献する、いわば「ゲンバノチカラ」「基礎体力」と言っても過言ではない、重要な概念です。

欠陥エンジニアリングの重要性と欠陥メタ情報の定義／管理

しかし日々の技術者としての活動では、欠陥管理DBに検出した欠陥を記録しますが、実は「欠陥を記録してどうする？」という目的意識が欠如している場合が少なくありません。

－欠陥マスターデータベースの普及と産業寄与に向けた提言－

また「欠陥管理DBを参照して利用するのは誰？」「欠陥はどうやって分類整理したらいいの？」という概念等も、国内ではあまり知られていないトピックです。
Nobuhiro Hosokawa
IT Architect
Quality Engineering
AIS – Global BusinessServiceIBM Japan Ltd.

Nobuhiro Hosokawa (carvin@jp.ibm.com)
Quality Engineering, Services Quality.
IBM Japan Ltd.

本プレゼンテーションでは、欠陥管理の一般的な問題点となぜ欠陥管理が負荷ばかり大きくうまく活用されないか、またどのように整理すればよいかを皆さんと一緒に考え、「ゲンバノチカラ」としてあるべき姿を紹介します。

carvin@jp.ibm.com

本日のプレゼンテーションでは、一部に刺激の強い画像が含まれています。

Twitter://__Dreamstate

気分が悪くなった方は、挙手するなどスタッフまでお申し付けください。

Copyright IBM Japan Ltd. 2009,2011. all rights reserved

Quality Engineering, Services Quality

Quality Engineering, Services Quality

世界で年9月月9日
日(1947-09-09)
世界で最初の最初のバグ 1947年
概要
The First "Computer Bug" Mothfound trapped between points at Relay# 70, Panel F, of the Mark II Aiken
Relay Calculator while it was being
tested at Harvard University, 9September 1947. The operators affixed
the moth to the computer log, with theentry: "First actual case of bug being
found". They put out the word that they
had "debugged" the machine, thus
introducing the term "debugging acomputer program". In 1988, the log,with the moth still taped by the entry,
was in the Naval Surface Warfare
Center Computer Museum at Dahlgren,Virginia, which erroneously dated it 9
September 1945. The Smithsonian
Institute's National Museum ofAmerican History and other sources
have the correct date of 9 September1947 (Object ID: 1994.0191.01). TheHarvard Mark II computer was notcomplete until the summer of 1947.

第１章 − 医学との医学との対比との対比
#1病理学
#1病理学

Copyright IBM Japan Ltd. 2009,2011. all rights reserved

Quality Engineering, Services Quality

Removed caption read: Photo # NH 96566-KB First Computer "Bug", 1945
日付 1947年
年 9月
月 9日
日(1947-09-09)
原典 U.S. Naval Historical Center Online Library Photograph NH 96566-KN
著者 Courtesy of the Naval Surface Warfare Center, Dahlgren, VA., 1988.
許可 (このこのファイル
再利用 This image is a work of a sailor or employee of the U.S. Navy, taken or made during the course of the person's official duties. As a work of the U.S. federal government
このファイル の再利用)

Copyright IBM Japan Ltd. 2009,2011. all rights reserved

Quality Engineering, Services Quality

欠陥の欠陥の形 - Shape of Defects 尖り具合で度合いを表す

除去困難度
重要度・影響度

欠陥名と分類

出現頻度

兆候情報

6つのトゲ

除去情報

＋４象限で欠陥の全体像を表す

定義||

欠陥を可視化

予防情報

検出情報
検出困難度

予防困難度
相互依存度

第２章 −
欠陥マスター
欠陥マスターのマスターの必要性

欠陥の概要と性質

Copyright IBM Japan Ltd. 2009,2011. all rights reserved

Copyright IBM Japan Ltd. 2009,2011. all rights reservedQuality Engineering, Services Quality

Quality Engineering, Services Quality

全ての検出欠陥
何でもいいから”DBにに登録せよての検出欠陥は検出欠陥は”何でもいいから登録せよのせよの法則

プロジェクトとプロジェクトと欠陥の欠陥の関係
 プロジェクトとプロジェクトと欠陥の欠陥の関係を関係を整理すると整理すると次のような関係。（解説）すると次のような関係関係。（ER図風。（ 図風に図風に解説）

バグ報告者側 （テスター、開発者….）
1. 検出順序を意識せず登録する
2. プロジェクトで検出した欠陥は全て、BTS(Bug Tracking System) に記録する
3. 同種の欠陥があるかもしれないがとりあえず入力・入れる
4. 誰がどう使われて、どう意思決定されるかわからないけどとりあえず登録する
5. 粒度はばらばらで入力する
6. 明確な「何を欠陥として記録するか」というルールと欠陥定義がない

報告される側 （PM、品質管理担当…）
1. 未整理で「何を言っているかわからない」がとりあえず多量に登録されてくる2. 欠陥の関連が不明。全ての欠陥は単独と考える
3. 出てきた順に欠陥除去しようと考える
4. 簡単なものから対処するよう指示する
5. 週次報告書以外にバグ情報を使わない
6. 再発している欠陥に気付かない・気付けない
7. プロジェクトを終わったら使わない せっかく時間
せっかく時間と工数をかけて記録利用していない・
活用できて時間と工数をかけてをかけて記録した
記録した欠陥情報した欠陥情報を欠陥情報を、実は利用していないしていない・活用できていない事例
いない事例が事例が散見される
散見される

1. プロジェクトには複数の欠陥が発生する
2. 一つの欠陥は複数のプロジェクトで検出される

プロジェクト欠陥

 上記M対の関係は
上記 対Mの関係は、１対１関係の関係の「関連エンティティ関連エンティティ」エンティティ」をおくと整理をおくと整理できる
整理できる
1. プロジェクトと欠陥の間に「プロジェクト欠陥」エンティティを設定。
2. 各１対Mの関係でリレーションを整理

プロジェクト欠陥

プロジェクト欠陥
プロジェクト欠陥 欠陥管理DB・の情報が欠陥管理 ・BTSの情報が活用されない
活用されない理由
されない理由はなにか
理由はなにか？
はなにか？
Copyright IBM Japan Ltd. 2009,2011. all rights reserved

Copyright IBM Japan Ltd. 2009,2011. all rights reserved

Quality Engineering, Services Quality

Quality Engineering, Services Quality

医学との医学との対比との対比、対比、再び医学には．．．

IT業界には．．．

医学では、稀な症例や現場の事例を学会等を通じて共有する仕組みがある 稀なバグや被害の大きな欠陥を業界全体で共有する仕組みがない現場の実例から抽象化して「病気」だけを定義・管理・維持する学会・権威機関がある。そういう医学分野がある そもそもバグを研究する「バグ屋」という分野の人
材も・技術分野も存在しない

現場医師は最新動向や検査・対処方法を継続的に学ぶ習慣が付いている 現場は「除去」さえできればよいため欠陥の情報の獲得を行わない

PubMedPubMed comprises more than 20 million citations
for biomedical literature from MEDLINE, life sciencejournals, and online books. Citations may include links to full-text content from PubMed
Central and publisher web sites.

第3章 −欠陥マスター
欠陥マスターDB
マスターDBのDBの構築

医学分野で世界最大の文献データベース。1966年からNLM（米国国立医学図書館）でデータ収集が始まり，現在毎月約3万件の文献が新たに追加される。現在では，米国を中心に約70ヵ国から，900万件を超える文献が収録される。

Copyright IBM Japan Ltd. 2009,2011. all rights reserved

Copyright IBM Japan Ltd. 2009,2011. all rights reserved

Quality Engineering, Services Quality

Quality Engineering, Services Quality

欠陥の欠陥の情報分類：
情報分類： #1 「病理学」
病理学」風の整理
医学の視点では、定義と用途を重視した永続的・長期的な情報整理を行います

1.

名前・別名

1. どのように検出するか？

2.

欠陥の定義・分類

2. どのメトリクスを計れば欠陥兆候を

3.

一般的な推定原因発生・確率

4.

併発症・合併症

5.

特記事項

保守性／変更容易性欠如（成果物体系とも関連）
Level 5 堅牢性／安全性／信頼性
保守性 試験性（リグレッション他）

Lvl4
機能欠落

捕らえることができるか？

欠陥の情報
 除去方法・除去方法・予防方法

1. どうやったらその欠陥に気付くか？

1. 関連する欠陥・連鎖欠陥

2. どのメトリクスを計れば欠陥兆候を

2. 除去時の注意点
3. 副作用・除去リスク
4. 再発予防方法

Copyright IBM Japan Ltd. 2009,2011. all rights reserved

検出
順序

3. 定性情報？定量情報？

 兆候情報捕らえることができるか？

レビュー・レビュー・テスト担当者
テスト担当者の担当者の視点では視点では、では、検出順序を検出順序を考慮した考慮した階層的した階層的な階層的な欠陥分類が欠陥分類が必要です
必要です 検出情報 定義・基礎情報

3. 定性情報？定量情報？

欠陥の欠陥の情報分類：
情報分類： #2 「レビュー・レビュー・テスト」
テスト」専門家の専門家の整理

Level 3
難読／複雑度
不整合

Level 2
不統一／未決表現／NGワード

Level 1
標準／ルール／形式違反
対象の有無

現行機能保証／現行踏襲に関する記述含有
機能分割間違い／処理・機能の粒度不統一
機能性欠陥／機能性矛盾／処理の欠落／省略
難読性／一意性欠如／
理解容易性欠如／機能重複
複写／転用による誤り・齟齬

処理不統一／表現矛盾
題名ー内容間の矛盾
用語不統一／略号・略称多用
誤字脱字／表現の不統一

時系列不整合処理不整合
成果物間不整合高い業務複雑度／試験性欠如/分岐条件／繰り返し条件の曖昧性

機械処理でないものの記載
未決／検討中／保留の残存
NGワード表現の含有

指定書式／標準／規定違反
成果物が提出されていない（集まっていない／不足あり）成果物が作成されていない／規定／ルール違反

Copyright IBM Japan Ltd. 2009,2011. all rights reservedQuality Engineering, Services Quality

Quality Engineering, Services Quality

欠陥の欠陥の情報分類：
情報分類： #2 「レビュー・レビュー・テスト」
テスト」専門家の専門家の整理

欠陥の欠陥の情報分類：
情報分類： #3 「品質管理」
品質管理」専門家の専門家の整理

それぞれのレベルそれぞれのレベルにレベルに応じて最適じて最適な最適な検出方法を検出方法を用いるべきです。
いるべきです。

品質管理の品質管理の専門家の専門家の立場からは立場からは、からは、以下の以下の３つの観点つの観点での観点での欠陥分類での欠陥分類が欠陥分類が必要です
必要です。
です。

Level 5
保守性

検出順序

Lvl4
機能欠落
Level 3
難読／複雑度
不整合

Level 2
不統一／未決表現／NGワード

Level 1
標準／ルール／形式違反
対象の有無

保守性／変更容易性欠如（成果物体系とも関連）
堅牢性／安全性／信頼性
試験性（リグレッション他）

目視でしか検出できない／
検出難易度が高い欠陥

現行機能保証／現行踏襲に関する記述含有
機能分割間違い／処理・機能の粒度不統一
機能性欠陥／機能性矛盾／処理の欠落／省略

難読性／一意性欠如／
理解容易性欠如／機能重複
複写／転用による誤り・齟齬

時系列不整合処理不整合
成果物間不整合

処理不統一／表現矛盾
題名ー内容間の矛盾
用語不統一／略号・略称多用
誤字脱字／表現の不統一高い業務複雑度／試
験性欠如/分岐条件／繰り返し条件の曖
昧性２）除去難易度

１）検出難易度

３）予防難易度

自動化ツール
測定ツールで検出する欠陥機械処理でないものの記載
未決／検討中／保留の残存
NGワード表現の含有開発者のセルフレビュー／
チェックリストで検出する領域

指定書式／標準／規定違反
成果物が提出されていない（集まっていない／不足あり）
成果物が作成されていない／規定／ルール違反

検出困難度
検出困難度---開発者
検出困難度 開発者または開発者またはプロジェクト
またはプロジェクト内部
プロジェクト 内部メンバー
内部メンバーによるメンバーによる自己による自己レビュー
自己レビューでレビューで検出しにくい
検出しにくい欠陥
しにくい欠陥除去困難度
除去困難度---欠陥
存在は確認できたが確認できたが、本番環境から除去除去工数のかかる欠陥
除去困難度 欠陥の欠陥の存在はできたが、本番環境からから除去しにくく除去しにくく、しにくく、除去工数のかかるのかかる欠陥
予防困難度
予防困難度---他
予防困難度 他の困難度に困難度に関係なく関係なく頻発なく頻発し頻発し、根本原因対策が根本原因対策が難しいため、しいため、再発予防の再発予防の難しい欠陥
しい欠陥

Copyright IBM Japan Ltd. 2009,2011. all rights reserved

Quality Engineering, Services Quality

Copyright IBM Japan Ltd. 2009,2011. all rights reserved

Quality Engineering, Services Quality

誰が使う？メリットはメリットは？
■ プロジェクトマネージャー（プロジェクトマネージャー（開発中）
開発中）②兆候情報＋兆候情報＋③検出情報＝
検出情報＝品質管理上の品質管理上の必要アクション
必要アクション指示
アクション指示③検出情報＋検出情報＋④除去・除去・予防方法＝
予防方法＝品質管理上の品質管理上の予防アクション
予防アクション指示
アクション指示■ プロジェクトマネージャー・プロジェクトマネージャー・経営層（経営層（プロジェクト計画時プロジェクト計画時）計画時）②兆候情報＋
兆候情報＋④除去・除去・予防方法＝
予防方法＝当該プロジェクト
当該プロジェクトのプロジェクトのリスク判定
リスク判定＋判定＋プロジェクト
計画①定義情報＋定義情報＋④除去・除去・予防方法＝
予防方法＝品質管理計画■ プログラマ・プログラマ・設計者①定義・基礎情報①定義情報＋定義情報＋③検出情報＝
検出情報＝

③検出情報

欠陥の
欠陥の情報

自己レビュー
自己レビュー・レビュー・自浄②兆候情報■ テスト／
テスト／レビュー担当者
レビュー担当者

第4章 −欠陥エンジニアリング
エンジニアリングの欠陥
エンジニアリングの未来#2診断学#2診断学へ
診断学へ④除去・予防方法①～④の全部！！
全部！！どうやって！！どうやって？
どうやって？
Copyright IBM Japan Ltd. 2009,2011. all rights reserved

Quality Engineering, Services Quality

Copyright IBM Japan Ltd. 2009,2011. all rights reserved

Quality Engineering, Services Quality

欠陥エンジニアリング
欠陥エンジニアリングのエンジニアリングの未来

まとめ：
まとめ：欠陥エンジニアリング
欠陥エンジニアリングのエンジニアリングの重要性

診断レベル

 まず“まず“銀の弾丸”弾丸”で倒すべきモンスターすべきモンスターをモンスターを知る

欠陥マスタ

欠陥の定性測定||診断学

 欠陥は欠陥は定量側面／定量側面／定性側面がある定性側面がある 欠陥は欠陥は企業にとっての企業にとっての財産にとっての財産である財産である||

 欠陥を欠陥を収集し収集し、分類して分類して蓄積して蓄積する
蓄積する

病理学

定量測定

 欠陥は
欠陥は単独では単独では存在
では存在しない
存在しない

 欠陥の欠陥の学習が学習が人と組織を組織を成長させる
成長させる

欠陥追跡&収集 欠陥を欠陥を知る事から全から全てがはじまる

レビュー&テスト時間
Copyright IBM Japan Ltd. 2009,2011. all rights reserved

全ては安心ては安心のために
安心のためにCopyright IBM Japan Ltd. 2009,2011. all rights reserved