シリコンバレーでフェイスブック、エアビーアンドビーなど急成長を遂げた起業家たちにアドバイスを与えてきたベン・ホロウィッツ氏の著書の中に、下記のような文章を見つけました。
良い製品マネジャーは、チームを売上と顧客に集中させる。悪い製品マネジャーは、チームをライバルが開発している機能の数に集中させる。
良い製品マネジャーは、良い製品を大きな努力によって実現できるものと定義する。悪い製品マネジャーは、良い製品を実現不可能なものと定義する、あるいはエンジニアリング部門に彼らがつくりたいものをつくらせる（つまりは最大の難問を解かせる）。『HARD THINGS 答えがない難問と困難にきみはどう立ち向かうか』（ベン ホロウィッツ, 滑川 海彦, 高橋 信夫, 小澤 隆生（序文） 著）より
「これから開発する製品をヒットさせるために、ライバル製品よりも多くの機能をつければ勝てる！」
「オレは良いアイデアを思いついた、これなら誰にでも勝てる。こんな難しい技術は誰も解決できない。何としても解決するんだ。そのためにお前らに高い給料を払ってきたんだ。」
もし、こんなリーダーのもとで働くことになったら、不幸としか言いようがありませんね。
上司は選べないと言いますが、できることならこちらから選べるようにしたいものです。
あるプロダクトリーダーが、「これなら売れる！」と自信を持って企画している製品があるとします。
これをプロダクトリーダーの視点ではなく、製品を購入するお客様の視点から見てみますと、お客様は何を評価してその商品を購入するのでしょう？
お客様は商品に込められた「機能」を評価されるのではないでしょうか。
この機能を間違えると、いくら一所懸命に造っても、お客様は満足してくれませんし、製品は売れません。
例えば、辞書の機能は、一般的には「言葉を調べる」ことだと考えます。
「言葉を調べる」だけなら「電子辞書」でも構いません。
しかし、辞書に「本棚に飾る」という機能を求める人がいます。そのような見方をすると、「電子辞書」ではその機能を満足することはできません。
重厚で高級感や知的な感じを重視し、外装をまとった紙の辞書でないと、満足できないお客様もいるのです。
このようなお客様を想定して、お客様の望む機能を間違えて商品開発をしてしまうと、お客様に受け入れてもらえない製品となってしまう、ということです。
商品企画はアイデア出しから入り、新製品のアイデア書をまとめ、方向性を決めます。
次に、市場動向や、他社動向も調べ、これらをベースに「商品企画」を行います。
あくまでも、お客様の求める機能をベースに「商品企画」を行うことが重要です。
「お客様」⇨「製品開発」であって、「製品開発」⇨「お客様」ではありません。
「商品企画」の次の「製品企画」のステップでは、具体的にどのような機能と特性の製品にしていくかを決めます。
これを思いつきでやってしまうと、神様がついていれば良いですが、もし、神様に見放されてしまったら成功はおぼつきません。
まして、神様の存在は人の心の中にだけのものであって、どこかで優しく見守ってくれている絶対的な存在などあるはずがないのです。
開発の方向や重視する特性の優先順位を、思いつきではなく論理的に決めて製品開発を進めることが重要です。
いわゆる「当たるも八卦、当たらぬも八卦」では、ヒットすることもあるかもしれませんが、外す場合の方が多でしょう。
実際、機能も特性も抜けだらけになってしまうことでしょう。
ここで活用するのが、QFD＝品質機能展開です。先述の通り、品質機能展開は製品企画を提示した際の「根拠」として不可欠のものです。
（Quality Function Deployment / 要求品質展開顧客に満足が得られる設計品質を設定し、その設計意図を製造工程まで展開するために用いられる手法。）
例えば、静かなフューエルポンプを開発するという企画であれば、脈動の幅を具体的に「何kPaに抑える」と言ったときの数値の根拠や、なぜ脈動幅を重視したかという根拠が必要です。
品質機能展開を使わないと、技術者が選んだ機能や特性に対して、経営陣などにそれらを選んだ説得力を持った根拠を示すことできません。当然、製品企画も承認されません。
QFDは、製品開発を行う際に、どのような機能が必要とされていて、その機能を発揮するためには、どのような特性が必要かについて決めるためのツールです。
機能（要求品質展開表）を横（行）に、特性（品質特性展開表）を縦（列）に配置したマトリックス（品質表）を作成し、どこを重点的に開発すべきかを決定するために使います。
開発設計者が次の製品を開発する際に、頭に漠然と製品のイメージを思い描いているだけでは、具体的な設計に移行することができません。
頭の中で考えている「次の製品はこんな感じがいいなあ」というイメージを、具体的にどのような機能にし、そしてその機能を満足する特性をどのようにするかを「見える化」する。
そのために使うのが品質機能展開です。
残念ながら、このQFDという開発設計者にとっては必須のツールなのですが、きちんと活用できている企業は1割程度ではないかと言われています。
理由は２つ考えられます。
1つは、QFDの使い方がわからない。
もう一つは、品質機能展開を使わなくても、とりあえず製品を造ることができるからだと思います。
品質機能展開という言葉は知っているけれど、実践できていない企業がほとんどです。品質機能展開に関する本はたくさん出ていますが、本を読んだだけでは、QFDを実践するのは難しい面があります。
基本的には、QCのマトリックス図法の活用になります。QCを取り入れている会社も少なくありませんが、意外と実践できている会社は少ないと思います。
「マトリックス図法」は、「系統図法」によって展開した方策の「重みづけ」や「役割分担」などを決めるのに使用される方法。
行に属する要素と列に属する要素に構成された二次元の表の交点に着目して問題解決を効果的に進める手法。
品質機能展開を使わなくても、とりあえず製品を造ることができきてしまうのですが、社内評価ではそれを良しとしてしまうことが多く、品質機能展開を実践することが面倒くさく感じてしまうのでしょう。
品質機能展開を使わないと、どのようなデメリットがあるのでしょうか。
本当に必要な機能に抜けが生じてしまいます。例えば、車の燃料ポンプを開発する時に、「燃料を送ること」という機能だけを想定して開発してしまうと、圧力変化の大きなフューエルポンプが出来てしまうことがあります。これでは、「燃料を送ること」はできるのですが、騒音も振動も大きくなってしまいます。
さすがに基本機能については落とすことは少ないのですが、大切な他の機能を漏らしてしまう場合があります。
ところが、お客様からすると基本機能は「当たり前の機能」であり、その他の機能に価値を求める人は意外に多いのです。これでは、製品としては不完全です。
冒頭で紹介した、
「悪い製品マネジャーは、チームをライバルが開発している機能の数に集中させる。」
という製品マネジャーが存在する理由です。
品質機能展開では、機能には、5つの種類があるとします。［1］基本機能、［2］付加機能、［3］本体機能、［4］弊害防止機能、［5］自己防御機能、の５つです。
こうした機能の種類があることを理解していないと、製品を成立させる上で必要な機能の抜けが多くなってしまいます。［1］の基本機能だけにとらわれてしまい、その他の機能を漏らしてしまうことが多くなってしまいます。
トヨタグループでは、プロセスを大切にしますので、品質機能展開を製品開発における必須のツールと考えています。
先ほど「品質機能展開を使わなくても製品を造ることはできる」という考え方では、一度何らかの幸運が働いて、良い結果が得られるかもしれませんが、継続的に良い製品を生み出すことはかなり困難です。
やはり「きちんとしたプロセスを経ているから、良い結果が生まれる」という考え方が重要ですし、健全ではないでしょうか。
品質機能展開を活用すると、なぜその機能の特性値に着目したか、なぜそれを重要特性として選んだかをロジカルに説明できます。
設計者個人の知見としてではなく、組織の知見として共有することができるようになります。
品質機能展開を使うときのポイントは、機能として何があるかを抜け漏れなくに見つけ出すことです。
品質機能展開は機能をベースに特性を考えるため、機能が抜けてしまうと特性も出せず、製品開発が進まなくなってしまいます。
設計者1人で機能を見つけ出すのではなく、設計、製造、生産技術、品質保証、検査がそろって品質機能展開を実施します。
品質機能展開の進め方については、フォーラムに記載しました。
（フォーラムは、メールアドレスの登録が必要です）