MVPの初期スコープで、施策の優先順位はどう決めているか？
原田七穂氏（以下、原田）：ちょっとコメントで質問がきているので。
向井毅男氏（以下、向井）：おっ、ありがとうございます。
原田：言ってもいいですか？
向井：はい、お願いします。
原田：「MVPの初期スコープにおいて、施策の優先順位はどう決めていますか？」とのことです。
向井：おぉ、これもすごく悩ましいポイントですが、MoT側、カウシェ側でそれぞれ簡単に答えてもらってもいいですか？
脇水誠氏（以下、脇水）：そうですね。じゃあ最初（に答えても）いいですか。
向井：お願いします。
脇水：そうですね。まず、セグメントとかターゲットのユーザーを明確にしなきゃいけないなと思っていて。全員を救うのは、やはりペイン解決という意味では難しいので。
タクシーアプリGOの場合だと、最初はやはりタクシーをふだん使ってくれているヘビーユーザーさん向けのいろいろな機能提供をしようという話があって。ヘビーユーザーをきちんと救った上で、新しいお客さんに対して機能を提供していく。そういったストーリーを作ってやっていたりはしていました。
なので、まずセグメントとターゲットのユーザーを明確にするというところを意識して、そこの優先順位を高くしてやっていました。
向井：なるほど。カウシェさん側はどうですか？ 近藤さんかな、このあたりは。
近藤優輝氏（以下、近藤）：そうですね。カウシェの場合だと、今までECにないような機能、価値をどんどん提案していかないといけないところがあって。初期スコープとしては「それが使われるかどうか」みたいなところをけっこう優先順位高めに定義しています。
何かの機能が使われるかどうかを優先していて、逆にその機能をエンハンスするようなものは優先順位を下げるようにしています。エンハンスするものというのは、プッシュ通知とかお知らせとか、きれいな導線設計とか。あとツールチップ、コーチマークみたいなものとかがあると思います。
それって、その機能が使われることがわかって初めてエンハンスしてより使われるようにする施策だと思うので、そこの優先順位を落として、まず機能として提供して使われるかどうかをハイプライオリティに置いて出していくことを意識しています。
向井：なるほど。これはあれですかね。プレモーテムというところも絡んできて、なるべく出して使われるかどうかを検証して、また次を出してみたいな繰り返しということですかね？
近藤：そうですね。
向井：ありがとうございます。
原田：ありがとうございます。
考慮漏れを防ぐためのMVP定義にかける時間のバランス調整は？
原田：あともう1つだけ質問を読みたいと思うんですけれど。
向井：はい、お願いします。
原田：「考慮漏れを防ぐためには、MVPの定義に時間がかかるかと思います。かけられる時間と考慮漏れのないMVPの定義はトレードオフの関係にあると思うのですが、このバランスはどのように調整されているのでしょうか？」とのことです。
向井：あぁ、すごくいい質問ですね。たぶんこれは、質問されるとすごく困る質問でもあると思うんですけれども。
近藤：（笑）。
向井：ちょっと今近藤さんが笑っていたので（笑）。近藤さんかな。どうでしょうこのあたり。どのように調整されていますか？
近藤：そうですね。これはバランスというところだとどれだけ早くデリバリーできるかとかも関係してくるかなと思っていて。カウシェの場合だと、なるべくすべてのユースケースを満たすんじゃなくて、まずはシンプルなユースケースを満たすところを目的に仕様策定とかを進めています。
先ほどのエンハンスの話にもつながるんですが、シンプルなユースケースを満たして、使われることが確実になって不確実性が下がったら、「じゃあ、より作り込んだユースケースを提供していこう」というかたちでアプローチしてます。
なので、シンプルだからトレードオフのコストが低めに保てているというところが、カウシェのアプローチという感じです。
向井：なるほど。一方MoT側はどうでしょうか？ どのようにバランス調整、トレードオフされていますか？
脇水：そうですね。これはまさに先ほど紹介したトレーサビリティチェックがけっこう使えると思っていて。MVPの定義の時間って、これまでプロダクトにどれだけ関わっていたかという、そういった経験にもけっこう寄っちゃうと思うんですよ。なので、なるべく仕組みを提供して、誰がやっても漏れがないような感じにやっていきたいなとは思ってはいます。
ただ、これはPdMだけじゃ（足りない）。どうしても意識が偏っちゃうところもあるので、いろいろなロールに仲間になってもらって、一緒に見つけていくことをやってはいます。
なので、それをやった上で考慮漏れを防ごうと思っていて。それにプラスして、もともとPdMとしてやりたいところは、やはりMVP定義をしていくので、ハイブリッドというか、掛け合わせをやって、考慮漏れプラス今回の案件で実現したい最小限の機能を定義している感じにはなっていますね。
あと、これはたぶんtoB側の山田さんのほうで、いろいろな機器構成があるという話があったと思うんですけれど。そこの考慮漏れってメチャクチャ難しいなってはたから見て僕も思っているんですが、なにか意識していることはあったりします？
山田慶氏（以下、山田）：そうですね。最近やり始めているかたちとしては、今までは先ほど言ったように、例えば乗務員向けアプリだけでも4つのアプリがあるというような時に、プロダクトマネージャーがその4つに対して1プロダクト1プロダクトマネージャーみたいなかたちでついて、要件を検討したりみたいな体制になっていました。
でも、それだと視野がどうしても狭まっちゃって、俯瞰して見られなくなる部分もやはりあると思って。今は1人のプロダクトマネージャーが複数のプロダクトを機能横断みたいなかたちで要件検討するような体制に、ちょっとずつ変更していっています。
そうすると、複数名のプロダクトマネージャーがいろいろな視点で指摘できるようになるので、それによってより考慮漏れのない精度の高いMVPを定義できるように（する）みたいなところを構築しようとしていたり。組織変革みたいなかたちの取り組みも始めています。
向井：ありがとうございます。この部分を話し出したら、たぶんあと1時間や2時間お話ししそうな気がしていて。ちょっとすでに（時間が）押しちゃって、本来の終了時間になったので。また1個質問をいただいているので、この後で触れようと思いますが、いったんここで締めたいと思います。
本日はあらためてご視聴いただきありがとうございます。今後もみなさまのナレッジとかTipsとか、ふだんの業務に活かせるようなイベントを企画していきたいと思っているので、何卒アンケートの回答にご協力いただければと思います。
ぜひ忌憚ないご意見とかご感想とか。コメント欄とかでは、逆にちょっと恥ずかしくて聞けなかった質問とか、がんがん流してもらえればうれしいかなと思っています。
MVPからユーザー規模を拡大するまでのロードマップをどう考えたか？
向井：みなさんにアンケートに協力いただいている時間を活用して、もう1個だけ質問をいただいているので、そちらに触れていきたいと思います。じゃあ、せっかくなので七穂さん、ちょっと読んでもらってもいいですか？
原田：はい。そうですね。「MVPからユーザー規模を拡大するまでのロードマップってどのように考えられましたか？」ということなんですが。
向井：これはまた難しい話です。
原田：ロードマップ。
向井：じゃあ今度はMoT側から。（脇水さんが）今すごく右上を見ていますが。脇水さん、どうですか？
脇水：（笑）。いい質問ですけれど、難しい質問ですよね。拡大するまでのロードマップとか、一言で「これ」っていうのはやはりないんですよね。いろいろな組み合わせによってやはりユーザーは増えていきますし、単純に新しい機能を提供したら使ってくれるユーザーもいる一方で、既存の課題解決に集中して直してあげると、そこに対して恩恵を得て使ってくれるユーザーさんもいるので。
新しい機能の提供と既存の改善は、どうしても同時にやっていく必要があるかなと常に思っています。そこをきちんとやっていくことで、1回使って離脱しちゃうユーザーをすごくケアしたいと思っていて。
タクシーって、1ヶ月の間に何回も使ってくれるユーザーさんがすごく多いんですよ。そういったユーザーをきちんと大事にしながらも、新しいユーザーを取り込んでいくマーケティング施策とか。
新規ユーザーとヘビーユーザーと分けて定義しているんですが、それぞれに効果的に効く案件を地道にやってきたのが、ここ2年間かなと思っていて。その結果が今の乗車数とか、ユーザー数につながってくるかなとは思っていますね。
なので、先ほどのお話にもありましたが、セグメントを分けて、それに対してちゃんと課題解決のような案件や改善をここ2年間でやったことの結果として、ユーザー規模が増えてきたかなというのは実感として持っています。
向井：カウシェさん側はいかがですか？ これからどんどん成長していくと思っていますが、今の時点で引いているロードマップとか、そういったところの考えはどうでしょうか？
近藤：そうですね。スタートアップだと、理想的にはアクティベーションとか継続率みたいな。海賊指標、AARRR（Acquisition、Activation、Retention、Referral、Revenue）指標でバケツの穴をふさぐようなことをまずやって、そこからグロース（する）のがセオリーとしては正しいとは思うんですけれど。
カウシェの場合、ある機能を提供した時に、爆発的に想定外に伸びたようなケースがあって。カウシェで友だち招待の機能とかを提供した時に、数値がすごく想定外、予想していたより伸びてしまって、その急拡大にプロダクトとして逆に追いつかないといけないような事態になったりして。
ロードマップというよりは帳尻合わせで、プロダクトの提供価値を拡大だけに集中せず、バランスを取って施策を講じて取り組んでいく。そんなみたいなところを、今はやっていっている感じですね。
なので、事業として成長を止めずに、なおかつプロダクトの提供価値の検証を進めるみたいなところがあって。そこのバランスがけっこう難しいなと思いながら今進めているところです。
向井：ありがとうございます。
原田：あともう1個質問を。
向井：いっちゃいますか。じゃあそちらに触れましょう。
原田：いいでしょうか？
向井：はい。お願いします。
原田：ありがとうございます。
プレモーテムにおいて、事前の想定はどこまで立てておくべきか？
原田：たくさん質問をいただきました。「途中にあったプレモーテムの話で、何が原因だったかによって対応策が変わると思います。ただ、原因が何だったかを解明するのってすごく難しいんじゃないかと思いますが、どこまで事前に想定を立てていますか？」
向井：じゃあこれは、近藤さん。お願いします。
近藤：そうですね。お話のとおり、すべてのケースを洗い出して対策を講じるのは工数的にも膨大になりますし、無理だと思うんですね。
検証したいことに対して、どういったものを計測していくかはあらかじめわかると思うので、そこで悪化し得る指標に対して、想定されるメジャーなリスクを数ケース洗い出しておくのが1つの手法かなと思っています。
あと、さまざまなケースが発生すると思いますが、そこに対してアプローチできるように、設計・仕様とか。疎結合とかをシンプルに保つように設計の段階でしていくのが重要かなと思っています。
そこで密結合とか、複雑な仕様とか設計・実装になっていると、不測の事態が発生した時に修正できないことが容易に発生するので。そこをあらかじめ想定して、きれいな仕様、きれいな設計を意識していると、想定外のケースが発生しても、ある程度は対応できるのかなと思っています。
向井：ありがとうございます。というわけで、たくさんの質問をありがとうございます。すでに終了予定時刻を少し押してしまっているので、ここで締めたいと思います。
