自 動 車

ソフトウェアバグ発生時の真因分析手法の策定
片岡智＊美・古戸健・松本

達治

The Analyzing Method of Root Causes for Software Problems ─ by Tomomi Kataoka, Ken Furuto and Tatsuji
Matsumoto ─ In this technical paper, the authors propose an analyzing method of the root causes for software
problems. To prevent the recurrence of the same problems, it is necessary to logically identify the root causes andtake appropriate measures. Therefore, the authors applied “the 5 whys analysis,” a technique that has been usedmainly in the manufacturing process, to the trouble shooting of software. First, the authors visualized the proceduresof software design by arranging documents illustrating work pieces made in each process to find out the proceduresthat involve errors. Next, they prepared many “5 whys” samples related to software development, so that eveninexperienced users can be guided by referring to them. Consequently, the method effectively worked on thesoftware development and successfully shortened the lead time required for identifying errors and analyzing theircauses.
Keywords: software, trouble, analyze method, 5 whys1.

緒

言ソフトウェアの品質は適切なプロセスで確保する必要があり、その開発プロセスは、実際の運用で生じた問題点を開発特有の問題は大きく三つあることがわかった。
第一の問題点は、なぜなぜ分析結果がプログラムのバグフィードバックして、日々改善することが求められる。特にを引き起こすメカニズムの追求に終始するケースである

ソフトウェアのバグ発生時には、適切な再発防止策を立案す（図 1（a））。この例では、「特定フレームを送信しない」と、2）。
るため、プロセス上の真の要因を究明する必要がある（1）（

いうバグ事象に対し、「通信ドライバの初期化処理の誤り」

一方、トラブルの要因をシステム的にモレなく出し切るという要因を導出している。しかし、これはあくまでバグための分析手法に「なぜなぜ分析」がある（3）。この手法は、事象を顕在化させている原因に過ぎず、当該バグの修正方の一環として、製造業を中心に用いられている改法を導くことはできても、バグを作り込んだプロセス上のTQM※1

善の方法論として知られている（4）。
当社のソフトウェア開発現場でも、バグ発生時の要因分析になぜなぜ分析手法を適用してきた。しかし、ソフト要因を明らかにすることはできず、適切な再発防止策の立案に結びつけることは困難である。その点で、図 1（a）のケースは分析が不十分である。

ウェア開発に適用する際の具体的な手順がなく、分析作業第二の問題点は、分析者の思い込みや印象に頼った分析は分析者個人の力量に委ねられていたため、十分な分析品が行われるケースである。なぜなぜ分析では、分析をする質が得られないことによる手戻りも多く発生していた。そ前に、その問題とすべき対象物やことがらを整理して、事の結果、分析に時間がかかり、バグ発生からプロセス改善実のみを把握することが重要である（3）。しかし、図 1（b）までのリードタイムが長くなる傾向にあった。の例では、事実と判断できる確証がないにも関わらず、設そこで、ソフトウェア開発になぜなぜ分析を適用する際計者の心情やレビュー時の配慮に言及するなど、この事実の課題を洗い出し、高品質な分析を効率的に行うための手認識が主観的で漠然としたものとなっている。工場の製造順を策定したので、報告する。

設備などで問題が発生した場合は、製造設備や材料、設備の操作履歴などから原因となる客観的事実を収集できる。

2.

なぜなぜ分析適用時の課題

しかし、ソフトウェア開発はほとんど全工程が人手による作業なので、誤りが入り込んだ工程も人為的なミスである

真因分析の手順を策定するにあたり、当社のこれまでのことが多く、事実の認識が担当者の主観に大きく左右されなぜなぜ分析の適用事例からその傾向を調査し、ソフトやすい。従って、設計書などの客観的な確証をもって事実ウェア開発になぜなぜ分析手法を適用する際に分析担当者確認するべきである。

が陥りやすい問題を洗い出した。その結果、ソフトウェア第三の問題点は、上流工程からの入力情報の誤りに順々

2 0 1 1 年 7 月・ S E I テ クニ カ ル レ ビ ュ ー ・ 第 1 7 9 号 −（ 89 ）−に着目してしまったが故に、なぜの繰り返し回数が十分で上流から下流に向けて、要求を詳細化し実装するプロセスあるにも関わらず、深度が不足するケースである（図 1（c））。と、V 字の右側で下流から上流に向けて、実装した結果がこのケースでは、確かに担当者の「作業工程」に着目し、要求のとおりに正しく機能していることを検証するプロセかつ、詳細設計書から基本設計書へと客観的な確証であるスで構成される開発手法である。

「設計書」をたどって誤りの発生した工程を特定している。

［解決策 1］第一の課題「プロセス上の要因分析が不十分」

しかし、誤りの入り込んだ工程の特定に「なぜ」の分析ス

については、「プログラム上のメカニズム」調テップを費やした結果、誤った作業が「なぜ」行われたの査と「作業プロセス上の誤り」調査を分けて行かという本来必要な真因分析がなされていない。このよううことで、前者の調査に偏らない事実調査を行な作業誤りが発生した工程の特定までの作業は、本格的なう手順を策定することとした（図 3【手順 1】）。

「なぜなぜ分析」作業の前工程で完了させておくことが、［解決策 2］第二の課題「客観的な事実収集が不十分」につより深い真因分析のためには必要である。

いては、ソフトウェア開発プロセスの初期段階からプログラム製作段階に至るまでの間に作成されるすべての設計書をプロジェクトの登録文書からリストアップし、どの工程の設計書が誤〈バグ事象〉〈Why-1〉〈Why-2〉〈Why-3〉○○の条件下で、特定フレームを送信しない送信中フラグと送信要求ビットの不整合が発生していた初期化完了前のチャンネルへ送信処理を実施
していた

通信ドライバの初期化処理時に意図しない割込許可が存在していた［解決策 3］第三の課題「工程内の真因追究が不十分」につ設計書を工程の順序に並べ、どの工程までの設りを含んでいるかを調査することで、主観に左右されない確証収集を行うこととした。
いては、［解決策 2］で述べた方法で収集した（a）バグを引き起こすメカニズムの追求に終始した例〈バグ事象〉〈Why-1〉〈Why-2〉〈Why-3〉△△装置に対する通信確認コマ
ンドがエラーとなる

受信途絶後、100ms で受信バッファをクリアしていた設計者が仕様を誤認しているのに気づかず、不要な処理を実装した

仕様書レビューを行ったが、設計者が誤認していることに気づかなかった

計書が正しく、どの工程から設計書に誤りが含まれるかを調べることで、V 字モデルのソフトウェア開発プロセス上で誤りが織り込まれた工（b）分析者の思い込みや印象に頼った分析例〈バグ事象〉〈Why-1〉〈Why-2〉〈Why-3〉○○の条件下でソフトウェアが起動しない

実装工程にて、ポート番号に△△と謝った設定をした

詳細設計書に、△△と誤ったポート番号が書かれていた基本設計書に、ポート番号の記載がなかった程を特定することとした（図 3【手順 2】）。

ここまでの分析作業を機械的な手順で行うことにより、（c）上流工程からの入力情報の誤りのみを分析対象とした例

図1

従来のなぜなぜ分析適用事例【手順2】プロセス上の要因分析
要因工程

ソフトウェア要求分析

バグの織り込み要因基本設計

3.

詳細設計

課題解決方針の策定目的とするソフトウェアバグ発生時の真因分析手順を策定するにあたり、2 章で示した課題の解決方針を検討した。
当社の開発プロセスは V 字モデルであり、解決方針を検討するにあたっては、この開発プロセスに即したものとなるよう留意した。なお、V 字モデルとは、ソフトウェア開発プロセス手法の一つで、図 2 に示すように、V 字の左側で実装〈Ｖ字モデル発生側〉（流出側省略）バグ
事象

バグの【手順1】 織り込み 【手順2】箇所

ソフトウェア要求分析

ソフトウェア総合テスト

基本設計

結合テスト

詳細設計

単体テスト
実装

図2

V 字モデルと開発プロセス−（ 90 ）− ソフトウェアバグ発生時の真因分析手法の策定

車両の挙動
ソフトウェアの挙動分析の方向＝発生メカニズム追及

バグ事象

バグの織り込み箇所

要因工程＋バグの織り込み要因【手順3】

真因要因工程バグの織り込み要因
直接要因

分析の方向＝
要因深掘り

プロセス要因管理要因
組織要因【手順1】発生メカニズム調査
図3

分析の方向＝上流工程へさかのぼりバグの織り込み箇所

真因【手順3】なぜなぜ分析

あるべき分析の流れイメージ図

図 3 の【手順 3】で示すような、プロセスルール上の要因、管理上の要因、組織をとりまく風土など、誤り発生の背景となるより深い要因まで分析する作業により多くの時間を割ける手法を策定することにした。

順のモレを防ぐことができるとともに、分析者以外のメンバが分析結果を客観的に確認できるよう工夫した。
4−2

V 字モデルのプロセスに沿った事実調査

続いて、バグを織り込んだ時期の事実の把握を行い、「要因工程」の絞り込みと「バグの織り込み要因」の特定を行う手

4.

ソフトウェアバグ発生時の真因分析手順の策定
4 −１

バグ発生時の真因分析の流れ

3 章で示した順について説明する。
この手順では、事実を正しくモレなく調査する事が重要であり、この作業を進めるために、図 6 に示すツール①

方針に従い、バグ発生時の真因分析手順を策定した。真因「V 字プロセス別事実調査票」を用意した。この帳票では、分析は、図 3 で示した、「あるべき分析の流れ」に沿って行開発プロセス名と調査項目をマトリクス上に配置しており、うものとし、次の（1）～（3）の手順で実施する。

分析に不慣れな作業者であっても、順を追って欄内に記載（1）【手順 1】発生メカニズム分析

していくことで無駄やモレなく調査を行えるよう工夫した。

プログラム上で、対象のバグ事象を引き起こしているメカニズムを追求し、バグの織り込み箇所を特定する。
（2）【手順 2】プロセス上の要因分析

V 字モデル開発プロセスに沿って、設計書類を調査し、誤りが織り込まれた工程（要因工程）とその誤り内容（バグの織り込み要因）を抽出する。
（3）【手順 3】なぜなぜ分析

要因を深掘りし、バグが織り込まれた真因を導出する。
以上の手順に、3 章で示した解決策織り込むため、図 4

手順（２）：構成管理情報
成果物構成情報
No プロセス名 ・フォルダ名
・ファイル名ソフトウェア ・文書番号
1 要求分析・作成／更新日付
2 基本設計・担当者など
3 詳細設計

事実・問題点
要因工程・変化点抽出あるべき姿に・フォルダ名
・事実の把握対する問題点・ファイル名・文書番号
手順（4）：発生側要因工程
・実施日
基本設計書
（正）
・レビュー
実施形態 「条件a＝0のとき、負荷B＝OFF→ON」
・レビュー記録
詳細設計書（誤）条件a＝1とすべき■など「条件a＝1のとき、ポート ところが、a＝0となって発生Bに1をセットいた（誤）条件a＝1とすべき
ソースコード上「条件a＝1のとき、ポート ところが、a＝0となっていたBに1をセット」に示すツール①～③を用意した。以降に、各々のツールの4 実装詳細を説明する。

5 単体テスト

手順（1）：発生メカニズム分析
結果より転記6 結合テスト
ソフトウェア
7 総合テスト（ソフトウェアのバグ検出）【手順1】発生メカニズム調査【手順2】プロセス上の要因分析（再発防止策立案）

図4（誤）条件a＝0のとき負荷結合テスト仕様書■
条件aに関するテスト項目 B＝OFF→ONのテスト項目
流出がなかったなし

手順（6）：なぜなぜ分析へ

図6手順（5）：流出側要因工程

V 字プロセス別事実調査票〈解決策（分析サポートツール）〉
ツール① Ｖ字プロセス別事実調査表
ツール② なぜなぜ分析シート（様式）【手順3】なぜなぜ分析

手順（3）：事実・問題点

レビュー時記録

ツール③ なぜなぜ分析時のポイント

V 字プロセス別事実調査票を使った具体的な調査手順を以下に示す。
（1）図 4 の【手順 1】発生メカニズム調査の結果を元に、実装プロセスの事実・問題点欄にバグ織り込み箇所とその内容を記載する。

バグ発生時の真因分析手順と解決策（2）プロジェクトの登録文書を参照し、当該バグが織り込まれた時期の各プロセス成果物の作成およびレビュー時の記録情報を記入する。

まず、一連の手順通りに、順を追って確実に作業できる（3）（2）で収集した成果物を参照し、（1）で記載した

よう、図 5 に示すツール②「なぜなぜ分析シート」を用意

バグ織り込み内容と関連する事実や誤りの有無を確した。このシートには、個々手順の出力となる一連の項目証に基づいて洗い出し、事実・問題点欄に記載する。に対応した記載欄を設けた。この欄を順に埋めることで手（4）（1）で記載したバグ織り込み工程から順に、事実・問題点欄の記載を参照しながら上流側プロセスにたどり、一つ上流の工程までは正しく、当該工程

J1

J2J3

Why1

Why2

Why3

バグ事象
車両の挙動

バグ事象
ソフトの挙動バグ事象
織り込み箇所

バグの織り込み要因

直接要因

プロセス要因（ソースコード上）

要因工程：に誤りがある場合に、当該工程を発生側要因工程と判断することで、発生側の要因工程を特定する。図6 に示す例では、事実・問題点欄の記載内容から、「詳細設計」工程に「条件 a ＝ 0」の誤りが含まれるが、一つ上流の「基本設計」工程は正しいことから、
図5

なぜなぜ分析シート（一部抜粋）「詳細設計」工程を発生側要因工程としている。

2 0 1 1 年 7 月・ S E I テ クニ カ ル レ ビ ュ ー ・ 第 1 7 9 号 −（ 91 ）−（5）基本的には、発生側要因工程に対し、V 字モデル上に分析する際には参考になりにくかった。

で相対する（V 字の右に当たる）検証工程の、一つそこで、不慣れな分析者でも品質の良い分析を行うこと上位の工程が流出側要因工程であると考えて、流出ができるように、参考文献（5）で提案されている「なぜな側の要因工程を導く。図 6 に示す例では、（4）で発ぜ分析実施の 10 則」などを参考に、ソフトウェア開発で生側要因工程と特定した「詳細設計」工程に相対す

分析時に陥りやすい誤りを整理し、ソフト経験に即したサる検証工程である「単体テスト」工程の一つ上位にンプルを付記して、表 1 に示すようなツール③「なぜなぜあたる「結合テスト」工程を、流出要因工程として分析時のポイント」として整備した。

いる。この考え方は、V 字モデルでは、そのバグが織り込まれた発生側（詳細化・実装）工程に相対す

表1

る流出側（検証）工程の一つ上位の工程で検出すべ

なぜなぜ分析時のポイント（例）きという原則に基づいている。なお、分析者が、こNo.の考え方に不慣れな場合でも手順通りに特定できる（×）流用元 PJ のシステムデザインにバグが含まれていた。
→流用元 PJ 開発時に作り込まれたバグである
流用元 PJ のため、発生要因は不明。
潜在バグも
B4
自 PJ 視点で（○）流用元 PJ のシステムデザインにバグが含ま分析するれていた。
→流用時に、必要な成果物が揃っていないにも関わらず、当該 PJ へ適用する際の差分検証を実施しなかった。

よう、図 7 に示すプロセスおよび成果物の流れを用意し、発生側要因工程から流出側要因工程を導出する手助けとした。

凡例：プロセス名称（Ｖ字プロセス別事実調査票のNo.を並記）：成果物名称（代表的なもの）：プロセスの流れ：成果物の流れソフトウェア
要求分析（No.1）
ソフトウェア
要求仕様書

ソフトウェア
総合テスト設計（No.7）
ソフトウェア
総合テスト仕様書

ソフトウェア
総合テスト（No.7）
ソフトウェア総合
テスト結果報告書

基本設計（No.2）
基本設計書

結合テスト設計（No.6）
結合テスト仕様書

結合テスト（No.6）
結合テスト結果報告書詳細設計（No.3）
詳細設計書

単体テスト設計（No.5）
単体テスト仕様書

単体テスト（No.5）
単体テスト結果報告書

実装（No.4）
プログラム

図7

ソフトウェア開発における例（×：悪い例、○：良い例）（×）担当者のスキルが低く、分析が不十分だった。
対個人ではなく仕組み（○）車両の振る舞いという観点から、エラー時
B8 と し て の 視の挙動の分析が不十分だった。
点で分析す（○）担当者は必要な教育を受けていないにも関るわらず、デザインリーダとしてアサインされた。

5.

V 字モデルとプロセス成果物の流れ

ポイント

開発プロセスへの適用と手順導入の効果
4 章で述べた一連の分析手順は、試行運用を経て 2010

年 7 月に量産開発部門の標準ルールとして採用された。
SQA ※2 部門の指導・監督の下、各開発プロジェクトの担当者が、バグ発生時に本手順に基づいて分析を行うという体（6）以上の手順で特定した、発生側要因工程および流出制で運用を開始した。

側要因工程に対する、「あるべき姿に対する問題点」

SQA 部門が 2010 年度末にとりまとめたソフトウェア品欄の記載内容を、次項で説明するなぜなぜ分析の質活動実績によると、バグ発生から真因分析完了までのWhy1 に設定する。

リードタイムは 2009 年度と比較して約 40 ％短縮でき、バこれまでに説明した手順を用いることで、従来は、事実グ発生からプロセス改善までのトータルリードタイムは約調査が十分でなく、しかも分析担当者の直感に頼っていた1/3 になり、問題の再発防止策を策定するまでのスピードバグの織り込み工程の特定作業を定型化でき、また、確証が向上できた。

を用いて客観的に分析結果を判断できる仕組みが整った。

本稿で述べた各手順のソフトウェア品質向上への寄与を次に 4 − 2 で導き出した

分析するため、SQA 部門にアンケート調査を行い、今回定発生側および流出側の Why1 をスタートとして、図 5 のなめた方策のツール①「V 字プロセス別事実調査票」ツール

4−3

なぜなぜ分析の実施

ぜなぜ分析シートを使用してなぜなぜ分析を行う。

②「なぜなぜ分析シート」ツール③「なぜなぜ分析時のポ真因を導くためには、要因を規則的に順序よく深く掘りイント」のそれぞれについて、「リードタイム短縮」と下げる必要があるが、これまでは適用事例も少なく十分な「分析品質向上」の観点で評点を算出した。その結果を図 8

ノウハウがないという問題があった。なぜなぜ分析のノウに示す。別途実施した SQA 部門へのヒアリング結果と合ハウが示された一般的な文献もあるが、製造設備上の問題わせて手順導入の効果を考察した。以下にその考察結果をを対象とするサンプルが多く、ソフトウェアのバグを対象述べる。

−（ 92 ）− ソフトウェアバグ発生時の真因分析手法の策定

4 − 1【手順 2】「プロセス上の要因分析」で使用する分析品質の点ではまだまだ改善の余地があり、今後は、ツール①「V 字プロセス別事実調査票」は、客観的な事実さらに分析品質を高めるため、教育面でのツールの活用を確証に基づいてバグ織り込み工程の特定ができることか促進するとともに、当社開発プロセスや対象製品に特有のら、事実関係の把握が正確にでき、分析品質の向上と共に分析事例を蓄積し、なぜなぜ分析時のノウハウとして活用

リードタイム短縮にも有効であること分かった（共に評点を進めていく。

3.4）。更に、「調査票作成の手間は増えるが、事実確認が十分でないことが理由の分析の手戻りが減り、結果的にリードタイム短縮に貢献している」とのコメントも得られた。このことから、事実調査の品質向上が、源流対策推進活動に寄与できていることがわかった。

用 語 集ーーーーーーーーーーーーーーーーーーーーーーーーーーーー※1

しかし、4 − 1【手順 3】「なぜなぜ分析」で用いるツー

TQM

TotalQualityManagement ：総合的品質管理。

ル②「なぜなぜ分析シート」およびツール③「なぜなぜ分析時のポイント」については、前者はリードタイム短縮に※2は一定の効果があるものの、何れの手順も現時点での分析

Softwarequalityassurance ：ソフトウェア品質保証。

SQAの品質向上効果への寄与は判断できかねた。その理由として、なぜなぜ分析の品質には、分析者の熟練や慣れが大きく影響するためと考えられた。そのため、ツール③を教育用資料として活用するとともに、過去事例を整理し、当社ソフトウェア開発に特化した分析ノウハウをさらに蓄積し活用していくことが重要と考えている。

参考文献（1） ソフトウェアエンジニアリング研究所、「能力成熟度モデルのキー
プラクティス 1.1 版」、CMU/SEI-93-TR-25、カーネギーメロン大学（1993）（2） 寺久保敏 他、「CMM レベル 3 に準拠した車載向けソフトウェア開発
プロセスの構築」、SEI テクニカルレビュー第 166 号、pp45-500

有効性（リードタイム短縮）①Ｖ字プロセス別事実調査票−【プロセス上の要因分析】で使用

234
良い

3.0
2.0

③なぜなぜ分析時のポイント−【なぜなぜ分析】で使用

0.0

0.5

1.0

1.5

2.0

2.5

3.00

有効性（分析品質向上）①Ｖ字プロセス別事実調査票−【プロセス上の要因分析】で使用

13.5
234.0

悪い

良い・C MM は、カーネギーメロン大学の登録商標です。

2.6
1.8
0.0

0.5

1.0

1.52.02.53.03.54.0【調査対象】 量産開発部門のSQA選任メンバ【調査方法】 選択式【調査時期】 2011年3月15日〜3月17日【回答者数】 5名【集計方法】 以下配点で、回答者の平均値を算出
4点：非常に良い、3点：良い、2点：普通、1点：余り良くない、0点：悪い

図8

6.

結

（5） 小倉仁志、「なぜなぜ分析を使いこなそう！なぜなぜ分析徹底攻略ドリル」、JIPM ソリューション（2002）

4

3.4②なぜなぜ分析シート−【なぜなぜ分析】で使用（3） 小倉仁志、「なぜなぜ分析徹底活用術−「なぜ？」から始まる職場の改善」、JIPM ソリューション（1997）（4） 早川勲 他、ソフトウェア品質シンポジウム 2008、「ソフトウェア開発へのなぜなぜ 5 回の適用」、pp185-194

3.4②なぜなぜ分析シート−【なぜなぜ分析】で使用③なぜなぜ分析時のポイント−【なぜなぜ分析】で使用

1悪いSQA 部門へのアンケート結果

言執筆片岡者 ----------------------------------------------------------------------------------------------------------------智 美＊：㈱オートネットワーク技術研究所
ソフト開発センター
車載ソフトウェアの開発プロセス、開発環境構築業務に従事

古戸健 ：㈱オートネットワーク技術研究所
主任研究員

ソフト開発センター

松本

達 治 ：㈱オートネットワーク技術研究所
センター長

ソフト開発センター------------------------------------------------------------------------------------------------------------------------------------＊主執筆者

本稿では、高い品質が求められる車載ソフトウェアのプロセス改善活動をより効率的に行うために策定したなぜなぜ分析運用手順と、その導入効果について述べた。
今回策定した手順は、V 字モデルを採用する車載ソフトウェア開発に限らず、開発プロセス上で発生した問題の真因分析に広く応用できる手法であると考えている。

2 0 1 1 年 7 月・ S E I テ クニ カ ル レ ビ ュ ー ・ 第 1 7 9 号 −（ 93 ）−