フレームワーク活用ガイドひとことで言うと#
開発候補の機能に仮想的な価格をつけ、参加者に限られた仮想通貨を配布して「買いたい機能」に投票してもらうことで、顧客が本当にお金を払ってでも欲しい機能を炙り出す優先順位付けゲーム。
押さえておきたい用語#
- Buy a Feature
- 機能に価格をつけ、参加者が仮想通貨で購入投票するイノベーションゲーム。個人では買えない高額機能を設定することで、参加者同士の交渉・合意形成が自然に生まれる。
- 仮想通貨（Play Money）
- 参加者に配布する架空の予算。全機能を買えない額に制限することで、優先順位の判断を強制する仕掛け。
- イノベーションゲーム（Innovation Games）
- ルーク・ホーマンが提唱した顧客参加型のリサーチ手法群。Buy a Featureはその中で最もよく使われるゲームの一つ。
- ウィリングネス・トゥ・ペイ（WTP）
- 顧客がある機能に対して支払ってもよいと感じる金額。Buy a Featureはこれを擬似的に可視化する。
Buy a Featureの全体像#
こんな悩みに効く#
- 顧客要望が多すぎて、どの機能から開発すべきか決められない
- 「全部大事」と言われてしまい、優先順位がつかない
- アンケートでは全機能に「欲しい」と回答され、差がつかない
- 社内の声の大きい人の意見で開発優先度が決まってしまう
基本の使い方#
開発候補の機能を10〜15個リストアップし、それぞれに仮想価格をつける。
- 価格は開発コストに比例させる（重い機能は高く、軽い機能は安く）
- 1枚の機能カードに「機能名」「簡単な説明」「価格」を記載
- 機能の説明は技術用語を避け、顧客が理解できる言葉で書く
- 全機能の合計金額は、参加者の総予算の2〜3倍になるようにする
顧客や社内ステークホルダーを6〜8名集め、1人あたり同額の仮想通貨を配布する。
- 1人では高額機能を買えないが、安い機能なら複数買える額が目安
- 紙のお金でもポイントでも付箋でもよい。「お金を使っている感覚」が重要
- ルール説明：「予算内で、自分が一番欲しい機能を買ってください。他の人と相談して共同購入もOKです」
30〜45分間、参加者に自由に機能を購入してもらう。
- 高額機能を買いたい人同士が自然に交渉を始める（ここが最大の価値）
- 交渉の中で「なぜその機能が欲しいのか」という本音の理由が語られる
- ファシリテーターは口を挟まず、会話をメモ・録音する
- 全員が予算を使い切ったら終了
各機能に投じられた合計金額と出資者数を集計する。
- 合計金額が高い順に並べると優先順位が見える
- 金額だけでなく「何人が出資したか」も重要な指標（幅広いニーズ vs. 一部の強いニーズ）
- 交渉中に出てきた定性的な発言もあわせて記録し、開発チームに共有する
具体例#
従業員50名のBtoB SaaS企業。次の四半期に開発できる機能は3つだが、要望リストには14個の候補があった。社内で議論しても「営業は連携機能が最優先」「CSはレポート機能を」と意見が割れ、3か月間結論が出なかった。
Buy a Featureの実施:
- 主要顧客8社の担当者を招待（オンラインでMiro使用）
- 14機能に$20〜$120の仮想価格を設定
- 1人あたり**$150**を配布（全機能合計$820に対して8人で$1,200）
結果:
- 1位：Slack連携（$380 / 7人が出資）
- 2位：カスタムレポート（$310 / 5人が出資）
- 3位：権限管理の強化（$240 / 6人が出資）
社内で最も推されていた「AI要約機能（$120）」は**$60しか集まらず4位以下。交渉中の会話で「AIより先にSlack連携がないと使ってもらえない」という現場の声が多数出た。上位3機能を開発した結果、翌四半期のNPSが+12ポイント**改善。
従業員200名のWeb制作会社。社内で使っている工数管理ツールの改善要望が22件溜まっていたが、専任の開発者が1名しかおらず、何から手をつけるかが常に揉めていた。
エンジニア12名でBuy a Featureを実施:
- 22件の要望を機能カードに整理し、$10〜$80の価格を設定
- 1人あたり**$100**を配布
- 会議室に機能カードを並べ、付箋のお金で投票
発見:
- 最も投票が集まったのは「日報の自動下書き生成（$60）」で**$420**。12人中10人が出資
- 一方、マネージャーが強く推していた「ガントチャート機能（$80）」は**$80**しか集まらず、1人しか出資しなかった
- 交渉中に「ガントチャートは見たいけど、自分で更新する手間が増えるなら要らない」という本音が判明
日報自動生成を最優先で開発した結果、日報提出率が**62% → 94%**に向上し、マネージャーが本当に欲しかった「メンバーの稼働状況の把握」は日報データから自動集計する形で解決された。
生徒数120名の個別指導塾。新年度に向けて新サービスを1つ追加したいが、候補が6つあり、スタッフ内で意見が割れていた。
保護者8名を招いてBuy a Featureを実施（対面）:
| サービス候補 | 仮想価格 | 集計額 | 出資者数 |
|---|---|---|---|
| オンライン自習室 | $40 | $280 | 7人 |
| 定期テスト対策講座 | $30 | $180 | 6人 |
| 保護者面談の月次化 | $20 | $60 | 3人 |
| プログラミング教室 | $50 | $50 | 1人 |
| 英検対策コース | $30 | $150 | 5人 |
| 送迎サービス | $60 | $80 | 2人 |
1人あたり**$80**を配布。
発見と意思決定:
- オンライン自習室が圧倒的1位。交渉中に「家で勉強しないのが一番の悩み」という声が多数
- スタッフが推していたプログラミング教室は最下位。「興味はあるけどまず学校の成績を」という本音が出た
- オンライン自習室を導入した結果、3か月で利用率78%、保護者満足度が4.1 → 4.6に向上
やりがちな失敗パターン#
- 全機能を1人で買える予算を配ってしまう — 予算が多すぎると全部に少しずつ投票して差がつかない。1人の予算は全機能合計の30〜40%以下に抑え、トレードオフを強制する
- 機能の説明が技術者目線になっている — 「REST API対応」ではなく「他のツールとデータを自動連携」と書く。顧客の言葉で説明しないと正しく評価できない
- 交渉タイムの会話を記録しない — 金額の集計結果だけでなく、交渉中に出てきた「なぜその機能が欲しいか」の定性情報こそ最大の収穫。必ずメモまたは録音する
- 社内の人だけで実施する — 社内メンバーだけでやると社内政治が持ち込まれる。実際の顧客を参加させることで、バイアスのない優先順位が得られる
まとめ#
Buy a Featureは、機能の優先順位を顧客自身に「お金を払う」という行為で決めてもらう手法だ。限られた仮想通貨という制約があるからこそ、参加者はトレードオフを迫られ、交渉の中で本当に欲しい機能とその理由が表面化する。アンケートの「全部欲しい」では見えなかった優先順位が、お金の力を借りることで明確になる。集計結果の数字だけでなく、交渉中の会話に耳を傾けることがこのゲームの真価を引き出すカギだ。