このシリーズは、私がこれまで経験したプロジェクトで培ったマネジメントノウハウをPMBOKの知識体系に沿って、駆け出しPMの方々や新入社員向けの読み物的な位置づけでノウハウや考え方をまとめています。ぜひご覧ください。
品質マネジメントにおける各プロセスは以下の通りです。
システム開発は、ものづくりです。そういう意味では作り上げるものの品質を担保しなければいけないというのは当然です。しかし、システムは形あるモノ（車や携帯など）と違って、触ることができません。そうした品質を管理するのが、この品質マネジメントです。
そのため、その品質（良し悪し）を図ることが非常に難しいです。
ここでは現場で役立つ品質の捉え方について解説していきます。
テスト計画
テスト範囲の決定
PMにとって一番大切と言っても過言ではない工程定義によって、どのテストでどこまで検証するかを決定します。
工程定義については以下の記事をぜひ合わせてご覧ください。
一言で単体テストといっても会社やプロジェクトによってその指し示す範囲はバラバラです。そのため、人によっても受け止め方も変わってきます。
このテスト工程が終わった段階でどこまでの機能を検証し担保したことにするのかをPMが音頭を取り、プロジェクトメンバー全員に周知しなければいけません。
工程定義によって、どこからどこまでをテストするのかという前提が整理されていることが、この後の不具合管理や不具合分析をするうえでの土台となります。
指標の決定
ここではあまり深く触れませんが、品質の評価指標としてよく用いられるものとして、
工数密度と不具合(指摘)密度があります。
テスト密度・・・テストケース数 ÷ テスト対象規模 (または規模)
不具合(指摘)密度・・・不具合数 ÷ テスト対象規模 (または規模)
指標値の参考として、IPAが公開している資料や自社で取り扱っている標準指標があればそれらを利用します。
そのうえで、今回のプロジェクトを対象にその特性を踏まえて指標を調整して、今回のプロジェクトオリジナルの指標を決めていきます。
と、ここでは教科書的な説明をしてきたが、小規模開発の場合はそもそも定量的な指標を決めないことも多いです。そういう場合、PMの勘が頼りになってしまう・・・。ぜひ定量的な指標を設けていきたいですね（自戒の念も込めて）
不具合管理・不具合分析
摘出できた不具合について分析をすることが大切です。
一般的にはX管理図や先にあげたテスト密度や不具合密度を軸での分析が良く上げられます。
ここでは、そこまでの分析は紹介しませんが最低でも実施すべき即効性のある管理と分析について解説したいと思います。
当工程バグ
当工程バグとは、対象のテスト工程にて摘出すべきバグのことです。どういうバグを摘出すべきかは、前述したPMの工程定義によるものですが、例えば、単体テストでは機能レベルの不具合が摘出できるであったり、結合テストでは画面遷移時の不具合が摘出できるであったりといったものです。
当工程バグが全くでない場合はそれはそれで、ちゃんとテストができているのかという疑った目線で見る必要があります。
前工程バグ
一番大切なのが、この前工程バグです。
当工程バグはその量の問題はさておき、摘出すべきバグであるため、摘出できることはむしろ喜ばしいことです。
しかし、前工程バグはその限りではありません。
前工程バグが出たということは、前工程での品質が担保できていない可能性が浮上します。
例えば、上記のような（ざっくり）工程定義をしていた時、内部結合テスト工程の段階で、ある画面の登録ボタンを押下したら例外エラーが発生した場合には単体テストが不十分であったと言わざるを得ません。また、シナリオテスト工程にて、画面遷移ボタンを押下したらエラーになった場合も同様です。
前工程バグは引きずれば引きずるほど、そのダメージを負うことになり、後になればなるほどリカバリをすることが難しくなります。
そのため、抽出された不具合を確認し、抽出された不具合が、本来前工程で抽出すべき不具合であったかどうかを分析・評価していきます。
そして、前工程バグが発覚した場合には即時に対応を行い、後述する横展開対応を行います。
横展開
抽出された不具合を確認したのち、横展開が必要な場合は、該当の不具合を是正するだけではなく、他に潜在的な不具合がないかのテストや、テスト実施前に事前のプログラム修正を行います。
【横展開が必要な主な例】
・不具合を抽出した機能と類似する機能に対しての追加テスト
・不具合がを抽出した業務パターンと類似する業務パターンでのテスト
・前工程バグとして抽出された不具合に対するテスト
特に３つ目に関しては前述した通り必須です。前工程バグが抽出されたということは、そのテスト観点が抜けていた可能性やテストが十分ではなかった可能性が非常に高いです。
したがって、横展開を行い、追加のテストを行うことで品質向上を行います。
品質不良対策
品質問題（品質目標値の未達、前工程バグの多発など）が発覚した場合には、品質不良に対する対策を打つことになります。
この時、発生した品質問題の根本原因を分析します。
この時、なぜなぜ分析を行うことが効果的で最も強力です。
よくある根本原因を例として挙げると、
・要員スキル不足
・特定の要員に問題がある
・前工程のテスト不足
これらの原因に対しては、要員の交代や、要員の増員、有識者・ベテランのアサイン、前工程に戻っての改善、問題のあった要員が担当した機能に対する集中テスト、机上での再点検などが挙げられます。
当然、コストや納期といった制約があるため、その中で打てる最善の対策を講じて、なんとかできないかを考えることになります。
こうして発生した不具合に対して対策を行い、品質を向上していくことが、品質管理そのものです。
まとめ
ものづくりに関わる以上、つくったものの品質を適切に管理し、コントロールすることは、開発者としては避けては通れません。
ぜひ、品質管理について今回の内容が何かの一助になれば嬉しいです。
参考文献
・情報処理教科書 プロジェクトマネージャ （三好康之著）
私は2019年度版を参考にしています。
・プロジェクトマネジメント実践講座 伊藤大輔（著）
コメント