要求事項を明確にし、現実対比を行い、要素技術/設計仕様/開発目標にまで落とし込む方法は以下のようなイメージです。
QFD「品質機能展開」よりも「開発コンセプト」を導入することで、お客様からより必要な情報が引き出せると感じています。
要求事項を明確にし、現実対比を行い要素技術/設計目標/開発目標にまで落とし込む方法
要求事項
お客様の要求事項です。お客様はあなたの提供する商品/サービスの良し悪しを判断できる人と定義しますので、対外的なお客様、社内のお客様、いずれも含みます。
しかし、お客様はすべてを語ってはくれません。製品を使ってもらう上で必要な制約条件はお客様も製品の事が良く分かっていないので、何が制約条件になるのか分からないのです。
従って、設計/開発者が実績のある既存品と何が違うのかを明確にして、お客様とどういった問題が起こる可能性が有るのか、協議をすることが必要になります。
つまり、制約条件を明確にするにはお客様の声を出発点とするだけでは抜けが有り、設計/開発のコンセプトを最初にしっかり組み立て、まずはコンセプトをお客様と協議しながら同時に要望事項を並行して引き出して行く事が大切になると感じています。
設計開発は何かを変更すると影響が色々な所に出て来ます。予想もしていなかったところに出てくることも良くあります。なので、既存品との違いは何なのか明確にして広く前広に協議することが大切です。
開発目的
その開発は何のためにするのか？ということです。例としては以下のようなものを想定しています。
- コストダウンのため、
- A社の参入障壁になっている品質案件で、他社を凌駕し、新規に参入するため、
- B社向けで、他社に劣っている〇△の品質で、他社を凌駕し、シェアーアップを測る。
開発コンセプト
目標を達成するためのより具体的な方法、また、開発を進めるにあたっての全体の考え方、という意味で開発コンセプトといった言葉を用いています。
例えば梱包容器のコスト削減で言えば以下のようになります。
- 容器仕様見直しによる50%以上のコストダウン、
- 品質やハンドリング性能は前機種同等以上、
- 前機種と使用上互換性がある事
要素技術
設計コンセプトを具現化するために必要な個々の具体的な技術的アイデア。技術的検討課題です。
例えば梱包容器のコスト低減で言えば
といった具合です。
この例は改善に近いので、新しい開発というよりは仕様の見直しに近いですが、新規の技術を検討する必要がある場合にはアイデアを思いつく必要があります。
品質展開
要求事項から開発目標、設計仕様への落とし込み
単純にお客様の要望事項を一つの特性で表すことが出来る程、単純でない場合もあります。そんな場合は要求品質内容と工学的な関連をまとて二次元で表した品質表にして考える必要があります。
要求機能展開、QFDと呼ばれる手法が有名ですので良ければ参照してください。
部品を生産しているような場合は、お客様で使われる状態での特性で考える必要があります。例えば、ガラスの梱包容器であれば、お客様から見れば必ずガラスが乗っかって梱包された状態です。社内であれば、空容器で使う場合も、ガラスが乗った場合もあります。
ガラスが乗った状態で使われる場合は、ガラスの積載の状態も特性に大きく影響します。
当たり前のようですが、慣れてくると、梱包容器だけの比較で特性を考えようと、途中を飛ばすような事があり、抜け、もれ、が発生する場合があるので注意が必要です。
お客様の要望は、ガラスが積載された状態での要求事項ですので、容器単体としての要求事項だけで考えるのではなく、製品として必要な要求事項から部品に必要な要求事項を考えないと漏れが出てくる。という事です。
目標の数値化について
これも、難しい物はいっぱいあります。具体的に言えば梱包容器の作業性です。これを、具体的な数値目標に落とすと非常に難しい。実際に作業者に聞いても、問題視する人としない人と大きく分かれますので、お客様の多くの意見を聞いて、優先順位を決めておく事が必要です。
仮に、一人作業で1分以内で作業が出来る事。と決めても、作業に関する特性なので適切ではないです。一人作業で一分以内で作業できるために、どうするかを考えることになりますが、実際は色々難しいです。
こんな場合は比較対象を決めて、同等以上としておいた方が現実的です。比較対象としては、他社の容器となります。作業性が優れているか、いないか、何人かで実際に扱ってみて比較し、改善が必要であれば、その改善を開発目標として運用していました。（他社品は何とかして手に入れましょう。）
お客様に聞くのが合理的なような気もしますが、作業者によって意見が違っていたり。他社品が多く流れている所であれば、他社の容器に慣れているので、他の容器は作業性が悪く感じる。お客様によっては、他社と同じ構造にしろと無理を言ってくるお客様もいます。当然、逆のパターンで、自社の方が使いやすいと言ってくださるお客様もいます。
お客様の声ではなくて、自分たちで実際に使ってみる。また、設計者が使ってみると、甘えが出るので、社内の第3者の評価を仰ぐといった事も必要と思います。
要求事項の優先順位
要求事項の優先順位は、設計部門だけでは決められないので、本格検証の際に他の部門の協議、合意を得ながら進めて行く必要があります。
まとめ
- 要求事項を明確にし、現実対比を行い要素技術/設計目標/開発目標にまで落とし込む
- コンセプトを説明しながら制約条件を引き出し、既存品との違いは何なのか明確にして広く前広に協議することが大切。
- 品質展開
- 部品の場合は、その部品を使った製品から必要な特性から部品に必要な特性を考える。
- 目標の数値化について
- 人の主観が入るような要求事項は無理に数値化する必要は無い。比較対象を決め、複数のメンバーで比較し、改善が必要であれば、それを開発目標とするのも一つの方法
- 要求事項の優先順位
- 開発/設計だけでは決められないので、本格検証の際に他の部門との協議が必要。
コメント