QC7つ道具について(分析編)【2/3】

はじめに

　前回の記事では、ソフトウェアテストにQCがなぜ必要なのかということからはじめ、QCストーリーについての解説、QCのために必要なQC7つ道具と新QC7つ道具について簡単な説明を行いました。
　今回の記事では、QCストーリーに沿って、問題の分析部分にあたるステップで、QC7つ道具と新QC7つ道具がどのように活躍するか紹介していきます。
　おさらいになりますが、QCストーリーは以下のようなステップで進みます。

QCストーリーのステップ

　今回は、問題の分析部分にあたるステップ1からステップ4までで活躍するQC7つ道具と新QC7つ道具を紹介していきます。

QCストーリーのステップごとに道具を解説〜問題を見える化する〜

　今回の記事では、問題の分析について考えていくことになります。​​​​「何が問題かわからない」「原因が特定できない」といった悩みを抱える状況で非常に役立ちます。

1. 問題の明確化

活躍する道具：親和図法（新QC7つ道具）

このステップで何をするのか

　QCストーリーの出発点は、「問題がある」という漠然とした認識を、扱える形の問題に変えることです。
ソフトウェアテストの現場では、

といった声が上がることは珍しくありません。しかし、これらはまだ「問題の兆候」にすぎず、そのままでは改善活動のテーマとしては曖昧です。
このステップでは、まず現場で感じていること・起きていることを制限なく出し切ることが重要になります。

親和図法が活躍する理由

親和図法は、こうしたバラバラな情報を「意味の近さ」でまとめる手法です。
因果関係や正しさを考える前に、

を整理することに集中します。 この作業を通じて、「不具合が多い」という一言の裏に

といった異なる性質の問題が混在していることが見えてきます。

作業者の視点

管理者の視点

2. 現状把握

活躍する道具：チェックシート／グラフ／ヒストグラム（QC7つ道具）

このステップで何をするのか

問題の方向性が見えてきたら、次に行うのが現状把握です。ここでは、「本当にその問題は起きているのか」「どの程度なのか」を、事実と数字で確認します。
現状把握が不十分なまま次に進むと、「思い込み」や「一部の印象」に引きずられた改善になりがちです。

チェックシートの役割

チェックシートは、後で分析できる形でデータを集めるための土台です。
不具合を記録する際に、

といった項目をあらかじめ決めておくことで、集計や分析が可能になります。

グラフ・ヒストグラムの役割

グラフは変化や差を直感的に捉えるために、ヒストグラムは分布やばらつきを捉えるために使います。

といった点を、誰が見ても同じ解釈ができる形で示すことができます。

例えば、このグラフでは、テストが本格化した日付から検出数(青線)が急激に増加していますが、時間がたってバグが出尽くすと、件数が収束していきます。一方で、修正完了数は、検出数に少し遅れますが、しっかりと検出されたバグを修正できており、グラフの後半では、こちらも収束していっていることが読み取れます。

上のヒストグラムは、APIレスポンスタイムの分布図を表しています。このヒストグラムをみると、ほとんどが速い応答（左側）だが、一部だけ極端に遅い（右側に長く伸びるロングテール）様子が読み取れます。

■ 作業者の視点

■ 管理者の視点

3. 目標設定

活躍する道具：パレート図（QC7つ道具）

このステップで何をするのか

現状を把握すると、改善したい点が多数見えてきます。しかし、すべてに同時に取り組むことはできません。
このステップでは、改善の焦点を定めることが目的です。

パレート図が果たす役割

パレート図は、「重要な少数」に注目するための道具です。
不具合種別や原因別に件数を並べることで、

が明確になります。
目標設定の段階でパレート図を使うことで、「何となく重要そう」ではなく、データに基づいた目標を設定できます。

上のパレート図は不具合原因別に件数を表したものです。このパレート図をみると、累積比率が80％を超える、2つの項目、コーディングミスと仕様考慮漏れに対策をとるべきだということがわかります。

■ 作業者の視点

■ 管理者の視点

4. 要因解析

活躍する道具：特性要因図／散布図／連関図法

このステップで何をするのか

目標が定まったら、次はなぜその問題が起きているのかを考えます。
ここで重要なのは、安易に結論を出さないことです。

特性要因図

特性要因図は、問題を「人・プロセス・成果物・環境」などの切り口で分解し、考えられる要因を網羅的に洗い出します。
　例えば、以下のような背景ストーリーを考えてみましょう。リリース直後に、決済画面でエラーが発生しました。担当者は「確認したはず」と言っていますが、責めるだけでは再発します。一見すると「テストケースの不足」という問題に思えますが、本当にテストケースの不足だけが問題なのでしょうか。
　このようなときには、特性要因図が役立ちます。特定のバグがなぜ発生し、なぜ検出されなかったのかを、「個人のミス」で終わらせず、プロセスや環境を含めた「構造的な弱点」として洗い出すのに最適だからです。今回は特性要因図を作るにあたって、要因を「人・プロセス・技術・環境」の4つの視点で洗い出すことにしました。

このようにして、問題を「人・プロセス・成果物・環境」などの切り口で分解し、考えられる要因を網羅的に洗い出していくと、「テストケースの不足」という問題だけではなく、「有識者の不在」や、「仕様書の更新漏れ」といった問題があることも確認することができるようになります。

散布図

散布図は、2つの要素の関係性を確認するために使います。相関が見られれば、有力な要因候補になります。
例えば、次のような背景ストーリーを考えてみましょう。開発チームとテストチームの間で、「どの機能を重点的にテストするか」の議論になりました。テストチームは「複雑なスパゲッティコードになっている機能こそ危ない」と主張し、それを裏付けるために過去のデータを分析しました。過去のデータから、以下のような散布図を作成できたとします。

この散布図をみると、コードの複雑さを表すサイクロマティック複雑度と検出バグ数が正の相関をもっていることがわかります。このことから、コードが複雑な部分には今後検出されるバグが多く潜んでいる、と考えることができ、重点的に検証するべき機能の選定に役立てることができます。

連関図法

連関図法は、要因同士の影響関係を整理し、より根本に近い要因を見つける助けになります。
例えば、
バグの原因を掘り下げてみたとき、「時間がなかったから」に行き着きがちですが、そもそも「なぜ時間がないのか」を探ると、「仕様変更が多い」「決定が遅い」など、複数の要因が絡み合っています。この「悪循環」を可視化するには連関図法が役立ちます。

上のように、連関図法で原因をかきだしていくと、多くの問題が、「要件定義の詰めが甘い」という問題から発生していることがわかります。また、「テスト実行期間の圧迫」「テスト設計・レビューの省略」「テスト中の手戻り多発」という悪循環から抜け出すには、やはり、「要件定義の詰めが甘い」という問題を解決しなければならなくなるということがわかります。

■ 作業者の視点

■ 管理者の視点

次に

　今回は問題を分析するステップに沿って、QC7つ道具と新QC7つ道具の一部を紹介しました。何が問題かわからない状況や、原因の特定に苦労している際は非常に役立つはずです。
ぜひこれらの道具を活用して、直面している問題を分析してみましょう。その一歩がテスト業務をより高品質なものに近づけていきます。

この記事をシェアする