既に存在する巨大なプロダクトの維持と改善をしながら、さらに新しいプロダクトのアイデアをかたちにするまでの道のりは、決して易しいものではない。実用化までの時間やコスト、既存プロダクトとのシステム連携や社内承認……、ほかにも考慮するべき要素は多々存在する。そうしたプロセスの過程で壁にぶつかり、日の目を見ることなく消えてしまったアイデアも少なくないだろう。

そこで当記事では、飲食事業で実施した現場発のMVP（※）検証を例に、新しいプロダクトが製品化されるまでのリアルな流れを公開。2022年9月にリリースされた『セルフチェックイン』の開発に携わった柴田直幸、長縄祐美子に、アイデアの着想からMVP検証までの流れ、検証の具体的な中身などをインタビュー。プロダクトデザインに関わる人にとって参考になりそうなポイントを紹介する。

（※）Minimum Viable Product：ユーザーに必要最小限の価値を提供できるプロダクト。製品やサービスを正式リリースする前に最低限の状態で市場に投入し、顧客の反応を見ながら改善策を講じる目的で実施される。

#PROFILE

①経緯：既存プロダクト運営の中で新プロダクトの追加開発は難しい

――まずはお二人が所属する「飲食クライアントソリューション１グループ」のミッションについてお聞かせください。

柴田：主なミッションは、飲食店の業務と集客を支援するプロダクト開発です。飲食店専用の予約管理システム『レストランボード』に関しては、2022年9月に飲食店の複雑な受付対応を自動化する来店管理アプリ「セルフチェックイン」をリリースしました。

――開発にあたっては、正式リリースの一年前からMVP検証を実施したそうですね。

柴田：はい。僕らのグループでは以前から、飲食店の受付対応に課題があることを把握していました。特に、現場でヒアリングをした際によく聞いたのは「ホールスタッフが不足していて受付対応まで手が回らず、来店客を待たせてしまう」という声。そこで、受付の負担を軽減するシステムを開発できないか考えたんです。

しかし、新たにプロダクトを立ち上げるのは、そう簡単な話ではありません。特にリクルートのプロダクト開発は、すでに多くの取引顧客が存在する中で、障害などをケアしながらしっかりと体制を組んで行われます。例えば『ホットペッパーグルメ』なら「予約数を伸ばす」といった半期での指標を決めて、それを達成するための予算や人的リソースが配分されるんです。

戦略に基づいたプロダクトの開発計画が優先順位をつけて推進される反面、目標への貢献度が低ければ検討の優先順位が下がってしまう案件も存在します。『セルフチェックイン』も一見すると予約数増加というような戦略的指標からは遠いので、優先順位を上げたくても上げられないジレンマがありました。

――そこで、まずはMVPをつくろうと考えたわけですね。

柴田：そうですね。それが、2021年の9月ですね。既存の製品に手を加えるのではなく、そして既にやらないといけない戦略案件をやりつつ、浮いた工数を使ってMVPで検証するならば文句はないだろうと考えました。

②目的の置き方：プロダクト価値を磨くためにMVPで仮説検証

――リクルートのプロダクト開発でMVP検証を行うケースは珍しいのでしょうか？

柴田：いえ、MVP検証自体は珍しくないですね。ただ、今回は従来のやり方とは少し違うアプローチをとりました。それは、「今回のMVPはあくまで、クライアントに提供できる価値やニーズ、使い勝手などを確かめる目的」で行うのであって、「技術の検証は行わない」ということ。つまり、そこで技術的な課題が出たとしても、いったん無視しようと。必要な技術については、正式にプロダクトを開発する段階になってからゼロベースで考えればいいと思っていました。

――せっかくMVPをつくるなら、技術的な検証も行ったほうが効率的なように思えますが……？

柴田：規模の小さいサービスをつくるなら、そのほうがいいと思います。しかし、プロダクトを大きく成長させていくことを視野に入れている場合は得策ではない気がします。なぜなら、MVPのように「小さいプロダクトをスピーディーに構築する技術」と「大きいプロダクトを運用していくために必要な技術」は全くの別物だからです。

――つまり、MVPで採用した技術をベースに製品化すると、プロダクトの規模が大きくなっていったときに“ひずみ”が出てしまうと。

柴田：その通りです。これまでのリクルートのプロダクト開発は、基本的に「まずは小さく作り、サービスの規模が大きくなるにつれて技術を継ぎ足していく」という手法をとっていました。いち早くプロダクトを世に出せる反面、どうしても技術面のひずみが出てきてしまい、解消するまで数年かかるケースもあったんです。そこで、僕たちはMVPでプロダクトの価値やニーズを確認できたら速やかに検証を終わらせ、最初から“大きいプロダクト”を見越した技術を改めて構築しようと。そんな方針で進めました。

③実施上の工夫：MVP検証の工数を最小限にし、スピード感を重視

――では、どのようにMVP検証を進めていったのか、具体的な体制や流れを伺えますか？

長縄：要件定義やデザイン・店舗での検証を担当するディレクター、アプリやシステムを開発するメンバーといった小さなチームで進めていきました。最初のバージョンを完成させたのが2021年の10月下旬です。ディレクターが要件をまとめ、開発に接続するというサイクルは通常の案件と同様ですが、とにかく高速で実店舗導入し検証を進められる体制づくりをメンバー全員で意識していました。

――検証のスピードを上げるために工夫したことはありますか？

長縄：まず、プロジェクトが途切れることなく進むよう、検証と開発を同時並行で行いました。現在のバージョンを検証しつつ、次のバージョンの開発も進めるようなイメージですね。また、検証結果をふまえて要件を開発にパスする際にも、あらかじめ優先度の高いものを整理してからパスするなど、こまめにコミュニケーションをとって認識の齟齬が出ないようにしていました。

それから、今回のMVPはあくまでサービスの価値やニーズなどを検証する目的だったため、細かな設計書の作成や、仕様変更のログを細かくドキュメントに残すことはしませんでした。先ほど柴田が説明したとおり、ここで使った技術は“捨てる前提”だったので、チームとして合意形成できる最低限のドキュメントの作成に留め、何か課題が出た時にその都度ミーティングで解決する方法をとったんです。

――とにかく、スピードを優先されたわけですね。

長縄：はい。それに、技術を本製品に引き継がない前提なので、MVPの開発では自由にツールを選ぶことができます。通常だと既存の開発環境との整合性をどうとるかといった検討が必要ですが、既存環境に囚われずに、MVPに最適な技術選定を行うことができ、スピーディーに検討・開発することができました。

④製品化が決定：MVP検証で価値を見極めたポイント

――MVP検証を経て、製品版に進むことになった決め手は何だったのでしょうか。

柴田：事前にMVP検証のポイントを大きく2つ設定していて、それをクリアしたら製品版にしようと決めていました。一つは「来店したお客様が迷わず席に行けるかどうか」。受付を自動化したものの、結局は席に迷ってしまって入口で店員を呼び出すとか、使い方がわからないといったことが起こると意味がないので、そうした事態にならないように工夫をしました。

もう一つは、「配席の仕方が、納得感のあるものになっているか」。お客さんをどう配席するかは飲食店ごとに考え方が異なります。そのため、さまざまなお店にとって納得感のある配席ができなければ、オーナーもお金を払って導入したいとは思ってくれないでしょう。

MVP検証の結果、この2つのポイントをクリアできる目算が立ち、プロダクトの価値を証明できたため製品化につながりました。

――目算通り、検証後には社内の製品版開発の承認の壁を突破することができたと。

柴田：ただ、今回のMVP検証を通じて感じたことは、社内を納得させられるかは二の次で、その本質は「クライアントの課題をどこまで解決できるのかを把握すること」であるという点です。ニーズがないのに製品版を作ってしまうのは、誰にとっても不幸なこと。その点、今回のように3か月で開発・トライアルをして十分にニーズがあるという確証が得られたうえで、さらに半年かけて製品版をブラッシュアップしていくアプローチは、みんながハッピーになれるやり方なのかなと思います。

――今回の知見は、今後のプロダクト開発にも活かせそうですね。

柴田：そうですね。今後も、業務支援のプロダクトを手掛けていくうえで、非常に有効な手段が見つかったと思います。また、新しいプロダクトをつくる際だけでなく、既存の大きなプロダクトから一部の機能を切り出して検証するような時にも、今回のようなアプローチが使えるのではないかと考えています。ですから、今後は、MVP検証の発展的な活用方法や、それを実現できる仕組みなども考えていきたいです。