正しくないものをつくらない。7つの失敗パターン

正しくないものをつくらない - サービスづくり7つの失敗パターン Ichitani Toshihiro Toshihiro Ichitani All Rights Reserved. 市⾕聡啓

Ichitani Toshihiro 市⾕聡啓 ギルドワークス株式会社 代表 株式会社 エナジャイル 代表 ⼀般社団法⼈ 越境アジャイルアライアンス代表理事 DevLOVE コミュニティ ファウンダ ソフトウェア開発16年 SIer→サービス→受託→起業 仮説検証とアジャイル開発 0→1 http://about.me/papanda0806 Toshihiro Ichitani All Rights Reserved.

• http://about.me/papanda0806

本⽇のテーマ のべ200本以上(推定)の サービスづくりの中で、 よくある失敗パターン(体感) Copyright (c) 2017 Guild Works Inc.

7つの失敗パターン Copyright (c) 2017 Guild Works Inc.

失敗① Copyright (c) 2017 Guild Works Inc.

こういうサービスをつくりたい。 (必要とするユーザーは必ずいる！) Copyright (c) 2017 Guild Works Inc.

こういうサービスをつくりたい。 (必要とするユーザーは必ずいる！) 想像だけで始めてしまう。 既にプロダクトをつくるという意思決定が 終わっているが、その根拠が特にない。 (担当のたぶんこうなんじゃないかという勘) Copyright (c) 2017 Guild Works Inc.

よくあるケース 社⻑の肝⼊り。 俺はこうやって当ててきた。 この領域のユーザーのことは俺が⼀番知っている。 とりあえずつくりたい。 この経産省の資料によると〜 → まず、担当者の本気度を測る。 Copyright (c) 2017 Guild Works Inc.

このサービスをつくるのに、 明⽇、銀⾏に⾏って、 ⾃分でお⾦を借りて、始められますか？ Copyright (c) 2017 Guild Works Inc.

このサービスをつくるのに、 明⽇、銀⾏に⾏って、 ⾃分でお⾦を借りて、始められますか？ (あるいは、この仕事を引き受ける場合の⾃分の本気度を⾃分に問う) Copyright (c) 2017 Guild Works Inc.

よくあるケース 社⻑の肝⼊り。 俺はこうやって当ててきた。 この領域のユーザーのことは俺が⼀番知っている。 とりあえずつくりたい。 この経産省の資料によると〜 ⾃信が無ければたいてい踏みとどまる可能性があるが、 結果を背負っている(まさにお⾦を借りてくる!)、 社⻑(アントレプレナー)には通じない。 Copyright (c) 2017 Guild Works Inc.

それでもやるかどうかは、「正しいものをつくる!」とは もはや別の判断 「鉄壁の中のアジャイル」 https://www.slideshare.net/papanda/ss-79239778 Copyright (c) 2017 Guild Works Inc.

• https://www.slideshare.net/papanda/ss-79239778

「想像だけで始めてしまう。」 問題はなに？ できること(仮説検証)をやっていない。 (「勘と経験」に基づく判断が必ずしも誤りなわけでもない) どうする？ 仮説検証のやり⽅や考え⽅は世の中に沢⼭あるので ⾃分のケースにどう適⽤するかを設計する。 (設計においては「⾃分が何を分かっていないか」を想像してみる) Copyright (c) 2017 Guild Works Inc.

不分明に対する戦略 -What- ⾃分が 分かっている ⾃分が 分かっていない 他⼈(⾃分以外)が 分かっている 他⼈(⾃分以外)が 分かっていない ⾃明 競争優位 顕在課題の 仮説検証 潜在課題の 仮説検証 まず、分かっていること、分かっていないことを キャンバスで棚卸しする。 Copyright (c) 2017 Guild Works Inc.

不分明に対する戦略 -How⾃分が分かっていないこと(仮説)を分かるようにする(検証) ための⼿段が分からない ⼿段を学ぶための練習を⾏なう ・仮想のテーマでトライアル、⼿段はなんぼでもある。 仮説検証の経験者と組む ・ただし、仮説検証の理論だけあれば良いわけではない。 実案件で取り組むならば、実現可能性の議論が並⾏して必要。 (もちろん、ギルドワークスにご相談どうぞ。) 「仮説検証型アジャイル開発の提案」 https://right.guildworks.jp/ Copyright (c) 2017 Guild Works Inc.

• https://right.guildworks.jp/

失敗② Copyright (c) 2017 Guild Works Inc.

ウーバー版◯◯をつくりたい。 (Uberのモデルに乗っかろう) Copyright (c) 2017 Guild Works Inc.

ウーバー版◯◯をつくりたい。 (Uberのモデルに乗っかろう) 優位性とつながっていない。 モデルを転⽤するのは良いが、転⽤先の領域に 何かしら⾃社の競争優位性があるわけではない。 いくらでも思いついちゃって(◯◯の部分)、 ⼀つも前に進められない。 Copyright (c) 2017 Guild Works Inc.

「優位性とつながっていない。」 問題はなに？ 「われわれはなぜここにいるのか？」他ならぬ ⾃分たちがこのテーマを取り組む理由は何か？ に答えられない段階でも、意思決定してしまう。 結果、判断としては ・「優位性はつくりこむ」→ コスト度外視？ ・「先⾏することが優位性」→ 先⾏≠参⼊障壁 になりがち。スタートはできても継続する⼒が不⾜。 Copyright (c) 2017 Guild Works Inc.

「優位性とつながっていない。」 どうする？ モデルの転⽤はアイデアを「発散」する際に利⽤し 「収束」はキャンバス思考で⾏なう。 Copyright (c) 2017 Guild Works Inc.

何がどうあるべきかの仮説を構造で捉える 仮説キャンバス Toshihiro Ichitani All Rights Reserved. Photo credit: perceptions (off) via Visualhunt / CC BY-ND

何がどうあるべきかの仮説を構造で捉える 仮説キャンバス Toshihiro Ichitani All Rights Reserved. Photo credit: perceptions (off) via Visualhunt / CC BY-ND

「優位性とつながっていない。」 どうする？ モデルの転⽤はアイデアを「発散」する際に利⽤し 「収束」はキャンバス思考で⾏なう。 優位性は「他ならぬ⾃分たちが取り組むべき理由」として、具体 的に挙げられる既存事業のリソース、データ、ソリューション、 状況など。 「提案価値」や「(新しい)ソリューション」、「チャネル」に 現れる。 優位性棚卸→課題解決の創出、課題解決の仮説→優位性探索 両⽅向ある。 Copyright (c) 2017 Guild Works Inc.

失敗③ Copyright (c) 2017 Guild Works Inc.

これで課題解決できる！ (…でも、何かピリッとしない感じ？) Copyright (c) 2017 Guild Works Inc.

これで課題解決できる！ (…でも、何かピリッとしない感じ？) アテンションにあたる価値がない。 想定ユーザー、顧客の課題を解決できる仕組みは 構想できたし、何なら検証の結果もまずまず。 しかし、検証では「ユーザーが⾶びつくほどの 感じ」ではない。本当にこれで良いのか？ アテンション(=注⽬)にあたる価値が⽋けている かもしれない。 Copyright (c) 2017 Guild Works Inc.

「アテンションにあたる価値がない」 問題はなに？ 「使ってもらえたら、(価値を感じてもらえる)」 という仮定。その仮定はたいてい成⽴しない。 「使ってもらえたら、」という仮定を満たすために 「チャネル」獲得にいくらリソースを投⼊しても できるのは「届ける」こと。 「届く」と「⽬を引く」は違う。 Copyright (c) 2017 Guild Works Inc.

「アテンションにあたる価値がない」 どうする？ 提案価値は２種類存在する。 ① 利⽤することで価値を実感できる ② どう考えてもメリットでしかないと即時判断できる 「無料」「◯◯不要」「無制限」etc 既に顕在化された課題であり代替⼿段が無い場合、 あるいは代替⼿段に不満がある場合 → 存在⾃体が価値。 しかし、代替⼿段で既に課題解決できている、 あるいは潜在課題の場合 → まず利⽤する動機が必要。 Copyright (c) 2017 Guild Works Inc.

ユーザーが利⽤するまでのストーリーを描く ユーザーに「届き」、既存の代替⼿段からの 「スイッチングコスト」を凌駕する「お！」を もたらせられるか。 ストーリーで点検する。 ストーリーとは… ユーザーがプロダクトを理解するための⼿段。 対象を認識するための枠組み。 やることとしては… ユーザーに味わってもらいたいプロダクトの 利⽤体験を、出来事の固まりごとに配置する。 Copyright (c) 2017 Guild Works Inc.

失敗④ Copyright (c) 2017 Guild Works Inc.

検証で結果が出た！ Aさんのインタビュー結果はダメだった けど、この⼈はユーザーではない。 Copyright (c) 2017 Guild Works Inc.

検証で結果が出た！ Aさんのインタビュー結果はダメだった けど、この⼈はユーザーではない。 検証結果を都合良く解釈してしまう この⼈はユーザーではない、 10⼈中7⼈がOKだったから、OK この機能がまだ無かったから、ダメだっただけ… ⾃分の⾒⽅に偏り(バイアス)があることに、 ⽣まれていることに、気づけていない。 Copyright (c) 2017 Guild Works Inc.

「検証結果を都合良く解釈してしまう」 問題はなに？ 都合の良い解釈で、誤った意思決定してしまう。 また、想定ユーザー側が事実を語っておらず、 解釈は正しいが、データが誤っている場合もある。 (定量的な数値判断が出来ない段階ではこの⼿の誤りが起きやすい) Copyright (c) 2017 Guild Works Inc.

「検証結果を都合良く解釈してしまう」 どうする？ 仮説検証=モデル(構造)の成⽴ AさんはOK、BさんはNG、10⼈中7⼈OKだからOK! と、少ないNで定量的に判断するのではなくて、 「モデル(構造)が成り⽴っているか」を⾒る。 つまり、キャンバスの基本構造 「状況」-「課題」-「代替⼿段」-「提案価値」 が成りたっているか。 Copyright (c) 2017 Guild Works Inc.

キャンバスで仮説(PSfitの構造)を⽴てる 構造=仮説 仮説としておいた状況はあてはまるか？ この状況下で課題はどの程度切実か？ ： 構造=事実 ユーザーインタビューの結果から、 「想定している課題が成⽴するのは ◯◯という状況にあるとき。」 →キャンバスの状況をupdate。 Copyright (c) 2017 Guild Works Inc. ユーザーインタビュー ※データの誤りの可能性は常にあるため 解釈者がインタビューを⾏なうべき。

失敗⑤ Copyright (c) 2017 Guild Works Inc.

課題の仮説も、ソリューションの仮説も 検証できた。あとは機能を開発！ Copyright (c) 2017 Guild Works Inc.

課題の仮説も、ソリューションの仮説も 検証できた。あとは機能を開発！ 体験の検証をやっていない インタビューやモックアップでの検証を通じて 仮説の構造を成り⽴たせるところまで来た。 ⾔葉や絵、イメージで想定ユーザーとの コミュケーションは取れているかもしれない。 でも、UserはまだはUseしていないけど⼤丈夫？ Copyright (c) 2017 Guild Works Inc.

「体験の検証をやっていない」 問題はなに？ 想定ユーザーの利⽤体験を成り⽴たせることが 出来るのか、まったく検証しないままつくり はじめてしまう。 MVPの検証の⽬的が分かれるところである。 ① 体験の検証のために ② あくまでプロダクト開発 なのか。②の場合「つくりすぎのムダ」の可能性が⾼い。 Copyright (c) 2017 Guild Works Inc.

何の検証を⾏っているのか？ そもそも仮説とは何か？仮説には3つの側⾯を捉えることができる。 「利⽤者の課題についての仮説」「サービスの機能についての仮説」 「ユーザーインターフェースについての仮説」なのか。 それぞれ、提供サービスの「本質」「実体」「形態」にあたる。 それぞれが検証の対象。 か かた かたち 課題の仮説 機能の仮説 UIの仮説 本質 どんな状況の⼈たちの、 どんな問題を解決するのか = 本質的な価値 実体 本質的な価値が利⽤者に もたらされるために必要な 機能とは何か=機能性 形態 利⽤者が機能を使えるために 適したUIとは何か = ユーザビリティ Copyright (c) 2017 Guild Works Inc. 参考「代謝建築論―か・かた・かたち」 https://www.amazon.co.jp/dp/4395012086

• https://www.amazon.co.jp/dp/4395012086

「体験の検証をやっていない」 どうする？ 代替MVP 体験の検証の難しさは「最も精度の⾼い検証結果を 得るためにはプロダクトそのものが必要」という点。 代替⼿段をMVPに⾒⽴てて検証を⾏なう。 全く⽤途が異なる製品だが主要機能が合致する。 ex. チャット機能がメインの体験の検証 = チャットアプリ 想定状況が異なるため機能は⼀致しないが⽬的は果たせる。 ex. 何かをリストで管理する体験の検証 = タスク管理アプリ Copyright (c) 2017 Guild Works Inc.

失敗⑥ Copyright (c) 2017 Guild Works Inc.

どうやって、このサービスを ユーザーに届けるかって？ 広告と、⼝コミさ。 Copyright (c) 2017 Guild Works Inc.

どうやって、このサービスを ユーザーに届けるかって？ 広告と、⼝コミさ。 チャネルの検証をやっていない 開発がほぼ終わりを迎える頃に、チャネルの検討を 本格的に始める。 構想段階では「広告と⼝コミ」という置きの想定 しかない。結果、実現段階では「広告」頼み。 ユーザーにどうやって知ってもらうの戦いの開幕。 Copyright (c) 2017 Guild Works Inc.

「チャネルの検証をやっていない」 問題はなに？ ユーザーにどうやって届けるかの算段が初期の 段階では、後回しになりがち。 そもそも、インタビューでの検証を⾏なう時に 「インタビュー相⼿が確保できない」という状況 から学びを得なければならない。 インタビューもできないのに、どうやってユーザー に届けるのか？ Copyright (c) 2017 Guild Works Inc.

「チャネルの検証をやっていない」 どうする？ ⾃前の会員基盤や代理チャネルの活⽤などをあてに するにしても、想定ユーザーの「現在の状況=(傾向)」 を把握し、新しいソリューションが「届く」までの ストーリーに無理がないか、⾒⽴てが必要。 この場合のチャネルも「仮説」なので「検証」を⾏なう。 ⾃前の会員は新しいサービスに⾒向きするのか？ 代理チャネルはこちらの⾔い分をどの程度聞いて動いて くれるのか？ Copyright (c) 2017 Guild Works Inc.

失敗⑦ Copyright (c) 2017 Guild Works Inc.

MVPが完成した！ さて、どうやって売ろうか。 Copyright (c) 2017 Guild Works Inc.

MVPが完成した！ さて、どうやって売ろうか。 事業を始めてしまう 分かりやすい動くモノがまとまって得られると、 組織的な圧⼒、また関係者(当事者含む)の期待が ⾼まり「どうやって売るか、どのくらい売れるか」 の議論と活動が始まってしまう。 Copyright (c) 2017 Guild Works Inc.

「事業を始めてしまう」 問題はなに？ MVPで検証したいのはビジネスモデル。 事業を始めてしまうと、モデルの検証ではなく ビジネス⾃体が始まってしまう。 結果、「達成すべき収益計画」へのコミット圧が ⾼まり、体制が構築され、コストを抑える議論が 早期に始まり、検証が進まないまま、突き進んで しまう。(まさに顧客開発モデルの問題意識の再現) Copyright (c) 2017 Guild Works Inc.

顧客開発モデル スティーブン・G・ブランク⽒が提唱する⽅法論。 ⼈、資⾦、時間を投⼊したにも関わらず必要とされないプロダクトを 開発してしまったという従来型の事業開発の失敗を回避するプロセス。 「顧客の声」を聞きながら進めていくモデル。 顧客発⾒ 顧客実証 (価値検証) (成⻑検証) 顧客開拓 組織構築 ピボット (軌道修正) 従来の事業開発である、 ①組織構築(営業体制、開発体制)→②顧客開拓(営業)→③顧客実証(販売)→④顧客発⾒(ニーズ充⾜) とは逆の流れが「顧客開発」。顧客が発⾒できた後(仮説の検証後)に、組織をつくる。 Copyright (c) 2017 Guild Works Inc.

「事業を始めてしまう」 どうする？ キャンバスの⽬的とビジョンを置く 「なぜ、この事業をやるのか」という⽬的から 「なぜ、このMVPをつくるのか」や、 「このMVPで何をするべきなのか」まで 落とし込んで置く。 Copyright (c) 2017 Guild Works Inc.

「事業を始めてしまう」 どうする？ 先⼿を打って、線表をつくる とはいえ、関係者の期待圧は直接的に制御できない 可能性があり、とやかく⾔われる前に線表を作る。 新規事業づくりで、あえて「線表」をつくる狙いは、 関係者に向けた「意思表明」である。 線表には、いつ、何をするかが書かれている。 逆に「いつまでは何をしない」を表現することになる。 (特に開発段階の中盤〜終盤には可視化しておく) Copyright (c) 2017 Guild Works Inc.

7つの失敗に⾄る2つの背景 Copyright (c) 2017 Guild Works Inc.

基本は、リーン製品開発 トヨタ⽣産⽅式をプロダクト開発に適⽤したプロセスとして「リーン製品開発」がある。 リーン製品開発では、選択肢の幅を中⼼においた「セットベース」という考え⽅が基本。 正解を誰も持っていない、不確実な環境においては選択肢を早期に絞りきると、 ⼤きなムダであり、時間的なロス(ゼロからの⽴ち上げを繰り返す)となる場合がある。 構想段階 検証段階 ソリューション設計段階 アイデアの幅 デザイン思考等で広げる ソリューションの幅 ⽅向性を定める 仮説検証結果を踏まえて絞る ※選択肢は、ユーザーや顧客にサービス、 事業を届けるところで再び広がっていく。 このサイクルを繰り返す

ベンチャーの場合 = セットが広すぎる 採⽤の失敗 ☓ ◯ ◯ ◯ 選択肢採⽤の基準がゆるく、 絞りきれていない。 何でもありになりがちで、 後々でも思いつきで⽅向性が変わる ☓ ☓ 基準が無い、ゆるいため、ダメなアイデア でも先に進めてしまう。 検証していない、できていないために 7つの失敗が起きる。

⼤企業の場合 = ポイントベース 却下の失敗 ◯ ◯ ◯ ☓ 選択肢採⽤の基準が厳しすぎる。 不確実なことでも予めの検討を 詳細に求められれる。 途上で、組織的判断でアイデアが死ぬ。 ☓ ◯ ☓ ☓ 基準が厳しすぎるため、検証しないと 判断できないことも却下される。 結果的に、検証していない、恣意的な判断に基づくため 7つの失敗が起きる。

組織の傾向性がもたらす2つの失敗 <組織⼒学のタイプ> 採⽤の失敗 スタートアップ・ベンチャー ⼤企業、中堅企業 却下の失敗 参考：「イノベーションを巻き起こす「ダイナミック組織」戦略」 スタートアップ・ベンチャー ⼤企業、中堅企業(組織の歴史が⻑い) する確度が⾼い。 確度が⾼い。 アントレプレナーが意思決定を主導する。 取り組み・企画は採⽤されやすく、ゆえに、 採⽤の誤り(正しくないものをつくる)が発⽣ 意思決定は組織の⼿順に則り稟議として⾏われる。 取り組み・企画への却下は⾏われやすく、ゆえに、 却下の誤り(正しいものをつくらない)が発⽣する

正しくないものを、つくらない。 採⽤の失敗 スタートアップ・ベンチャー 正しくないものを、 つくらない ⼤企業、中堅企業 仮説検証型 事業創出の動機づけ 却下の失敗 「正しくないものを、つくらない。」 スタートアップ、ベンチャーの⽅には、「正しくないものを、つくらない」アプローチを。 ⼤企業、中堅企業の⽅には、まず第⼀に、アントレプレナー型の事業創出(仮説検証)の動機づけを。 踏まえて、「正しくないものを、つくらない」アプローチを。

求められるのは、 採⽤の失敗を抑えながら、製品開発を⾏う⼿段。 仮説の確からしさを検証しながら、漸進する開発。 仮説検証型アジャイル開発 ①正しくない仮説を採⽤しないよう「検証に基づく意思決定」を前提とする ②状況に応じて、仮説検証の「精度」と「頻度」を調整する Toshihiro Ichitani All Rights Reserved.

仮説検証の「精度」と「頻度」のマネジメント 検証の頻度 精度よりも頻度を重視 バランスのとれた頻度と精度 頻度よりも精度を重視 検証の精度 (1)精度よりも頻度を重視 (2)頻度よりも精度を重視 (3)バランスのとれた頻度、精度 数多くの検証を得て、集中すべき 領域・テーマが判断できている段階。 ⼀定の検証を得て、領域は絞れたが 実現⼿段の⽅向性が決めきれない。 検証⼿段の精度(作り込み)よりも 試⾏する回数(幅)を選びたい。 現実に実⾏した場合とほぼ同レベルの 検証結果を得たいため、検証⼿段を作 り込む(MVP)。 より確度の⾼い検証結果を得るために 運⽤プロダクトほどではないが、 ユーザーがサービスの体験が味わえる 程度のプロトタイプを作り込む。 集中すべき領域・テーマがまだ 無い段階。

作戦によって、検証と開発の配分を適応させる。 (1)精度よりも頻度を重視 (2)頻度よりも精度を重視 (3)バランスのとれた頻度、精度 数多くの検証を得て、集中すべき 領域・テーマが判断できている段階。 ⼀定の検証を得て、領域は絞れたが 実現⼿段の⽅向性が決めきれない。 検証⼿段の精度(作り込み)よりも 試⾏する回数(幅)を選びたい。 現実に実⾏した場合とほぼ同レベルの 検証結果を得たいため、検証⼿段を作 り込む(MVP)。 より確度の⾼い検証結果を得るために 運⽤プロダクトほどではないが、 ユーザーがサービスの体験が味わえる 程度のプロトタイプを作り込む。 集中すべき領域・テーマがまだ 無い段階。 状況に応じて、取るべきモードが変わる モード(1) モード(2) モード(3)

7つの失敗パターンと、2つの背景 採⽤の失敗 却下の失敗 想像だけで 始めてしまう 優位性と つながっていない アテンションにあたる 価値がない 検証結果を都合良く 解釈してしまう 体験の検証を やってない チャネル検証を やってない 事業を始めてしまう

失敗には学びがある。ただし、時間は有限だ。 学ぶために失敗する。ただし、時間は有限だ。 限りある時間の中で、何を学ぶべきなのか。 何を⾃分の経験として学び、何を他⼈の経験から学ぶのか? 参考：検証２年！七転び⼋起きで進めてきた事業開発【不屈の仮説検証】 https://guildworks.jp/works/item.html?id=30 Copyright (c) 2017 Guild Works Inc.

• https://guildworks.jp/works/item.html?id=30

良い検証を。 Toshihiro Ichitani All Rights Reserved.