どうもこんにちは！
食べログが運営する名店の味のお取り寄せサイト「食べログモール」のシステム開発を担当している @sudomeg です。
システム開発工程ぜんぶやるマンです。
直近ではおせちを販売できるようにする対応を担当しました！
はじめに
MVPって聞いたことありますか？
Minimum Viable Product（実用最小限の製品）の略で「ムダを省き、いかに失敗のダメージを減らすか」という手法のことです。
「ムダ」は「ユーザーが望んでいないこと」で
「失敗のダメージ」は「ユーザーが望んでいないものを作っちゃった」ことです。
ユーザーが望んでいそうだからとリッチに作り込んでリリースしたものの、結局ほとんどの機能が使われなかったら、失敗のダメージが大きいですね。
ユーザーが望んでいそうなもののうち、まずはひとつ小さく作ってリリースしてみよう。これなら使われなかったとしても失敗のダメージが小さく済みます。
そしてもし使ってもらえたなら「それならこれも望んでいるかな？」とまたひとつ小さく追加してリリースする。これを繰り返すことで、
ユーザーが望んでそうなものを失敗のダメージを小さく抑えながら作っていくことができる。
という手法なんです。
ただ小さく作るのではダメ
MVPは、ただ小さく作ってリリースすることを繰り返せばいいかというと、そうではありません。
例えば、
・小さく作りすぎて単体では機能しないもの
・単体で機能するものであっても、ユーザーにデメリットが生じてしまうもの
はユーザーにとって実用的ではありません。
それに作り手側にしてみても
・使えない機能だったからなのか需要がなかったから使わなかったのか、ユーザーの反応を区別できない
・大切なユーザーにご迷惑をお掛けしてしまう
など、いいことがないからです。
ですので、作るものはあくまでも、実用的な最小限でなくてはならないのです。
しかし、困りました。
この実用最小限を見つけるのが難しい......
どうやって見つければいいのかわからないから余計に難しい......！
せめてこの難しさを軽くできればと
おせち案件を通して気づいた、実用最小限の見つけ方のポイントをいくつか紹介します。
実用最小限の見つけ方のポイント
「誰に」とって「役に立つ」かを考えて実用性を確認する
役に立つとは、それを使った結果、ある目的を達成するのに良い効果をもたらすことです。
たとえ目的を達成できても、その効果を帳消しにするほどの悪い効果ももたらすものは、役に立っていないということです。
例えば、提供した機能を使ってもらう際に、手間は必ず発生します。
手間が掛かっても使って頂けるのは、手間よりも目的を達成できる効果が大きいからです。
ですので、サービスや製品を作るときに
・「何のために？」「なぜ？」それをしたいのだろう？と考えて「目的を明確にする」こと
・達成に足りないものを補う手段はなんだろう？と考えた手段で「目的を達成できる」こと
・その手段が及ぼす良い影響と悪い影響はなんだろう？と考えて「良い効果と悪い効果のバランスが取れている」こと
これらを全て満たしているよね、だから役に立つよね。という確認が大切です。
ちゃんとみんなの役に立っていることも大切なポイント
誰かにとっては良い効果があっても、別の誰かには悪い効果をもたらしてしまったら、みんなの役には立てていないですよね。
もしみんなの役に立てていない機能が提供されてしまったら、その機能が修正されるまでずっと一部の人に負担がかかり続けてしまうこともありえます。
例えば、食べログモールには「お料理を購入するユーザー」と「お料理を出品するお店の方」がいます。
ユーザーの役に立つと考えて、購入時に「お届け希望日時を指定できる機能」を追加したとします。
ユーザーが到着希望日時を指定できるようになるということは、当然ながら、お店のほうで発送タイミングを調整しなければなりません。その発送タイミングが、お店のオペレーションとして対応できない範囲であれば、到着希望日時通りに届けることができず、お店の方にもユーザーにもご迷惑をかけてしまうことになります。
このように、誰かの役に立てていないことがあるなら、みんなの実用性を満たせているとは言えません。
機能を提供したことで誰かの負担にならないように、ちゃんとみんなの役に立っていることも大切です。
いま必要ではないものを見つけて削っていくことで
最小限が見えてくる
「そもそも、これなぜいまやりたいんだっけ？」ならいつもやっているよという方がほとんどでしょう。
ポイントは意識していろいろと疑ってみることです。
というのも、意識しないと、疑う対象が実は偏っていることがあるからです。
例えば、いつものことだから当然だと思っていることを、わざわざ疑ったりしませんよね。
知らないことについて、そのことに詳しい人から言われたことは疑ったりせず素直に受け入れることありませんか。
このように疑いもしなかったことや、そうあるはずだという思い込みの中に、見逃していた、いま必要でないものが隠れていることがあります。
食べログモールで「おせちを販売できるようにする」案件は当初、
「お届け希望日時を指定できる機能」をまず作り、それを拡張して「おせちを販売できる」ように対応して欲しい。
という2つの目的が企画からの要望でした。
「お届け希望日時を指定できる機能」は前に出てきた事例のように、みんなの実用性を満たせる形を見つけることが難しく、
これはもっと検討が必要だと気がついた時にはもう8月に差し掛かっていました。
おせちの販売開始は11月1日なので、それまでの残り2ヶ月半で
「お届け希望日時を指定できる機能」と「おせちを販売できるようにする」対応をしなくてはなりません。
間に合わないかもしれない、どうしようと考えたそのとき
そもそも、11月1日までに必ずやりたいのは「おせちを販売できるようにする」ことだけだと気づきました。
いつも企画の方が要件を決めてくださるので、そこに疑いを持つことがなく、どちらもやらなくてはならないと思い込んでいたのです。
そこから「お届け希望日時を指定できる機能」の対応は延期させてもらえることになり
「おせちを販売できるようにする」対応を、無事に期日を守ってリリースすることができました。
このように、ふだん疑わないことも意識して疑ってみることで
まだ気づいていなかった、いま必要ではないものを見つけられる可能性を広げることができます。
利用者に直に確認できるならその機会を最大限に活用する
情報を集めて考え抜いても、根拠が十分でないと
これで本当に役に立てるのか、ここまで削ってしまって本当に大丈夫か、などの判断に迷いますよね。
短時間で実用最小限の姿をより鮮明にできるので
利用者に直に確認できるなら活用しない手はありません。
実際に、直に確認できてよかった事例を紹介します。
「お届け希望日時を指定できる機能」の開発自体は延期になりましたが
「おせちだけでもお届け希望日を指定して購入できるようにしたい」という要望がありました。
ただ、お届け希望日を指定できる機能をおせち購入限定で簡易的に作ろうとすると
どうしても実用性に不安が出てきてしまうので頭を悩ませていました。
例えば簡易的に作ると、在庫をお届け日によらずまとめて管理することになるので、お店の方は各日50台ずつのつもりで100台に設定したとします。
もし想定から大きく外れて、お届け希望日が極端に偏って注文が入ってしまったら……
お店の方は、分けて準備するつもりだったおせちをほぼまとめて準備しなくてはならなくなり困ってしまうのではないか……
このような不安要素が他にもいくつも出てきました。
お届け日が1日だけならこれらの不安要素はぜんぶ無くなるんだけどなあ……困ったので疑ってみました。そして、そもそも、おせちのお届け日を選べる必要があったんだっけ？ということに気づきました。
必ず必要なことは、ユーザーとお店の方の間でおせちがいつ届くかという認識が合わせられること。
もしそうなら、お届け希望日を選べる必要はないかもしれない！
そこで、昨年おせちを販売していたECサイトを調査しました。
なんと5サイト中4サイトがお届け日が1日固定で時間帯も指定できないことがわかりました。
おせちの通販は、お届け日が決められていることが一般的で、購入者もその認識である可能性がかなり高そうです。
それでも、お届け日を決めて販売する方法にした場合に
我々が想像できていないところで、お店の方の実用性を損ねてしまわないかが心配です。
そこで企画と営業の方にご協力頂いて、おせちを出品してくださるお店の方から意見をうかがうことにしました。
幸いどのお店からも、差し支えないですと仰って頂けまして、
今年のおせちはお届け日を決めて販売できることになりました。
このように、利用者の意見を直に確認することで実用最小限の姿をより鮮明にすることができます。
それだけでなく、お客さまの声を聞くと、このサービスを提供することが必ずお客さまの役に立つのだと確信が持てます。
すると、お客さまの声を聞く前より、ずっとずっと開発が楽しくなります。
まとめ
- MVPは、失敗を少なく抑えて作っていくことができる手法のことです
- 小さく作って、ユーザーが望んでいないものを作っちゃったという失敗を少なく抑えましょう
- ただ小さくではなく、ユーザーにメリットがあり機能する最も小さい単位「実用最小限」で作りましょう
- 「実用最小限の製品（Minimum Viable Product）」開発を繰り返していきましょう
-
「誰に」とって「役に立つ」かを考えて、実用性を確認しましょう
- 目的を明確にして、目的を達成でき良い効果と悪い効果のバランスが取れている策を考えましょう
- 「みんなの役に立つ」ことをしっかりと確認し、機能を提供したことで誰かの負担にならないようにしましょう
-
いま必要ではないものが含まれていないか探して、最小限を見つけましょう
- これまで疑いもしなかったことや、そうあるはずだという思い込んでいたことを、特に疑って探してみましょう
- 「なぜ？」「そもそも…」「いま」「本当に？」を使って探してみましょう
-
実用最小限の姿をより鮮明にしましょう
- 利用者に直に教えてもらえるなら、その機会を最大限に活用しましょう
おわりに
あまり考えずに望まれていないものを作ってしまう。これって楽なんですよね。
調べて考え抜いて本当に望まれているものを作るのは楽でないし難しいです。
それでも頑張って、みんなにとっての価値を見つけて実現したその先は、笑顔で満ち溢れていると信じてやみません。
本記事をお読み頂きありがとうございました。
少しでもより良い開発のご参考になりましたら幸いです。
12/16に公開予定の @k-sekido さんによる「振り返りによるチーム作りの実践」もお読み頂くと、よりユーザーに価値を感じてもらえる成果をチームでもっと出していけるようになると思います！ぜひご覧ください〜！
それでは美味しいおせちで良いお年をお迎えください (･-･*) ﾍﾟｺﾘ