はじめに
品質分析は、正しく活用すると品質向上するだけでなくスケジュール遅延の抑止、コスト低減など多くのメリットを作ります。
ところが多くのプロジェクトでは、品質分析の目的を理解せずに実施しているケースが見られます。
多くの人が品質分析は無駄と思いつつ、社内審査を通すために仕方なく実施しているのではないでしょうか。
ここでは品質分析が無駄と思われる原因と、正しい品質分析について解説します。
品質計画の作成については、別記事「品質マネジメント計画」を参考にしてください。
品質分析の誤解
品質分析を「意味がない」「時間の無駄」と考えている人に、その理由をヒアリングすると、その理由は主に次のような点のようです。
- 分析しても成果物の品質は上がらない
- 分析結果を報告することが目的になっている
- とにかく分析に時間がかかる
確かに、品質分析には相応の労力が必要です。
ただ「報告すること」が目的であり、プロジェクトにメリットが感じられないのであれば、避けて通りたいと感じるのも当然です。
さらに品質に課題があるように報告することで改善対策を指示されると手間なので「品質に問題ないこと」を訴えるための資料になる傾向にあります。
品質分析は誤解されることが少なくないのですが、どのような誤解があるか見ていきます。
誤解１：品質レベルの指標値として利用される
品質分析で使用する指標値は、統計をもとに不具合やテストケースの項目数を算出するのに使用されます。
指標値は目安であり、高品質／低品質を決めるレベルの物差しではありません。
よくある誤解として、プロジェクト計画作成時に品質指標値（不具合発生の上限／下限値など）と比較して、その範囲内に収まっていたら「品質がよい」と判断するようなケースです。
例えば、不具合件数やテストケース数が品質指標値を満たしていないと品質に問題あり（不合格）と判断するプロジェクトです。
これは品質分析についての理解が浸透していないため、組織内で規定されたルールが独り歩きする場合に発生します。
重要なのが「品質指標値とは何か」を理解することです。
品質指標値は、過去プロジェクトの実績データから「これくらいの規模であれば、これくらいのテストケース数を作成し、これくらいの不具合が出る傾向にある」という目安です。
プロジェクトは多様であり、それぞれ特徴があります。
その特性を無視して、品質を担保する絶対の基準値を定義することはできません。
品質指標値は、テストケース数や不具合件数が多いのか少ないのか傾向を知るために、「今までのプロジェクト実績の傾向をみると、これくらいの規模なら、これくらいの件数に集約している」という物差しとして利用します。
当然、指標値から外れることもあります。
例えば既存機能を流用してプログラムを作成した場合などは、ゼロから作ったときの指標値より不具合発生は少なくなるでしょう。
むしろ、指標値と同じくらい不具合が出ている場合は、逆に問題があるかもしれません。
発生している不具合や作成したテストケースが多いのか、少ないのか気づくために基準値を使用しているだけで、品質の良し悪しには直結しません。
重要なのは標準より多い／少ないを知り、その理由を意識したうえで懸念点や改善ポイントがないか考察することです。
誤解２：品質報告するために分析する
品質分析の目的は現状の品質状況を把握して改善点を発見し、品質向上やトラブルの抑止につなげることです。
ところが多くの場合で「工程完了審査のルールで報告する必要がある」という目的で品質分析しているのではないでしょうか。
工程完了審査で品質報告するのは良いのですが、その時に分析して報告するのは正しい運用ではありません。
開発を進める中で、定期的に成果物の品質傾向を確認し、問題が起きやすい傾向がある場合は軌道修正する取り組みを行います。
そうすることで、それ以降の開発精度は高まりますし、気づいた問題点を早期に対処することもできます。
そして工程審査では、これまで行った分析と対策を含めながら状況報告するものです。
大切なのは品質を向上するための取組みであることを理解しましょう。
誤解３：品質はテストだけで確認できる
「テストで確認しているから、これ以上の取組みは必要ない」という言葉を耳にします。
テストで品質状況を確認しているのは正しいのですが、だからと言ってテストが完了したら潜在している不具合もゼロになっているとは言い切れません。
もちろん品質分析をしたからと言って不具合をゼロにできるわけではありませんが、それでも検知できる潜在的不具合を取り除く努力は行うべきです。
あらゆる膨大な量のテストを行うことで不具合件数をゼロに近づけることは出来ますが、そもそもテスト工数にも限度があります。
品質分析を行うことで、「テストケースが足りているか」「どのような点に不具合が集中しているか」などを検証し、テストケース不足を検知したり、弱点のありそうな箇所を強化テストすることにつなげることで、ポイントを絞って品質向上に向けた対策をとることができます。
正しい品質分析
品質分析は、成果物の不具合発生状況や開発規模、作業工数を分析することで、現在の弱点や改善ポイントを検知するために行います。
次からは、分析元データの入手と分析ポイントについて解説します。
分析元データの入手
品質分析を行うために使用するデータはレビュー記録表や不具合管理の情報、プロジェクトの規模情報といったデータを使用します。
品質分析の定量データについては、別記事「品質を定量分析する方法」を参考にしてください。
ここでは品質分析の時間を短くするポイントについても記載しています。
プロジェクトによって特性もあるため、分析に必要な情報があれば追加します。
ただし情報を追加しすぎると記入する担当者の負荷が高くなるので、本当に必要な情報だけに絞ってください。
もし、これらの情報入力に不備があればメンバを指導して正しく入力してもらいます。
障害区分や障害分類の入れ方に慣れていないと誤った設定をされる可能性もあるので、特に初期の段階では正しく入力されていることを確認しましょう。
５つの分析ポイント
諸元データが集まってきたら分析します。
分析は区分などの発生件数に偏りがあるかをチェックします。
これらのデータを毎回手で集計すると大変なのでBIツール（TableauやDr.sum）のようなデータをグラフィカルに表現できるツールの利用や、Excelで数値化やグラフ表示するツールを作成します。
Excelの不具合管理表とレビュー記録表についてはサンプルを用意しているので、よければご活用ください。
この分析は工程完了時に１回だけ実施するのではなく、中間で定期的に実施することで効果を発揮します。
そこでは報告資料は不要であり、自分で結果を把握できれば十分です。
分析方法は以下の５つがポイントです。
１．発生頻度の高い不具合原因があるか
各工程の中で障害区分と障害分類が突出して発生しているものがないか確認します。
例えば障害区分の「インターフェイス誤り」が多く、その障害分類を見ると「業務理解不足」が多かったとします。
この結果から担当者は外部連携に関する業務理解が足りないため不具合が多く出ていることがわかります。
すると次のような対策を取ることができます。
- 担当者への業務説明を行い再発防止する
- 外部インターフェイスで他に問題ないかチェックする
２．不具合が埋め込まれた工程はどこか
不具合が現在の工程で混入されたのか、前工程に原因があったのかチェックします。
例えば内部設計でロジック不具合があった場合、内部設計の検討で誤ったのか、インプットとなる基本設計に不具合があったのかチェックします。
もし前工程が原因の場合、前工程の不具合発生原因と、その前工程で検知できなかった理由について検討します。
もちろん、横展開する不具合がないかチェックする必要もあります。
これにより前工程起因の不具合が他に潜在していないか確認することができます。
３．成果物を作成した担当者やグループの傾向
特定のメンバやグループに偏って発生していないか確認します。
ただし犯人捜しにならないように注意してください。
もし特定メンバやグループに発生件数が多い場合は、偏りがおきる原因を分析して対策を検討します。
その原因が知識不足であれば、業務説明を行うことで正しい設計を行えるようにします。
もしくは有識者の支援を入れることで改善する方法も考えられます。
または、メンバに開発で必要な最新情報が連携されていないことが原因であれば、情報共有を促進したり、ツール導入することでコミュニケーションを円滑にするなどの対策が行えます。
このように分析することで、品質向上だけでなく生産性向上につなげる施策を検討することもできます。
４．品質計画の指標値との比較
品質分析では各種データを活用して分析しますが、その中で品質計画の指標値も使用します。
これは冒頭で説明した誤解の１つ「品質レベルの指標値」ではなく、統計データの数値と比較して多い／少ないの判断材料として活用します。
ちなみに指標値は、自社のプロジェクト過去実績を収集し、統計を取るのがベストです。
社内に蓄積された過去データがなければIPA（情報処理推進機構）が提供するソフトウェアデータ白書の指標値を参考にすることも有効ですが、多様の会社から収集した統計データなので、自社に特化した統計データの方が精度が高いためです。
この指標値と実態を比較すると、現在の品質状況が見えてきます。
例えば、次のような分析につなげられます。
- 特定機能だけテストケースの項目が指標値より極端に少ない
→担当者の考慮不足でテスト観点が足りなかった - プログラム流用したのに不具合件数が多い場合、流用の仕方について担当者が理解不足だった
→担当者へのレクチャーとフォロー実施 - 不具合が多いのは設計書レビューの工数がすくないから
→レビュー不足の機能に対して追加チェックする
指標値と乖離していること自体を問題視するのではなく、改善ポイントを検討することが大切です。
５．前回の分析結果との比較
この品質分析は定期的に行うことで、より品質向上につなげることができます。
品質分析して改善策を適用した場合、その成果が出たのか、また新しい課題が出ていないかチェックします。
まさにＰＤＣＡサイクルで品質向上させるイメージです。
このように改善を繰り返すことで、見えなかった新しい問題課題を発見することもあります。
その時は、さらに改善を行うことで品質の底上げをしていきます。
品質はテストで検知するだけではありません。
改善を繰り返すことで潜在的な不具合を除去することで、品質を作り上げることを意識しましょう。
