QFD「品質機能展開」よりも「開発コンセプト」を導入することで、お客様からより必要な情報が引き出せると感じています。

要求事項を明確にし、現実対比を行い要素技術/設計目標/開発目標にまで落とし込む方法

要求事項

　お客様の要求事項です。お客様はあなたの提供する商品/サービスの良し悪しを判断できる人と定義しますので、対外的なお客様、社内のお客様、いずれも含みます。

しかし、お客様はすべてを語ってはくれません。製品を使ってもらう上で必要な制約条件はお客様も製品の事が良く分かっていないので、何が制約条件になるのか分からないのです。

従って、設計/開発者が実績のある既存品と何が違うのかを明確にして、お客様とどういった問題が起こる可能性が有るのか、協議をすることが必要になります。

つまり、制約条件を明確にするにはお客様の声を出発点とするだけでは抜けが有り、設計/開発のコンセプトを最初にしっかり組み立て、まずはコンセプトをお客様と協議しながら同時に要望事項を並行して引き出して行く事が大切になると感じています。

設計開発は何かを変更すると影響が色々な所に出て来ます。予想もしていなかったところに出てくることも良くあります。なので、既存品との違いは何なのか明確にして広く前広に協議することが大切です。

開発目的

　その開発は何のためにするのか？ということです。例としては以下のようなものを想定しています。

• コストダウンのため、
• A社の参入障壁になっている品質案件で、他社を凌駕し、新規に参入するため、
• B社向けで、他社に劣っている〇△の品質で、他社を凌駕し、シェアーアップを測る。

開発コンセプト

　　目標を達成するためのより具体的な方法、また、開発を進めるにあたっての全体の考え方、という意味で開発コンセプトといった言葉を用いています。

　例えば梱包容器のコスト削減で言えば以下のようになります。

• 容器仕様見直しによる50%以上のコストダウン、
• 品質やハンドリング性能は前機種同等以上、
• 前機種と使用上互換性がある事

現状整理

　一般に技術ばらしとも呼ばれているようですが、お客様の要望事項を実現するためには色々な
要素があり、それを整理するのが現状整理です。
　例えば、コストダウンが目的であれば、既存品のコスト分析（現状整理）を行い、効果が大き
いと思われる項目についてコストダウンの施策や技術課題（要素技術）をまとめ目標に落とし込みます。
　お客様の要求事項が性能の改善である場合は、その技術要素を整理することになります。例えば、ガラスの輸送中のずれを防止するのであれば、ガラスの保持機構、衝撃吸収、除振機能などの対策が
考えられるが、現状の技術を整理し、効果が大きいと思われるものについて対策方針、技術課題
（要素技術）をまとめ目標に落とし込みます。

要素技術

　設計コンセプトを具現化するために必要な個々の具体的な技術的アイデア。技術的検討課題です。

　例えば梱包容器のコスト低減で言えば

　といった具合です。

　　この例は改善に近いので、新しい開発というよりは仕様の見直しに近いですが、新規の技術を検討する必要がある場合にはアイデアを思いつく必要があります。

品質展開

要求事項から開発目標、設計仕様への落とし込み

単純にお客様の要望事項を一つの特性で表すことが出来る程、単純でない場合もあります。そんな場合は要求品質内容と工学的な関連をまとて二次元で表した品質表にして考える必要があります。

要求機能展開、QFDと呼ばれる手法が有名ですので良ければ参照してください。

部品を生産しているような場合は、お客様で使われる状態での特性で考える必要があります。例えば、ガラスの梱包容器であれば、お客様から見れば必ずガラスが乗っかって梱包された状態です。社内であれば、空容器で使う場合も、ガラスが乗った場合もあります。

ガラスが乗った状態で使われる場合は、ガラスの積載の状態も特性に大きく影響します。

当たり前のようですが、慣れてくると、梱包容器だけの比較で特性を考えようと、途中を飛ばすような事があり、抜け、もれ、が発生する場合があるので注意が必要です。

お客様の要望は、ガラスが積載された状態での要求事項ですので、容器単体としての要求事項だけで考えるのではなく、製品として必要な要求事項から部品に必要な要求事項を考えないと漏れが出てくる。という事です。

目標の数値化について

これも、難しい物はいっぱいあります。具体的に言えば梱包容器の作業性です。これを、具体的な数値目標に落とすと非常に難しい。実際に作業者に聞いても、問題視する人としない人と大きく分かれますので、お客様の多くの意見を聞いて、優先順位を決めておく事が必要です。

仮に、一人作業で1分以内で作業が出来る事。と決めても、作業に関する特性なので適切ではないです。一人作業で一分以内で作業できるために、どうするかを考えることになりますが、実際は色々難しいです。

こんな場合は比較対象を決めて、同等以上としておいた方が現実的です。比較対象としては、他社の容器となります。作業性が優れているか、いないか、何人かで実際に扱ってみて比較し、改善が必要であれば、その改善を開発目標として運用していました。（他社品は何とかして手に入れましょう。）

お客様に聞くのが合理的なような気もしますが、作業者によって意見が違っていたり。他社品が多く流れている所であれば、他社の容器に慣れているので、他の容器は作業性が悪く感じる。お客様によっては、他社と同じ構造にしろと無理を言ってくるお客様もいます。当然、逆のパターンで、自社の方が使いやすいと言ってくださるお客様もいます。

お客様の声ではなくて、自分たちで実際に使ってみる。また、設計者が使ってみると、甘えが出るので、社内の第3者の評価を仰ぐといった事も必要と思います。

そのうえで、設計者がこれで良いと思ったら、具体的に早くお客様に評価してもらう事が大切になります。

要求事項の優先順位

　お客様の要求事項そのものに対する優先度は、コンセプトを決める際に絞り込む事になります。たとえば、△△性能の改善要請があるが、今回は盛り込まない等です。当然設計開発の部門 だけでは決められません。コンセプトは関連部署と協議し要求事項の優先順位を決める事が大切 になります。

　その上でお客様の要求事項を、一旦、開発目標と設計仕様に落とし込みを行います。設計仕様は 制約事項なので守らなくてはならないものです。設計を進める上で、お客様に変更をお願いする 事はあり得ますが優先順位を付ける対象にはなりません。

　開発項目は、現状整理したうえで必要な対策、開発目標を定めたものです。一番効果が 得られると思われる項目から優先して進める事が大切になります。 　また設計開発者は機能向上を優先しがちで特に初期の頃はコスト意識が薄くなりがちです。 コストダウン設計に限らず、コスト目標は開発目標に入れ、初期の段階からしっかりフォロー して行く事が大切になります。

まとめ