"ミニマム"ってどこまで？BtoB SaaSのMVPをつくる中で学んだこと

こんにちは、建設×ITのスタートアップ「SHELFY」でプロダクトマネージャー（以下:PdM）をしているShoko（@shokosuzuki1991）です。

突然ですが、MVPとかリーンスタートアップについてのフレームワークやノウハウは溢れていますが、実際にMVP作ってるとこんな疑問が湧いてきませんか？

① プロトタイプと何が違うのか？プロトタイプ＋会員登録機能＝MVP？
②実用最小限機能ってどこまで？コア機能をどうやって定義するか？
③MVPをリリースした後、何をどう判断すればいいのか？

さらには事例があっても、BtoCのサービスや米国のものが多く、BtoB向けのプロダクトをつくるうえではあまり参考にならないな、、という経験はありませんか？（私がそうでしたw）

そこで今回は建設業向けのカンタン書類作成サービス『Greenfile.work（以下：GF）』のMVPができるまでを通して、私が学んだことをまとめてみました。

GFはリリース後1年で1000社に利用いただいたBtoBサービスなのですが、個人的には「ああしとけばよかった」という反省の嵐でした...そのあたりが今後BtoBのプロダクト開発に取り組む方の参考になれば幸いです！

※前提知識を書籍等である程度のプロダクト開発の基礎知識を入れた方が、実践編的な位置付けで読んでもらうことを想定しています。
（まだ基礎知識が充分にない！という方はPMにオススメの書籍をまとめたこちらの記事をどうぞ ）

①プロトタイプとMVPは何が違うのか？プロトタイプ＋会員登録機能＝MVP？

■MVPとは👉
「百聞は一見に如かず」ということで、まずはMVPが何たるかが最も分かりやすい画像を。
（参照元：https://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp）

自動車で移動したい！というユーザーに向けて、前輪→後輪→車体...と作ってもうまくいかないよ、まずは「移動」というイシューを解決するために小さくリリースできるものをつくって改良していこうぜ、というのがMVPの基本的な概念です。

■プロトタイプとは👉
次は「プロトタイプとは？」について。
例えば、あなたが上記の「新たな移動手段をつくる」プロジェクトのPdMだとすると、プロトタイプとは下記①②の検証のために、最小コストでつくったスケートボードを指します。

つまりプロトタイプ＝ユーザーにぶつけてフィードバックを得るためのものであり、この時点でのスケートボードは素早く学習するための手段です。

ちなみにGFのプロトタイピングでは、Prottで画面遷移をつくり、10人ちょっとのユーザーの協力を経て①②の検証を行いました。（ユーザーインタビューの目的や効果についてはこちらの記事をどうぞ）

■プロトタイプとMVPは何が違うのか❓
そこである程度仮説が実証されれば、ここではじめてスケートボードを製品化＝MVPとしてリリースしようとなるわけですが、プロトタイプと一番の違いが「不可逆性（一度決断したら戻れないこと）」です。

検証サイクルを早く回すために作って壊すことを前提にしているプロトタイプに対し、製品として以降も運用していくMVPは「一度決断したらもどれないこと≒不可逆性が高いこと」が一定数発生します。

例えば、お金のとり方などビジネスモデルの根幹に関わるところはもちろんですが、開発面ではデータベースの構造やユーザーの行動データのとりかた、スケールすることを見越した設計など。開発以外でも、サービスのコンセプトや温度感などもリリース後に変更するのは容易ではありません。（これはたとえアジャイルであっても同じです）

プロトタイプとしてのスケートボードは「ユーザーが乗って検証できればOK」でしたが、MVPは"将来自動車になることを見越した"スケートボードでなくてはならないということです。

この「初期で失敗する（考慮していない）と後戻りできないことを決めきる」のがMVP作成時のPdMの勝負ポイントになります。

■実際の経験談：不可逆性を考慮した判断の先送り...
幸いGFのMVP開発においては、新規開発の経験豊富なエンジニアが入ってくれていたのもあって、

・その後の拡大を見越したデータの持ち方
└書類作成に必要なものとサービス運営に必要な情報の分け方
└個人名はふりがなも必要か？
└セレクト、自由記述、サジェストの入力方式の使い分け

・事業上重要な数字を取得する仕組み
└ユーザー登録数
└"アクティブ"ユーザーの定義とその数の取得
└作成された書類の数と種類別の内訳

といった不可逆性の高い事柄は熟考のうえ、その後の運用に耐えうるものができました。

一方で、逆に「不可逆性が低いものは意図的に判断を先送りする」ことが私は絶望的に下手くそでした...orz  「テンプレート以外の書類が必要なユーザーがいたらどうする？」「情報入力のUIは本当にこれがベストなのか？」といった、"今決めなくていいこと"の議論に結構時間をつかってしまったという後悔があります。

「物事が決まっていない」状態というのは人間にとって不快なので、ついつい全てを決めなくては...！というモードになってしまうのです。

実用最小限の製品である"スケボー"に会員登録機能や管理画面などをつければMVP、というのあながち間違いではないのですが、この「不可逆性」への配慮が落とし穴かなと。

ということで、MVPつくるときの合言葉は「一度決めたら戻れないことは何か？」と「今決める必要あるか？」です！
PdMは不可逆性の高い判断に脳みそのキャパを割いていきましょう( ･`ω･´)

②実用最小限機能ってどこまで？コア機能をどうやって定義するか？

■早すぎた or やりすぎたの罠⚡
機能の充実と迅速なリリースはいつもトレードオフです。そのためにはPdMは義務としてプロダクトおよびチームが、
・「早すぎた」：ユーザーが価値を感じるには機能が足りない
・「やりすぎた」：オーバーな開発により使われない機能が存在
の"2つの罠"に落ちないようバランスをとることを求められます。
（下記は「移動」という課題に対しての早すぎた＆やりすぎたの図）

「早く出すこと」の重要性は言わずもがなだと思うので、PdMは”実用最小限の機能”とは、を考えるわけですが、ここでぶつかるのが”Viable"の定義範囲広すぎ問題です。

■Viableってどこまで❓
"Viable"＝「実行可能である、実用に耐えうる」という意味ですが、どうとでも解釈できると思いませんか？笑
私的に『Viable』という言葉には、下記5段階くらいが含まれていると感じます...

そして厄介なことに①〜⑤のどの段階でリリースすべきかは、事業特性によって異なるので絶対解がありません。既に先行している製品があるのであれば、③に達することは必須だったり、金融業界向けであれば厳しいセキュリティ要件が課されるので②のハードルがめちゃくちゃ高かったり...といった具合です。

■実際の経験談：どうやってコア機能を決めたのか
GFの開発初期においては、

・建設業に関する書類をかんたんにつくれる
・その中でも作成頻度が高い書類から着手する

というところまではスッと決まったのですが、

A：ユーザーが使える
＝まずはマスター管理なしで、1種類の書類だけがつくれるもの
B：既存手段と代替できる
＝書類を横断する情報をマスターとして管理する機能つきのもの

のどちらまでをMVPとするのかは、なかなか結論が出ませんでした(´・ω・`)

そこで私がとった手法が「方針を結論としてチームに共有し、メンバーの反応をみる」というものです。

まずはどちらかの選択肢にポジションをとったうえで、それを結論としてチームメンバーに話し、スッと浸透するか、そうでないか、を見るのですが、なんか違和感のある議論になるときは間違っていることが多いのですｗ

ちなみに違和感のある議論とは

・「それそんなに重要？」と聞きたくなるような枝葉の質問が多くでる
・不安気、訝しげな表情のメンバーがいる
・そもそも議論の場の空気が暗い、どよーんとしている

あたりが特徴で、逆にスッと浸透するときというのは、それぞれのメンバーの頭の中に成功イメージが湧き上がっていて、アクションまで自然に落ちる、という状態なのだと思います。「自分も同じこと思っていた！」「分かってました」くらいの反応が来れば最高かと。

GFの場合は「A：まずはマスター管理なしで、1種類の書類だけがつくれるものでいく」という方針を伝えたときにスッと浸透したので、まずは1書類だけにフォーカスをしてリリースしました。

結果的、書類1種類だけでも使ってくれるユーザーが一定数おり、そこから得たフィードバックを活用して、次のマスター管理機能をつくれたので、不確実性を下げることができたと感じています。

③MVPをリリースした後、何をどう判断すればいいのか？

■"MVPがほしい"と思っているユーザーはいない❌
有名な検証方法は「あなたはこのプロダクトを友人に薦めますか？」という質問に対して0から10の値で回答を求め、その数値によって刺さっているかを測るというNPS（ネットプロモータースコア）ですが、やってみて私的にはあまり意味がないと感じましたｗ

なぜなら「MVPが欲しいと思っているユーザーはいない」からです。
MVPの検証＝自動車で移動したいと思っている人にスケートボードを渡して「これでも今よりは早く移動できませんか？」ということであり、自動車がほしいと思っていたユーザーからすれば物足りないのは当たり前ですｗ

よってMVPに対してはNPSスコアが低かったり、マイナスの反応がくるのは当たり前で、GFの初期リリースでも「他の書類も対応してないと使えない」「会社関の連携機能はないのか！」などポジティブかネガティブかで言えば、ネガティブなフィードバックの方が多かったです。笑

■成功ユーザーは広告塔になってくれるか？📺
だからといって「うまくいっていない」という判断をするのは時期尚早です。BtoBプロダクトの場合はとくに、判断軸は「成功ユーザーが生まれたか、そしてその人は広告塔になってくれるか」に尽きると思います。

成功ユーザーとは、実際の業務であなたのプロダクトを使い成功体験を積んだ人を指します。この人が広告塔になる／なってくれることに同意してくれるなら、次の段階（追加機能開発、ユーザー獲得のためのマーケティング施策など）に進む価値はあると思います。

逆にインタビューなどでポジティブなフィードバックが多数来ていても、実際の業務で使ったユーザーがいない、という状態は危険かと。

■実際の経験談：リリース時の反応

GFのMVPリリース時は前述した通りマイナスの反応も多かったですがｗ、ある職人さんが「これで作った書類を受注元に提出した」と言ってくれたこと、そして建設業界である程度知名度のあるコミュニティで「みんな絶対使ったほうがいいよ！」と広めてくれたことが継続判断の決め手になりました。

ちなみにBtoBの場合は、どの業界にもオピニオンリーダー的な存在がいるはずなので、その人たちを巻き込めるとその後のマーケティングがぐっと楽になって最高です。

まとめ

① プロトタイプと何が違うのか？プロトタイプ＋会員登録機能＝MVP？
👉MVPは「不可逆性」を考慮しなくてはならない点がプロトタイプと異なる
👉「一度決断したら戻れないもの」は議論を重ねて熟考し、「今判断しなくていいもの」は先送りする勇気を持とう

②実用最小限機能ってどこまで？コア機能をどうやって定義するか？
👉Viableの定義は5段階くらいある。レベル感は競合環境やユーザー特性次第
👉自社のプロダクトに必要なレベルの判断方法は色々あるが、「チームメンバーに話したときの反応」は重要指標になるかもよ

③MVPをリリースした後、何をどう判断すればいいのか？
👉大前提：MVPがほしい、と思っているユーザーはいない＝マイナスのフィードバックが来るのは当たり前。めげないで！
👉BtoBの場合、次の段階（がっつりマーケ）へ進む最低条件はマーケティングに協力してくれる成功者の有無。

おわりに

先日ポケモンGOのPMだった人とお話する機会を得たのですが、「どうやってリリースタイミング決めたんですか？機能ですか？外的要因ですか？」と聞いたら、「エンジニアの"世に出したい"モチベーションが臨界点に達したとき」という答えをもらって絶妙に腹落ちしました。

事実、リリースまでに実装したかった機能がいくつかあったそうなのですが、社内エンジニアが「もうこれ以上はユーザーの反応ないと不安！出したい！」となったタイミングでリリースしたとのこと。こういうMVPの決め方もあるのだな〜と勉強になりました。
（以降、ポケモンGOは世界的なブームとなったことも相まって、このとき入れたかった機能には1年以上着手できなかったそうです...）

＼Twitterやってます／