プロジェクト管理の中の品質管理の説明です。
品質管理は、なかなか大変な割に効果が疑問で、きちんとできているプロジェクトも少ないのが実態です。もちろん１０億を超えるようなプロジェクトでは、きちんとできないと駄目ですが。品質管理には定量評価と定性評価があり、それに加えてトレーサビリティーで、網羅性を担保したりします。
１．定量評価のキモ
一般的に定量評価は工程開始前までに目標値を定めて、実績と目標値の乖離で評価をします。ただ実際にはこの目標値との比較はあまり効果がなく、それよりもサブシステムごと、あるいは機能ごとに実績を比較して、品質の悪いサブシステムや機能にフォーカスをあてる方が有効です。プロジェクトごとにいろいろな特性があって、それごとに目標値を持っている会社は私の知る限りでは存在しません。適用するのが妥当なのか良く分からない目標値と比較して頑張って評価するよりも、実績で比較する方が正確です。
例えばMDシステムを構築するプロジェクトがあり、結合テストのテスト密度の目標値が５０〜９０ケース／ＫＳ（キロステップ）だったとします。この時、実績が４０ケース／ＫＳだったとして、目標値を下回った実績となりました。ではこれは品質が悪いと言えるのでしょうか？そもそもテストケース１件の粒度は、システムやプロジェクトによって異なります。データバリエーション１つ１つを１テストケースとすることもあれば、１テストケースで複数のデータバリエーションをテストすることもあります。目標値のテストケースはどのような粒度なのか、誰も答えることができない中で、目標値との乖離についても、すっきりとした評価が難しいのが実情です。それよりも、この実績をサブシステムで見た時に、発注サブシステムは５５ケース／ＫＳ、検品サブシステムは６０ケース／ＫＳ、売上サブシステムは３０ケース／ＫＳという内訳だったとしたら、売上サブシステムはテストが不足しているのでは？という仮説を立てることができます。通常プロジェクト内ではテストケースの粒度は統一するものだからです。
このように定量評価は、目標値と実績値の比較よりも実績同士の比較をする方が有効です。
２．定量評価の指標のキモ
①レビュー密度：レビュー時間／ページ
要件定義書や設計書１ページあたりのレビュー時間です。分母のページ数は、絵が多いとページ数が多くなることから文字数にしているプロジェクトもありますが、文字数をカウントするのは結構大変なので、ページ数を採用するのが妥当と思います。絵も立派なレビュー対象ですし。それよりも重要なことはレビュー時間です。複数人でレビューする場合、１時間のレビュー会議に３人のレビュアーが参加した場合、３時間とするのか１時間とするのかです（通常は後者）。また対面でのレビューは計測しやすいですが、メール等で設計書を送って、各自が自席でレビューする場合、どのように時間を計測するか、等を実績を集計する前に決める必要があります。
②指摘率：指摘件数／ページ
要件定義書や設計書１ページ当たりの指摘件数です。誤字脱字を指摘件数に含めるかどうか、これも事前に決めておく必要があります。誤字脱字は品質には関係ないからカウントしないという考えもあれば、誤字脱字が多いと読みにくくなって品質にも影響するという考えもあります。
③レビュー密度：レビュー時間／ＫＳ
④指摘率：指摘件数／ＫＳ
プログラムソースのレビュー時の指標です。考え方は①、②と同じですが、ソースを全てレビューするプロジェクトは稀なので、製造工程は品質評価しないことが多いです。
⑤レビュー密度：レビュー時間／テストケース数
⑥指摘率：指摘件数／テストケース数
テストケース作成時のレビュー指標です。これも考え方は①、②と同じです。
⑦テスト密度：テストケース数／ＫＳ
テストケース作成時の指標は他にもう一つあります。プログラムソース１キロステップあたりのテストケース数です。⑤、⑥はレビューに対しての指標ですが、⑦は開発規模に対しての指標です。パッケージ製品の場合には、スクラッチ換算して算出することもありますが、パッケージの場合には、なかなか評価が難しいです。
⑧バグ密度：バグ件数／ＫＳ
これはテストを実施した後の指標です。プログラムソース１キロステップあたりのバク発生件数です。バグのカウントの仕方は、事前にルール決めが必要です。ある程度大きなシステムの場合、一つのバグが複数箇所に埋め込まれているケースがあります。それをそれぞれカウントするか、１カウントとするか、場合によってはそのケースごとに判断する必要があるかもしれません。
３．定性評価のキモ
定性評価では、指摘やバグの原因や原因工程、本来発見すべき工程といった観点で分析します。原因の分類で重要なことは、アクションに繋げられる分類にすることです。品質評価の目的は、品質の悪い機能があった場合に再レビューや強化テスト等を実施することです。このアクションに繋げられない分類は無意味です。
例えば基本設計書のレビューで、「要件定義ミス」「基本設計ミス」というような漠然とした分類は意味がありません。ある機能で「要件定義ミス」が多いという実績が出たとしても、要件定義の何が悪かったのか再度、評価し直す必要があります。それに対して、「要件提示漏れ」「要件定義書記載不十分」「要件定義理解不十分」というような分類であれば、すぐにアクションに繋げることができます。「要件提示漏れ」であれば、ユーザー部門に他に類似の漏れがないか確認することになります。「要件定義記載不十分」であれば類似箇所の記載を再点検し、同様に記載不十分な箇所があった場合、基本設計が正しくできているか再点検することになります。「要件定義理解不十分」の場合、理解が不十分だった担当者の他の箇所の理解度合いを確認することになります。
またテストでは、適切なバグの分類以外に、どの工程で潰すべきバグだったのかという観点も重要です。総合テストで出たバグのうち、本来は結合テストで潰すべきバグが大量にでた場合、なぜ結合テストで潰せなかったのか分析が必要です。結合テストのケースに漏れがあったのか、テストはしたけどテスト結果の確認が不十分だったのか、あるいは設計書が誤っていたのか。それによってアクションも変わってきます。
４．トレーサービリティーチェック
要求を一覧化し、各要求が要件定義書のこのページに反映されている、あるいは取り下げとなったことをチェックします。要求と要件が１対Ｎになっている一覧表を作成することで、要件定義に漏れが無いことを保証します。同様に要件と基本設計も１対Ｎの一覧を作ります。さらにテストもテストケースをこの一覧の各行に紐つけることで、テストケースの網羅性も保証します。
トレーサビリティーは、それなりに作成の負担がありますが、スキルの高い人が作るとテストケース作成の生産性が上がるので、非常に有効です。ただしスキルの低い人が作ったトレーサビリティーは全く使い物にならないので、プロジェクトメンバーのスキルを見極めて、適切な判断が必要です。
トレーサービリティーに限らず、品質は全般的にスキルの高い人にしか管理できませんが・・・。
【振り返り】
今回はプロジェクト管理の中の品質管理の説明でした。そのリスクや課題を発見する手段の一つですが、次回はもう一つの手段である進捗管理の説明をしていきたいと思います。
①．進捗管理
②．品質管理
③．コスト管理
④．課題管理
⑤．リスク管理
⑥．変更管理
⑦．コミュニケーション管理
⑧．成果物管理（文書管理）
⑨．要員管理
⑩．ステークホルダー管理
⑪．外注管理
