 |
第５７回（2004.06.07） プロジェクト品質を考えよう |
◆品質ってなに 品質と聞いて真っ先に思い浮かぶものはなんだろうか？標準化された開発プロセス、統計的に（実験計画で）裏付けられたテスト計画、など。あるいは、最近だと、顧客の要求の充足割合といったことを思い浮かべる人も多いだろう。 品質に対する認識というのは本当に難しい。プロジェクトマネジメントＯＳ本舗の考える品質マネジメントの一端は、以前、「品質の家」というテーマで述べた。 http://www.infoscape.jp/tms/pm/method/quality.html 品質マネジメントにあたって、品質をどう捉えるかはきわめて重要である。以下のような２つの例を考えてみてほしい。 ◆２つの例 ひとつは鋳造した車のエンジンにバリが残っている。エンジン外側のバリであるので、エンジンの機能にはまったく影響はない。強いていえば、エンジンルームを開け、エンジンを眺める人がいれば、バリがあることを気にするかもしれない。これをとるには、バリ取りの工程が必要になるが、実際にある会社では必ずバリを取っている。どう考えるか？ もうひとつの例。ソフトウエアにはいわゆる潜在的なバグが残るのは常識化している。したがって、ソフトウエアの品質はテストのカバレッジの問題だと考える。つまり、そのソフトウエアの操作で実行される可能性のある動作をどれだけカバーするテストをするかの問題だと考える。極論すれば、バグが存在していても、それがテストで顕在化しなければ問題ないと考える。 前者のような品質の捉え方をすると、よく過剰品質だといわれ、コストや納期の観点からは問題があるといわれる。後者のような捕らえ方は、一定の合理性があると考えられる場合が多い。 さて、問題はここからだ。前者のケースで、なぜ、バリを取る会社があるのか？をよく考えてみたい。プロダクトの品質という点で言えば、確かに、過剰であるのは間違いない。ところが、プロダクトの品質には一種の落とし穴がついて回る。たとえば、鋳造物であれば中に巣（す）ができるといったことが起こる可能性がある。ソフトウエアでいえば潜在バグである。 ◆リスクが品質を救う これらは、存在していたとしても、チェックされることがなく、その意味では存在の可能性の域を出ない。品質の計画スコープから外れている。つまり、計画からいえばリスクなのである。リスクとして巣が存在している可能性、潜在的バグが存在している可能性がある。これをリスクと考えるかどうかも議論のあるところだろう。家の中でゴキブリを一匹見たら百匹いると思えという格言（？）があるが、品質についても同じことがいえる。タンジブルな（目に見える）不適合は、インタンジブルな（目に見えない）不適合がたくさん隠れていると考えた方がよい。ＩＳＯのプロセス品質の向上というのはまさにそのような前提である。 そのように考えるとインタンジブルリスク対策を考えなくてはならない。そのリスク対策で有力なひとつは、鋳造の作業や、ソフトウエア製造の作業の品質を向上させることである。その方法がプロセスのレビューであればＩＳＯ９０００になるし、また、作業者のモチベーションの向上といった対策もある。 つまり、プロダクトの品質に対して、潜在的な不具合については、その存在をリスクとし、そしてリスク対策を採ることによって、発生確率を抑えることができる。これがプロジェクト品質の正体である。 ◆プロジェクト品質で成熟度を向上させる プロダクトの品質は正しいかどうかを判断すればよい。プロセスの品質はルールが守られているかどうかをチェックすればよい。もちろん、どのようなテストをするか、プロセスのルールをどうするかは難しい問題であるが、方法論は明確である。これに対して、プロジェクトの品質はとらえどころがない。人の問題、組織の問題、マネジメントの問題、経営の問題、などあらゆることを考えていかなくては実現できない。経営レベルでは、「経営品質」という概念があるが、これに近い。まず、指標を作り、その指標を改善していく中で組織としてのマネジメントの成熟度を向上させていく必要がある。 |
|
| 読者からのコメント | |
■本稿に対するご意見，ご感想をお聞かせください．■ ■は必須入力です |
|
| このコンテンツは「プロジェクトマネージャー養成マガジン」としてメルマガで配信されています．メルマガの登録はこちらからできます． | |