各社で微妙に異なる「MVPの定義」の捉え方　MoT・カウシェの「toB・toCプロダクト」が位置付けるMVP

3つのパネルテーマ

向井毅男氏（以下、向井）：では、さっそく本編に入っていきたいと思います。あらためて、本日はMoTとカウシェでプロダクトマネージャーを務めている総勢4名の方から、それぞれ3つずつアンチパターン、失敗談を共有してもらいながら、いろいろな知見とかをみなさまに共有できればと思っています。

（スライドを示して）本日のパネルテーマは大きく3つあります。1個目、2個目がアンチパターンを理解する上でのいろいろな部分の背景を、みなさまに共有しながら触れていきたいと思っています。主に3個目です。ここがたぶん一番盛り上がると思います。ここに触れていきたいと思っています。

カウシェの軌跡

向井：まずは1個目のパネルテーマです。共に順調に成長をしているサービスですが、これまでいろいろな歴史があったので、そこの部分をみなさんに共有してもらえればと思っています。じゃあ、まずカウシェからお願いします。

近藤優輝氏（以下、近藤）：カウシェの今までの簡単な軌跡みたいなところでいうと、2020年の9月に最初のiOS版の「カウシェ」というアプリがローンチして、まずは食品カテゴリー限定でリリースしました。その後にAndroidのリリースがあったという流れです。

我々は総合ECモールという位置付けのプロダクトになるので、そこからカテゴリーの展開を増やしていっていて、家電だったり日用品だったり、美容コスメの取り扱いをしている感じです。

その中で特徴的なところだと、牛1頭買い、「牛1頭をまるまるシェア買いしよう」みたいな、カウシェならではのキャンペーンだったりだとか。あと「2,000人で炭酸水をシェア買いしよう」みたいなイベントをやっていて。通常のECとは変わった取り組みをしています。

LINEのオープンチャットは合計で3つの公式ルームを運営していて、そこにお客さまが8,000人いたりとか。あと、ベトナムのコミュニティでバズったことがあって、そこでの利用が加速しているみたいなものが現状です。

そういったかたちでカテゴリー展開して、今までグロースしてきましたが、今後カウシェが目指していきたい世界観、方向性みたいなところでいうと、我々は“ソーシャルEC”を目指していきたい。ソーシャルの体験とECの体験が融合したようなECを目指していきたいと考えています。

そこで特徴的な機能でいうと、SNSとかではよく見ると思いますが、ECではあまり見ないようなプロフィールの機能だったり、なにか特定のアクションを促すようなミッションの機能だったり。

あと、プロフィールで作ったアカウントがつながれるような、フォロー・フォロワーの機能だったり。アプリ内でのお客さま同士がやり取りできる、コミュニケーションできるようなスタンプの機能だったりをどんどん追加していっているような状況で、新しいECのかたちを実現するところを今進めています。以上です。

向井：ありがとうございます。新しい概念への取り組みということで、興味深いところだなと聞きながら思っていました。

MoTの軌跡

向井：じゃあ続いてMoT側、お願いします。

脇水誠氏（以下、脇水）：まず2020年4月にJapanTaxi株式会社とDeNAのオートモーティブ事業部の2社が統合し、株式会社Mobility Technologiesができました。略して「MoT」と呼んでいます。この場でも、MoTと言ったら弊社の会社名だと思ってください。

最初に大きなフェーズ、マイルストーンがあって、2020年9月にタクシーアプリをローンチしています。これは、もともとDeNAで作っていた「MOV」というタクシー配車アプリがベースになっています。そこに加えてJapanTaxi株式会社が持っていたアセット、いわゆるタクシー車両と会社を連携して、「GO」というアプリでJapanTaxi車両とMOV車両を両方とも呼べる状態を最初に提供していました。

約2年経ち、いろいろな機能追加をして順調にユーザー数も増えています。2022年9月に1,000万ダウンロードを突破したというところで、これは社内にとっても大きなマイルストーンかなと思っています。拍手を自分の中でもしています（笑）。ありがとうございます。

これはかなり大きな成長を遂げているなと思っています。最近、竹野内豊さんのCMを見た方も多いかなと思いますが、だいぶ市場に認知されているなと思って。あと「ラッピングカーがよく走っているな」って、もしかしたら気づいた方もいるかと思います。「GO」という文字が一般的に浸透している実感を持って、今サービスを作っている状況です。

（スライドを示して）右側の展開エリアについても、2年前は約11都道府県でサービスをローンチしていましたが、現状は36都道府県で順調に拡大しています。まずは日本全国どこでも使えることを目指して拡大中です。以上です。

向井：ありがとうございます。これはあとで気づいたのですが、実はカウシェもGOというアプリが登場したのも、同じ2020年9月なんですね。これは知っていましたか？

脇水：そうですよね。気づきました。

向井：実は同級生なんですよ。

近藤：気づいていました。

脇水：そうですよね。

向井：気づいていましたか。そういう同級生のアプリがこうやって順調に成長していくというところを間近に見られて、当事者としてうれしいなというのがあって。良かったなと思っています。

カウシェのtoC向けプロダクトのMVPの定義

向井：こんな感じでお互い順調に成長してきたサービス、プロダクトではあると思いますが、流れで2個目のテーマにいきたいと思います。

（スライドを示して）今回のテーマの1つであるMVP（Minimum Viable Product）です。いろいろ工夫されながら仕様策定をされているかなと思いますが、MVPと書かれているとおり、（MVPは）「顧客、お客さまに価値を提供する最小限の機能を持ったようなプロダクト、サービス」と、一般的にはこのような定義をされていると思います。（しかし）各社に応じて、やはりこのあたりの捉え方って微妙に違うと思うんですよね。

その部分の考え方は、この後の3つのテーマにつながると思うので、少しずつ共有してもらえればと思っています。まずはカウシェからお願いします。

近藤：カウシェにおけるMVPで、まずカウシェのプロダクトには、toC向けのプロダクトとtoB向けのプロダクトがあります。toC向けのプロダクトは、ユーザーが使っているような通常のアプリです。toB向けには、商品を掲載してもらっている事業者さんが使うような管理アプリケーションがあります。

それぞれのプロダクトで定義が分かれているので、それぞれ紹介できればと思います。我々は「カスタマーApp」と呼んでいますが、toC向けにおけるMVPの定義として、「仮説検証したい最小の体験を実現する機能を有する施策」というような位置付けでいます。

MVPというもの自体が、不確実性に対するアプローチだと我々は考えています。不確実性というのは、「本当にそのニーズが存在するのか」「本当にそのユースケースは存在するのか」「本当にその施策は顧客の課題を解決するのか」と、わからないことがたくさんある中で、それに対してMVPという手法でアプローチして、課題の解決をしていくことを考えています。

そのMVPには使われるかどうかを最速で検証するところが大きな目的かつメリットとしてあるかなと考えていて。まずは使われる最小限のものを作る。目安として50点ぐらいの状態を目指して、逆にそれよりも大きい80点みたいな。クオリティがすごく高い、モリモリの要件のプロダクトになってきたら、それは逆にMVPとしてはトゥー・マッチだと考えていて。そこは要件を落として、逆にそのデリバリーを早める考え方でtoC向けのプロダクトを進めています。

特にカウシェは「世界一楽しいショッピング体験」という、なんか楽しそうではあるけれど、人によってイメージするものが違っているし、Howとしてもいかようにも取れるプロダクトかなと思っています。

それをどう実現していくかの不確実性が非常に高いのかなというところで、そういったプロダクトを生み出そうとする過程では、MVPというアプローチが非常に重要なのではと考えています。

では池松さん、お願いします。

カウシェのtoB向けプロダクトのMVPの定義

池松恭平氏（以下、池松）：toB向けのプロダクトについて、簡単にMVPをどういうふうに考えているかを話そうかなと思います。

カウシェのtoB向けのプロダクトって、簡単に言ってしまうとECの業務運用に必要な機能を揃えているようなプロダクト、EC用の管理画面みたいなものです。ECサービスってすでにいろいろあったりするので、必要なものが一定見えている部分もあります。一般的なEC管理画面は豊富なユースケースを想定していて、ものすごくいろいろな機能があって。

だけれど、今のカウシェのフェーズで同等レベルの機能実現をするとなると、かなり過剰になってしまう。とはいえ不足しすぎると、普通の業務進行ができないかたちになってしまう。

なので、今のカウシェのフェーズでtoB向けのプロダクトをどう考えているかというと、「想定される業務遂行に必要な最低限の機能を有する状態みたいなもの」をイメージとして持っています。不安があったり、「これを出すのは恥ずかしいな」と思うような状態でなるべく出すことを意識している感じです。

例えば、最初のリリースとかだと、CSVによる商品の入稿しかできなくて。あとは商品の一覧と商品詳細を確認できるだけで、1個ずつ商品を登録したり、1個ずつ編集したりみたいなのは一切できないみたいな。使用するユースケースをかなり絞った状態で出すことをやっていたりします。

向井：ありがとうございます。このあたりはECならではという感じがしますね。

GOのtoC向けプロダクトのMVPの定義

向井：続いてMoT、GO側のMVPの考え方を教えてもらえればと思います。

脇水：MoTのGOの事例を紹介したいと思っています。GO側でもtoC、toB向けで分かれているので、まず私からはtoCの紹介をしたいと思っています。

まず全体の定義です。MVPといっても、案件もだいぶいろいろ行っているし、ローンチしてから2年経っている背景もあるので、現状は案件ごとにMVPの概念を使っています。

弊社の場合、PRD（Product Requirements Document）、要求仕様書を書いて、それに向けて開発を進めていきます。案件ごとにPRDを書いて、要求に対して優先順位を3つの段階で定義しています。

（優先順位は）P1、P2、P3と分けています。P1は「Must have」で、必ず実現しなきゃいけない機能を定義していて、リリースブロッカーになります。

P2は推奨です。基本的に実現を目指しますが、開発コストの観点や難易度という観点で、どうしても見送る可能性があるところを残していて、こちらはリリースブロッカーにはしていない要求になっています。

P3は「Nice to have」といったところで、これがあると、その案件の機能がより良くなるという観点で定義しています。まずこういった大前提があります。

GOアプリのエンドユーザー向けのプロダクトの考え方ですが、これは常に天秤というかバランスかなって。そこはけっこう頭の中にあると思っています。

基本的にその案件をやる理由って、ユーザーのペイン解決になってくると思います。一方で、開発コストは常につきまとうので、そこのバランスを意識して定義しているというところです。

まずは、ペインの解決を最優先して考えていきたいなと思っているので、それをやった結果としての見積りを、エンジニアにお願いしてやってもらいます。その見積もった開発コストを天秤にかけて調整して、狙っているスケジュールがあるので、そこに向けて近づけることをやっています。

基本的にP1の要求は実現必須ですが、先ほどお伝えしたとおり、P2、P3については、状況によって見送られる場合もあります。

あとは、弊社の状況として、GOはローンチしてから2年経っていますが、QCD（Quality、Cost、Delivery）でいうと、いわゆるデリバリー、リリースを最優先するところがどうしてもありました。といったところですが、デリバリー最優先と言いながらも、守るべきものはちゃんと守るところを定義しています。

特に最近一番気をつけているのは、ミニマムで提供しようと思ってスピードを優先して出してしまうことによって、初回でユーザーさんががっかりしてしまって、もう2度と使わないところに対しては、すごく気にしています。

そのペインを解決しようと思って新しい機能を提供しますが、そこでがっかりして使ってもらえないとなってしまうと、元も子もないです。

あとこれもやりがちになってしまいますが、新しい機能を作って提供したものの、ペインを解決するはずが、新しいペインを生んじゃうみたいな。そういったことも起きてしまったことがあったので、デリバリーを優先しながらもクオリティを最低限担保するところは意識しています。

あと、弊社はけっこうステークホルダーが多くて。モビリティは実際に車を使ってサービスを展開する特徴を持っているので。

もちろんエンドユーザーがステークホルダーであることは間違いありませんが、タクシー事業者さんとかタクシー乗務員さんとか。あと案件によっては国交省と協業してサービスを展開するのはマストになってくるので、そういった観点も含めて気にはしています。

（スライドを示して）ここに書いている3つについて、例えばエンドユーザーは喜ぶけれど、パートナーさんが怒ってしまう機能はやはりだめです。使った機能に対して価値を提供しているとユーザーさんがお金を払って使ってくれるんですが、とある機能を作って売上が瞬間的に上がったとしても、納得感を持って使ってもらえなくて、クレームが増えちゃうとか。

あと、先ほどお伝えした法律に反してとか、特許を侵害するとか、そういった観点ですね。やはり犯してはいけないところがあるので、そこはきちんと守った上で、ミニマムの提供をするところを意識して案件を進めています。次、toB向けは山田さんからお願いします。

GOのtoB向けプロダクトのMVPの定義

山田慶氏（以下、山田）：GOのtoB向けのプロダクトのMVPの定義です。GOアプリって、ユーザーアプリとしては簡単にというか、シンプルでわかりやすく使える体験が売りなんですけれど。それを実現するために、裏側で受け口の事業者とか乗務員向けプロダクトは相当苦労して、複雑な構成を維持管理している状況になっています。

そうなっている背景は大きく2つあります。1つは、JapanTaxiが提供していたアプリとMOVというDeNAが提供していたアプリの2つが1つになっているということで、もともと出自が異なる。ただし、ユーザーにはどのタクシーに乗っても同じ体験を提供しなきゃいけないところから、それができるように工夫を凝らしているというところが1つ。

もう1つは、もともとタクシーや事業者さんが導入している機材とかを活かしたかたちでGOを導入してもらって、シームレスな業務体験みたいなことを実現できるようにを心掛けている部分。そういった観点から、いろいろなハードやソフトを連携させながら動かしている状態になっています。

なので、もうインフラと化しているような状態です。それゆえにMVPを作る際に大事にしていることが、例えば新しい機能を提供するとなったとしても、それを必要としている事業者さんとか乗務員さんに漏れなくその体験を提供できる。「どこかの構成ではそれができません」とならないようにするところが1つ。

あとは、新しい機能が追加されたとしても、今まで使っていた機能になんらかの支障をきたすとか、犠牲になるとか、そういったことが起きないようにするところが注意しているポイントです。

なのでMVPと言いつつも小さくまとまりすぎるのではなくて、最低限必要な箇所をちゃんと見極めるということを大切にして日々プロダクト開発をしている点が特徴かと思います。

向井：ありがとうございます。やはり各社、微妙に定義が異なる部分が、聞いていて非常におもしろいなと思いました。

（次回に続く）