CREATIVE
UXデザイン＆ビジネスデザイン視点から見るスポーツの可能性 /
最適なプロトタイピングは「急がば回れ」を徹底することで生まれる /
実は「要件定義」でこそ使える「ビジネスモデルキャンバス」 /
前回、要件定義は「現状（As-Is）」と「理想（To-Be）」とのギャップ（課題）を明らかにして、その課題を解決するために満たす必要のある条件＝「要件」を定める、っていう構造を理解すると捗るよね、ということを書いたので、今回はWebサイトだけでなくサービス領域にも比較的適用できそうな具体的手法をひとつ紹介します。
Featured
ビジネスモデルキャンバスは情報整理に使える
それがタイトル通り「ビジネスモデルキャンバス」を使う方法。
ここ10年ほどですっかりおなじみの（むしろもはや古めいた感すらある）フレームワークですが、改めてざっくり説明すると、「ビジネスモデルを9つの要素に分類し、各要素間の相互関係を1枚のキャンバスに示したもの」で、新規事業開発や既存事業改善でよく使われるイメージがあります。
ただ、ビジネスモデルキャンバスの9要素は他のフレームワークと比べてもかなり網羅的・俯瞰的である分、思考も抽象的になりやすく、白紙のビジネスモデルキャンバスから具体的な事業アイデアを詰めるのは、実は結構難しい。
一方で、ビジネスモデルキャンバスに限らず「〇〇キャンバス」と名の付くフレームワークの特長は、なんといっても複雑な要素間の関係性を網羅的に1枚の図で可視化・把握できること。つまり、同じく様々な意図や課題が複雑に絡み合う「要件」を解きほぐして情報整理するのに使えるんじゃないかというわけです。
※実際に、以前担当した「AOI FORUM」立ち上げのプロジェクトでは、具体的な実行内容を決める要件定義でビジネスモデルキャンバスを活用しました。
とはいえ、ビジネスモデルキャンバスにも弱点があって、それはある瞬間を切り取ったスナップショットでしかない、つまり「現状（As-Is）」から「理想（To-Be）」への変化は1枚で描けない、というところ。
だったら、「現状（As-Is）」と「理想（To-Be）」両方のビジネスモデルキャンバスを描いて、その変化を実現することを「目的」として定義すればいい。
ビジネスモデルキャンバスに「BACCM™」を組み合わせる
これが大枠ではあるものの、もうひとつ別のフレームワークを組み合わせると、ここからさらに具体的な「課題」を洗い出して、各種「要件」まで落とし込みやすくなります。
それが「ビジネスアナリシス・コア・コンセプト・モデル™（BACCM™：Business Analysis CoreConcept Model™）」です。
長くなっちゃうのでここもざっくり説明すると、BACCMは、6つの「コア・コンセプト」で構成されるビジネスアナリシスに関するコンセプトのフレームワークで、実はそれが以下のようにビジネスモデルキャンバスの9要素と（ある程度）対応しています。
BACCMの6個のコア・コンセプト
ビジネス・モデル・キャンバスの9つの要素とコア・コンセプトとの関係
具体的には、「現状（As-Is）」と「理想（To-Be）」を描いた2枚のビジネスモデルキャンバスを突合しながら、BACCMを1つずつ言語化していく。
①ステークホルダー
【概要】チェンジ、ニーズ、ソリューションと関係を持つ個人またはグループ
【BMC対応箇所】顧客セグメント／チャネル／顧客との関係／パートナー
【考える視点】本当の顧客は誰か？その仕事で誰が喜ぶのか？
②ニーズ
【概要】対処するべき問題または機会（ニーズがステークホルダーの行動意欲を駆り立ててチェンジを引き起こすこともあれば、チェンジがニーズを生み出すこともある）
【BMC対応箇所】顧客セグメント
【考える視点】その顧客の真のニーズは何か？何を満たすと顧客はお金を払ってくれるのか？
③価値
【概要】あるコンテキストにおける、ステークホルダーに対する値打ち、重要性、有用性
【BMC対応箇所】価値提案／収益の流れ／コスト構造
【考える視点】顧客に提供できる価値は何か？プロジェクト結果の具体的な目標（売上、利益など）は何か？
④ソリューション
【概要】あるコンテキストにおいて、一つ以上のニーズを満たす具体的な方法
【BMC対応箇所】価値提案／リソース／主要活動
【考える視点】何を通じて価値が提供できるのか？
⑤コンテキスト
【概要】チェンジに影響を及ぼし、チェンジから影響を受ける状況
【BMC対応箇所】※「As-Is」と「To-Be」の差分
【考える視点】そのチェンジが影響を及ぼす範囲は？（社内、社外、国内、海外 etc.）
⑥チェンジ
【概要】ニーズに対応して変える行為、エンタープライズのパフォーマンスを改善するためのもの
【BMC対応箇所】※「As-Is」と「To-Be」の差分
【考える視点】ステークホルダーはそのソリューションを通じて何を変えるのか？
こうしてBACCMが定義できたら、「現状（As-Is）」と「理想（To-Be）」を描いた2枚のビジネスモデルキャンバスを突き合わせて、「理想（To-Be）」の「①ステークホルダー」に「②ニーズ」と「③価値」を提供できていない阻害要因を「課題」として位置づけることができるようになる。
課題が明確になれば、あとはそれに向けた解決策を考えるだけ。
考え得る限りのソリューションを洗い出して、「本当に課題の解決になっているか？」「現実的に取り得る手段か？」という視点で精査＆優先順位付けを行っていけば、今後のロードマップを描くことができるし、その中でこのプロジェクトの中で実行するべきソリューションを取り出し、各種要件に切り分けて精緻化していけば、要件定義となる。
「プロジェクト・ミッション」を掲げよう
プロジェクトマネージャーに求められる最も大事な役割のひとつに、メンバーやステークホルダーが逸れたり迷ったりしないように、ブレないプロジェクトの意義を示し続ける、というのがあると思う。
6つのBACCMが言語化できたら、それをつなぎ合わせてひと連なりの文章に編み上げることで、そういう「プロジェクト・ミッション」とでも呼べるような旗印をつくることもできる。こんな感じ。
Amazonが本だけでなく日用品も売るようになった変化を例に取ると、
「アマゾンで本を購入していた顧客」には、「本だけでなく日用品もWebサイトから購入したい」というニーズがあり、「本以外の物も発注後2日以内に届くことが嬉しい」と感じるため、「ECサイトで日用品まで販売する」というソリューションを「Amazon.com」に導入することで、「利益と顧客のロイヤリティーを向上させる」。
と定義できるだろうし、あるコーポレートサイトリニューアルでは、
顧客となる「社内外に変革を起こしたいが、何をすればいいか分からない企業」には、「そのために何をすべきなのか、それにどんな価値があるのかを知りたい」というニーズがあり、「様々なアプローチやノウハウ」に価値を感じるため、「実際の事例とそのプロセスを言語化して発信する」というソリューションを「コーポレートサイトをハブとするマーケティング活動」に導入することで、「より広い顧客に対して価値創造のプロジェクトを創出する」。
と言えるかも知れない。
あくまで自己解釈に基づく我流ですが、「ケースバイケース」の具体手法のひとつとして参考になれば嬉しいです。
なんとなくやりがちな「要件定義」を構造分解してみる /
ディレクター、プロジェクトマネージャーのみなさん、要件定義やってますよね。要件定義って超大事ですよね。
でも、じゃあ「具体的に何からどうすればいいのか教えて」って言われると、意外と難しくないですか？
「そういえば俺はこういう風に考えて要件定義やってるな」っていう要件定義の基本構造を整理してまとめてみました。
そもそも「要件定義」とは？
つまり、要件定義とは、「プロジェクトを進める上で、実装すべき機能や満たすべき性能など、課題に対する解決策として欠くことのできない必要な条件を定める」こと。
具体的には、例えばwebサイトリニューアルのプロジェクトであれば、
機能要件
コンテンツ要件
デザイン要件
構造設計／情報設計
などの形で定義される。
「要件」を導き出すためには？
これらの「要件」は、課題に対する解決策なので、それを導くためには、そもそも「課題」が明らかになっていないといけない。
さらに、「課題」とは「現状（As-Is）」と「理想（To-Be）」とのギャップ（埋めるべき差）なので、課題を明らかにするためには、現状と理想像が明らかになっていないといけない。
つまり、要件定義の構造を図にするとこうなる。
混同しやすい「背景」「課題」「目的」
提案書やプロジェクトマネジメント計画書などで、「背景」「課題」「目的」を書こうとして、どこに何を書けばいいのか迷ったことがある人も多いかも知れないが、こうして構造化してみると以下のように説明できる。
背景：現状・理想・課題の関係性の説明
課題：現状と理想のギャップ（埋めるべき差）
目的：理想の状態を実現すること
そして、「課題」を解決するために満たす必要のある条件が、各種「要件」となる。
この構造を、クライアント含めプロジェクトメンバー全員が頭に置いておかないと、粒度がずれたり、話が噛み合わなかったり、いつの間にか手段が目的化してしまったり、認識相違やボタンの掛け違いが起きてしまう。
それを避けるために、初回のヒアリングなどの際には、以下の「要件定義キャンバス」を大きく貼り出して（描き出して）、ポストイットなどで随時メモをプロットしながら、「今の話はどこのことを指しているのか」の認識を合わせながら行うと安心。
考える順番
そもそも、「現状（As-Is）」「理想（To-Be）」「課題（Problem）」が明確になっている場合は、素直にその課題に対する解決策を考えればいいので、要件定義にはそんなに悩まないはず。
「何からすればいいのか分からない…」となるときは、「現状（As-Is）」か「理想（To-Be）」のどちらか（あるいは両方）が不明確な場合が多い。
「現状（As-Is）」が不明確な場合
クライアントが「なんとなくこうなりたいという理想像はあるけど、どうしていいのか分からない」という場合は、以下の順番で考えると良い。
1. 理想像を精緻化
2. 現状を把握
3. 課題の洗い出し
4. 課題解決に必要な要件の具体化
「理想（To-Be）」が不明確な場合
クライアントが「現状のままでは良くないことは分かっているけど、どうしたらいいのか分からない」という場合は、以下の順番で考えると良い。
1. 現状を把握
2. 課題の洗い出し
3. （課題が解決された状態としての）理想像を精緻化
4. 課題解決に必要な要件の具体化
じゃあ具体的に「理想像を精緻化」「課題の洗い出し」ってどうやるの？と言われると、それはもう本当にケースバイケース。
じっくりデザインリサーチした方がいいかもしれないし、ビジネスモデルキャンバスやカスタマージャーニーマップを描くのが有効かもしれないし、逆にシンプルに膝つき合わせてヒアリングする方がいいかも知れない。
むしろ、そういう手法やフレームワークなどの「手段」に囚われず、チームメンバーのキャラクターとかリテラシーとかも勘案した上で、それぞれの「目的」に対してどうするのが本当に最適かを常に考えることこそが要件定義プロセスの肝だと思う。
次回は、Webサイトだけでなくサービス領域にも比較的適用できそうな具体的手法をひとつ紹介します。
Featured
ローンチへの熱い決意 “仲間”として共に取り組んだマイナビ 「hin+（ヒンタス）」を振り返る /
“New-Move” Society｜もし外出がポイント制になったら、僕らの生活はどのように変わるだろうか？ /
0→1をデザインするために大切な4つのステップ /
ゼロから構築するUXのプロセスと方法論 /
リーンスタートアップにおけるMVP制作のポイント /
※2021/6/21 追記更新
「良い事業アイデアを思い付いたんだけど、実際に立ち上げるためには、まず何をすればいいんだろう…？」
ハッカソンやアイデアソンといった言葉も当たり前になり、一昔前から見れば新規事業アイデア創出の需要も機会も増えているけれど、それと同時に、事業アイデアを思い付いてもどう形にしていけばいいのかが分からずに頓挫してしまったり、逆に突っ走って失敗してしまう、という声もよく耳にする。
アイデア創出の「次」に何をすればいいのか、日経新聞社主催『AG/SUM HARVEST』のアクセラレーター・プログラムで講演した内容をもとに、MVP制作のポイントについてまとめてみた。
リーンスタートアップのプロセス
リーンスタートアップとは、まずはアイデアから最低限実用に足る製品（Minimum Viable Product）を作り、顧客の反応を検証しながら改良・軌道修正を行うという、構築（BUILD） - 計測（MEASURE） - 学習（LEARN）の学習サイクルを迅速に繰り返すことによって、無駄を最小限に抑えて成功に近づくというスタートアップ手法。つまり、いかに短期間でたくさん学びを得られるかが勝負になる。
とはいえ、厳密に言えば本当にアイデア出しの「次」にやることは、MVP制作ではない。
多くのスタートアップが、「その課題が本当に存在するのか」や「そのソリューションは本当に課題を解決できるのか」の検証をすっ飛ばしてMVPを作ってしまうが、実はこれがスタートアップが死ぬ原因のひとつ。MVPとはいえ、モノをつくるには当然リソースが必要なのだが、検証をせずに誰も欲しがらないものを作ってしまうのは「最大の無駄」。そして限られたリソースの中で成功のサイクルに乗ることが至上命題のスタートアップにとっては、この「無駄」が致命傷になる。
リーンスタートアップは「成功へのショートカット」ではなく「急がば回れメソッド」であることを肝に銘じ、MVPを作る前に最もリスクの高い要素から順に検証していくことが、本当に無駄のない「LEAN」を実現するポイント。
仮説「検証」のプロセス
では、その仮説検証はどのように進めていくのか。検証する順番は「リスクの大きい順」。
間違っているソリューションの市場を検証しても無意味だし、問題が存在しなかったらそのソリューションも存在しない、という風に逆算していくと、最も大きなリスクとなるのは「顧客と課題」だと分かる。
つまり、「顧客と課題」＞「解決策とサービス・プロダクト」＞「サービス・プロダクトと市場」の順番にひとつずつ検証していく。
仮説「立案」のプロセス
さらにもう一段掘り下げて、検証するべき「仮説」とは何か、その仮説はどうやって立てるのかについて、順を追って考えていく。
STEP 1：顧客と、その顧客の最も重要な課題を選ぶ
上記の通り、まずは最もリスクの大きい「顧客と課題」、本当にその顧客と課題が存在するのか（解決すべき課題なのか）から検証していくので、その事業アイデアの対象として想定している「顧客」と、その顧客が抱えていると想定している課題の中で最も重要だと思う「課題」をひとつ選んで書き出す。
STEP 2：課題の前提条件を洗い出す
次に、その課題の「前提条件」を書き出す。
ここでのポイントは、「課題」と「仮説」は違うものであることを認識すること。なぜなら、「こういうことを課題に感じたことがあるか」と課題をそのまま検証しようとしてしまうと、確かにそれ自体は課題でも、実はそんなことが問題になるシーンはほとんどなかった、ということが起こってしまい、本当の意味で解決すべき課題なのかの検証にならないから。課題をそのまま検証しようとするのではなく、「この前提条件が正しければ、課題は正しい」と言えることを仮説にする。
ここではひとまず粒度は気にせず、思いつく限り、顧客の状況や行動など課題にひもづく前提条件を書き出す。
STEP 3：最も検証が必要な前提条件を洗い出す
前提条件を書き出したら、それらを「インパクトの大／小」「確度の自明／不明」の2軸でマッピングする。
その前提が合っていようが間違っていようが大した影響がないものならば検証する意味はないし、わざわざ検証しなくても分かりきったことならば検証に時間を割く必要はない。つまり、最もインパクトが大きく不明な前提条件＝最もクリティカルな前提条件こそが最も検証すべきもの。
また、こうしてマッピングすると検証しなければならない前提条件は山ほどあることに気付くが、欲張って2つも3つも一気に検証しようとしてはいけない。複数の前提条件を同じ検証の俎上に上げてしまうと、どの前提条件がどう課題にひも付いているのかが分からなくなり、有効な検証ができなくなってしまう。ここでも「急がば回れ」を思い出して、最もクリティカルな前提条件からひとつずつ検証を進めていくことが大切。
STEP 4：検証方法と判断基準を決める
検証方法とはつまり、MVPとして何をつくるのか。MVPの選び方は後述するとして、ここでのポイントは判断基準＝KPIを定めるということ。
ただ、検証で100％の白黒がつくことはないので、「◯◯人以上」「◯◯％以上」といった数値の設定に絶対の正解はない。KPIはあくまで判断材料のひとつなので、何をもってして「検証できた」とするかは「直感」でOK。
これもよくあるスタートアップが陥りやすい罠で、慎重になるあまりユーザテストから抜け出せずに、いつまでたってもきちんとしたプロダクト・サービス開発に入れないままリソースが尽きてしまうことがある。そうなっては元も子もないので、ある程度「アリ」か「ナシ」かの判断ができたなら、だらだら検証を続けるよりさっさと次のステップに移り、サイクルを早く回していくことが大事になる。
こうして検証を繰り返し、その度にアイデアと仮説を修正しながら、「顧客と課題」＞「解決策とサービス・プロダクト」＞「サービス・プロダクトと市場」と検証のフェーズを進めていく。
MVPの例
改めて「MVP」とは何か。MVPとは Minimum Viable Product の略で、「最低限実用に足る製品」などと訳される。
ここでいう「実用に足る」というのは、「仮説検証から学びを得るために過不足がない」という意味。MVPは単なる初期のプロトタイプではなく、最も効率的に学びを得られるプロダクトであること、つまり「検証できること」と「それをつくるのにかかるリソース」のバランスが取れていることが大切。
参考までに、以下にいくつかMPVの例を紹介する。
CASE 1：プロトタイプ（β版）
いわゆる試験やデモ用に作られる実験機。完成版ではないものの、
実際に動作する製品を作り、クローズドβ版などテストユーザに使用してもらいフィードバックを得る。
洗練はされていなくとも実際に動作する製品なので、その分つくるにも比較的大きなリソースが必要になる。
開発の段階としてはローンチに近く、市場投入前の段階で使用するMVP。
主に検証できること
・機能は十分か
・操作性は問題ないか etc.
CASE 2：ペーパープロトタイプ
紙でアプリやサイトを制作する手法。リソースを費やして実際に実装する前に、紙とペンでモックアップを作成することで、事前にフローや仕様の齟齬を確認することができる。
手軽に作れるMVPだが、デザインなどUIの仮説検証に向くため、開発のフェーズとしては比較的後期のプロダクトの作り込みのフェーズで使用することが多い。
主に検証できること
・要素に過不足はないか
・フローや仕様は適切か etc.
CASE 3：プレオーダー
ローンチ前に事前に登録や購入を募る手法で、そのサービス・プロダクトのベネフィットが顧客に響くかや、十分な数の顧客が得られそうかを探ることができる。
ランディングページやメルマガ購読、クラウドファンディングもプレオーダーの有効な手段のひとつ。これは実際にプロダクトができる前に実行できるため、比較的作りやすいMVPだと言える。
主に検証できること
・十分な顧客がプロダクトに興味を示すか
・顧客のプロフィール
・サービスに顧客がお金を払ってくれるか etc.
CASE 4：デモムービー
ローンチ前に出すサービス紹介ビデオのこと。Dropboxは3分間のデモムービーを作り、Dropboxを実際に利用する流れを見せることで、顧客にどのような価値が得られるのかを想像させて事前登録を募り、ユーザー数を5,000人から75,000人へと大幅に増加させた。
これもサービスアイデアが固まった比較的初期の段階で実行できるMVPのひとつ。プレオーダーと併用も。
主に検証できること
・十分な顧客がプロダクトに興味を示すか etc.
CASE 5：オズの魔法使い型
システム化されているように見えるが、実際は人間が手動で実行することで、大掛かりなシステム開発の前にニーズを確かめる手法。
靴通販の「Zappos」も、当初は注文が来たときに創業者が自ら商品を買いに行って発送を行い、需要を確かめた後に本格的なシステムを構築した。
裏側のシステムはできていなくとも、表向きは完成版のように見えるものなので、これも比較的制作にリソースが求められる。
主に検証できること
・ソリューションは課題を解決できるか
・サービスに顧客がお金を払ってくれるか etc.
CASE 6：コンシェルジュ型
「オズの魔法使い」が裏側のシステム部分だけ人力で行う手法だとしたら、こちらは製品を開発する前に、全てを人力のマニュアルで実行し、需要があるかを検証する方法。
近所のセール情報と食の好みから献立を考えてくれるサービス「Foodonthetable.com」は、Webサイトを立ち上げる前に、自分で直接スーパーで主婦に声をかけ、サービス内容を訪問して提供して直接フィードバックをもらって成功につなげた。
ほとんどリソースをかけることなく、サービス価値を検証できるので、価値検証がしたいなら、まずはコンシェルジュ型の採用を検討してみるのがおすすめ。
主に検証できること
・ソリューションは課題を解決できるか
・サービスに顧客がお金を払ってくれるか etc.
（番外編）SFプロトタイピング
SFプロトタイピングとは、SFの力で未来を想像し、そこからバックキャスティングして今なにをすべきかを考えるための手法。
具体的なシーンをストーリーで描くという点では、ストーリーボードに近いところもあるが、バックキャスティングすることで現状の延長に囚われない発想ができる点、物語の中に没入することで解像度高くその未来を想像できる点が特長だと感じる。
SFを描くということは、ひとつの世界とルールを構築する作業であり、SFの中にアイデアを配置する際には、必然的にその世界のルールとの整合性を取ることになる。その思考プロセスによって、現実世界に置き換えた際にも通じるある種の実装シミュレーションができる可能性がある。
「プロトタイピング」という名前は付いているが、どちらかというとMVPではなくアイディエーションのフェーズで有効な手法。
適切なMVPを設計するには
きちんと学びを得られるMVPをつくるには、今一度リーンスタートアップのプロセスを理解する必要がある。
当然、実証していく際にはBuild → Measure → Learnという流れになるが、検証方法を考える際は、逆算してLearn → Measure → Build の順に考えていく。
つまり、仮説から何を学びたいのか（Learn）を起点として、そのためにはどんな方法で何を測ればいいのか（Measure）、そしてそのためには何を作ればいいのか（Build）、というプロセスで考える。
表層的にリーンスタートアップの実証サイクルだけを見てしまうと、Ideasの次、つまりMVPとして何を作るべきか（Build）からいきなりスタートしてしまいがちだが、「MVPは単なる初期のプロトタイプ」ではなく「最も効率的に学びを得られるプロダクト」なので、後ろから逆算して「何を学びたいのか」から始める必要がある。そうすることで「MVPをつくってみたが良かったのか悪かったのかよく分からない」といった失敗を防ぐことができる。
いきなりMVPをつくろうとせず、適切なMVPの形は「学び」からの逆算で決まることを意識するのが大切。
MVPキャンバス
「MVPキャンバス」とは、AppSociallyの高橋氏とRecruit MTLが共同で開発したもので、最適なMVPを設計するために、リーンスタートアップの思考プロセスを一枚のキャンバスにまとめたもの。
思考の順に項目を埋めていくことで、どこにフォーカスすべきなのかそれぞれのポイントが整理され、効率的にMVPの制作と学びのサイクルを回すことができる。
ここではより最低限の項目に絞って簡易化したものを紹介する。
1：検証したい仮説は何か
そのサービス・プロダクトの中で最もクリティカルな仮説（前提条件）を記入する。
2：何を学ぶのか
この仮説検証をする理由、知りたい結果を記入する。
あらかじめ明文化しておくことで、仮説のピボットなど次のアクションが考えやすくなる。
3：仮説をどうやって検証するのか
どのように検証すれば、知りたいことが学べるのかを具体的に記入する。
複数検証方法がある場合は、それぞれでキャンバスを作成する。
4：実証に必要なデータ・条件は何か
仮説実証のためにどのような条件や定量データが必要なのか（KPI）を記入する。
実証結果がOKなのかNGなのかの判断基準。
5：MVPとして何をつくるのか
3・4を踏まえ、MVPとして何をつくる必要があるのかを記入する。
その際、MVPをつくるのにかかるリソースも考え、MVPを選ぶ材料にする。
6：検証結果
KPIに照らし合わせてどうだったのか、実証できたのかできなかったのか、得られた検証結果を記入する。
7：得た学び
結果から何を学べて、次のステップにどう活かすことができるのか、次のアクションを記入する。
まとめ
ここまでを振り返って、大事なポイントをまとめてみる。
リーンスタートアップは「急がば回れ」メソッド。検証すべき仮説を順番につぶしていくのが大切。
仮説を検証する順番は「リスクの大きい順」、「顧客と課題」から始める。
「課題」と「仮説」は違う。「この前提条件が正しければ、課題は正しい」と言えることを仮説にする。
課題検証はひとつずつ。最もインパクトが大きく不明な前提条件＝最もクリティカルな前提条件を選ぶ。
KPIはあくまで判断材料。直感で「OK / NG」の確信が得られれば十分。
MVPは単なる初期のプロトタイプではない。仮説検証のためのプロダクト。
MVPは「検証できること」と「それをつくるのにかかるリソース」のバランスが取れていることが大切。
いきなりMVPはつくらない。適切なMVPの形は「学び」からの逆算で決まる。
ここまで、フレームワークや事例を交えてMVP制作のポイントを紹介してきたが、実はその実行を妨げる一番の要因は自分の「無意識」や「気持ち」だったりする。
MVPをつくってスタートアップを立ち上げようとしているということは、それだけ良い事業アイデアだと心から思っているからこそ。ただ、その思い入れが強ければ強いほど、無意識のうちに否定される恐れのある検証を避け、「幻のニーズ」を誘導して自分のアイデアに「幻の裏打ち」を与えてしまうリスクをはらむことになる。
リーンスタートアップは、「早く成功するために、早く失敗して、早く学びを得る」考え方。逆に言えば、最初のアイデアは「失敗する前提」。あまり最初のアイデアに固執しすぎずに、アウトプットの質は「何回修正できたか」が規定すると考え、早くたくさん失敗して、たくさん学びを得たほうが良い。
アイデアに「これはいける！」という手応えがあればあるほど、自分に都合のいい検証結果を導いてしまわないように、自分自身がドライに「このアイデアは自分だけの思い込みじゃないか？」と疑って顧客の心の声に真摯に耳を傾けることが大切になる。
もちろん、顧客からのフィードバックを学びとして反映していくにつれて、最初の事業アイデアとは違うソリューションやビジネスモデルに変わっていくことになるが、それはその分だけ正しい方向に進めているということ。もし、ピボットしたアイデアの形に「これは自分が作りたいものじゃない」と感じてしまったら、それは厳しいけれど「ただ自分が作りたいものを作りたいだけ」だったのかもしれない。
アイデアの形は最初に思い描いたものと違ったとしても、それが解決したい課題や実現したい世界、自分のビジョンに合っているものであったら、きっと最初のアイデアと同じように情熱を傾けられるはず。
自分が心から情熱を燃やせるビジョンを大切に、一歩ずつでも確かに「正しい」方向へ進んでいくこと。それが何よりの成功の近道なんだと思う。
未知の領域に挑み続けるクリエイティブディレクター：高井 勇輝 ロフトワークディレクター分解シリーズ Vol.5 /
ロフトワークのディレクターを一人ひとり紹介するコーナー、ディレクター分解シリーズ。
今回は入社して間もなく大プロジェクトに抜擢され、全く未体験の領域にも関わらず見事やり遂げた高井が登場。若手ながらバランスが良く安定感があり、周囲からの信頼も厚い今後の進化が楽しみなディレクターです。
（聞き手：PR石川）
ー前職は何をされていましたか？
インターネット広告会社に新卒で入社し、アカウントプランナーとして、不動産や化粧品、健康食品、ゲームコンテンツ等、幅広い業種のクライアントを相手に提案からディレクション、そして運用まで一連して担当していました。スピード感あるベンチャー気質の会社で、プッシュ営業もやりましたし、代理店、メディア、クライアントと、様々なステークホルダーに囲まれて仕事をしてたので鍛えられましたね。
クライアントとメディアの間に立って調整しながらプロモーションプランを実施していくのは、今のロフトワークでやっているディレクションに共通するものがあると思っています。
ーどういう案件が得意ですか？今までどのような案件に関わってきましたか？
2012年11月に入社したので、ロフトワークに来てちょうど1年半（インタビュー時）、Webサイトリニューアルやコンテンツ案件も担当してきましたが、他にも新規自社サービスの立ち上げとか、空間ディレクションや、新しいCMS導入など、ロフトワークのディレクターの中でもかなり幅広く関わっている方だと思います。結果的にまだ誰もやったことないような新しいタイプのプロジェクトが多いかもしれません。
ちなみに、ロフトワークに入社するまでWebのディレクションはほとんど経験がありませんでした。HTMLは知っているけど書いたことはない、Photoshopなどのデザインツールは多少触ったことがある程度で、制作系の知識は充分とは言えませんでした。
ー柏の葉のオープンイノベーションラボ「KOIL」が4月にオープンしました。高井さんはこのプロジェクトにずっと関わっていたそうですね？
三井不動産のイノベーションセンター「KOIL（Kashiwa-no-ha Open Innovation Lab.）」プロジェクトにおいて、ロフトワークはコンセプトの提案から空間デザイン、会員システム、Webサイトまで幅広くクリエイティブ全般をサポートしてきました。
KOILは、電磁石の「コイル」をイメージしていて、「磁場」となっていろんな人が集まり、場所や僕らが触媒となって、いろんな人が交わって刺激しあって、イノベーションが起こるエネルギーが生まれる場所にしたいという思いから名付けられています。
僕は入社1ヶ月後にこの大きなプロジェクトに携わることになったのですが、担当したのは結果的に非常に多岐に渡っていて、空間ディレクションから、会員管理システム構築、映像音響設備プランニング、プロトタイピング機器プランニング、インターネット環境プランニングから、気付けば最終的には運営計画の部分含めて全体に関わっていました。
成瀬猪熊建築設計事務所が空間設計を担当し、バッタネイションの岩沢兄弟とも一緒に家具の設計をしたのですが、自分で空間のコンセプトを決めてぐいぐい推し進めるというよりは、僕は運営側からの必要な視点でのフィードバック、逆に建築現場からの意見を運営側にフィードバックしたり、全体を俯瞰して、要望をそれぞれのプロフェッショナルに上手に伝えて間をつなぎ、彼らに十分に力を発揮してもらえるようにすることを心がけました。
インターネット環境プランニングでは、どのWiFiルーターをいくつ・どの構成で置くか検討したり、また「KOIL FACTORY」に設置する、レーザーカッター、3Dプリンター、3Dスキャナー、3Dモデラー、その他工具一式といったデジタルファブリケーション機器や、KOIL全体の映像・音響機器のディレクションと調達も行いました。
もちろん、僕はこれらの分野のプロフェッショナルでは全然なかったので、それぞれの専門家とコラボレーションしながら、手探りながらもプロジェクトを進めてきました。
また会員管理システムの構築に関してはメインでディレクションとプロジェクトマネジメントを行っています。 会員情報のDB、申し込み機能から課金システム、予約システムなどと連携が可能なパッケージを検討し、Bplatsを導入しています。施設予約システムに関してはリザーブリンクを採用しました。
ー同じプロジェクトでも本当に多岐に渡る案件に携わってたんですね…。なんというか、全体俯瞰できて、フットワーク軽くて、気が回る高井君だからこそ、役割を果たせたんじゃないかと思えてきました
はい、どこからどうボールが転がってくるか分からないから、とにかくレシーブしまくった感じです。
大小含め、タスク量はすごく多かったですね。
プロジェクトマネジメントともディレクションとも違う、例えて言うならサッカーの「ボランチ」みたいなイメージで、フットワーク軽くセカンドボールを拾って、適切な相手に展開してプロジェクトがスタックしてしまわないように前進させることを意識しました。
例えばなかなか捕まらない代表の諏訪と林を捕まえて意思決定の場を整えるとか。
とにかく、来たボールをしっかり展開して、彼ら（設計する人間やコンセプトを決める人間）のアシストをすることに集中しました。
ー言い方は良くないですが、「最強の雑用係」だったんですね！
はい、まさにそんな感じです（笑）
ーでもフォロー力と処理能力が高くないと務まりませんからね。スーパーマルチプレイヤーということにしておきましょう！
…苦労話とかありますか？
この規模の「イノベーションセンター」をつくったのは日本初で、誰も見たことのない正解を知らないものを創らなきゃいけない中、建築とか空間とかシステムとか、全部ほぼ未経験の中、初めてのことだらけで全部手探りの大変さは当然ありました。 担当クリエイティブディレクターとしてこの大きなプロジェクトに関わっているというプレッシャーは常にありました。
これだけの規模のプロジェクトとなると、ステークホルダーも多く、皆頭のなかに描いている画が微妙に違うのは仕方がありません。
その中でひとつずつ合意形成していくのも大変でした。でもだからこそ、相対するのではなく、みんなで同じ目標や課題を見据えて進めることができたという面もあって、クライアントと同じ方向をみて進められたところは良かったと思います。
あとは発注が来なくて動けないとか…そういった苦労は、往々にしてありましたね（笑）。
ー話変わって、これから伸ばしていきたいスキルはなんですか？
新しいサービスをつくってみたいと前からずっと思っています。
KOILではプロジェクトを描くというよりは推進していくという役割だった反面、今後はもっとコンセプトメイキングなどができるようになりたいです。価値ある「0→1」を描き「1→10」を着実に積めるのが本当のクリエイティブディレクターだと考えていて、リーン・スタートアップやグロースハックのスキルもそのために要るものだと思っています。
なので、クリエイティブディレクターという肩書きは重いですが誇りでもあるので、本当の意味での「クリエイティブディレクター」になるべくこれからも頑張ります！
あなたのリーンスタートアップがうまくいかない4つの理由と覚えておくべき3つの心得 /
「リーン」って具体的にどうやるの？
耳にすることも多くなり、すっかり定着した感もある「リーンスタートアップ」という言葉。関連記事を読んだり話を聞いたりすれば「おっしゃるとおり！」と納得するけれど、いざ自分でやってみようと思うと、何から始めてどうすれば「リーン」になるのかよく分からない。そこで、リーンスタートアップの手法のひとつ、『Validation Board（バリデーションボード）』を使って実際にやってみました。
まさに、百聞百見は一験にしかず。実際にやってみて分かったつまずきやすいポイントや、得られた教訓を、気をつけたいポイント4つと、覚えておくべき3つの心得にまとめてみました。
ポイントその1： 実験仮説の立て方
「バリデーションボード」とは、仮説→実験→検証のフィードバックサイクルを繰り返しながら製品の精度を高めていく手法です。最初のステップである実験仮説（Assumption）を適切に立てるところで早速難しいと感じるかもしれません。というのも、「こういうことを課題に感じたことありませんか？」と課題仮説をそのまま投げかけてしまったら、「言われてみればそういうこともまああるかな…」と、幻のニーズに誘導してしまうことになるからです。
それでは「本当に解決すべきニーズなのか」を検証できません。課題仮説そのままを実験仮説にするのではなく、「こういう体験があるなら、課題仮説が正しいと言える」ということを実験仮説にすることが大切です。
ポイントその2： ユーザインタビューの実践
ターゲットとその課題が本当に存在するのか、それを検証する方法のひとつがユーザインタビューです。無意識に答えを誘導してしまわないよう、そしてしっかりユーザの声を引き出すために、ちょっとしたインタビュースキルが必要になります。
まずは、軸となる質問を聞きもらさないためにも、インタビューシートを持参すること。次に、インタビューが終わったらすぐに振り返ってチームで共有できるように、気になったキーワードやコメントなどは随時メモしながら進めることです。
また、あらかじめ用意していた質問項目以外から、いかにユーザの本音や新しい気付きが得られるかも、とても重要なポイントです。思いもよらない言葉から真の課題が見つかることも多いので、なるべく一問一答のぶつ切りのやりとりにならないように、対話形式でキャッチボールしながら、興味深い話をどんどん掘り下げていきます。
そして、1人のインタビューが終わるごとに、都度インタビューのメモをチームで共有して、「ここが気になる」とか「ここはこういう聞き方をした方が引き出せそう」とか、小さなことでもフィードバックして改善していくと、わずかな人数にインタビューする間でもどんどんいいインタビューができるようになっていきます。バッチサイズを小さくして、フィードバックサイクルを早く回すことがリーンスタートアップの肝です。
インタビュー結果の何をもってして「検証」するかは、「直感」でOKです。もちろん、判断基準としてのKPIを定めておくのも大切ですが、それはあくまで判断材料のひとつ。
ユーザインタビューでは定量的な調査は難しいので、「アリ」か「ナシ」かの判断さえつけば良いのです。ある程度判断ができたなら、だらだらインタビューを続けるより、さっさと次のステップに移りましょう。「そんなこと言ってもそんな簡単に判断できるもの？」と思うかもしれないけど、意外に大丈夫です。実際にユーザに対峙して直接声を聞くことは、想像している以上に雄弁に物事を語ります。
ポイントその3： MVPの作り方
MVPとは、「Minimum Viable Product」の略で、「検証に必要な最低限の機能を持った製品」という意味です。つまり、「完璧な企画書を作りこむより、とりあえずでもモノという形にしてみよう」ということ。モノを作り始めるとどうしても「いいモノ」にしたくなってしまう気持ちは分かりますが、大切なのは、「1機能・1プロトタイプ・1検証」に絞り込むこと。欲張らずに、重要な仮説から一つずつ着実に検証していくのがポイントです。
MVPの例としては、Webサービスとして作る前に、単機能のサービスを手動（アナログ）で提供してみてユーザのニーズを確かめるやり方（コンシェルジュ型）もあれば、端的にサービスの特長とビジュアルをまとめてティザーサイトを作り、そこへの反応で検証するやり方もあります。他にも、世界観を表したムービーや、プレスリリース、今ならクラウドファンディングのプロジェクトを立ち上げるのもMVPになり得るかもしれません。
リーンスタートアップの基本は、「ユーザから学びを得て修正する」というサイクルです。ブラッシュアップするためには、一度対象から離れて客観視することが必要なので、そのためにも、プロトタイプという形でアウトプットを一度出して客観視することがとても大切なプロセスなのです。
ポイントその4： 検証実験の設計
MVP（Minimum Viable Product）という形ができると、「さあ、あとはこれを世の中に投げて問うだけだ！」と急ぎたくなる気持ちもやまやまですが、ここでいったんその問い方を考えましょう。
大切なのは、ちゃんと「学びを得られる構造が設計されている」かどうかです。十分な数のデータが集められるのか、集まるデータは検証したいことに合致しているか、次のアクションに移るトリガーは何なのか…。MVPがランディングページやティザーサイトであれば、サイトのアクセス解析から色々なデータを取得することができますが、「データは取ったものの、結局この結果って良いの？悪いの？」とならないように、あらかじめ検証方法を考えておかなくてはいけません。
適切な比較材料や基準となるKPIがなく、判断のつかないような定量データを取るくらいなら、ユーザの声などの定性データから学びや良し悪しの直感を得られるようにした方がいいこともあります。
そして、検証できたら早く次のサイクルに移れるように、その後のアクションへのフローまでセットで考えておくことも忘れずに。
「リーンスタートアップ」は「急がば回れメソッド」
やってみて思ったのは、リーンスタートアップとは「成功」にジャンプできる魔法のショートカットではないということです。最初に僕が漠然と思い描いていたのは、「とにかくさっさと作って、駄目ならさっさとピボットすればいいんでしょ？」というイメージでした。一見近いようにも思えますが、でも正しくは「外せないポイントをちゃんと仮説を立てて考えて、それを検証できるMVPをさっさと作り、駄目なポイントがはっきりしたなら、その学びをもとにさっさとピボットする」ということ。このサイクルを早く回すために、バッチサイズは最小限まで小さくするのです。まどろっこしいからと欲張って一度に複数のことを検証しようとしたり、とりあえず製品を作ってしまおうとすると失敗しがちです。「魔法のショートカット」というより、むしろ、愚直に確かめながら進めるという当たり前のことを一歩ずつ、それをものすごいスピードでやるから早く成功できる、ということなのです。自分の思いつきを過信せずに、確実な一歩を早く積み重ねるというド正攻法を貫くこと、それがリーンスタートアップの本質なのではないでしょうか。
今回の取り組みは実質15回、週一回のペースで3ヶ月間やってみました。ぎゅっと集中して取り組めば、2週間もかけずにここまでのことは充分できます。実際には技術的・権利的なハードルをいくつも超える必要がありますが、少なくともスタートアップを進めるときにはどうすればいいのかが具体的にイメージできたことはとても大な成果でした。
リーンスタートアップ「3つの心得」
これらの体験をもとに、リーンスタートアップを実践するにあたって大切なエッセンスを凝縮して「3つの心得」にまとめてみました。
1．自分の感覚を疑い、ユーザの心の声に従え
2．否定を恐れず、修正回数を誇れ
3．サービスにこだわらず、ビジョンにこだわれ
リーンスタートアップは、「早く成功するために、早く失敗して、早く学びを得る」考え方。早くたくさん失敗して、たくさん学びを得たほうが良い、ということです。つまり、アウトプットの質は「何回修正できたか」が規定するとも考えられます。逆に言えば、最初のアイデアは「失敗する前提」。けれども、実現させようと思ったということは、最初のアイデアにそれなりに「いける！」という手応えを感じているはずです。その思い入れが強ければ強いほど、無意識のうちに否定される恐れのある検証を避け、「幻のニーズ」を誘導して自分のアイデアに「幻の裏打ち」を与えてしまっているかもしれません。誰だって自分の素晴らしいアイデアを否定されるのは怖いと思います。でも、だからこそ、まずは自分自身がドライに「このアイデアは自分だけの思い込みじゃないか？」と疑い、思い込みに隠された本当のニーズを暴こうとする作業が大切なのです。
その結果導き出されたソリューションやビジネスモデルに「これは自分が作りたいものじゃない」と感じてしまったら、それはきっと残念ながら「作りたいものを作りたいだけ」だったのかもしれません。ソリューションの形は最初に思い描いたものと違っても、それが解決したい課題、つまり自分のビジョンに合っているものであったら、きっと最初のアイデアと同じように情熱を傾けられるはずです。
「リーンスタートアップ」とは、それに則れば成功が約束されたマニュアルではなくて、文化やマインドに近いものなんだと思います。逆に言えば、この「心得」さえ忘れずにいれば、きっと、たとえ多少進め方が違ってたとしても、ちゃんと「リーンスタートアップ」ができるはずです。
※今回の実践の全スライドはこちらからご覧いただけます。
