【戦略ノート230】品質マネジメントからプロジェクトマネジメントへ

本ブログは移転しました。こちらをご覧ください

◆「品質優先、コスト、納期は柔軟に対応」

製造業やＳＩでは、プロジェクトマネジメントを品質マネジメントの拡張だと考えているケースが多い。組織を見ても、品質管理部門の中にＰＭＯを設置したり、あるいは、品質管理部門をＰＭＯに組織替えしているケースもある。

その品質のマネジメントも２０年前と較べると大きく変わっている。２０年前であればユーザが不都合だと考える事象は品質に問題があると考えられてきた。しかし、今は商品の複雑化に伴い、すべてのユーザが了とする「絶対品質」というのは無くなりつつある。そこで、商品毎に「品質がよいとはどういうことか」を計画し、顧客や市場と合意しなくてはならなくなっている。言いかえると瑕疵（問題であるという状態）の定義をしなくてはならない。もちろん、提供サイドに品質メトリクスがなくなったわけではないが、知覚的なレベルの品質で市場との合意ができない商品は問題を引き起こす。少し前に世の中を騒がせたトヨタプリウスのブレーキの問題はまさにそうだろう。

このように考えていくと、プロジェクト品質という考え方の合理性が見えてくる。成果物の品質も含めて、（プロジェクト）品質とは計画の精度であると整理できるからだ。つまりは、プロジェクトマネジメントを品質マネジメントの延長線上に取るということは自然である。

◆「絶対品質」の呪縛

問題はその後である。プロジェクト品質が「絶対品質」の発想に引っ張られている。問題は２つあるように思う。一つはプロダクト品質だけは特別であるという発想。もう一つはプロジェクト品質全体を厳格に管理していかなくてはならないという発想。

前者はナンセンスである。上に述べたように、品質概念は計画的なものになっている。逆説的であるが、だからこそ「ダントツ品質」といった戦略が登場している。品質は戦略（戦術）の対象であり、また、トレードオフの対象である。絶対的に求められる品質や品質レベルなどは存在しない。

後者は一見正しいようにも思える。ＱＣＤＳを計画通りに実現すること。プロジェクトマネジメントはそのためにあると考えている人は少なくない。

ただし、現代のプロジェクトへの要求には仮説が含まれていることが多いことは考慮する必要がある。つまり、ＱＣＤＳに対して制約を与える際に、その制約条件を満たすことによって目的が達成できるかどうかは仮説であることが多いのだ。例えば、商品開発のスケジュールは戦略実行のためにそこまでに商品を投入できればよいというのは仮説に過ぎない。もし、競合などの環境が変わればその仮説は変わる。

余談になるが、これは制約の設定に問題があるとも言える。本当に制約条件というのであれば、例えば「競合より１ヶ月早く商品を投入する」というのが制約であるが、なかなか、そういう制約設定の方法は取られない。

◆仮説の変化に対応する品質概念とは

話を元に戻そう。制約が仮説に基づくものである限り、プロジェクトの計画は絶対的なものではない。あくまでもプロジェクト状況の物差しである。

では、品質も計画（目標）も流動的なものだとすると、プロジェクトは何を拠り所に進めればよいのか。今、多くのプロジェクトマネジャーが悩んでいる問題である。この答えはそんなに難しいものではない。「価値」である。もう少し、制約にいえば、「顧客の価値」である。

それなら実践しているというプロジェクトマネジャーも多いかもしれない。確かに、「ＱＣＤＳの中でどれが一番大切ですか」と聞けば、「どれも大切だ」という答えが返って来て、仕方なしに、粛々と計画通りに進めて行くということをしている企業は多い。これは「顧客の価値」の意味を理解できていない。

顧客にとってＱＣＤＳはどうでもよい。もちろん、実現したい価値が背景にあってＣＱＤＳの要求をしているわけで、その意味ではどうでもよくないのだが、顧客の考える方法が唯一の価値実現の方法ではないことが多いのだ。そこにメーカやベンダーの提案の余地がある。

◆NAVTIME

例えば、NAVTIMEという携帯電話のサービスがある。この分野は古くは駅スパートといったソフトがＰＣの創生期から存在する分野で決して新しいものではなく。もともと
、電車ルートや出発時刻や到着時刻を知りたい、料金を知りたいというニーズに対応する商品であり、利便性を価値として与えるものである。

しかしよく考えてみると、顧客の最大の価値はそこにはないことは明らかである。現在地から行きたいところまでのルートと時間であることは明らかである。この価値に注目したのがNAVTIMEである。従来の顧客価値との違いはかなり大きいように感じる。

つまり、プロジェクトマネジメントの中の品質マネジメントには、プロダクト品質のマネジメント、プロジェクト品質のマネジメント以外に、価値のマネジメントが必要なのだ。ＰＭＢＯＫの知識エリアでいえば、統合変更管理の中に価値のマネジメントを入れる必要がある。顧客の価値を最大化できて、初めてプロジェクトとして「ダントツ品質」を実現しているといえる。