顧客共創プログラムの制度的失敗——協創が形骸化する構造的メカニズム

「お客様の声で作った」という言葉の実態

製品・サービスの発表資料に「顧客との共創により開発」「ユーザーとの協創プロセスを経て」という説明が加えられることが増えた。コ・クリエーション、ユーザーコミュニティ、顧客参加型開発——名称はさまざまだが、「顧客を開発プロセスに巻き込む」という発想は広がっている。

しかし、この「顧客共創」の実態を問われると、答えが苦しくなるケースが多い。

「顧客に話を聞いたことはあるが、その後の開発に反映されたかどうかはわからない」「顧客コミュニティに登録してもらっているが、活動が停滞している」「共創と言っているが、実際は顧客から情報を取るためのリサーチだ」——これらは顧客共創プログラムの形骸化を示す典型的な症状だ。

---

形骸化の3つの構造的パターン

パターン1: 権力非対称による「参加の演劇」

顧客共創の制度的失敗の最も根本にあるのは、企業と顧客の間の権力非対称だ。

企業は設計の最終意思決定権、資源配分権、スケジュールの決定権を保持している。顧客はそれらを持たない。この非対称な関係において「共に創る」という建前を設定した場合、顧客参加は本質的に制約を持つ。

参加した顧客が提案したアイデアや指摘が、企業側の都合（技術的制約、コスト、内部の方針）によって反映されない場合が繰り返されると、顧客は参加が形式的であることを学習する。 形式的な参加への動機は低下し、やがて参加そのものが形式的になる。「アイデアを出しても採用されない」という学習が積み重なった顧客は、本音を出さなくなる。

参加の演劇が完成すると、企業側には「共創している」という認識があり、顧客側には「参加しても意味がない」という認識がある。このギャップは可視化されにくいため、形骸化が進行しても気づきにくい。

パターン2: 知識の境界による「翻訳の失敗」

顧客と企業の間には、知識の境界がある。顧客は自分の体験・不満・期待について深い文脈を持っているが、製品設計・技術実現可能性・市場全体の文脈を持たない。企業は技術と事業の文脈を持っているが、顧客の具体的な生活・業務の文脈を持たない。

共創が機能するためには、この異なる種類の知識を翻訳する作業が必要だ。

翻訳が失敗する典型的なパターンは、顧客の言葉をそのまま設計仕様に変換しようとするケースだ。 顧客が「もっと使いやすくしてほしい」と言う場合、その「使いやすさ」の中身は顧客の文脈に深く依存している。直接的な翻訳（「使いやすさ」→「インターフェースのシンプル化」）は、文脈を捨てた解釈だ。

逆に、技術的な実現案を顧客に提示して「これでいいか」と聞くケースも翻訳の失敗になりやすい。技術的な内容を顧客が評価できる形に変換しないまま提示された場合、顧客は「よくわからないけど反対もできない」という状態で同意する。これは顧客の知識が設計に組み込まれた状態ではない。

パターン3: 制度的形骸化の慣性

共創プログラムが組織内で制度として定着すると、プログラムの「実施」自体が目的化する慣性が生まれる。

定期的な顧客ワークショップ、ユーザーコミュニティのイベント、共創チームのミーティング——これらが習慣的に行われるようになった時点で、「何を共創するのか」「共創した内容が開発に反映されているか」という問いが立てられなくなる場合がある。

制度として存在することが、「機能している」という証拠とみなされる認知の歪みが生まれる。 共創プログラムを廃止することは「顧客を軽視している」というシグナルになるため、形骸化していても継続される。内部には「共創担当者」がおり、予算が確保されており、報告書が作成されている。しかし実際の製品開発への影響は限定的、あるいはゼロになっている。

顧客アドバイザリーボードが形式化していく構造については「顧客アドバイザリーボードのトークン化」を参照されたい。

---

ユーザーリサーチと顧客共創の混同

形骸化の背景にある基本的な混同として、「ユーザーリサーチ」と「顧客共創」を同一視するケースがある。

ユーザーリサーチは、顧客から情報を収集する活動だ。顧客インタビュー、アンケート、観察調査——これらは顧客を情報源として扱う。設計の意思決定は企業が行い、顧客はインプットを提供する。

顧客共創は、設計の権限を一定程度顧客と共有する関係だ。顧客がアイデアを提案し、それが実際に採用される経路がある。顧客が設計の決定に意見を持ち、それが考慮される構造がある。

この区別が明確でないプログラムは、ユーザーリサーチの手法を使いながら「共創した」と説明するパターンに陥る。 顧客側はインタビューに答えただけだが、企業側は「お客様の声を反映した」と説明する。この非対称な認識は、顧客の信頼を失う原因になる。

ユーザーリサーチの限界と構造的な過信については「ユーザーリサーチの過信」で詳しく分析している。

---

共創関係が機能する構造的条件

形骸化しない顧客共創関係には、いくつかの構造的条件がある。

条件1: 反映のフィードバックループ

参加した顧客の意見・アイデアが製品設計にどのように反映されたか、されなかった場合はなぜかを、参加した顧客にフィードバックする経路がある。

このフィードバックがない共創は、顧客にとって「入力のみで出力が不明な箱」だ。入力の結果が見えない関係への参加動機は低下する。反映の有無とその理由を透明にする誠実さが、共創関係の継続を支える。 採用されなかったアイデアに対して「なぜ今回は反映できなかったか」を説明することは、むしろ参加者との関係を強化する。

条件2: 非対称な権力の開示

企業と顧客の権力非対称を解消することはできないが、開示することはできる。

どの意思決定に顧客が関与できてどの意思決定には関与できないかを、あらかじめ明示することで、顧客は参加の範囲と意味を理解した上で関与できる。「最終的な製品化判断は弊社で行う」「価格設定には参加いただいていない」という開示は、後からの失望を防ぐ。

曖昧な共創関係より、制約を明示した部分的な共創関係の方が、信頼に基づく関係を維持しやすい。

条件3: 互恵性の設計

共創参加者が受け取る価値の設計が必要だ。金銭的な謝礼だけでなく、自分が貢献した製品・サービスが世に出るという「共同作者感」、他の参加者との学習機会、企業との直接接点による情報へのアクセス——これらが参加者にとっての価値を構成する。

参加者に価値が見えない共創は、企業による無償の調査活動に成り下がる。 この認識が広がると、質の高い参加者が離れ、残るのは「とりあえず参加しておく」という低動機の参加者になる。

---

共創の設計が問うていること

顧客共創プログラムを設計する際に、回避しにくい問いがある。「顧客を本当に設計のパートナーとして扱うのか、それとも情報源として扱うのか」という問いだ。

どちらが悪いわけではない。情報収集としてのユーザーリサーチは有効な手法だ。ただし、情報収集を「共創」と呼ぶことは、顧客への誤った期待設定になる。

設計の前に、この問いに正直に答えることが、共創プログラムの実効性を決める出発点になる。 共創と呼ぶからには、顧客の貢献が実際に設計に影響する経路を設計し、その経路が機能していることを継続的に検証する仕組みが必要だ。そこまでやる用意がないのであれば、正直にユーザーリサーチと呼ぶ方が、長期的な信頼関係の構築に寄与する。