コンシェルジュMVP

英語名 Concierge MVP
読み方 コンシェルジュ エムブイピー
難易度
所要時間 2〜8週間
提唱者 エリック・リース
目次

ひとことで言うと
#

プロダクトを開発する前に、サービスの全工程を人力で提供し、顧客が本当にお金を払うかどうかを検証する手法。ホテルのコンシェルジュのように一人ひとりに手作業で対応することで、顧客の本音のニーズと最適なサービス設計を同時に学ぶ。

押さえておきたい用語
#

押さえておきたい用語
コンシェルジュMVP
プロダクトやシステムを作る前に、人手でサービスを提供して仮説を検証する最小限の実験手法。
MVP(Minimum Viable Product)
仮説を検証するために必要な最小限の機能を持つプロダクトのこと。コンシェルジュMVPはその中でも「プロダクトすら作らない」手法にあたる。
ウィザード・オブ・オズMVP
顧客からは自動化されて見えるが、裏側では人力で処理しているMVPを指す。コンシェルジュMVPとの違いは、顧客が人力であることを知っているかどうか。
プロダクト・マーケット・フィット(PMF)
プロダクトが市場のニーズにぴったり合致している状態。コンシェルジュMVPはPMF達成前の学習フェーズで使われる。

コンシェルジュMVPの全体像
#

開発前に人力でサービスを提供し学びを最大化する
コンシェルジュMVPの流れ1仮説設定誰のどんな課題を解決するか2人力で提供手作業で顧客にサービスを届ける3観察と学習顧客の反応を直接観察する4判断続行・ピボット・撤退を決める通常のMVP開発との比較通常のMVP開発コスト:数百万〜数千万円期間:2〜6ヶ月学び:プロダクト経由(間接的)コンシェルジュMVP開発コスト:0〜数十万円期間:2〜8週間学び:対面で直接得られる開発前の確信「顧客が本当に欲しいもの」を体験から理解した上で開発に進む
コンシェルジュMVPの実践フロー
1
仮説を明文化
誰の・どんな課題を・どう解決するか
2
手動で提供
システムなしで5〜10人にサービスを届ける
3
反応を記録
満足度・課金意思・改善要望を収集する
Go/No-Go判断
開発着手・ピボット・撤退を決定する

こんな悩みに効く
#

  • 新サービスのアイデアがあるが、開発に着手すべきか判断できない
  • MVPを作ったが誰も使わなかった経験があり、開発前に確信を得たい
  • 顧客が本当に欲しいものと自分が作りたいものがズレている気がする

基本の使い方
#

検証したい仮説を1つに絞る
「忙しい共働き家庭は、栄養バランスの取れた夕食の献立提案に月額3,000円払う」のように、ターゲット・課題・ソリューション・価格をすべて含む仮説を1文にする。複数の仮説を同時に検証しない。
5〜10人の初期顧客に手動でサービスを提供する
アプリもWebサイトも作らない。Excelで管理し、メールやLINEで顧客とやり取りし、手作業でサービスを届ける。5〜10人で十分。この段階で大切なのは「スケーラビリティ」ではなく「学び」の量。
課金意思と行動を観察する
「いいサービスですね」という感想ではなく、「実際にお金を払ったか」「2回目も利用したか」「他人に紹介したか」を観察する。言葉ではなく行動が仮説検証の唯一の証拠。無料で提供して満足度を聞いても検証にならない。

具体例
#

例1:食事管理アプリの開発前にLINEで手動提供した起業家

元管理栄養士のフリーランス(30歳)。「AIで個人に最適な食事プランを提案するアプリ」を構想していたが、開発費の見積もりが 500万円 で、いきなり投資する判断ができなかった。

コンシェルジュMVPとして、知人 8名 にLINEで毎日の食事写真を送ってもらい、手動で栄養分析と翌日の献立を返信。料金は月額 3,000円4週間 実施した結果、8名中6名 が翌月も継続を希望。

しかし予想外の学びもあった。顧客が最も喜んだのは「AIの栄養分析」ではなく「自分の食事を誰かが見てくれている安心感」。開発するアプリの方向性を「分析ツール」から「栄養士とつながるコミュニティ」に大幅にピボットし、開発コストを 500万円 → 180万円 に圧縮できた。

例2:BtoB SaaS企業が新機能の需要をスプレッドシートで検証

従業員 40名 のBtoB SaaS企業。営業から「顧客が競合分析レポートの自動生成機能を欲しがっている」という声が上がり、開発チームは 3ヶ月 の開発を見積もった。

CTOがコンシェルジュMVPを提案。営業 2名 が既存顧客 10社 に「月額 5万円 の追加オプションとして競合分析レポートを提供します」と案内。実際のレポートはアナリストが手作業でスプレッドシートから作成した。

結果、10社中3社 が申し込み。ただし3社すべてが求めていたのは「競合の価格動向」の1項目だけで、営業が想定していた包括的な競合分析は不要だった。開発スコープを 競合価格のトラッキング機能 に絞り、開発期間を 3ヶ月 → 3週間 に短縮。リリース後 半年28社 が契約し、ARRが 1,680万円 増加した。

例3:地方の学習塾がオンライン指導の需要を手動で確認した事例

地方都市で個人経営の学習塾(生徒 25名)。少子化で通塾生が減少する中、オンライン指導への展開を検討していたが、システム導入費 200万円 の投資に踏み切れなかった。

まず既存生徒の保護者 25名 に「オンラインでの補習を月 5,000円 で提供したい」と案内。申し込みは 7名。Zoomの無料プランとLINEだけで 6週間 手動運営した。

オンライン指導を受けた 7名 の保護者にヒアリングしたところ、最も価値を感じていたのは「リアルタイム指導」ではなく「録画を後から見返せること」だった。この発見を活かし、録画配信型の教材を中心にしたオンラインコースを月額 3,000円 で設計。県外からの申し込みも入り、6ヶ月 で生徒数が 25名 → 52名 に倍増した。

やりがちな失敗パターン
#

  1. 無料で提供してしまう — 「まず無料で試してもらおう」は最も危険な判断。無料なら誰でも使うが、課金した途端にいなくなる。最初から有料にして課金意思を検証する。
  2. 人数を増やしすぎる — 手動提供は5〜10人が限界。50人に提供しようとすると作業に追われ、観察と学びの時間が取れなくなる。
  3. 学びを記録しない — 顧客の反応や要望を体系的に記録しないと、後から「結局何が分かったのか」が曖昧になる。毎回の対応後に気づきを書き出す。
  4. 手動運営を長引かせる — コンシェルジュMVPは検証のための手段であって、永続する事業モデルではない。4〜8週間 で判断し、次のステップに進む。

まとめ
#

コンシェルジュMVPは「作る前に売る」という発想の究極形。システムを開発する前に人力でサービスを提供し、顧客が本当にお金を払うかを確認する。開発費ゼロで最大の学びを得られるこの手法は、新規事業の失敗確率を大きく下げる最初のステップになる。