突発的な変動(Volatility)が多く、不確実(Uncertainty)で、複雑(Complexity)かつ曖昧(Ambiguity)なVUCAの時代において、開発現場でも臨機応変な対応を求められる機会が多くなったのではないでしょうか。
本セミナーでは、UXデザインコンサルティングにおいて知見のあるニジボックスの、テクノロジーソリューション室 室長である藤原 裕司 氏より、開発現場におけるMVP(Minimum Viable Product)の考え方と実現させるための事例を紹介頂きます。

セミナー動画&内容


登壇者紹介

藤原 裕司 氏

藤原 裕司 氏
株式会社ニジボックス
テクノロジーソリューション室 室長

SIer出身のWEB系エンジニア。株式会社リクルートが主催する日本最大級の開発コンテスト「Mashup Awards」での入賞を機に、SIerからリクルートに転職。
RHD(リクルートホールディングス)の新規事業開発を目的とする、MTL(Media Technology Lab)「現:次世代事業開発室」でMVP開発とLEANUXによる高速プロトタイピングを多数実施。
TypeScript、高速プロトタイピングを得意とし、MVP開発+高速PDCAサイクルを中心としたプロダクト、サービス成長支援に従事。
2013年よりエンジニア組織のマネジメントに携わり、プレイングマネージャとしてニジボックスに在職中。


はじめに

改めまして私、ニジボックスの藤原と申します。ニジボックスはリクルートの子会社でして、そこでエンジニアマネージャーを担当しております。

早速なのですが、ニジボックスという会社は基本Web系企業のようなところがあります。最近はUXに力を入れておりまして、ブログなどもかなりUXの記事を中心に書かせていただいてます。

UXフックでコンサルティングから携わらせていただき、その後のデザインであったり開発であったり、もちろん運用保守のところでグロースなども併せてお手伝いします。また人数がそこまで多い会社ではないのですが、職種も一通り揃っておりまして「一気通貫で対応できます」といったところがウリとなっております。

こちらは「IT人材白書2017」から引っ張ってきました。ピンクはいわゆるIT以外の企業、青がIT企業です。

ピンク、いわゆるITではない企業、普通のメーカーがデジタルで何かをしたいときというのは、IT企業に「受発注の関係で依頼してますよね」ということですね。ですので「内製化していないのでDXが進まないのですよ、日本ダメですね」といった図なのですが「日本は何が悪いんだ?と私としては思っていまして、受発注の関係が多いということであるので、そこをベースに今回を発表させていただきたいと思います。

今回の発表といたしましては基本的にはいわゆるベンダーに発注する立場の方に向けて、私も結構ガチのエンジニアなのですが「開発側はこんなことを思いながら、作っていたりします」ということをご理解いただくことを目的として作った資料です。

また、UXでコンサルティングで新規事業のようなところが我々の主戦場のようなところがありますので、そこが基本スコープになっております。

UXを掲げると開発領域で避けて通れないこと

開発領域で避けて通れないことが、この発表の名前にもなっておりましたMVPという単語です。「Minimum Viable Product (実用最小限の製品)」の略ですね。

右下は割と有名な図でして「MVPはこういう風に考えましょう」というものです。車というものを作りたいときに、上では「まずタイヤを1個作って、それをシャフトで繋げて、ボディを作って完成させましょう」ということになりますが、MVPの思想といたしましては「いやいや、そうではないんだよ」ということです。

まず最初にとりあえず一番簡単な仕組みで動くものを作りましょう。要するにこれはスケートボードのようなものですね。

そこに対して、
「少し安定性が悪いなぁ」
「少しだけでもいいから曲がりたいな」

と思った段階で手すりをつけます。

「もう少し楽に動かしたいな」という要望が出た段階で自転車を作ります。もっともっと楽をしたいということであれば、エンジンを搭載してバイクを作りましょう。さらに発展させてを作りましょう。

「プロセスを踏んで製品を成長させて行く方が良い結果につながりますよ」という思想です。このようなことは割と浸透している考え方かなと思います。

我々開発現場では一番最初のミーティングで幾度となくこのような会話をしています。最初から作り込むのではなく、柔軟に調整しながらアジャイルでスピード感を持って進めましょうといった形ですね。

ただそこからもう一段階話を進めてみると、

「で、いつまでにどんなものが納品されるの?」
「全部必須!最低限に絞り込んだものがこれだから!」と言われたり、

「動くものがないと伝わらないから、とりあえず適当にいい感じのものを作ってよ」
という割と無茶なオーダーが来てみたり、一生懸命作ったと思ったら「これじゃないんだよね、わかってないなぁ」などと言われて「ああ、悲しい」みたいなことですね。

そういったことが色々なエンドユーザー、クライアント担当者、あるいは組織の風通しが悪いところですと上長がまた違うことを言ってきたりですとか、またコンサルが突然出てきたりして、我々としては少し苦しいところがありますね。そこにおいて「こんなことをしています」という形の発表です。

 

ニジボックスの取り組みについて

礎となった「とある案件」についてですが、5,6年前に遡ります。

その前はニジボックスは実はIT企業と言いましても、いわゆるソーシャルゲームを開発している会社でした。そこで「eラーニングシステムにゲームを追加してくれないか」という依頼を受けたんですね。単純にゲームと言っても色々ありますので、当初困惑した気持ちはありました。

その案件をどのように進めていったかといえば、構想の段階で「どのようなことをすればユーザー側が喜ぶのか?」というモチベーションマップを作りました。ワイヤーフレームを書いて、画像を引っ張ってきて「メイン機能はこんな感じかな?」という打ち合わせをしていきました。

このソフトは小学生向けだったのですが、ゲームは世界観が大事ですのでどんなテイスト好まれるのか、そのときにはどうにも判断がつきませんでした。

ですので、異なるテイストのものを複数制作して小学生に実際にアンケートをとりました。

デザイナーや我々は実は左上のデザインが一番良いのではないかと思ったのですけども、実際の結果は左下の男の子と女の子のより中性的なものが一番人気になりまして、僕は結構衝撃を受けました。「小学生の気持ちを考えるのは難しいな」と思いました。

 

新しいものを作ることは不安と不明だらけ

eラーニングシステムの話に戻りますが、「タブレットがメインです」というところがありましたので、タブレットの大きな画角で軽快なアニメーションを動かす必要がありました。まだWebGLと言われるものがそこまで全盛ではありませんでしたので、割と思い切った選択なのですが、CSSだけでアニメーションを再現しようという風に方針を決めました。

その中で「これは本当に実装できるの?」という話になります。キャラクターがどんどん追加されていくのですが、例えばキャラクター追加するのに1人月とか2人月とか、コストが大きくかかったりしないか確認をするために、実際にアニメーションのみを実現するプロトタイプを開発するプロセスを踏みました。

開発が進んでいくと「色々機能を考えてきたけれども、本当に使うのか?」というところがありましたので、複数機能を開発して、いわゆるABテストですね。ユーザーごとに機能が絞り込まれている状態というものを実装しました。

ここで少しだけ面白かったのが、KPIがDAUや継続率ではなくて、eラーニングでゲーミフィケーションですので、いわゆる勉強をしてくれないと意味がないのですよね。ですので授業の視聴数について

「タイプA」
「タイプB」
「タイプC」
「タイプD」

でKPIとしてテストしてみました。ここでも我々としては少し驚きの結果でして、実はタイプBという少し機能の少ないものが選ばれました。

これは実はタイプAは勉強をしなくなってしまったんですね。面白かったんでしょうかね。僕らとしては「してやったりだ」というところもあったのですが「結局、勉強進んでないよな」といった話になりまして、結局タイプBが採用されました。

ここで落とされた機能も開発する際に非常に苦労を伴いましたので、悲しい気持ちになったのですが、数字として結果が出ているので、おとなしく閉じましょうという結論にはなりました。

少しまとめますと、基本的に「何か新しいものを作ろう」というときは、とにかく不安と不明だらけなのですね。それを一つずつ細かく「具現化」「検証」と書きましたが、本当に大丈夫かどうか確かめていったというだけなんですね。

「作ろうとしているものが、そもそも正しいのか?」というところでモチベーションマップで整理して「小学生に受けるテイストは何だろう?」といったアンケートも取りました。アニメーションに関しては、プロトタイプを作って確認したり、実際の効果を確かめる意味でリリースしたものを触ってもらいました。

ですので、何を誰向けに検証するか決めて1つだけ検証するというのは我々としては一番大事だなと思いました。最小化して、それだけを検証して、いわゆる検証コストというものをできるだけ小さくして、サイクルを何度も何度も回そう。これがベストとは言わないまでも、ベターな選択肢であろうという風に考えたわけですね。

その中でMVPという一般的な思考というものに親和性がありましたので、それとひも付けながら僕らの仕事のあり方を考えていきましょうという流れになっていきました。

 

MVPを取り入れる上で重要視する思想

我々は今こんな形でMVPについて取り組んでいます」というところで、

心得 其ノ一
「誰向けなのかを強く意識する」
としました。

アーリーアダプターという言葉が結構出てくるわけですが、製品はMVP、いわゆる小さな最小限の製品の時点で割と完成形に近づいており、だんだんと万人受けする機能を持つようにレベルが上がっていくものです。

ちなみにアーリーアダプターの前にイノベーターという新しいものに何でも飛びつく人がいます。「アーリーアダプターをメインストリームに色々な人が使ってくれる」そういった形で基本的にはここはセットで成長していくものです。そこで検証が必要なのですが、すごく重要なのは我々は「万人」なんですね。ですのでここでいうMVPとは少しズレます。ここが非常に厄介なところで難しいところだなと思っております。

いきなりおかしな文を出すのですが、

全国一般風ノ向キハ定リナシ
天気ハ変リ易シ但シ雨天勝チ

これは日本で最初の天気予報と言われるものです。

日本全国のその日の天気を2行で表したもので「はあ、そうなんですか」という感じなのですが、私がもしこれをある日聞いたとしましょう。

「はっきり言って、風の向きなんてよく分からないし、天気は変わりやすいよね。まぁ雨かもね」もう分からないって言っているのと一緒だと思うのですよね。その日の予定も全然立てられません。ですので、基本的にはこういう本当の最初の最初の一番ミニマムなものって、普通の人は良いか悪いか判断できないと思っているんです。ですので、先ほどの図に照らし合わせるとこういう風になってきます。

MVPというのは、この2行の天気予報ですね。その上にあるホールプロダクトが少し前までの天気予報です。一番上が最新の天気予報です。最近では「アメッシュ」があったりですとか、自分のスマートフォンで現在地の天気予報が時間ベースで分かって非常に便利です。

私の親も含まれるのですが、私より上の世代って割と天気予報を信頼していないんですね。中間の位置にあるホールプロダクトであっても「これは要らない」といったことを判断する人は結構多かったです。そんな中で我々は万人であるということを意識しながら、

「今誰向きに検証しているのか?」
「あくまでアーリーアダプター向けに検証しなければならない」

といったところを我々の心構えとして強く意識しています。

 

天秤をイメージし、「バランス維持」を心がける

心得 其ノ二
『Minimumなのか』を強く意識する

MVPのMはミニマムですので、それが本当にミニマムなのかということを強く意識するようにしています。従来型の開発というのは、いわゆるウォーターフォールかもしれませんが、開発を一気にドーン、リリースをドーンでした。そこでMVPという考えが生まれて、必要最小限の開発をしてリリースをしてエンハンスという形になっていくと思います。我々のMVPという概念はさらに細かく、

部分開発→検証→部分開発→検証→

という形で考えています。その中でこのような天秤が出てくるわけですね。

ABCと検証したい項目があってそれぞれ10日かかります。3作品作るXと、1作品にまとめるYですね。単純な比較ですと絶対に私でもYを取ります。ただこれはYに傾く重力が無駄に発生するんですね。

現場でよくあるケースなのですが、検証項目が実は複数だったとか検証項目が単一であっても曖昧であったり、広義すぎたり結局小さくできなくて、大きいことを検証しようとして、あまりミニマムでないものを作りがちです。

ですので、我々といたしましては常にXに向けるような反対の力を与えて「何とかこの坂を下り落ちるのを避けよう」というようなところに意識をしています。

なぜかというと、Zがあとで出てくるわけですね。

一番最初のMVPの図でいうと「いきなり車を作りましょう」といった話になりがちなんですが、そこまでやるのであれば工数が膨大にかかってきますので、検証する意味合いが薄くなってきます。ですので、Zに落ちていかないように、あくまで反対の効力を与えるわけです。

「それって本当に価値があるのですか?」とか、
「この程度で出す意味がないだろう」
とかいうところをすごく自分たちで判断しがちです。

「自分たちが判断できるわけがないのに」
というところが、一番最初に出てきた天気予報のような形ですね。
ですので「我々が勝手に判断する(できる)ことではない」と考えています。

 

「限りなくミニマムにしてから考え始める」という方法

例えばECサイトを作りたいという要望があったときに「いや、作らなくて乗っかりましょう」というのが至極正解な話だと思います。私なら絶対にそう言います。

それとは別に、MVPの考え方ということを説明するためだけにあえて例を出しますが、

・Googleフォームで注文受付
・その後はメールでやり取り
・決済はアナログで手動

このようなECサイトとは呼べないものを作ってしまうこともMVPの考え方としては全く悪くないと思っています。

この中でも検証できることってあるんですよ。例えばECサイトで売りたい商品に本当に引きがあるのか確かめるために「興味がありますか?」という聞き方でアンケートを取るだけではとても判断がつきません。

例えば「10万も20万もする高額な商品が、本当に売れるのか?」という場合にこの方式で確かめることはあるはずです。

「実際に作ってみて、売れるか売れないかの検証ができましたね?」
「今度はさらに売上を上げるためにはUIのどこを変えればいいでしょうか?」
「とはいえ運用が厳しいので、どこを自動化すると楽になるでしょうか」

その後のグロースの判断も非常にしやすくなったりします。ですので、自身の感覚にとらわれず「覆しすぎでしょ!」と思うようなところまで限りなくミニマムにしてから、考え始めるというところが我々としては重要なのかなと思います。

MVP分解定義

MVPで有名な事例、Dropboxの事例が非常に有名です。Dropboxが何をしたかというと、機能を全く作らずに「こういうサービスがあったら使いたい」というような動画だけを作ったのです。それで引きがあるのかどうか確かめたような話がありました。そこから実際に引きがあるというのが分かって、1stリリースまで物をどんどん作っていきます。

その中で様々なプロセスがありますし、世の中一般的にも色々な単語があります。ペーパープロト、ワイヤー。モック、プロトタイプあたりは会社ごとに定義が相当違うのではないかと思います。さらに違うのがα版、β版ですね。

沢山あるので色々なところから記事を引っ張ってきたり座学をした上ではあるのですが、

MVPをこのように6つのMVPフェーズと6つのプロトタイプという風に小さく分解して呼称定義しています。それぞれ1つ1つ細かく説明していきますね。

 

6つのMVPフェーズ

まずMVPフェーズの方ですが、どんどん下にいくほど作り込んでいく感じになります。

まずはPaper(ペーパー)です。紙というよりは実態がないものです。先ほどのDropboxの動画事例のようなLPサイトや動画だけ作って引きを確認するものです。

次がConcierge(コンシェルジュ)と言われているものです。インターネットとかで調べると別名が「オズの魔法使い」だったりするのですが、通常はシステムや自動で担保するのを、あくまで人力主導で乗り切る場合ですね。先ほどのECサイトの例も割とこのコンシェルジュと近いものを例としてあげました。実際にCSVで決済処理を手動管理ですとか、サービスで我々は実はあまり経験がないのですが、実サービスでは「裏では学生バイトがシフトで組んで手で返しています」といったチャットサービスがあったりするようです。

その次はCombination(コンビネーション)です。既に日本に存在するサービスの組み合わせ、開発なんて細かいことをせずにありもので作りましょうと言われているものですね。ただ、ここでいうと非常に使いづらいものになったりします。たとえ一緒に使いづらくてもメインで実現したいことが実現できているので「きっとアーリーアダプターは評価してくれるはずだ」という感じの思考です。使いづらさには目をつむるという風になっています。

繰り返しになりますが我々は万人ですので、つい使いづらさが目に入ってしまうんですよね。「もう少し変えた方がいいのではないですか?」という思考になりがちですが、使いづらいけどメインでやりたいことができるということを優先するという方式です。

次はOnly Visual(オンリービジュアル)としました。これはもう過去からずっと多発している、常に作られているものかなと思います。見た目だけでやるものですね。モックアップなどという表現もあるかなと思います。昨今ではAdobeのXDを活用することが非常に多くて、その時々によって利用目的というのはもっとデザイン、トンマナを確認するだけの場合もあれば、画面の項目をしっかりそこで定義しておいて「こんなIA設計をしましょう」といった部分まで持っていく場合もありまして、見た目だけとはいえ、非常に幅広いものになってきます。

次がPrototype(プロトタイプ)です。これは実際に動くものを開発しようというものです。Only VisualとPrototypeあたりが実際のプロトタイプと呼ばれる範囲なのですが、そこが幅広いので次のスライドでさらにプロトタイプとして分解しています。

最後のFinal(ファイナル)というのは「世に出してリリースしましょう」という部分ですが、ここで限定公開にするようなこともよく行う手法です。

 

6(+1)のプロトタイプ

次にプロトタイプの説明をします。

いきなりペーパー被りをしてしまうのですが、ペーパープロトという一般的な用語が非常に有名ですし、そこと対した差異がないのでペーパープロトのままで進めています。手書きで作るワイヤーフレームですね。ペーパープロトの前には基本的にホワイトボードを使うなどして概要を作っていきます。ただ、昨今ではこのケースがどんどん減っているというのが実情です。手書きをしてプロトを使ってリンクをして、というようなことです。

なので、いわゆる「こういったことを気をつけた方がいいですよ」というTipsも結構あったのですが、次のUIデザインプロトがAdobe XDが非常に便利でして、基本ペーパープロトを採用する理由は速さ優先なのですが、Abode XDの使い回し機能やコピー&ペースト機能が優秀すぎてペーパープロトの制作速度を超えるようになってしまったんですね。ですので、今はUIデザインプロトのようなところが中心になってきたりはします。ただ、アサインメンバーによってはAdobe XDを使い慣れてなかったこともあったりしますので、その場合にのみペーパープロトが復活するような形でやっています。

次にUIアニメプロトですね。Adobe XDでやろうと思えばできるのですが、アニメーションのようなところを実現するには少し厳しい面がありますので、そこは実際に開発に近い形でアニメーションのみ作りましょうというところだけをやるプロトタイプですね。

そこからもう少し組み立てていくのが、静的MODELプロトと書いていますが、これはいわゆるバックエンド、通信をゼロにして、フロントエンドだけで何ができるかといった思考で作るものです。やはりAdobe XDのプロトタイプのようなところがどんどんと侵食していくのはここまでも侵食しちゃって来てまして、いわゆる単純な画面遷移しか確認したくないという場合は昔は静的MODELプロトで作っていたのですが、今はAdobe XDで済ませることが多いですね。

次は技術検証プロトです。これは一番最初のeラーニングのゲームの話でもあったような、「本当にそれって実現可能なの?」といったものを検証するプロトタイプです。

次はデータフロープロトです。これは静的MODELプロトの真逆のような考え方が正しい

と思います。デザイン要素はまったく関係なく、ただバックエンドとしてデータを持たせてないと確認がすごくしづらいというケースです。よくあるのが承認システムのような形です。「申請を出したらここに一覧が出て、それがこう承認されると次にここに出るようになります」みたいな。そこの確認はバックエンドのみ実装した上でステータスを変化させながらやった方が早いです。そうしないと確認できない面がありますので、このようなものを作っています。そういったもので、割と見た目に目をつぶることが多いので割とBtoB向けの場合に活用することが多かったりします。

一番最初に6つのプロトタイプと言いましたが、(+1)となっていますね。これは私が資料を作りながら付け加えたものです。

ノーコードプロト。AppSheetとかMicrosoftのPower Appsなどが最近有名なのですが、いわゆるソースコードを全く書かずに世の中のサービスを実現しましょうというものです。実案件では我々としてはまだ未採用なのですが、領域が今からどんどん加速していくだろうという風に予想していますので、我々も今からふんだんに使っていきたいなと思っています。

 

MVP分解の留意点

このような分解をしているのですが、留意点としてはこのようなことがあります。

・すべてやるわけではありません。
・6個に分解したからといって6個全部やるわけではないです。
・案件特性において6個のうち2個だけやりましょう

というような話になります。

また先ほどのペーパープロトとUIデザインプロトの話でもありましたけれども「Adobe XDをメンバーは使い慣れてるんだっけ?」のようなところで、場合により「今回はこっちにしましょう」ということは十分にあります。また完全合致するものではないです。「なんとなくこういう定義はあるけど、UIアニメと静的モデルを合わせたようなプロトタイプにしましょう」ですとか「技術プロトタイプを2個作りましょう」という会話のための素材として使っています。

ここが一番言いたかったところですが、とりあえず動くα版のような所ですね。我々としましては認識齟齬を避ける意味や「それは本当にミニマムなのか」というセルフチェックのために使っています。

コンビネーションでやっていますが、そもそも「検証項目はこれです、それペーパーだけでできますよね?」といった確認ですとか、「コンシェルジュ、コンビネーションやや複雑なことをしようとしているけど、それは検証項目自体が間違ってませんか?」とか、そういう風にもっとミニマムにできるのではないかという、例えばXYZがあるとして「Xに寄せることは本当にできないのか?」という確認に使っています。

MVP分解事例集①「保育施設のマッチングサービス」

これだけではイメージがわかないかなと思いますので、このような形で実際やっていますという事例集です。

保育施設のマッチングサービス。このような案件があったのですが、基本的にはこの日預けたい子供を施設とマッチングするサービスでした。このサービスには予約機能が必要なのですが、実際にやっていることはGoogleカレンダーを共有するだけでした。

よく見ると、図の上と下にあるロゴが違うのですけど、検証のためだけに仮のサービス名で

とりあえず使っていただきました。そういったもののコンビネーションを採用して取り合わせたものを作り、

「集客の引きがあるのか」
「利用時間を見て、どの時間帯で多く利用されるのか」
などをチェックします。

あとは保育側が使ってくれるかどうかという話もあります。いわゆる重要顧客ではありませんが、サービスにとって必要不可欠な人材ですので、母集団をあらかじめ形成するという意味でも使えそうだというところがありました。

そういった上のものを実装していきながら、デザインはこういうものが良いのではない

かといったところでOnly Visualのところだけでデザインだけを確認していき、担当者間だけで「もう少しフレンドリーなものにしたいです」などといった調整をしながら、組み立てていき、最終的に予約機能を開発した上で実際のサービスとして利用できるものをリリースしたという流れです。

またこの予約機能を本実装した上で、リリースしたものは使えるエリアなどを限定した上で限定公開にかなり近い形でやっていきました。取捨選択というのはこういうことですね。6個あるうち今回は3個だけ選びました。

 

MVP分解事例集②「Wi-Fiスポット検索・接続アプリ」

これは訪日外国人向けのアプリの企画でして、日本に来た方に対して自動でそのスマホがwi-fiにフリースポットなどを検索してつなぎにいくアプリですね。

訪日外国人向けでしたので極力「日本語は使えません」「アイコンだけで表現しましょう」といった留意点がありました。そこをデザインをAdobe XDで確認して、XDプロトタイプで実際に外国の方に触っていただいたり、ちゃんと判断がつくかどうかを検証したりしました。

「自動接続ってできると思うけど本当に出来るの?」や、できたらできたで「バッテリーがグイグイ減ったりしないよね?」という確認をするために技術検証プロトを作った感じです。

 

MVP分解事例集③ 「オンライン獣医師診断Webサービス」

次がオンライン獣医師診断Webサービスですね。

ペットの獣医師の相談というところで、ちょっと空き時間のある獣医師に動画を送って診てもらうというWebサービスです。一番最初にLPを作って、事前ユーザ登録を行いました。

これにより、
「これを使いたい人が本当にいるのか?」
「どれくらいユーザーがいるのか?」
といった検証にもなりました。

また事前ユーザー登録をしてもらうことで、リリース直後のユーザー数の母集団が増えることとなり、プロダクトを運営していく上で資金繰りの面も含めて、今後ヒットしていくのではないかというプラス予想にもつながります。

事前登録だけですとユーザーは忘れてしまったりもしますので、メルマガ運用という形でどんどん記事を配信しました。これは「この件名のメールを送ると割とクリックされる」といったユーザーニーズの検証を更に深堀りするために役立ちました。

この件に関していうと「作りたいものがかなり明確なので、どんどん制作していきましょう」というところなのですが、プロトタイプは担当者間で作りたいものを相互に確認を取りながら行います。プロトタイプが形になった段階で、実際の獣医師さんにも触ってもらい「このサービスは回答しやすいですか?」という確認を最後に取りました。

最後に地方限定版をリリースしました。

見てわかると通り、ここのプロトタイプはやはり相当簡素なんですよね。そこをデザイン品開発でここまでリッチにしていったということです。ここは実はですね、最初いわゆるデザインを作って、そこからバックエンドを連携させていってといったところが一般的な流れだと思いますが、あえてデザインが最後になった例ですね。それは狙ったわけではなくて、アサインされたメンバーのスキル特性に寄ったというだけです。

 

MVP分解事例集④「MVP Paper」

こんなことも行なっていたりしてます。これはMVP Paperですね。

例えばApple Watchを使って「水泳中に便利で面白い体験ができるアプリが作れないか」という企画のときに、このような「ほめ上手アプリ」のアイデアを漫画チックにまとめまして、これを実際のターゲットの人に

「こういうものがあったら使ってみたいですか?」
「どんな機能が欲しいですか?」

という説明で使うものです。

漫画を使う方法は非常にストーリーがわかりやすいですし、LPを作って検証するよりも安価で行えます。

 

MVP分解事例集⑤「ペーパープロト」

これが最近どんどんなくなっているという話をしましたが、ペーパープロトタイプです。先ほどの水泳アプリを一旦作ってみましょうという場合に手で書いてみたわけですね。

技術検証プロトもこのタイミングでは作っていて、
「Apple Watchからどんな値が取れるんだっけ?」
と確認するためだけのアプリを作成したという感じですね。

ここで軽い留意事項としては、検証ごとに別リポジトリにしたりですとか、こちらの方が重要なのですが、エンジニアは割と作りたがる傾向がありまして、

「もう少しやりたい」
「もう少しリッチにしたい」などとよく思っています。

「もっと時間くれよ」と迫ってくるようなことがありますので「本当にやらなくていいからというマネジメントが実は重要だったりします。みんなやりたがりなんですよね。

 

MVP分解事例集⑥「UIアニメプロト+静的モデルプロト」

次はUIアニメプロト+静的モデルプロトの例ですが、ニジボックスは開発合宿をたまに行なっています。そこで1日で作ったものです。チャットUIにすることでユーザー負荷が軽減するかどうかの検証、確認ですね。

これは1日で作ったわけですが、別にスーパープログラマが作ったわけではなくてライブラリーを使ったら一瞬でできちゃった」ようなことが多いです。「開発現場において10人日のような普通の見立てのものが、実は2時間で終わるケースがあるのですよ。ある部分のこことここを犠牲にすれば」ということがあるので、それをエンジニアから提案したい場合によく使う手法です。

いわゆる入力項目、質問項目が非常に多くて、その後に「では、そういった暮らし方をしていると年金はこれくらいもらえます」というシミュレーションアプリです。

これは割と昔ながらの手法かもしれないですね。お客様にこれを持って行って、

「こんな形の画面にしますがどうでしょうか?」
「ここをもっと分かりやすくしてほしいな」

というようなやりとりをしていく形です。

それをさらに「もう少しグラフの動きを確認したいな」というようなところがあって、スライダーをいじると、アニメーションチックにグラフが変化します。これはライブラリで簡単にできますので、

「これくらいでよくないですか?」といった確認ですとか、
「この方式を使えば一瞬で終わります」

「ただ、円グラフが簡単には二重にできません」
というやりとりに使ったりしました。

 

まとめ①「誰のために検証するか」

最後にまとめです。

よくあるMVPへのイメージとギャップなんですけれども、MVPって「最初にパッと作ってリリースすること」と思っている方が非常に多いのですが、我々といたしましてはそれだけではなく、もっと広義なものだと捉えています。

リリースの必要はないですし、何なら作る必要もないと思います。またリリースというイメージがあるので、どうしてもMVPというのはBtoC向けであって、BtoBには向かないというイメージがあると思います。

ただ、その気持ちも分かるのですが、C向けとB向けで明らかに違うのは、検証項目と誰のために検証するかです。MVPのように「小さく範囲を狭めて確かめましょう」という概念はBtoBでもBtoCでも絶対に有効なものであると我々は信じています。

割と今までの話を思い浮かべてみると「似たようなことをやっていたな」と思う方は大分多いのではないかなと思います。ですので、Ajaxがバーっと出たときに古くて新しい技術ってやりましたけれども、私といたしましたらMVPもそういったところに近いものがあるなと感じています。

またMVP、さらにいうとアジャイルなのですが、やはり速いというイメージを持たれている方が非常に多いです。いわゆるウォーターフォールとよく比較されますが「無駄なことはしないようにしましょう」いう意味では、絶対に遅くないとは思いますが、そんなに速くもないと思っています。

 

まとめ②「変更にどう立ち向かうか」

この図なのですがウォーターフォールというのは弓矢のようなもので、ゴールに向かって一直線なのですね。

ただ、一直線した後失敗だったという、このような「正解を狙って的を射たら実は違う的に当てちゃった」ようなことがあると思っています。ですのでMVPというか、アジャイルのようなところは少しずつジグザグに進めながら「正解はどこだ?」という風にミサイル誘導弾のように方針を変えながら進めていくものかなと。こういうジグザグに行くことでやはりスピード感が出ない部分もあります。ただスピード感は出ないものの、結果的にゴールへたどり着けるのはこちらであるので、どちらかというと「急がば回れ」ですとか「石橋をたたいて渡る」ようなニュアンスが非常に強くて、総合的に見ると速度としてはやはりアジャイル、MVPの方が早いという結論になるのかなと思っています。

これらを実現するために必要なものですが、ジグザグに進行して何度も変更するのがMVPですので、基本「変更に対してどう立ち向かうか」が主題になってきます。

①変更に素早く追従できる技術力
②変更に寛容である資質・性格
③変更に寛容になれる状況

としましたが、③が最も重要だと思っています。

なぜなら①にある技術力のようなところでいうと、これは綺麗事ではあるのですが、当然初心者には太刀打ちできないですが、簡単なものを作るだけですので「そこまでスーパーエンジニアでなくても作れるはずだ」といった考えですね。

加えて性格的なところですと、確かにエンジニア界隈では「要求がー」とか「仕様変更がー」とかブツブツブツブツ文句をいうエンジニアは確かに多いです。その反面、企画から携わりたいという前向きなエンジニアも非常に人口として多くいます。割と上流から携わりたいエンジニアの方が多いかもしれませんね。ですので、世の中的に「技術者不足です」という意味でエンジニアを集めづらいですが、その中で更にレア層かと言われると、そこまででもないと思います。

そういう意味で重要なんだけど割とクリア出来るのが①と②でして、③が工夫によっては解決できるのに、解決できていない場合が多いなと思っています。

 

まとめ③「必要なのは、チーム一体感」

変更に寛容になれる状況というのを作るためにはどうすればいいかという話ですが、各々がそれに対して納得・共感できることが重要だと思っています。

そのためには前提について共通認識をメンバーが持つことが大事ですし、何か変更する
場合はジグザグのジグをするときに「こういう理由だからするんだよね」というところをちゃんと説明すること。みんなで同じ感覚を持つこと。および、みんながどんなことをしながらやってるのかな?というところで、情報の公開性といったところが必要です。

それに対して、いわゆるツールですね。インセプションデッキのようなものは必ず作った方がいいと思うのですが、そこで認識合わせをしたりですとか、カスタマージャーニーを作って、そもそも論の目線合わせをしたりですとか、オープンコミュニケーション、特にSlackなどは最近話題だなと思いますが、特に「包み隠さずすべてオープンにしましょう」といったところで、チームの一体感を出していくところが割とできていないですし、特に受託開発現場においてはできていないところが多いなと感じます。

ですので、結論といたしましてはチーム一体感が一番大事だと思っています。コミュニケーション不足なんて本当に何十年言われているんでしょうね。今になっては一番重要だと思っています。スクラム開発という手法はありますけれども、たとえスクラム開発でなくても、リアルなラグビーのスクラム感、いわゆるワンチームのような意識ですね。そういったものは非常に重要だと思います。そういったところで受発注なく共創が発生するような関係性が好ましいと思っています。

そこにおいてはすべて包み隠さない、オープンコミュニケーションのようなところがあります。我々はSlackを使っていますが、内部用のやり取りをするチャンネルにお客様を招待させていただいています。

「内部の内部同士のやりとりをどうぞ見てください」
「理解できなくてもかまいません」
「我々はこんな感じでやっています」

といったノリです。

それで割と伝わるものがあります。「本当にヤバいの頼んじゃったんだな」とか、そういったところで、結局それが後々になってチーム一体感につながっていくというところでオープンコミュニケーションは非常に大事なものだと思っています。

そのチーム一体感のようなところが、クライアントの上長ですとか、経営層のようなところまで範囲が広がっていくと、DXと呼ばれているものが目指す世界観と割と近くなっていくのではないのかなと思っています。

 

まとめ④「最後に」

最後に少しだけ補足です。我々はこういった手法「ゼロ→イチ」でやっておりますが、基本的にはこの考えがグロースにも少しだけ応用できます。

これは最初のeラーニングの話に戻るのですが、その後エンハンスを繰り返してるのですけど、エンハンス1つ1つに対しても具現化と検証というものを繰り返しています。エンハンス自体も「この新機能追加というエンハンスAはKPIによってヒットしたのかどうか」という検証をします。ゲーミフィケーションだけではなくて、小学生向けのeラーニングそのもの、それが組み込まれているeラーニングシステムとかサブシステム自体を含めて各所で派生させることで、サービス全体としては着実で大きな成長を実現することができるという思想でやっております。

 

お知らせ

これで私からの発表は終わりなのですが、最後に1つだけ。

とはいえ、「実践は難しいではないですか」いうことですね。

「ニジボックス CDD」で検索していただくと、なんと今まで説明したことが、月額50万円で可能でして、今ならおそらく初回の打ち合わせは私が参加します。ですので、ぜひ「ニジボックス CCD」で検索してお問い合わせいただければと思います
※ご紹介サービス「NIJIBOX CDD」はこちらからご覧いただけます。

以上です。ありがとうございました。

 

 

 

 

【Q&A】

回答者:株式会社ニジボックス エンジニアマネージャー 藤原 裕司 氏

 

【Q1】どれくらいの期間を持って進めるのかを知りたいです。一般的な話と、事例によった特徴などがあれば、是非お話聞かせください。

■藤原

これでいうと本当の検証の検証。例えばUXの一番最初ですと「ペルソナを決めてユーザーインタビューだけで、作るものも何も決まらない」といったところがありますが、そういったものから考えると、私個人としてはファーストリリースまで半年ぐらい欲しいなぁと思うところもあったりしますが、現実的にはどんどん省略して何とか2、3カ月でやりましょうということが多いです。

また「私いいものを作りたいので、半年かけたいです」という意味の場合ですが、またここでは別の人格が出てきます。MVPの段階はあまり美味しい商売ではありません。作るのも大変ですし、我々としてもMVPを割と短期間で終わらせて「本開発のところでしっかりしたものを作るのでお金ください」といったビジネスをさせていただいておりますので、どんなに引っ張っても半年。できれば半分の3ヶ月ぐらいということが多いと思います。

■質問者

逆に3カ月より短いパターンというのは、あまりないのでしょうか?

■藤原

本当に検証項目次第でして、その検証ってユーザーが全てではないんですよ。担当者間の検証のようなところもMVPで行おうと思っておりまして、いわゆる普通のウオーターフォールプロジェクトで「ここだけパパッとモックを作っちゃいましょう」といったアジャイル原理主義の方からしたら、すごく怒られそうなやり方をしています。


 

【Q2】POCとMVPの関係がよく理解できていませんので教えてください。

■藤原

POCの方が範囲が大きそうですよね。「サービスとしてこれはどうなんだ?」といったものがPOCだと思っています。先ほどの例ですと「Wi-Fiの自動接続のときにバッテリーはどれくらい使います」って多分POCの範囲じゃないかな?と思うんですね。ですのでPOCの一部分であったりとか、MVPのファイナルにおいてようやくPOCが検証できるような感じかなと思います。


 

【Q3】MVPを定義する際の進め方に関して、お伺いしたいです。
例えばAppを作る際には、ブレストであれば良い機能を出して、そこから絞り込むなどがあるかと思いますが、よくやっているような手法があれば教えてください。(データ・ドリブンに出来る方法などもあれば、ぜひ)

■藤原

「どんな機能かな?」というときは機能で話し合うよりは、漫画の例があったじゃないですか。あそこを何パターンも作ってみるということが多いですね。ストーリーが見えてくると自ずと出てくるわけですよ。「どんなことが嬉しいですか?」というストーリーがどんどん出てくるような方式でブレストをやることが多いですね。本当にどうするか悩んでいるときはそこからやります。


 

【Q4】先ほどの事例で挙げていただいた内容について、各項目ごとの開発(制作)日数、検証期間をお聞かせいただけますでしょうか。

■藤原

いわゆるペーパープロトといったものは1日、2日くらいです。Adobeで一生懸命プロトタイプを作るときは修正が入りますので、色々とあって1ヶ月ほどかかったりします。静的モデルなどエンジニア主導でパーッっと作ってしまうときは2週間くらいで作ります。

更にデザインの連結などをどんどん合わせていくと、結果どんなに絞り込んでも2,3か月かかってしまうのが全体のスケジュール感です。


 

【Q5】MVPを決めて、PoCを進めていくかと思います。その際のKPIはどのように定義していますでしょうか。プロジェクトを進める際に取りやめた事例、一回作ったプロトタイプを大きく変えたことなどあれば教えてください。

■藤原

「お客様に決めてください」と言っていますので、実は私からは答えられません。

この前一文だけ読んだのですけど、アジャイルコーチの説明でこのようなものがありました。「私はタクシーの運転手だと思ってください」ということですね。

「目的地を言われれば連れて行きますよ」
でも乗ってこられて「私の目的地はどこですか?」と聞かれたら困ってしまいます。

私もその感覚がすごくあります。もちろん「こんなことがあります」「こんなことがあるかもしれないですね」という議論はさせていただきますが「こういうものですよ」といったものは全くないのかなと思います。

■質問者

藤原さんがお客様に対して工夫されること、KPIを定義させるために工夫することはありますか?

■藤原

もう「全部話しましょう」という感じですね。腹を割って話すための共通認識を作っていきましょうみたいなものが、やはり「カスタマージャーニーを作成していきましょう」とか、「ツールでどんどん深堀していきましょう」ということなのかなと思います。


 

【Q6】LPを使ったMVPを進めた際に、ユーザーを獲得すると思いますが、検証結果が悪く、早期にクローズさせる際や軌道修正をした際は獲得したユーザーの当初の期待値をクリアできないと思いますが、それはそのままお断りをされるのでしょうか?

■藤原

そのお断りをされるというか「検証結果がダメだったのでこのプロジェクトは凍結します。ニジボックスさん、お疲れさまでした」という感じです。

■質問者

結構シビアというか、物悲しくスパーン!と終わってしまうんですね…。

■藤原

ただ、そこは日本的というか、割とどんなプロジェクトも検証して少し方向修正して、割と次に進むことの方が多いと思います。


 

【Q7】いただいだ事例のうちいくつかで良いのですが、おおよその期間とチームの人数を知りたいです。

■藤原

5名ぐらいでしょうか。やはり人数が少ないので、デザイナーとエンジニア(基本的に1名ずつ)が個々にやることになります。エンジニアはバックバックエンドとフロントエンドが明確に分かれている場合は2人でします。新入社員の教育を兼ねて複数体制になることもありますが、基本ひとりですね。

他にはAbode XDをひたすらいじっている人、プロデューサー寄りの営業チックで割と色々なファシリテートをしてくれる人などで5名くらいになるかなと思います。10名は絶対にやりすぎだと思います。


 

【Q8】MVPを作って検証してみて「価値がない」と判断されてプロジェクトが終了したり、当初想定と全く違うものを本開発したりすることになったご経験はありますか?(=MVPを作るにあたってのビジネスプランをどこまで深く考えるべきか?みたいな話かもしれませんが)

■藤原

「価値がない」はありますね。対ユーザーに宛ててというよりは、クライアントの上司に宛てて価値がないと判断されて、プロジェクトが終結するケースが多かった気がします。

■質問者

ユーザーだったり、マーケットそのものに対して価値があるかということを正しく判断してもらいたかったけど、鶴の一声で全部終わってしまうというのは辛いですね。

■藤原

当初と全く違うようなことには、ならない気がしますね。こんな機能やあんな機能を作りたいといった機能のアイデアが既に10個あるとして、Aというものをやりたいと思ってたけど、Bの方が重要だなということになって、じゃあ、Bに注力にしようというというケースは良くあることです。MVPを進行するにあたって、思いもつかないものが出てきたってことがない印象です。想定されることが沢山ありすぎて、合っているかどうか確かめていくだけですので、新しい何かが生まれてくるわけではないです。

■質問者

「どんどん夢が膨らむ」パターンってあると思うのですが、そのときにどうやってあるべき姿に持っていくのか。何か工夫をされたりしていますか?

■藤原

夢が膨らんだときに「これは何があったら正しいと言えますか?」のような議論を繰り返していく感じですね。

「夢の第1ステップってこれじゃないですか」
「じゃあ、これを確かめませんか?」みたいな感じですね。

対話はすごく重要だと思います。エンジニアが優秀というよりは、エンジニアのコミュニケーション能力がすごく重要だと思います。


 

【Q9】MVPの段階で、マネタイズはどこまで考えるものでしょうか。今の話を聞いていると、MVPの目的である「ユーザーの課題解決をしているか否か」と「マネタイズのバランスが難しそう」ですね。

■藤原

これでいうと事業計画は描けると思うんですよ。そのときに「これくらいのユーザー増加カーブを描くはずである」といった検証をどうすればできるのか考えて「ここの離脱率が20%くらいで抑えないと、この増加曲線は絶対描けないですよね」といった検証をする流れになるかなと思います。

■質問者

事業計画に照らし合わせるわけじゃないですけど「このタイミングでこうなっているはずだよね」という想像をしながら開発や投資をしていく感じでしょうか。

■藤原

ユーザーの必要を検証するようなところに、どこかで定量的な部分というか「コンバージョンはこれぐらいの数値を叩きださないと、そもそもダメだよね」といった話はあるかなと思います。なのでMVP中は完全に投資フェーズでして、そこで事業計画をブラッシュアップして整地化していく面もあるかもしれません。

■質問者

トップダウンの組織で「これは絶対目指さなきゃいけない」という目標達成を厳命される場面において、どのようにマネタイズの軌道修正をしていくのか試行錯誤した経験は過去にありましたか?

■藤原

そこはあまりないですね。一番私がMVPをやったのってその自己紹介でもありましたが、リクルートの次世代開発室みたいな部署です。リクルートで社内コンテストがありまして、そこで企画が通ったら、そこに突っ込まれるんですよ。各々が事業計画を立てるんですよ。1年目、2年目と経過する中で「ここまでやりました」といった目標を立てて、達成できないとプロジェクト終了、バイバイという感じです。

先ほどのユーザーの事前登録で
「2月までに3000人集めます」
「実際には1000人くらいしか来ませんでした」

「達成できませんでしたね」
「このプロジェクトは終わりですね」

そうやって「数打たないと、実際に成功ってしないのかな」というのは、いわゆる開発立場から覚えましたね。

■質問者

貴重なお答えをいただき、ありがとうございました!

 


ご質問等がございましたら、お手数ですが下記運営事務局までご連絡のほどよろしくお願いいたします。
メールアドレス:m_lg@members.co.jp