システム開発で品質を定量分析する方法 – データ収集から問題発見、改善方法の検討まで

はじめに

PMBOKで品質は「テストや検査で確保するのではなく作りこむもの」としています。
ひたすらテストで不具合を潰して品質を上げるのではなく、設計や製造工程で不具合を埋め込まないことに注力するという考え方です。

基本設計で埋め込んだ１件の不具合が、結合テストで10件の不具合につながることもあります。
そのため前工程で不具合を検知した方が品質向上、生産性向上につながります。

そして早い段階で不具合を検知したり、不具合の発生を抑止するための対策としてあげられるのが品質分析です。
この品質分析には定量分析と定性分析があります。

定量分析
数値データをもとに不具合の発生状況やテスト過不足について分析を行い、潜在的な不具合がないか確認します。

定性分析
品質対策で実施したプロセスなど、数値では扱えない事実について分析します。

今回は定量分析のやり方について解説します。
品質計画の作成については、別記事「品質マネジメント計画」を参考にしてください。

品質分析の目的

品質分析を誤解している人が本当に多いので、目的を定義します。

よくある誤解が「成果物の品質評価を報告するために行っている」というものです。
本来の目的は成果物の品質に関する傾向分析を行い、不具合の早期発見やチームの弱点を把握して対処することで成果物の品質向上、およびプロジェクト推進自体の生産性向上を目的とします。

積極的に早い段階で不具合への対処・予防を行うことで品質を作りこむことが目的であり、報告のため工程完了時点で分析するのではなく、工程の中で何度も繰り返して実施するものです。

しかし品質分析が負担になるのは問題なので、手軽にデータ収集できる仕組みを用意するとよいです。

データ収集方法

データ収集で注意すること

何のデータを収集するのか分析内容によって異なりますが、収集する項目が多いほど様々な角度から分析することができます。
ただデータ収集するためのメンバ作業が大きいと現場の負担となり、生産性が下がるだけでなく品質分析それ自体が形骸化する可能性があります。
そのためデータ収集するときは以下の点を意識します。

データ収集のツール化

諸元データを収集するような単純作業は、できるだけツール化します。
例えば複数あるレビュー記録表から指摘件数や指摘区分などの情報を集約して一覧化するような場合、ExcelのVBAやpythonを使ってcsv出力、Excelに一覧で集約するツールを用意します。
Redmineからダウンロードしたcsvを分析できるデータに成形ツールも該当します。
ツール作成には手間がかかりますが１つ作れば他プロジェクトでも活用できます。
社内などでツールを共有する仕組みを設けるとよいでしょう。

別記事にレビュー記録表と、それらを集計するExcelマクロを用意したので活用ください。
こちらの記事「レビュー記録表／レビュー記録集計ツール」からダウンロードできます。

収集するデータ項目は必要最小限にする

基本的に諸元データはレビュー記録表や不具合管理表を使うことが多く、それらは一般的に作業者が入力します。
分析者の視点で考えると多様な情報を採取したいところですが、登録情報が多すぎると作業負荷が増えるので、できるだけ必要最小限にします。

品質分析で必要となる諸元データ

システム開発の品質分析では「レビュー記録表」「不具合管理」をもとに品質分析することが多いです。
設計書やコードの机上デバッグではレビュー記録表、テストで発見した不具合は不具合管理表を使用するのですが、次の情報を収集するとよいでしょう。

＜レビュー記録表＞

規模	実装開始前の想定規模数です。 この規模は機能のステップ数を指します。
設計／製造担当	設計書、またはプログラムをコーディングした担当者です。
レビューア	レビュー実施者です。 複数いる場合は、複数名記載します。
レビュー時間	レビューで使った時間です。 複数人で実施した場合、時間に人数をかけ合わせます。
ページ数	設計書の場合、レビュー対象のドキュメントのページ数を記載します。 コードレビューでは不要です。
対象機能	画面やバッチなどの機能です。
発生工程	基本設計、詳細設計などレビュー時の工程を記載します。
原因区分	不具合の原因を選択します。 （例） ・要求仕様誤り　・外部インタフェース誤り　・設計漏れ　・処理誤り　・データ定義誤り　・規約標準の違反　・誤字　など
発見すべき工程	不具合が混入された原因の工程を記載します。 例えばコードレビューした結果、基本設計書に不備がありコーディングに問題がある場合は、基本設計と設定します。
重複有無	同じ指摘が他にもある場合は「有」を設定します。 この重複をどのようにカウントするのか、方針を決める必要があります。

＜不具合＞

規模	実装開始前と実ステップ数です。 ステップ数では空行やコメント行をステップ数に含めるのか方針を決める必要があります。
製造担当	コーディングした担当者です。
発生日	不具合を発見した日付です。
対象機能	画面やバッチなどの機能です。
発生工程	単体テスト、結合テストなどの工程を記載します。
不具合区分	発生した不具合の内容を選択します。 （例） ・表示不正　・入力チェック誤り　・データ更新誤り　・初期化ミス　など
原因区分	不具合の原因を選択します。 （例） ・機能漏れ　・処理誤り　・インタフェース誤り　・例外処理誤り　・単純ミス　など
発見すべき工程	不具合が混入された原因の工程を記載します。 例えば結合テストで発見した不具合が、本来は単体テストで検知すべき内容であれば、単体テストと設定します。 不具合の内容によっては基本設計、詳細設計という場合もあります。
重複有無	同じ指摘が他にもある場合は「有」を設定します。 この重複をどのようにカウントするのか、方針を決める必要があります。

問題点の発見方法

収集した諸元データをもとに分析して問題点を発見します。
指標値を参照して乖離、事象の偏りをみて判断します。

品質分析の考え方について、別記事「品質分析５つのポイント」も参考にしてください。

指標値との乖離

指標値とは、過去の経験値から開発規模（ステップ数）ごとに発生する指摘や不具合の想定件数です。
この数値は過去のプロジェクトデータを蓄積することで標準データを作成します。
もちろん新規開発／改修や、開発言語、業務により基準値は変わってきます。
この基準は開発ベンダが会社や部門内で集計するのですが、もし累積データがなければ、IPAのソフトウェア開発データ白書を活用してもよいです。
これは複数の開発ベンダからデータ収集して基準値を設定しています。
ただしプロジェクトの背景や環境は異なるため、参考程度として活用します。

上記の指標値と実績値を比較します。
これはステップ数あたりの指摘／不具合発生件数を比べて大きな乖離がないか確認します。
指標値とあっていれば合格ということではなく「これくらいの規模なら、これくらいの件数は出るだろう」という考え方です。

例えば、ある機能について指標値だと10件発生する想定が、実際は不具合発生件数が30件出たとしましょう。
想定より多く発生しているので、何か問題があるかもしれません。
この対象機能について、次の「事象の偏り」を確認しながら不具合内容をチェックします。

または逆に不具合件数が1件しか発生しなかった場合、想定より不具合が少ないです。
完成されている類似機能を流用したから不具合が少なかった、という理由があればよいのですが、そうでなければテスト内容が足りない可能性があります。

また設計書の指摘件数が少なければレビュー不足という可能性もあります。
レビューアによって問題点の発見粒度にバラつきがあるかもしれません。

品質指標値の分析手法については、別記事「品質分析の実施手法」を参照してください。

事象の偏り

設計、製造担当者に偏りがないか

特定メンバが突出して不具合を発生している場合、その原因を確認します。
原因は「メンバが担当している機能の難易度が高い」「スキル不足」など可能性は様々ですが、そのメンバが担当した機能は重点的にチェックするなど対策をとります。

その担当者を責めるような空気は作らず、品質向上に向けたプロセスを改善するという考えで取り組んでください。

不具合原因の偏り

発生した不具合の原因に偏りがないか確認します。

例えば、外部インターフェイスで指摘や不具合が集中している場合、そうなった背景を調査します。
その原因が「参照していた連携先の資料が古かった」だった場合、新しい資料をもとに仕様確認すると他に問題点を発見する可能性があります。

別の例として、異常終了する不具合が多発している場合、発生した例外をキャッチする仕組みが万全でない可能性があります。
その場合、システム全体の例外に対するアーキテクチャを点検するなどの対策を行うことで品質向上につながるかもしれません。

このように不具合が多く発生している箇所はプロジェクトにおける弱点であるため、それらに手当をすることで全体の品質が向上します。

不具合の発生工程が妥当か

発生した不具合が、そのテスト工程で見つけるべき内容なのか確認します。

例えば結合テストを実施中に、本来は単体テストで検知すべき不具合を検知したとします。
その場合、なぜ単体テストで該当の不具合を検知できなかったのか確認します。
もし単体テストの実施方法に不備があった場合、他に検知できなかった不具合がないのか強化テストを行ったりして対処します。

前工程で発生した不具合については不具合が拡散している可能性もあるため、注意して原因分析します。

品質向上施策の蓄積

品質分析で検知した問題は対策を検討して処置していきますが、その対策はチームにとってのナレッジになります。
そのプロジェクトの中で開発メンバに周知すると思いますが、他のプロジェクトに参画したときに同様の問題が発生しないよう、このナレッジを活用することができます。

そのためプロジェクト完了時に品質向上に向けた取り組みを振り返ると良いでしょう。
そうすることで参加メンバのスキルを向上することができます。
また社内に品質改善のナレッジを蓄積／周知することで、組織全体の品質向上にもつながります。

おわりに

品質分析にはコストとパワーを使いますが、後工程で問題が噴出することを考えるとプロジェクト全体の負荷低減につながります。

不具合などで慌ただしいプロジェクトもありますが、しっかり品質分析をして改善をしていれば、そのような事態を回避できたかもしれません。

もし品質分析の取組みが慣れていなければ、一度に全部をやろうとすると大変なので出来るところから少しずつ取り組んでいくと良いでしょう。