2024 /
年末に行った台湾の羅東運動公園からの景色
あまり誕生日や年始に節目の意味を持たせたり抱負を立てたりしないので、2023年も相変わらず日々を過ごしていたらあっという間に過ぎ去ってしまったなと虚しくなりかけながらも、ここ数年を振り返ってみればちゃんとそれなりに歩みを進めているのが我ながら自分のいいところだと思う。
一昨年の6月にTakramにジョインしてから早くも一年半が経ったけど、幸いまだ新鮮にアンラーニングとラーニングを続けられている。
よく人は周りにいる人でつくられると言うけれど、環境が変わってもここはちゃんとバリューが出せるなと確認できたことも、これはもう一段気合い入れてレベル上げないといけないなと感じることも、いやこんなすごい人たちもいるんだなと脱帽することもあり、有り体に言ってとても健全な緊張感と刺激のある環境だ。
本やPodcastからのインプットも格段に増えたし、この歳になってもう一度成長のスイッチを入れられたのはありがたい。英語も少しずつ勉強し直し始めたし、年齢的なこともあってジムや整体での身体のメンテナンスにも気を使うようになった。
去年プロジェクトディレクターのライセンス取得も済ませたので、今度はよりプロジェクトを率いる中でのトライを重ねながら学びとバリュー還元のサイクルを回していきたい。
＊
もう一足の草鞋であるSandSの方も面白い転がり方をし始めていて、2023年は奥大和で開催された芸術祭MIND TRAILでアーティストデビューを果たした。
個人的にはいちアートファンからコレクターになり、それからアーティスト野村康生さんとのユナイテッドという取り組みに発展したり、ロフトワークの最後の仕事では大丸松坂屋百貨店と一緒にアートプロジェクトARToVILLAを立ち上げたりと、それぞれは決して直接つながってはいないものの、とうとう自分たち自身がアーティストとしてクレジットされることになったのは感慨深くもあり愉快でもある。
これからさらにその方向に進むのか一度きりで終わるのかはまったく分からないけど、いずれにせよ今年も面白い方向に転がってくれたらいいなと思う。
＊
プライベートでは、これもまた乗りと勢いとある程度の計算の結果、11月に長野に土地を購入したのもひとつのイベントではある。
まあ住むにしろ遊ぶにしろ先立つものがないのでいずれにしても今年というよりは早くても数年後にはなるけれど、約900平米弱のそこそこ広さのある区画になったので、どうするか考えるのを気長に楽しもうと思う。
＊
まずは年始にひいた風邪を治すところから始めます。
【SFプロトタイピング】トラウマスター /
Artist Movement ”UNITED” /
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+（ヒンタス）」を振り返る /
組織は、1人の想いから変わり始める｜ボトムアップで組織を突き動かすために必要なこと /
“New-Move” Society｜もし外出がポイント制になったら、僕らの生活はどのように変わるだろうか？ /
0→1をデザインするために大切な4つのステップ /
ゼロから構築するUXのプロセスと方法論 /
PLART｜アートのある暮らしvol.5 アートの入り口を教えてくれる家。 /
リーンスタートアップにおける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をつくってスタートアップを立ち上げようとしているということは、それだけ良い事業アイデアだと心から思っているからこそ。ただ、その思い入れが強ければ強いほど、無意識のうちに否定される恐れのある検証を避け、「幻のニーズ」を誘導して自分のアイデアに「幻の裏打ち」を与えてしまうリスクをはらむことになる。
リーンスタートアップは、「早く成功するために、早く失敗して、早く学びを得る」考え方。逆に言えば、最初のアイデアは「失敗する前提」。あまり最初のアイデアに固執しすぎずに、アウトプットの質は「何回修正できたか」が規定すると考え、早くたくさん失敗して、たくさん学びを得たほうが良い。
アイデアに「これはいける！」という手応えがあればあるほど、自分に都合のいい検証結果を導いてしまわないように、自分自身がドライに「このアイデアは自分だけの思い込みじゃないか？」と疑って顧客の心の声に真摯に耳を傾けることが大切になる。
もちろん、顧客からのフィードバックを学びとして反映していくにつれて、最初の事業アイデアとは違うソリューションやビジネスモデルに変わっていくことになるが、それはその分だけ正しい方向に進めているということ。もし、ピボットしたアイデアの形に「これは自分が作りたいものじゃない」と感じてしまったら、それは厳しいけれど「ただ自分が作りたいものを作りたいだけ」だったのかもしれない。
アイデアの形は最初に思い描いたものと違ったとしても、それが解決したい課題や実現したい世界、自分のビジョンに合っているものであったら、きっと最初のアイデアと同じように情熱を傾けられるはず。
自分が心から情熱を燃やせるビジョンを大切に、一歩ずつでも確かに「正しい」方向へ進んでいくこと。それが何よりの成功の近道なんだと思う。
2016 /
日常に飲み込まれて忘れてしまわないうちに、今年もちょっとだけ振り返りと抱負めいたものを書き留めておこうと思う。
3年1周期の最終年として2015年に掲げた抱負のひとつは、「改めて足元を踏み固めて土台を積み上げ、ひとつここまで来れたなと納得できるように仕事をする」こと。
何か分かりやすい結果だとか目に見える成果が出せたわけじゃないし、いつだって満足できる仕事ばかりじゃないけど、プロジェクトの規模も難易度も上がっていく中で、曲がりなりにも全部やりきってこれたことには、それなりの手応えを感じられたし、仕事したなって実感は持てた。
2016年もきっと相変わらず（そしてたぶん今まで以上に）難しいことや大変なことはあるだろうし、もしかしたら周りからは「なんでまたそんな大変なところへわざわざ」みたいに思われることもあるかもしれないけど、自分で必要な経験だ、自分がやるべきものだって選んで飛び込んでいるからそれは全然納得しているというか受け入れている。
たぶん大事なのは、正解のルートなんてものは存在しないとしても、選べる範囲で少しでも正しいと思える方向を自分で選択し続けていくっていう意識で、そう思えれば後悔なんてしないし、大抵のことは背負えるはず。まだ何が見えたわけじゃないけど、そうやって段々向かうべき方向に向いてきた気はしている。何となく。
仕事は全力最善を尽くすだけだから特に抱負にはしないけど、近いところでは、自分のためにも、今年はもっと組織やチームを良くすることや、価値を可視化することの力になれたらいいなと実は思っている。
もうひとつ、2015年に立てた抱負は、「個人として向かいたい方向へハンドルを向けて、外に一歩足を踏み出す」ことだったけど、これは丸々宿題として持ち越してしまった。
この3年1周期という思い付きに沿えば、2016年は新しい3年周期の初年度になる。そう考えればこれはこれから始まる3年間で形にしていくことなんだと思う。そのためにも、今年はじっくり自分の中にあるものを棚卸ししてみたい。好きなもの、心動かされるもの。したいこと、やってみたいこと。できること、求めてもらえるもの。なりたかったもの、達成したいこと。思えばモデレーターやイベントプロデュースも去年初めてできたことだし、少しずつ広がっているものは確かにある。
未来はいつだって、予想と違う方向や速さで拓ける。
また来年振り返ってこの一年が全然思っていたものと違っていたとしても、きっとそこに来てしまえば、不思議となるべきようになったような気がするもので、そういう運命論めいた何かをポジティブに受け入れながら、転がっていく2016年を楽しみにしたいと思う。
今年もよろしくお願いします。
物語が欲しくなるとき /
本でも映画でも漫画でもアニメでも、無性にたくさんの物語を摂取したくなる時期というのが年に何度かあって、ろくに中身も見ずに本屋で無造作に5冊くらい文庫本を買ってきたり、ふらっとレイトショーを観に行ったりしたくなる。
何度もそういう時期を迎えるうちになんとなく分かってきたのは、それが訪れるのはどうやらあんまり調子が良くないときだということ。
戦争のような祭りのような忙しさの中にいる間は、余裕のないせいか、はたまたアドレナリンが出てるせいか、そんな気分になることはなくて、どちらかというと、うまくいかない仕事に対しての気の進まなさや、漠然としたこの先どうしようかという不安とふと目が合ってしまったときに物語が欲しくなる。単なるささやかな逃避なのかもしれないし、何か変化のきっかけや刺激を求めてるからなのかもしれないけど。
もしこれが、イマジネーションや面白いことを考える活力のストックが枯渇してきているサインなんだとしたら、直接的な特効薬になりそうなテクノロジーやクリエイティブ系の情報を摂るのが良さそうな気がするけど、直感に背いて雑誌やそういう本を買ってしまうと、不思議とだいたいうまく消化できずに枕元に積まれることになる。
甘いものをやけ食いするように、新しい素材が鍋の中のスープと化学反応を起こしてくれるのを期待するように、とにかくインプットを増やして樽の中の澱を押し出すように、頭に物語を放り込んでいく。
大概はそれで都合よく気分が切り替わるような面白いアイデアや新しい興味が見つかるなんてことはなくて、そうやってやり過ごしていくうちにまた忙しさに飲まれていって、なんとかこなしていくうちにいつの間にか調子を取り戻していく、という繰り返し。
でもいつか忘れた頃、元の作品もシーンも分からなくなった頃に、ふと思い浮かぶ一小節やそのときの情感がどこかで何かに生きるかもしれなくて、よく分からないけどきっとそういうことなんだろうと思う。
押し出された澱として書いた829文字。
GLAMPING Auberge “HARENOHI” /
http://www.harenohi.org/
Special Thanks to
and all our the relatives & friends.
『はじめの一歩』 /
現在開催中の「3331 Art Fair 2015 ‒Various Collectors' Prizes‒」。
昨年からアップデートした点のひとつに、『はじめの一歩』というものがあり、コレクターが初めて作品を買ったときのエピソードがパネルに掲示されている。僕のエピソードも載せてもらっているけど、構えてしまいがち、遠く感じがちな「コレクター」という存在に対して、なんとなく「別にみんな初めて買ったときはドキドキしながら買った普通の人なんだな」と思ってもらえるひとつのきっかけになったらいいと思う。
自分自身、コレクターというくくられ方はまだしっくりはこないけど、僕の場合の「はじめの一歩」をここにも載せておく。
この時のことはよく覚えている。ウィスット・ポンニミット（タムくん）の『I hear your heart beat』というリトグラフ。
ちょうどその前年に、あるイベントで若手のアーティストと話す機会があった。
もともとアートは好きだったけど、歳の近い作家が、生活をかけて好きなことに打ち込んでいる姿と、決して楽ではなくても、「やっぱりゆくゆくは作品一本で食べていけるようになりたいですね」なんて笑って話すのを聞いて、理屈抜きにいいな、応援したいなという気持ちがはっきり輪郭を持った気がした。もっと自由に、軽やかにアートを買える状況を作れたらと思った。
でも、そのときもそれまでも、自分でアートを買ったことはなかった。
それがちょっと、ずっと、引っかかっていた。
だから、4年前の年始、小谷元彦展を見た帰りに、森美術館に併設されたショップでそれを見かけたとき、これは新しい年の始めの買い物に相応しい、素晴らしい思いつきだと思った。
それでも、いざ決心するまでに随分悩んだ。
シャツや靴を買うならそれほど躊躇わない、1万円程度のちいさな版画なのに。
意を決して店員さんに声をかけると、丁寧に梱包して、手渡してくれた。僕はお金を払い、それを手に持って店を出た。
なんてことはない。それだけだった。買えてしまった。
あれだけ悩んでいたのが嘘みたいなあっけなさと同時に、なんとも言えない達成感があった。
シャツや靴にはない、なんだかとてもいいお金の使い方をした気がした。いい気分だった。
家に帰って飾る場所を考えながら、しみじみと、エディションとは言え、一点しかない作品を所有できる嬉しさと、でもどこか作家から預かったような緊張感とが混じりあうような、不思議な感覚を何度も思い出すように味わった。
さっき払った一万円の幾ばくかは、巡り巡ってあのアーティストに届くんだよなというリアルな手触りがあった。
こんなに「物を買う」という行為を意識したことはちょっと記憶にない。
金島隆弘×中村政人スペシャル・トーク：3331 Art Fair 2015 -Various Collectors' Prizes- プレイベント（2015.2.28） /
第2回目を迎える 3331 Art Fair 2015 -Various Collectors' Prizes- が、今年も2015年3月21日（土）～29日（日）に開催されます。
それに先駆けて行われるプレイベント、スペシャル・トーク「これからのアートシーンをつくるアートフェア」にモデレーターとして登壇することになりました。
“
日程： 2015年02月28日（土）
時間： 15:30-17:00
備考： スペシャル・トーク：「これからのアートシーンをつくるアートフェア」プレゼンター：金島隆弘 × 中村政人 ／ モデレーター：高井勇輝
料金： 無料
備考： 定員60名（立見になる場合がございます。）お申し込みは参加人数、お名前、ご連絡先（携帯番号など）を明記の上、こちらまで→af2015@3331.jp 定員になり次第、締め切らせて頂きます。
会場： 2F 206号室
3331 Art Fair 2015 -Various Collectors’ Prizes- プレイベント
■スペシャル・トーク「これからのアートシーンをつくるアートフェア」
■登壇者
・金島隆弘（アートフェア東京プログラム・ディレクター）
・中村政人（3331 Arts Chiyoda統括ディレクター）
／ モデレーター：高井勇輝（株式会社ロフトワーク クリエイティブディレクター）
本年3月に第二回目を予定している「3331 Art Fair 2015 -Various Collectors’Prizes‒ 」の開催に先立ち、プレイベントを行います。年に一度のアートディーラーとコレクターの邂逅の場として、ともすると特殊で閉鎖的なイベントのように思われがちなアートフェアですが、必ずしもそのようなことはありません。むしろ、国際的にはビエンナーレなどの国際展と対をなすアートシーンの重要なイベントとしてアートフェアの認知は近年、非常に増しております。
アートフェア東京プログラム・ディレクター金島隆弘氏と、3331 Arts Chiyoda統括ディレクター中村政人が、東京で同時期に行われる２つのアートフェアの魅力と役割についてお話しいたします。それだけにとどまらず、アートに関わる様々な立場と多様な局面の中でのアートフェアの位置づけと、これからのアートシーンの行方など、時間の許す限りクロストークを行います。
ぜひお楽しみ下さい。”
モデレーターという役割は初めての経験の上、3331 Arts Chiyoda統括ディレクターの中村政人さんと、アートフェア東京プログラム・ディレクターの金島隆弘さんという錚々たるお二方と席を並べるということで、光栄でもあり恐れ多くもあり、とてもドキドキしています。
僕自身はアート業界の人間でもない素人ですが、その「普通のひと」の立場から、そして同時に3331 Art Fairの企画に一枚かませてもらったひとりとして、コレクタープライズのプライズセレクターのひとりとして、ささやかながらアートとの間をつなぐ役割が果たせたらと思います。
もしよろしければ遊びに来て温かく見守っていただけると嬉しいです。