 |
|
ダブリンの風(55) 「プロセス品質」 高根 宏士：11月号
品質管理の大きな目的は妥当なコストで「出来上がった製品の品質」を確保することである。この製品には単品から複雑なシステムまで様々なものがある。ところが「出来上がった製品の品質」が判明し、その品質のレベルが低い場合、通常は納期間際になっており、その品質を上げるための時間はないのが一般である。またそのような作業するだけの予算的余裕もなくなっている。 品質管理ではこのような事態を起こさないために大きな仮説を置いた。「出来上がった品質」を「プロダクト品質」、製品を作るために実施する作業の品質を「プロセス品質」と呼び、 「プロダクト品質を上げるためには、プロセス品質を上げればよい」という仮説である。品質管理はこの仮説を拠り所にプロセス品質の向上を検討、実験、実施してきた。この仮説が否定されたら、現在の品質管理の基本は崩れるかもしれない。しかしこの仮説は数学的な観点からは証明できないけれども現実には真理に近い。 プロセス品質を上げる有力な手段として「レビュー」がある。レビューとは作業の区切りにおいて、その成果の見直し、確認を行う作業である。特に設計作業の区切りにおいて行うレビューをデザインレビューという、レビューは不具合や問題がある場合、できるだけ早く検出し、修正するための実質的に効果があり、誰でも活用できるほぼ唯一の手段かもしれない。特にものが見えないソフトウエアやシステムの開発過程のプロセス品質を上げる手段として昔から採用されているものである。レビューをベースとすることにより、工程と品質をリンクすることができる。ソフトウエアの場合、レビューをしないで作業進捗状況を具体的に把握することは不可能に近い。 最近このレビューに関して面白い例があったので紹介したい。ある企業(A)がシステム開発の作業をソフトウエアベンダーに依頼した。そして設計段階における中間成果物のレビューがあった。Aの担当者もそのレビューに参加した。レビュー結果は惨憺たるものであった。不具合があまりにも多すぎたのである。しかも不具合の中身は初歩的なミス、ケアレスミスの類が大半であった。Aの担当者はこのままで本当に予定通りの納期に予定の品質のものが仕上がるのだろうかと心配になってきた。その疑問を提示したところベンダーのチームから、レビューとはできるだけ不具合を検出し、以後の工程に不具合を残さないことであるから、その目的を達しており、問題ないとの回答であった。しかしAは釈然としなかった。 釈然としなかったAの感覚は自然であり、素直である。ベンダーの回答は品質管理やレビューの考え方として一見もっともなように思われるが、プロセス品質の向上という本質的なところで完全に間違っている。今回のレビューで間出された不具合はレビューでなければ検出できなかったものであろうか。初歩的なミス、ケアレスミスの類は作業者本人が、ほんの少し注意して、作業をするか、レビューの場に提出する前に一度読み返していればその90%以上は事前に修正できたはずである。それができなかったにしても誰か一人がチェックすれば大半は解消できたはずである。このようなものを大勢の人が集まって検出しているようでは、時間とコストの浪費である。「三人寄れば文殊の知恵」と云われるように、レビューの場では作業者だけではどうしても気がつかない不具合等を探し出すことがその目的である。ケアレスミスや初歩的なミスをレビューの場にできるだけ出さないようにすることはレビューにおける基本的なエチケットである。 確かにレビューで不具合を検出することは下流における作業、例えばテストフェーズで検出するよりも効果はある。しかしレビューで初歩的なミスを挙げて喜んでいるようではプロセス品質を上げるという目的からは程遠い。プロセス品質の向上においてはレビューよりも何よりも、成果物を作るという作業そのもの品質を上げることが本質である。今回の例では作業そのものの品質を上げるという認識と訓練ができていない。このような状態では、10人でレビューミーテイングをしていたならば、10人掛かって一人分の仕事しかしていないことになる。生産性は10分の1である。 品質管理においても、プロジェクトマネジメントにおいても、現場における全体の視点から見ずに、断片的な手法やツールを使ってやったつもりになっていることはないだろうか。 |
 |