ユーザ観察から得たヒントをどう開発に活かすか。

12月21日。商品開発のプロジェクトでユーザを観察したのですが、それを開発にどう活かすか、ということで今日はその作業をしていました。
試作品をユーザーにいじってもらったらかなりのことが分かりました。使いにくさや、実際に扱いにかかる時間など。
さて、それらを開発品どうフィードバックするか。これは開発を支援するコーディネータとしても非常に実践知を蓄えたい部分です。
まず、ユーザの観察、ユーザの声、そこから得られた情報の集合をAとしたら、その中で、個別性の高いもの、汎用的なモノ、に分けます。（十分なサンプルがとれないときは、ある程度、仮説的に、峻別していき、また検証を踏む）。
そして汎用的な情報の集合をA’と表したら、そのうち、自己矛盾しない機能セットを取り出します。A’を全て実装しようとしたら、矛盾・重複がおきます。
このときに、どれを入れてどれをいれないか。実は捨てるという部分が結構開発戦略において重要です。コアな価値をそがずに捨てていくわけです。
（あるコンサルタントの先生は、こうおっしゃいます。戦略とは「略」の字のとおり、いかに略すか、だ。言い換えれば、限られたリソースをどこに集中投下するか、どこをあきらめるか、そういうことだ。と。）
このときに、考え方のヒントの一つが実践的なMOT（技術経営）の手法であります。VE（価値工学）の基礎で考えて見ます。
価値とは、その商品・部品が、提供する効能機能を、その商品・部品のコストで割ったもの、と考えます。コストに、「害」をふくめる、というスタイルも。
ここで重要なのはその絶対値ではなく、相対値。何か一部を捨てたときに、コストも減りますが機能も減ります。何かを加えると機能が上がりますが、コストもあがります。その相対値を振らしていって一番おいしいところを探したいわけですね。
さて、価値工学。今回の商品開発で行くと、どう適用できるか。やってみると、「機能効能を定量的に考える」ことはかなり難しいですね。とはいえ、やってみるしかない。多分こうだろう、という目安を自分なりにつけて、後は仮説を検証する。これが何の目安も持たずになんとなく幾度もトライすると、合理的に絞っていけないわけですね。とはいえ、実際はほとんどそうはできていませんが。
そうして、A’のうち、商品に反映するべき情報の集合がA”、と分かるわけです。
私の支援（でおこなうコンサルティング）では、顧客現場の暗黙知をできる限り数字へ数字へと切り出していき、たとえ目の子でつけた数字であっても、計量の土俵に乗せて、検証プロセスに持ち込んでいきます。そして数字の再調整をしていきます。本プロジェクトは、される側がどれだけ大変なのか、を学ぶいい経験になっています。