コンシェルジュMVP — システムを作らず手動でサービスを検証する
「このサービス、ニーズがあるかどうかわからない。でも開発には半年かかる。」
大企業の新規事業で、このジレンマに直面しない人はいない。だが、解決策はシンプルだ。システムを作らず、人力でサービスを提供してしまえばいい。
これがコンシェルジュMVPだ。
コンシェルジュMVPとは、プロダクトやシステムを一切開発せず、人間が手動でサービスの価値を顧客に届け、需要の有無を検証する手法だ。エリック・リースが『リーンスタートアップ』で紹介したMVPの一形態で、開発コストをゼロにしたまま「顧客がお金を払うか」まで確認できる。
→ MVPとは何か — 新規事業で「最小限」をどう定義するか
なぜ作る前に手動で検証すべきか
新規事業の失敗パターンで最も多いのは、「誰も欲しくないものを作ってしまう」ことだ。
開発に着手した瞬間から、コストは加速度的に膨らむ。エンジニアの人件費、インフラ費用、テスト工数。3ヶ月後にリリースして「反応がない」と気づいても、すでに数千万円が消えている。
コンシェルジュMVPなら、この構造を根本から変えられる。
- 開発コストがゼロ。 システムを作らないから、かかるのは人件費だけ
- 即日で検証を開始できる。 仮説が固まったその日から、顧客にサービスを提供できる
- 顧客のリアルな反応が取れる。 実際にサービスを受けた顧客の声は、アンケートやLPテストとは質が違う
- 支払い意欲まで確認できる。 手動であっても価値を実感した顧客は、対価を払う
→ 仮説検証とは何か — 新規事業で「正解」を見つけるプロセス
実践の3ステップ
ステップ1: 提供する価値を定義する
最初にやるのは「何を検証するか」の明確化だ。
コンシェルジュMVPで検証すべきは、顧客がその価値に対してお金を払うか。機能の使いやすさでもUIの美しさでもない。価値そのものだ。
具体的には、以下を言語化する。
- 誰に: ターゲット顧客は誰か（役職、業種、課題の状況）
- 何を: どんな成果物やサービスを提供するか
- どう届けるか: メール、対面、チャット、スプレッドシート共有など
- 判断基準: 何人中何人が「継続したい」「お金を払う」と言えばGoか
判断基準を事前に決めることが極めて重要だ。検証後に基準を設定すると、都合の良い解釈をしてしまう。
ステップ2: 手動でサービスを提供する
定義した価値を、すべて手作業で顧客に届ける。
ツールはローテクでいい。Googleスプレッドシート、メール、Slack、Notion。既存のツールの組み合わせで十分だ。重要なのは、顧客が受け取る価値がシステム化した場合と同等であること。
最初のターゲットは3〜5社（BtoB）または5〜10名（BtoC）で十分だ。統計的な有意性は不要。この段階で欲しいのは、深い定性データだ。
ステップ3: 顧客の反応と支払い意欲を確認する
サービスを提供したら、顧客の反応を観察し、直接聞く。
確認すべきポイントは3つ。
- 価値の実感: 「このサービスがなくなったら困りますか？」
- 支払い意欲: 「月額〇〇円なら継続しますか？」
- 改善点: 「最も不満な点は何ですか？」
「便利ですね」は検証データにならない。行動レベルの反応を見る。「次回も使いたい」「社内の他部署にも紹介したい」「予算を取って正式に契約したい」。こうした反応が出れば、需要は確認できたと言える。
コンシェルジュMVPの具体例
BtoBの例: 営業リスト自動生成サービス
仮説: 中堅SaaS企業の営業マネージャーは、ターゲット企業リストの作成に毎月8時間以上かけており、自動生成サービスに月5万円払う。
コンシェルジュMVPの実践: AIや自動化は使わず、担当者が手動で企業データベースを調査し、顧客の条件に合うリストをExcelで作成して毎週メールで納品する。
検証結果の確認: 3社に4週間提供し、「来月も使いたいか」「月5万円で契約するか」を確認する。
BtoCの例: パーソナライズ献立提案サービス
仮説: 共働き世帯は、家族の好みと栄養バランスを考慮した週間献立の提案に月額2,000円払う。
コンシェルジュMVPの実践: アプリは作らない。LINEでヒアリングし、管理栄養士の知識を持つ担当者が手動で献立を作成し、毎週日曜にPDFで送付する。
検証結果の確認: 10世帯に4週間提供し、継続意向と支払い意欲を確認する。
オズの魔法使いMVPとの違い
コンシェルジュMVPと混同されやすいのが「オズの魔法使いMVP」だ。両者は似ているが、決定的な違いがある。
コンシェルジュMVP: 顧客は「人間がやっている」と知っている。裏側が手動であることを隠さない。サービスの価値そのものを検証する。
オズの魔法使いMVP: 顧客には自動化されているように見せるが、裏側は人力。フロントエンドは「完成品」に見えるが、バックエンドは手作業。自動化された体験への需要を検証する。
使い分けの基準はシンプルだ。
- 「この価値にお金を払うか」を検証したい → コンシェルジュMVP
- 「自動化された体験として成立するか」を検証したい → オズの魔法使いMVP
新規事業の初期段階では、まずコンシェルジュMVPで価値の存在を確認し、その後オズの魔法使いMVPやプロトタイプで体験を検証する、という順番が効率的だ。
→ プロトタイプの種類と使い分け — ペーパー・Figma・コード
大企業で手動検証を提案するときの説得ポイント
「手動でやるなんて非効率では？」。大企業で手動検証を提案すると、必ずこう言われる。
だが、手動検証は「非効率」ではない。「最も効率的な検証手段」だ。以下の3つのポイントで説得する。
ポイント1: 開発費との比較で語る
「手動検証に3ヶ月、人件費150万円。システム開発に6ヶ月、開発費3,000万円。どちらのリスクが低いですか？」
数字で比較すれば、手動検証のコスト優位性は明白だ。特に需要が不確実な段階では、小さく賭けて確認するのが合理的だ。
ポイント2: 「学習の速度」を強調する
手動検証の最大の価値は、顧客に直接触れることで得られる学びの質だ。
システム経由では見えない顧客の迷い、要望の細かいニュアンス、想定外の使い方。これらは事業の方向性を決める重要な情報だが、ログ分析やアンケートでは取れない。
→ Problem-Solution Fit — 課題と解決策の一致を確認する方法
ポイント3: 「撤退しやすさ」を伝える
システムを作ると、サンクコストが判断を歪める。「3,000万円かけたから、もう少し続けよう」。この心理が撤退判断を遅らせる。
手動検証なら、やめるときのコストはほぼゼロだ。結果が出なければ翌週に方向転換できる。大企業にとって、撤退しやすい検証手段を選ぶことは、攻めの意思決定だ。
まとめ
コンシェルジュMVPは、最も原始的で、最も強力な検証手法だ。
システムを作らない。コードを書かない。人間が手動でサービスを提供し、顧客の反応を直接確認する。それだけで、「このサービスに需要があるか」「お金を払う人がいるか」がわかる。
大企業の新規事業こそ、この手法が有効だ。開発予算が大きいからこそ、使う前に確認する価値がある。
手動でやって需要が確認できたら、そのときに作ればいい。順番を間違えない。それがコンシェルジュMVPの本質だ。
LITMUSは、新規事業の検証に特化したスタジオです。コンシェルジュMVPの設計から、プロトタイプ制作、ユーザーテスト、事業判断レポートまで、6週間で一気通貫で提供します。
50万円から始められるEntry Moduleもあります。詳しくは LITMUS をご覧ください。