#057 プロマネのお仕事(本編7) - 品質マネジメント(ちょうどいいテスト工数を見つけよう)
こんにちは。中小企業診断士の多田と申します。
本編7回目は品質マネジメント。
前回・前々回でスケジュールとコストを扱いましたので、これで「Q・C・D」の3つが揃います。
# 051: 資源マネジメント
# 052: コミュニケーション・マネジメント
# 053: ステークホルダー・マネジメント
# 054: リスク・マネジメント
# 055: スケジュール・マネジメント
# 056: コスト・マネジメント
# 057: 品質マネジメント ← 今回
# 058: 調達マネジメント
# 059: 統合マネジメント
# 060: スコープ・マネジメント
品質のマネジメントで難しいのは、「どこまでテストしたら良いのかを見極める」事だと思います。
人と時間とお金を際限なく投入すれば、品質を上げること自体は可能です。
しかし、そのためのコストがかかりすぎて製品やサービスの価格が高くなってしまっては、その製品は売れません。
お客様が要求する品質を、できるだけ効率的に、適正な工数で実現するマネジメントが必要になってきます。
「品質マネジメント」とは
PMBOKの10の知識エリアの中では上から5番目。
PMBOKでの定義は以下のとおりです。
「ステークホルダーの期待を満たすために、プロジェクトとプロダクトの品質要求事項の計画、マネジメント、およびコントロールに関する組織の品質方針を組み込むプロセスからなる。」
(PMBOK 第6版 p.24)
簡単に言うと、「要求品質を守るための一連の取り組み」のこと。
求められていることはわかりやすいのですが、いざ実行に移そうとするとどうやって良いかわからない、というのがこの知識エリアの特徴だと思います。
PMBOKに書かれているプロセス
「品質・マネジメント」に書かれているプロセスはシンプルに3つのみ。以下順番に見ていきます。
1. 「品質マネジメントの計画」
→ お客様の要求する品質を確保するために、「品質尺度」を明確にし、レビューの計画やテストの計画を立てます。
→ アウトプット文書: 品質マネジメント計画書、品質尺度
2. 「品質のマネジメント」
→ そのプロジェクトで扱っている製品・サービス・仕事そのものの品質に関する状況を、定期的にステークホルダーに報告します。
→ アウトプット文書: 品質報告書
3. 「品質のコントロール」
→ お客様の要求する品質と、実績を比較して、その差異をチェックします。
→ アウトプット文書: 検証済み成果物
なお、プロマネ自身は品質そのものの決定に関与しない、というスタンスが基本だそうです。
要求品質は、ステークホルダーから降ってくる、という考え方です。
では、以下、品質のマネジメントにおける効果的なテクニックについてまとめていきたいと思います。
とはいえ、この分野は、プロジェクトの種類によってやり方は大きく変わってしまうので、ここではどんなプロジェクトでも役に立ちそうなテクニックにしぼって書いてみます。
「品質のマネジメント」→ 何かをチェックするときには「観点」を決めよう!
品質マネジメントにおいては、「チェック」や「レビュー」という作業をいかに効率良く進めていけるかが重要になってきます。
例えば、製品の最終チェックで「抜け」が発生してしまうと不具合がお客様のところにまで流出してしまいますし、Webサイト制作の初期段階で仕様書のレビューに「漏れ」があると、想定していたのとは違う、なんだか思ってたのとは違うWebサイトができ上がってきてしまいます。
こうした「チェック」や「レビュー」を効率的に行う方法の一つに、各担当者に「観点」を与えて、その観点に基づいたチェックをしてもらう、というテクニックがあります。
これにより、漠然とチェックを行った場合と比較して、より効率的に、これまで気がつかなかった不具合を見つけることができるようになります。
例えば、「新商品の仕様」についてみんなでレビューする場合、例えば
・人: お年寄りの視点で見た場合使いにくいところはないか、子供にとって危ないところはないか、等
・作業: 箱から開封して使い始めるときの手順に問題はないか、使い終わって棚にしまうときはどうか、等
・時間: 3年後に故障した場合のサービスに問題は無いか、5年後捨てるときはどうしたら良いか、等
といったように、何らかの「軸」(ここでは、人・作業・時間)を設定して、その軸に従って「お年寄りの視点」「子供の視点」というような「観点」に立ちながらレビューを行うと良いと思います。
こうしたやり方をとおして、まず「観点」を決める段階で「抜け」や「漏れ」に気がつくことができますし、次に「観点」をベースにレビューすることで、より深い考察を行うことができるようになります。
「品質のマネジメント」 → テスト工数と不具合検出数の関係を理解しよう!
次は、製品やソフトウェアの「テスト」を行う際の考え方について。
テストの工数(どれだけテストを行ったか)と、そのテストで発見された不具合の数との関係について見ていきます。
ソフトウェアの世界では、「テスト密度」と「バグ密度」の関係、などと呼んだりします。
以下、この2軸の関係についてもう少し詳しく見ていきましょう。
全くテストを行っていないのが、上の図でいうと左下の状態。
で、その状態からテストを行っていくと、テスト工数に応じて不具合が発見されていくことになるのですが、
この「テスト工数」と「発見された不具合の数」には、適切な関係というものが存在します。
図で言うと、真ん中の「ちょうどいい」エリアが、適切なテスト工数とバグ発見数の関係。
これが、多すぎても少なすぎても何かがおかしいということになります。
例えば、上の図の場合、
・左下の領域: 「とりあえずテストする」
→ まだテストが少なくて不具合があるのかどうかわからない領域。
・左上の領域: 「一旦テストを中止して工程を見直す」
→ そんなにテストしていないのに想定以上に不具合が出まくっている状態。前工程での品質の作り込みが不足しています。
・右下の領域: 「テストが的外れの可能性あり」
→ いくらテストしても不具合が見つからない領域。テストのやり方がまずい可能性が高いです。
・右上の領域: 「テスト工数の見積もりが甘かった」
→ 想定していたテスト工数を終わっても不具合が出続ける領域。開発規模が想定より大きく、もっとたくさんテストする必要がありそうです。
…といった関係性が読み取れます。
こうした関係を認識していないと、
・全くテストしていないのに「不具合はありませんでした」と報告してしまったり、
・いくらやっても不具合を見つけることのできない意味の無いテストを延々と繰り返してしまったり、
・一旦テストを中止して前工程を改善しないといけないのにその兆候に気がつけなかったり、
ということになってしまいます。
なお、こうした関係性を理解した上でテスト行うためには、過去のプロジェクトを参考にして、このくらいの開発規模ならこれくらいのテスト工数が必要だな、という「あたり」をつけておく必要があります。このあたりの見積りができるかどうかは、プロマネの腕の見せ所です。
ちなみに、ソフトウェアの場合は、IPAという団体が典型的なプロジェクトにおけるテスト密度とバグ密度に関する数値を公開しています。ソフトウェアエンジニアの方は参考にしてみてはいかがでしょうか。
「ソフトウェア開発データ白書2018-2019」の発行
～近年の開発実態に即した統計データを公開～：IPA 独立行政法人 情報処理推進機構
https://www.ipa.go.jp/ikc/reports/20181011.html
「品質のマネジメント」→ 品質活動はメンバー全員参加でやろう!
最後は体制の話です。
「全員参加!」などというと、よく職場にスローガン的な意味合いでポスターが貼ってあったりします。かけ声をかけることで会社全体の意識を高めることが重要だと思います。
しかし、ここでは、単に職場風土の話だけにとどめてしまうのではなく、直接的な実利として、「いろんな人で手分けしてチェックした方が抜けや漏れが少ない」というメリットに注目してみたいと思います。
単なるかけ声だけに終わらせるのではなく、実際に「チェック」や「レビュー」、「テスト」にたいして、できるだけいろんな人が様々な視点をもって関わることで、製品やサービスの質をぐっと上げることができるように思います。
例えば、若干極端な例ですが、英語のWebサイトの間違いをチェックする場合、日本人だけでやるのと、英語ネイティブな外国人にも入ってもらうのとでは、後者の方が圧倒的に効率的なのは理解頂けると思います。
上で書いた「観点」に関しても、お年寄りの観点でチェックする場合には、実際に年齢層の高い方にチェックしてもらうに越したことはありません。
職場の多様性を品質のマネジメントにも活かしていけると良いと思います。
まとめ。
(1) 「品質・マネジメント」とは、「要求品質を守るための一連の取り組み」の事です。求められていることはわかりやすいのですが、いざ実行に移そうとすると継続して効果的な活動を続けていくのはなかなか難しいです。
(2) 「チェック」や「レビュー」といった作業を行う場合には、何か「観点」を決めておき、その観点に基づいてチェックするようにすると、抜け・漏れを防ぐことができます。加えて、もし可能であれば、できるだけいろんな属性の人に参加してもらえると更に良いと思います。
(3) テスト工数と不具合発見数の間には、「ちょうどいい」関係というものが存在します。過去の同じようなプロジェクトのテストを参考にするなどして、「ちょうどいい」テスト内容やテスト工数を見つけることができると、プロジェクトのアウトプットの品質を効率的に向上させることができます。
----------
(ここに書かれている内容はいずれも筆者の経験に基づくものではありますが、特定の会社・組織・個人を指しているものではありません。)
この記事が気に入ったらサポートをしてみませんか？