コンセプトエンジニアリング(Concept Engineering)は、顧客の置かれた状況を理解し、要求を明らかにして、その要求を満たす製品コンセプトを作り、選ぶための体系的な進め方です。
製品開発の初期にある曖昧さを扱います。
ここでは、Gary BurchillらがMITとCQMの活動を通じて発展させた方法を指します。

構造や部品を詳細に設計する前に、何を実現すべきかを定めることが中心です。
顧客に欲しい機能を尋ね、その回答をそのまま仕様にするだけではありません。
顧客の言葉と実際の利用を照合し、必要な結果と、その結果を生む解決策を分けて考えます。

顧客の状況から要求を作る

仮に、現場作業者の記録業務を支援する製品を考えるとします。
聞き取りでは「画面を大きくしてほしい」という要望が出るかもしれません。
しかし、作業を観察すると、手袋をしたまま入力しにくいことや、屋外で表示が見えにくいことが分かる場合があります。

画面を大きくすることは、解決策の候補です。
要求としては、装備を外さず入力できる、必要な情報を作業場所で確認できる、といった形に整理できます。
このように表すと、物理ボタン、音声、表示の工夫など、別の解決策も検討できます。

要求を評価可能にする

BurchillとWaldenの報告では、顧客の環境の理解、要求への変換、測定可能な形への具体化、コンセプトの生成と選択が結び付けられています。
考えたことを、観察やデータへ戻って確かめる往復が重要です。

記録業務なら、入力に必要な時間、修正の回数、作業を中断する頻度などが評価の候補になります。
ただし、測りやすい値だけで要求を代表させると、顧客が困っている内容を取り違えるおそれがあります。
その指標が、どの要求を、どの程度表しているかを確認します。

複数のコンセプトを比較する

要求が整理できたら、複数の解決案を作り、重要な要求や制約に照らして比較します。
見た目が似た案を並べるだけでなく、記録するタイミング、入力方法、情報を確認する場所など、仕組みの違いも検討します。

判断に必要な根拠が足りない部分は、コンセプトテストや試作で補います。
顧客が好意的に答えたことと、実際に使えること、事業として成立することは、別々に確かめます。

この活動の成果は、魅力的な説明文だけではありません。
どの顧客のどの要求を優先し、なぜその案を選んだかを、開発チームで共有できることに価値があります。
品質機能展開などへつなぐ場合も、要求の背景と根拠を引き継ぎます。

参考資料