イノベーションのフロントエンド

開発を正式に始める前には、どの問題に取り組むか、どの解決策を試すかがまだ定まっていない時期があります。
イノベーションのフロントエンドは、機会を探し、顧客を理解し、アイデアを製品案へ具体化する活動の範囲です。
PDMAの用語集は、初期に製品案がまだ曖昧な状態をFuzzy Front Endとして説明しています。

決まっていない内容を分ける

仮の例として、食品工場の記録作業を減らす新製品を検討します。
まだ顧客の作業を見ていないのか、作業はわかるが解決策がないのか、解決策の原理が動くかわからないのかを区別します。
すべてを「企画中」とすると、次に何を調べるべきかが見えません。
顧客の問題、技術、提供方法、事業性のそれぞれに未確認の前提を置きます。

工場の例で、記録をまとめる手間が問題なら、最初から入力機器を作る必要はありません。
現行の帳票や転記先を調べ、手作業で集約を試す方法でも学べます。
一方、設備から必要な値を取得できないなら、接続の試験が先になる場合があります。
不確実性に合わせて、聞き取り、観察、試作、データ確認を選びます。

期限と探索を両立させる

初期段階だからといって、調査の期限も予算も不要になるわけではありません。
何を判断するために、どの程度の証拠を集めるかを決め、調査のまとまりごとに次の配分を見直します。
見込みが薄いとわかった案件を止めることも、成果として扱います。
案の数や資料の厚さだけを目標にすると、開発を決められないまま作業が続きます。

正式な開発へ渡すときには、確かめた顧客課題、残したコンセプト、成立条件、未解決の論点を残します。
前提を消して確定仕様だけを渡すと、後から条件が変わった際に何を見直せばよいかわからなくなります。
また、探索は開発の開始と同時にすべて終わるものではありません。
初期に決める必要がある判断と、提供後の学習で更新する判断を分けます。
フロントエンドの活動量は、案件の新しさと、誤った判断の影響に合わせて調整します。

関連する記事：機会、アイデア創出、コンセプト創出。