「Airレジ ハンディ」セルフオーダーの立ち上げ初期の「ブレない価値の軸」の作り方
こんにちは!
「Airレジ ハンディ」でセルフオーダーのプロダクトマネージャーをしている川崎です。
前職やリクルートではこれまで、新技術を使った研究開発、新製品の企画・価値検証などを中心に行ってきました。
今回は、プロダクトディスカバリーのフェーズにおいての「価値検証」について、Airレジ ハンディ セルフオーダーの立ち上げ期の事例をシェアします。
ディスカバリーフェーズの価値検証でこんなこと、よくあると思います。
・何をプロダクトの価値として据えればよいかわからない
・検証はどうやればいいかわからない
・検証しても、ちゃんと価値提供できているのかが不安
この記事では、以下を持ち帰っていただけるように書きます。
・ブレない価値定義の仕方
・検証の前の検証設計の勘所
・意思決定を引き出せる検証結果を最短で出す方法
Airレジ ハンディ セルフオーダー とは
はじめに、今回生まれたAirレジ ハンディ セルフオーダーを簡単に説明しておきます。
Airレジ ハンディ セルフオーダーは、お客様のスマホでいつでもカンタンに注文ができるサービスです。
利用イメージは、以下です。
このサービスシステムには、リクルート、カスタマー（来店客）、スタッフ、そしてここには載っていませんが、サービスを購買し推進するオーナーが関わって実現しています。
※ QRコードは株式会社デンソーウェーブの登録商標です
リリースまでの流れと価値検証のフェーズ
セルフオーダーは、企画〜価値検証〜製品版リリースで2年かかりました。
ただ、価値設計とHighFidelity Prototypeによる検証で大体3ヶ月弱です。
今回は、赤枠の価値検証フェーズの工夫について書きます。
0. 飲食店に存在する問題・課題
まず、価値定義の話の前に、飲食店がどんな問題・課題をもっているのか簡単に触れます。
※ この記事では課題の整理方法については割愛します
まず、飲食店のオペレーションの流れはこうなっています。
フロアスタッフが対応しないと進まない工程がほとんどですね。
店内の業務の問題をざっくり簡単にまとめると、こんな感じの構造に整理できます。
問題：スタッフが多忙により、注文待ちや注文ロスが発生
原因：需要（注文）に対して供給（注文処理力）が不足
真因：フロアスタッフが不足すると滞るという「人依存の構造」
現存手段：採用、育成、オペレーション改善（どれも人に依存した構造には変わらず、機能しない）
理想の状態：注文がスムーズになり、客単価UP、来店客も待ちゼロ
（そのための）課題：需要（注文）以上の供給力を持つこと
（課題を実現させる）ソリューション：フロアスタッフが少人数でも回る人に依存しない構造（セルフオーダー）
※ ただ、既存のTTO（テーブルトップオーダー）ではコスト高く導入困難。来店客のスマホを使ったコスト安なセルフオーダーがソリューションとなります
では、その価値を生むために辿ったプロセスを、以下のご紹介します。
1. 価値定義 ー プロダクトの価値は、対価との等価交換で定義する
課題を特定した後、みなさんどのようにプロダクトの価値を整理していますか?
以下のようなやり方はよくネット上でも情報があります。
・ジョブ理論
・エレベーターピッチ
・バリュープロポジションキャンバス
・ビジネスモデル/リーンキャンバス
しかし僕の場合は、結構これで大事なことが抜けることが多かったです。
何より、PMF、つまり価値が提供でき、熱狂した状態が定義しづらいことに気づきました。
そこで今回セルフオーダーの時に行った整理の仕方が、これです。
ポイントは3つです。
1. サービスに関わるメインのステークホルダーを洗い出す
2. それぞれの課題・(顧客)価値を対応させる
3. (顧客)価値と「対価」をセットで定義する
「対価」とは、その(顧客)価値が提供された時、そのユーザーが支払ってくれる何かしらのコストです。
プロダクトの操作手間、時間、情報、お金などです。
逆に言うと、「この対価を支払ってもらえてはじめて、(顧客)価値が提供できた」ということです。
価値のループと価値の源泉
もう一つ大事なポイントです。
これらの価値の交換は、相互に関係しています。
価値には、因果があります。
誰かの価値と対価の支払いが、他の人の価値に繋がっています。
この価値のループによって、サービスが成立します。
そして、価値のループには、源泉があります。
全ての始まり、このサービスの目的であり、提供価値が生まれる理由です。
この価値の源泉が止まったとき、価値のループは止まり、ビジネスが収縮していく、ということになります。
ここまで価値を定義しても、仮説は仮説です。
では次に、この価値のループを盤石なもの(繰り返される事実)にするために、何をすればいいでしょうか。
2. 不確実性マップ ー 初期に致命的な不確実性を見定める
プロダクトディスカバリーで「検証」というのはよく出てくる言葉ですね。
Q : 何を検証すれば「いい」のか?
この問いに悩まされている方も多いかもしれません。
しかしこの問いは、もう少し正確にする必要があります。
「いい」 = 価値定義の交換が(事実として)成り立つ
「検証」 = 怪しいところを確かめる
つまり、先程の問いを、こう読み替えます。
Q : 価値定義が(事実として)成立するためには、どこが確かめるべき怪しい点(不確実性)か?
問いがクリアになったところで、不確実性を洗い出します。
不確実性は、以下の4つの観点で洗い出すと、かなり効率良く要点を抑えられます。
特に価値、ユーザビリティの不確実性が大事です。
「解決する価値がある問題か」「これで問題が解決できるのか」がわからないと、その効率的な実現方法を検討したって水の泡になる可能性があります。
例えばセルフオーダーの場合だと、以下のような仮説を初期に出していました。(一部抜粋)
画像には映っていませんが、来店客、スタッフ、オーナーについて、どこが不確実性があるかを洗い出しています。
そして、不確実性が高く、価値定義の成立を脅かすものを重み付けしました。
不確実性が洗い出せたら、いよいよ検証です。
3. 検証の成果設計 ー 検証は、研究ではない。判断のための学習行動
そもそも、検証は何のためにやるのでしょうか?
もちろん、「不確実性を下げる」ことですが、その先があります。
「検証」 = 怪しいところを確かめる
と言いました。
確かめて、どうするんでしょう？
確かめたら、価値定義が成立することが現実味を帯びてきますね。
そうしたらどうするんでしょう？
事業としては、「追加投資をするかどうか」を判断するんですよね。
確かめる（検証） → YES/NOを判断する
です。
なので、以下が検証の前に必ず考えることです。
・何を判断したいのか？
・（価値定義が成立するためには）何を確かめる必要があるのか？
・どんな結果があれば判断できるのか？
セルフオーダーの場合、ポイントとしては以下のような内容でした。
・「Q : MVP開発の初期投資をするか価値があるか?」を判断するために、
・「Q : お客様に使われるか?」「Q : 店鋪運用が回るか?」「Q : 買ってくれるか?」を明らかにする必要があり、
・それが「明らかだ」と判断できる理想の検証結果(アウトプット)を先に定義しました。
「検証」は、この成果物の実績と、その成果としての判断を最短で形成する活動です。
お気づきでしょうか。
検証点にすえているものは、先程の価値ループの「価値の源泉」と、キャッシュポイントとその転換率ですね。
特に、価値ループの源泉である価値・対価の交換が、重要な検証ポイントとなります。
スタッフがQRを配る ←→ 来店客が読み取り、注文利用する
4. ハイファイプロト ー 最重要な不確実性の検証に振り切る
では、いよいよ検証です。
どうすれば、最短で検証結果、そして判断という成果を埋めるでしょうか？
セルフオーダーでは、「HighFidelity Prototype」という方法をとりました 。
強く意識したことは、「今回作ったものを、欲を出してその後の製品版の前身（MVP）にしない」ということです。
つまり、「検証目的」と振り切りました。
具体的には、以下のようなものを作りました。
4人で2週間で開発し、4店舗で3日の実証実験をやりました。
メンバーに助力いただきながら、PCのSlack通知とSpreadSheetに飛んできたセルフオーダーの注文を見ながら、左下で僕がハンディで怒涛のように注文してます笑。
こんな半アナログなハリボテでも、検証したい体験は再現できています。
検証結果として、以下のような結果を集計・分析し、店舗に効果の推計値を伝えた上で、価値に見合う対価がどのくらい得られそうかヒアリングしました。
実験結果を集計し、市場の見立てを概算したところ、MVPを開発しても一定回収の目処が立つことがわかりました。
その結果、MVPの開発投資へ進むことができました。
そしてMVPへ
これまで、価値仮説を整理し、不確実性を特定し、プロトタイプで価値・ユーザビリティを検証しました。
次はプロダクトの発見です。
長文になりそうなので、MVP編はまた別の機会にこの辺のテーマを書くことにします。
※もしご興味ありましたら「スキ!」を押していただけると嬉しいです!
Q：MVPは何を基準に要件の全体像構想・取捨選択をすればいいのか？
Q：MVPで何を基準に「熱狂」を可視化するのか？
Q：MVPから製品版の間はどんな考え方でスコープを切るのか？
まとめ
まとめると、
プロダクトのブレない価値を作るためには、
・価値定義で、価値と対価をセットで定義する
・不確実性マップで、致命的な価値・ユーザビリティの不確実性を特定する
・ハイファイプロトなど、価値の源泉を中心に、検証に振り切った検証を最短で行う
このようにして価値を一定確信しながらMVPの構築に移ると、
MVPを構築したのに、「一番大事な価値の源泉となるアクションが生まれない！」なんてこともなく、
一つずつ着実に進みながら新しいプロダクトを生むことができます。
新しくサービス・プロダクトを始めるときに、
何をどうやって始めるのかよくわからない時のお役に立てれば幸いです。
それでは！