プロダクトを「小さく作る」とはどういうことか
私がプロダクトマネージャーとしてコネヒトで学んだことの中に「小さく作る」という考え方があります。
コネヒトでは、チームに要求を伝えた後に「どうやったら小さく作れるだろう？」という会話が飛び交うことが多々あります。
今回は「小さく作る」について、向き合ってみたいと思います。
なぜ小さく作る必要があるのか
なぜ小さく作る必要があるのか、それは「ムダなものをつくらない」ためだと思っています。
私が大事にしている「ユーザーインタビュー」も同じ目的で実施しています。
ユーザーインタビューについての記事はこちらです。
作ろうとしているサービスや機能は、本当に顧客に求められるものなのか分かりません。
だからまずは小さく作ることで「ムダなものをつくる」リスクを抑える必要があります。
最初から100点満点を目指して、人的・金銭的なコストをかけて大きなプロダクトを作ったとしても、そもそも顧客に求められているものでなければ、そのコストはすべて無駄になってしまいます。
そのリスクを最小限に抑えるために、
小さく作る
それにより、早く顧客に試してもらえる
それにより、早く学べる
それにより、次に活かせる
ということが大事になります。
このように小さく作るものは「MVP」と呼ばれますね。
そんなMVPについて有名な図と、その図のわかりやすい解説を引用します。
絵の上段は、タイヤから始まり、タイヤをつないだシャーシ、ボディのみ、最後に車のていを成しています。4段階目に至るまで、顧客を模した顔はしかめっ面になっていますね。提供されたモノに満足できていないということです。それはそうでしょう。タイヤやボディだけあっても、用を成しえませんよね。
一方、絵の下段はどうでしょうか。最初は、車輪がついたボードのようですね。それから、ハンドルがついて、自転車、オートバイク、最後にオープンカーへと変遷しています。顧客は最初こそ、への字ですがだんだんと笑顔になっています。上段と下段の違いが何か分かるでしょうか。
上段は、最後の段階に至るまで、利用ができるモノになっていません。下段は、最初から（満足はできないものの）移動を支援する手段として一応成立しています。すなわち、評価判断ができるということです。提供されたものへのフィードバックを返せるわけです。作り手は、そのフィードバックを元に何が必要なのか探索を続けていくことができます。最終的にオープンカーにたどり着いているのをみると、顧客は単に移動をラクにする手段ではなく、外の空気が存分に楽しめる、快適さをあわせ求めていたのだということが想像できます。こうした価値は最初から常に言語化できるわけではなく、利用体験を踏まえることで何を必要としているのか、顧客自身が理解し判断できるようになると言えます。
「小さく作る（MVP）」の様々な種類
「小さく作る」にも様々な方法があります。
引用①「プロフェッショナルプロダクトオーナー」におけるMVPの種類
「プロフェッショナルプロダクトオーナー」では以下の4つの種類が紹介されていました。
①マイニング型MVP
②ランディングページ型MVP
③オズの魔法使い型MVP
④シングルフィーチャー型MVP
マイニング型MVPとは、「調査や概念実証、潜在的な市場に関するデータを収集してビジネスモデルを検証するもの」と書かれていました。つまりはアンケートなどの類を指しています。
ランディングページ型MVPは、その名の通り、プロダクトの価値を説明するLPを作って検証することですね。
オズの魔法使い型MVPとは、顧客には一見完成しているように見えて、裏側では人力で作業を行うという検証です。
シングルフィーチャー型MVPは、小さな機能でリリースすることです。
引用②ニジボックスにおけるMVPの種類
もう一つMVPの種類について引用します。
ニジボックスではMVPを6種類に分類して、社内呼称を定義し、状況に応じて使い分けているそうです。
これらを読んで思ったのは、「マイニング型やモックアップなどをMVPを捉えるかどうかは、人によって解釈が異なりそうだな」ということです。
だから、社内で定義をするのは「MVP」が下手に一人歩きしたり認識齟齬が起きたりするのを防げるのでとても良いなと思います。
私の場合
私がママリのプロダクト開発において「小さく作る」を選択する際の方法はいくつかありましたが、例えば以下のような方法を取ることが多かったです。
フィーチャーを絞る：粗々でもまずは「一番検証したいポイント」を定義し、そこに絞った状態で開発・リリースする
既存の座組を活用する：そのために作られた座組ではなくても、ちょっと表側のUIをいじると意外と成立するような既存の座組がないかを探し、最小工数で開発・リリースする（座組によっては開発せずにリリースする）
外部サービスを活用する：KARTEを活用し開発をせずにコンテンツを表示させたり、 FirebaseのRemote Configに一時的にデータを持たせることで最初からデータベースを構築しないような開発を採用したりする
プロトタイプを活用する：Figmaのプロトタイプをできるだけ本番の動きに近いような形で作成し、ユーザーに触ってみてもらう
組織でどうやって「小さく作る」を実現しているか
「小さく作る」はもちろん私一人では実現できないというか、むしろ開発者が主体となって実現していくことが多いので、チームで「小さく作る」を実現するために以下のようなことを行なっています。
・「要件」ではなく「要求」を話す：ガチガチに要件を決めずに、「誰に対し、なぜ、どんな価値を提供したいのか」を話します。
・ユーザーストーリーマッピングを活用する：上記の実現方法を開発者とディスカッションして決めるために、Miroでユーザーストーリーマッピングを描いて議論します。
・時には「えいや」でやっちゃう：時間をかけて小さく作るのでは意味がありません。時には許可より謝罪精神で、「これ開発せずに出してみちゃいました」なんてこともありますが、都度やったことと結果はチームには共有しています。
「小さく作る」の勘違いと罠
「小さく作る」を実行していく中で、さまざまな勘違いや罠も存在していると感じたので、それについても記していきます。
（なお、半分くらいは自分へのブーメランです。）
勘違い①工数を減らすのが目的
いちばんの目的は「ムダなものを作るのを避ける」です。
そのための手段として「工数を減らし、顧客への価値提供スピードを早め、学習したい」という考え方になります。
逆に、「確実に必要とされている」とわかっている機能やサービスには、工数を削減することにフォーカスする必要はないと思っています。
勘違い②小さいものを小さく作る
ちょっと混乱を生みそうな表現をしてしまいましたが、「小さいものを小さく作るのではなく、大きいものを小さく作る」のが大事だと思っています。
ここでの「小さいもの」というのは、価値やリスクが小さいもののことを指しています。
「価値は大きいと思っているが、その分理想形を作ろうとすると工数もかかるしリスクも大きい」ようなものを「小さく作る」からこそ、小さく作る価値があります。
勘違い③最初から小さく作る方法を考えないといけない
小さく作る方法は、企画者だけで考えるのではなく、みんなで考えます。
「こんな工数のかかりそうなことを言い出したら開発者は困ってしまうかもしれない…」と思うこともあると思います（私もあります）。
でも最初は理想からで良くて、小さく作る方法はむしろ開発者が腕をまくって考えてくれるはずです。
大切なのはHOWを固めることではなく、WHYをブラさずにできるだけシンプルにすることです。
やりたい理由が冗長で、検証したいことも盛りだくさんあって優先順位がつけられていないと、小さく作ることは難しくなります。
罠①小さく作ることが目的化する
小さく作ることはあくまで顧客価値最大化の手段です。
先ほども書いたように、「確実に必要とされている」とわかっている機能やサービスは最初から大きく作ってもいいかもしれませんし、UIリニューアルのような、「大きな変化」自体に検証したいポイントがある場合は大きく作る、という手段もあって良いのかなと思っています。
罠②小さく作った後のプランが曖昧
小さく作って、検証したいことが検証できた後にどうするのか、を明確にしておかないと以下のようなシナリオが起こり得ます。
なんかうまくいかなかったから、撤退する（本当はもっと別のHOWを試したら当たったかもしれないのに・・・）
なんかうまくいったから、小さく作ったまま残す（本当はもっと理想の形があったのに・・・）
小さく作る場合は、その後のことをリアルにシナリオ立てることが大事です。
小さく作って、顧客価値を最大化しよう
不確実性が高い事業運営、特にスタートアップにおいて、この考え方はエンジニアリングに閉じるものではなくあらゆる部署や職種で活かせるのではないか、と思っています。
大きいものを小さく作って、どんどん市場に投入して、結果的に顧客価値を最大化する。
私自身も、改めて意識しながらプロダクト開発していきたいなと思います！
この記事が気に入ったらサポートをしてみませんか？