ナラティブ・プロトタイピング

ナラティブ・プロトタイピング プロダクトメイキングに「物語り」を取り込む Ichitani Toshihiro 市⾕聡啓 Toshihiro Ichitani All Rights Reserved.

市⾕ 聡啓 Ichitani Toshihiro DX伴⾛⽀援 (株式会社レッドジャーニー) 株式会社リコー CDIO付DXエグゼクティブ 特に専⾨は ・仮説検証、アジャイル開発 ・組織アジャイル https://ichitani.com/

• https://ichitani.com/

2022.2.21 https://www.amazon.co.jp/dp/4798172561/

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

本⽇のテーマ 「仮説が⽴たない、浅い問題」 プロダクトづくりがより広がる中で、直⾯するのは「そもそもの仮説が ⽴たない」という問題です。 プロダクトの対象とするユーザーやその状況が わかっているようでわからない。あるいは、わかっているつもりで実は解像度 が⾜りていない。もしくは作り⼿それぞれの中にユーザー理解のヒントは あるかもしれないがチーム内で連結できていない。 結果として「浅いプロダクトづくり」に多⼤な時間を費やしている ということが起こってしまう。

最初の構想は「グズグズ」であるもの ・何がどうなれば正解か分からないものを⾔語化、イメージ化 しようとしているのだから、グズグズであって然るべき ・むしろ中⾝がよく分かるものは⼤した企画ではない よく分かる = 既知のもの = 誰でも思いつく = 競争者が多い ・ただし、何も整理がついていない状態や何⼀つ「切り⼝」がない としたら、進めようがなくなる。 切り⼝ = 新たな発⾒ = 新たな視点 = コンセプトとなるもの ※切り⼝がないとしたら「仮説⽴てから始める」ということ！

どのレベルで「グズグズ」になっている？ なぜやるのか？ 何のためにやるのか？（⽬的） ①そもそものプロダクト・事業の狙いがあいまい ②顧客の視点がない ③数字しかない ④既存事業の延⻑線でカイゼンレベルでしかない WHY HOW WHAT どうやって実現するのか？ ①どうやって実現するかの算段が全く無い ②むしろよくある実現⼿段しかない (=裏返すと狙いが平凡) ③⾃分たちのケイパビリティが活きる観点がない (=他社でもできる) 最初に何をするのか？ ①最初の作戦が全く⽴っていない、何するか認識合ってない ②いきなり開発⽴ち上げになっている(いきなりスプリント1) ③顧客の声や反応を取る予定が全くない ④⾃組織内での合意が取れてないまま始める など

というわけで、皆さん そもそも「仮説」⽴てていますよね

前提(事実)が少ないほど、 仮定(想像)の部分が多い 前提 仮定 期待結果 前提 仮説 検証 仮定 期待結果 ゆえに仮説検証で仮定(想像=分からん)を 減らし、前提(事実=分かった)を増やす

探索適応型の事業・プロダクト開発 仮説検証型アジャイル開発 選択の幅最⼤ （セットベース） 検証 計画 仮説⽴案 (モデル化) 価値探索 スプリントプ ランニング 検証 MVP特定 （正しいものを探す） 評価 開発計画 (リリースプラ ンニング) 選択の振れ幅最⼩ （ポイントベース） スプリント 開発 アジャイル開発 （正しくつくる） スプリント レトロスペク ティブ MVP検証 スプリント レビュー 次の検証計画 (価値探索)へ 仮説検証 選択肢を⼗分に広げた後に 検証によって絞り適応 アジャイル 検証結果を早期に形とし フィードバックを得て適応

ベースは「リーン製品開発」 リーン製品開発とは、トヨタ製品開発(⽣産⽅式ではない)を源流とする、 海外におけるプロダクト開発の⽅法論。 初期段階では「取り得る選択肢」を広くとり、その後に段階的に絞り込んでいく ことで「当たり」を引こうとする考え⽅(セットベース／集合ベース)。 (逆に、最初から決め打ちで⼀点集中する考え⽅をポイントベースと呼ぶ) ☓ ○ ☓ ☓ 機能・形態仮説 ☓ ○ ☓ ※ 漏⽃が選択肢の幅をイメージしている ☓ MVP検証 ☓ ☓ ○ ☓ ☓ ☓ ☓ ☓ 課題仮説 ○ ☓ MVP特定 ○ ○ ※MVP検証段階でユーザーのリアルな反応 によって再び仮説(選択肢)が広がる

セットが広すぎるまま = 判断基準が壊れている ☓ ○ ☓ ☓ ☓ ○ ☓ ☓ ○ ☓ ☓ 選択肢への判断基準がゆるく絞りきれていない 何でも有りになりがちで、後々でも思いつきで ⽅向性が⼤きく変わる ☓ ○ ☓ ☓ ☓ ☓ ☓ ☓ ☓ ☓ ☓ ○ 採⽤の失敗 判断基準がないため、なんでもかんでも採⽤してしまう失敗

最初から絞りすぎ = 過去の経験と判断が全て 最初から絞れる = 過去の経験や判断基準に基づく絞り込み ゆえに、新たなユーザー体験など新規性の⾼い取り組むでは その後の成否はほぼ⼀か⼋かになる ☓ ○ ☓ ☓ ☓ ☓ ○ ☓ ☓ ○ ☓ ☓ ☓ ○ ☓ 却下の失敗 判断基準が過去に依っており、新規性の取り組みはだいたい リジェクトになってしまう失敗

分からないこと分かるようにする =「学びの積み上げ」 採⽤の失敗 (基準が無い) 仮説検証による意思決定 プロセスに取り組む 仮説検証による「学び」 の積み上げ = 基準作り 選択肢(仮説)を広げて可能性を ⾼めるセットベースの啓蒙 却下の失敗 (過去の基準のみ)

仮説検証の周回によって「学び」積み上げる 1周⽬ ⽬標は最初のPS tの⼿がかり(顧客は誰か？課題は何か？)を得ること 仮説を⽴てる (仮説キャンバス) 探索的検証 (顧客インタビュー) 仮説の再定義 2周⽬ ⽬標はストーリーの解像度を⾼めて、PS tの確からしさを上げること (価値があるか？) イメージを作る (ストーリーボード等) イメージを伴う検証 (顧客インタビュー) 仮説の再定義 3周⽬ ⽬標はソリューションの解像度を⾼めて、PS tの確からしさを上げること (価値があるか？) プロトタイプを作る (No Code Prototyping) 操作を伴う検証 (プロトタイプ検証) 仮説の再定義 4周⽬ ⽬標は実際に使えるプロダクトを提供して、PS tを確かめること fi fi fi (ユーザー⾏動フロー) 利⽤体験を伴う検証 (MVP検証) fi MVP特定と開発 仮説のPivot もしくは事業化

仮説には「構造」がある まず解くべき「問い」を発⾒する 次に、問いに答えられる「⼿段」を模索する そして、⼿段を扱えるようにするための「形」を⽤意する 問い = 本質的な課題や要望 = 課題仮説 ⼿段 = 課題の解決や 要望を充⾜する⼿段 = 機能仮説 形 = ⼿段を利⽤可能 とする形 = 形態仮説 「形は⼿段に従い、⼿段は問いに従う」

検証の周回によって確かめる仮説が異なる 1周⽬ ⽬標は最初のPS tの⼿がかり(顧客は誰か？何が必要？)を得ること 仮説を⽴てる (仮説キャンバス) 探索的検証 仮説の再定義 (顧客インタビュー) 課題仮説の検証 課題は何か？ 顧客は誰か？ fi 最初のインタビューは ほぼ実地調査に近い 想定ユーザーの状況把握に務める

検証の周回によって確かめる仮説が異なる 2周⽬ ⽬標はストーリーの解像度を⾼めて、PS tの確からしさを上げること (価値があるか？) (ストーリーボード等) イメージを伴う検証 (顧客インタビュー) 仮説の再定義 機能仮説の検証 課題仮説の検証 ストーリーボードなどで イメージを伝えて反応をもらう ゆえに機能の検証を伴う fi イメージを作る

検証の周回によって確かめる仮説が異なる 3周⽬ ⽬標はソリューションの解像度を⾼めて、PS tの確からしさを上げること (価値があるか？) (No Code Prototyping) 操作を伴う検証 (プロトタイプ検証) 機能仮説の検証 仮説の再定義 課題仮説の検証 プロトタイプによって ユーザーが検証に参画できる より機能の検証度合いが⾼められる fi プロトタイプを作る

検証の周回によって確かめる仮説が異なる 4周⽬ ⽬標は実際に使えるプロダクトを提供して、PS tを確かめること (ユーザー⾏動フロー) 仮説のPivot もしくは事業化 利⽤体験を伴う検証 (MVP検証) 課題仮説の検証 形態仮説の検証 機能仮説の検証 単体で動作するMVPを⽤いて 検証するため、想定ユーザーが ⾃⼒で使いこなせるか否かをみる fi MVP特定と開発

この繰り返しで⾏っていることは？ 探索と適応 選択肢を広げるため 結果から分かったことで の仮説⽴案と検証 次の判断と⾏動を変える たいてい1Week=1スプリントで検証活動を進める 1周回をだいたい6スプリント程度で回す Photo on VisualHunt

仮説検証の周回によって「学び」積み上げる 1周⽬ ⽬標は最初のPS tの⼿がかり(顧客は誰か？課題は何か？)を得ること 仮説を⽴てる (仮説キャンバス) 探索的検証 (顧客インタビュー) 仮説の再定義 2周⽬ ⽬標はストーリーの解像度を⾼めて、PS tの確からしさを上げること (価値があるか？) まずもってやるべきことは 「仮説」を⽴てること イメージを作る (ストーリーボード等) イメージを伴う検証 (顧客インタビュー) 仮説の再定義 3周⽬ ⽬標はソリューションの解像度を⾼めて、PS tの確からしさを上げること (価値があるか？) プロトタイプを作る (No Code Prototyping) 操作を伴う検証 (プロトタイプ検証) 仮説の再定義 4周⽬ ⽬標は実際に使えるプロダクトを提供して、PS tを確かめること fi fi fi (ユーザー⾏動フロー) 利⽤体験を伴う検証 (MVP検証) fi MVP特定と開発 仮説のPivot もしくは事業化

仮説キャンバス ⽬的 われわれはなぜこの事業をやるのか？ 実現⼿段 提案価値を実現 するのに必要な ⼿段とは何か？ 優位性 提案価値 提案価値や実現 ⼿段の提供に貢 献するリソース (資産)が何かあ るか？ われわれは顧客 をどんな解決状 態にするのか？ (何ができるよ うになるのか) ビジョン 中⻑期的に顧客にどういう状況に なってもらいたいか？ 顕在課題 顧客が気づいて いる課題に何が あるか？ 潜在課題 どうなればこの 事業が進捗して いると判断でき るのか？ 多くの顧客が気 づけていない課 題、解決を諦め ている課題に何 があるか？ 収益モデル どうやって儲けるのか？ 状況 課題を解決するた どのような状況 にある顧客が 対象なのか めに顧客が現状 取っている⼿段に 何があるか？ (踏まえて現状⼿段 への不満はあるか) 評価指標 (指標と基準値) 代替⼿段 チャネル 状況にあげたひ とたちに出会う ための⼿段は何 か？ 市場規模 対象となる市場の規模感は？ (課題が最も発⽣ する状況とは？) 傾向 同じ状況にある ⼈が⼀致して⾏ うことはある か？

fi fi 2つの ”締めどころ” きちんと締まっているかを⾒る Context Problem t 状況 Context Problem Solution t 課題 解決策 欲求 提案価値+実現⼿段 Problem Solution

fi fi 2つの ”締めどころ” 課題に対して、解決策で打ち返す構造になっているか Context Problem t Problem Solution t ①課題仮説 を⽴てる 状況 Context 課題 ②課題に適した 解決策の 仮説を⽴てる 解決策 欲求 提案価値+実現⼿段 Problem Solution

fi fi 2つの ”締めどころ” 課題が、より先鋭化する状況を仮説⽴てられているか Context Problem t Problem Solution t 対象者を仮決め して、その状況を 探索、理解深める 状況 Context 課題 解決策 欲求 提案価値+実現⼿段 Problem Solution

どこまで掘れているか （レベル1） デスクトップリサーチで分かるレベル ちょっと調べたら類似サービスや競合、事例が 分かるのに調べられてないということはないか （レベル2） 有識者や顧客ヒアリングで分かるレベル 実際に話を聞いてみる、領域に詳しい有識者に ヒアリングをしてみる、が出来ているか （レベル3） コンセプトを作って叩いているレベル 収集した情報から⾃分たちなりの「切り⼝」を 決めて、社内外での磨き込みを⾏っているか とっとと調査 (⼿段は選ばない) なんだかんだ ⾜で稼げ 多様な意⾒を 集めて磨く

仮説キャンバス ⽬的 われわれはなぜこの事業をやるのか？ 実現⼿段 提案価値を実現 するのに必要な ⼿段とは何か？ 優位性 提案価値 提案価値や実現 ⼿段の提供に貢 献するリソース (資産)が何かあ るか？ われわれは顧客 をどんな解決状 態にするのか？ (何ができるよ うになるのか) ビジョン 中⻑期的に顧客にどういう状況に なってもらいたいか？ 顕在課題 顧客が気づいて いる課題に何が あるか？ 代替⼿段 状況 課題を解決するた どのような状況 にある顧客が 対象なのか めに顧客が現状 取っている⼿段に 何があるか？ よくある仮説キャンバスの状態 (踏まえて現状⼿段 への不満はあるか) 評価指標 潜在課題 どうなればこの 事業が進捗して いると判断でき るのか？ 多くの顧客が気 づけていない課 題、解決を諦め ている課題に何 があるか？ (指標と基準値) 収益モデル どうやって儲けるのか？ チャネル 状況にあげたひ とたちに出会う ための⼿段は何 か？ 市場規模 対象となる市場の規模感は？ (課題が最も発⽣ する状況とは？) 傾向 同じ状況にある ⼈が⼀致して⾏ うことはある か？

課題が⼀般的すぎる (誰にでも思いつける) 仮説キャンバス ⽬的 ビジョン われわれはなぜこの事業をやるのか？ 実現⼿段 優位性 提案価値を実現 提案価値や実現 するのに必要な ⼿段の提供に貢 献するリソース ⼿段とは何か？ ⽬的⾃体が浅い (資産)が何かあ (やらなくても良いのでは) るか？ 提案価値 われわれは顧客 をどんな解決状 態にするのか？ (何ができるよ うになるのか) 評価指標 どうなればこの 事業が進捗して いると判断でき 課題の裏返しでしかない るのか？ どうやって儲けるのか？ 顕在課題 顧客が気づいて いる課題に何が あるか？ 代替⼿段 状況 課題を解決するた どのような状況 にある顧客が 対象なのか めに顧客が現状 取っている⼿段に 何があるか？ (踏まえて現状⼿段 への不満はあるか) 潜在課題 (指標と基準値) 「Aできない」→「Aできる」 収益モデル ユーザーの解像度が荒すぎて 中⻑期的に顧客にどういう状況に 誰にインタビューすれば良いか なってもらいたいか？ 分からない 多くの顧客が気 づけていない課 題、解決を諦め ている課題に何 があるか？ 市場規模 チャネル する状況とは？) 傾向 状況にあげたひ 同じ状況にある とたちに出会う ⼈が⼀致して⾏ ための⼿段は何 安易な想像 うことはある か？ か？ ユーザーの状況が分からない ため潜在課題が無い、浅い 対象となる市場の規模感は？ “サブスク” くらいしか 書いていない (課題が最も発⽣

課題が⼀般的すぎる (誰にでも思いつける) 仮説キャンバス ⽬的 ビジョン われわれはなぜこの事業をやるのか？ 実現⼿段 優位性 提案価値 ユーザーの解像度が荒すぎて 中⻑期的に顧客にどういう状況に 誰にインタビューすれば良いか なってもらいたいか？ 分からない 顕在課題 代替⼿段 状況 課題を解決するた どのような状況 にある顧客が 対象なのか なぜ仮説が浅くなるのか？ 提案価値を実現 提案価値や実現 するのに必要な ⼿段の提供に貢 献するリソース ⼿段とは何か？ ⽬的⾃体が浅い (資産)が何かあ (やらなくても良いのでは) るか？ われわれは顧客 をどんな解決状 態にするのか？ (何ができるよ うになるのか) 顧客が気づいて いる課題に何が あるか？ めに顧客が現状 取っている⼿段に ① 想定ユーザーを知らなすぎる ② プロダクトアウトに偏りすぎ 評価指標 どうなればこの 事業が進捗して いると判断でき 課題の裏返しでしかない るのか？ 収益モデル どうやって儲けるのか？ (踏まえて現状⼿段 への不満はあるか) 潜在課題 (指標と基準値) 「Aできない」→「Aできる」 何があるか？ 多くの顧客が気 づけていない課 題、解決を諦め ている課題に何 があるか？ 市場規模 チャネル する状況とは？) 傾向 状況にあげたひ 同じ状況にある とたちに出会う ⼈が⼀致して⾏ ための⼿段は何 安易な想像 うことはある か？ か？ ユーザーの状況が分からない ため潜在課題が無い、浅い 対象となる市場の規模感は？ “サブスク” くらいしか 書いていない (課題が最も発⽣

なのでユーザー⾏動フロー (Orカスタマージャーニーマップorユーザーストーリーマッピング) で、想定ユーザーについての理解を深めよう！

なのでユーザー⾏動フロー (Orカスタマージャーニーマップorユーザーストーリーマッピング) で、想定ユーザーについての理解を深めよう！ カスタマージャーニーマップでは 仮説を語るには解像度がまだ⾜りない (浅いものがそれっぽく⾒えるだけ)

なのでユーザー⾏動フロー (Orカスタマージャーニーマップorユーザーストーリーマッピング) この箱だけでどのくらい語れる？ で、想定ユーザーについての理解を深めよう！ 前の箱と次の箱の間で 何が起きているか語れる？ この後どうなっていくの？ このソリューションの使われ⽅について どれくらい”⻑話”ができるか？ (⻑話ができる=想像ができている)

ユーザーとソリューションの状況の解像度を上げて捉える ナラティブ・プロトタイピング Photo credit: jjpacres on VisualHunt

ナラティブ・プロトタイピングとは？ ストーリー形式 (⼩さな物語) で「問題が解決されていく状況」 や「ニーズが満たされていく様⼦」を表現する なぜストーリー形式を取るのか？ ① 想定ユーザーの取り巻く状況を「線と箱」でラフに表すのでは なく出来るだけ詳細に分かるようにしたいから ② 説明⽂ではなく物語であることで登場⼈物(想定ユーザー)の ⼼情まで表現することができるから ③ ⽂章なので消したり書いたり、作り直しが容易いから ④ ⽂章なので「絵で表現する」より参加しやすいから ⑤ 読めば分かるのでフィードバックが⾏いやすい いつ作るのか？ 仮説を⽴てる前に作る。作ったストーリーを 元に仮説キャンバスで仮説を⽴てる。

ナラティブ・プロトタイピングの3つの特徴 プロトタイピング (作って壊しが容易い) ストーリー (ユーザーの内⾯まで表現できる) ストーリーによるプロト 「モデル」でも「説明」で タイプだから妄想段階で も無い為「⼼情」まで表現 も形にできる できる 参加型 (参加障壁が極めて低い) 絵だと誰かに書いてもらう必要がある。結局伝えるという⾏為 が必要。もっと⾃分のイメージ通りにプロダクトを表現しよう フィードバック (読めば分かるので誰でもできる) ストーリーだから基本的に読めば分かる。 つまりその分フィードバックが集めやすい

そもそもコンセプト作り⾃体を 外部の⾼邁なデザイナーやコンサルタントに丸投げして これから⻑く取り組むプロダクトの「構想」を ⾃分のものにできるのか？ すごそうなそれっぽい解答を外から買ってくるのではなくて ⾃分で考え、⼿を動かし、形にする感覚を取り戻そう Photo credit: jjpacres on VisualHunt

ナラティブ・プロトタイピングの段取り テーマや アイデアを 洗い出す 対象テーマや アイデアを 絞り込む 登場する⼈物の ペルソナ・イン サイドを描く 登場シーンの 整理を⾏う ナラティブの 原型を描く まずコアとなるテーマや ナラティブ・プロトタイピ ナラティブ・ストーリーは ペルソナ・インサイドを描 ペルソナ・インサイドと、 アイデア群を洗い出しま ングでは、ナラティブ・ス 物語です。新たなサービス いた後は、新しいサービス 登場シーンと⾏動の流れの す。ここはナラティブ・ス トーリーと呼ぶ、新たな を先⾏して享受し、その価 をどのような流れで利⽤す 想定を元に、ストーリーを トーリーを描く前段階で サービスがリアリティを 値を体現してくれる存在と るのか、想定します。登場 作ります。と⾔っても、い す。まずは断⽚的でもアイ もってイメージできる⼩さ して「登場⼈物」の設定が ⼈物の動きを概要レベルで きなり完成した⽂章を作る デアを挙げます な物語を描いていきます。 重要です。 書き出します。 わけではありません。 今、事業として取り組んで ナラティブは複数本描いて 登場⼈物のペルソナを描き アウトプットは簡易的な 箇条書きレベルで、⾏動の いる領域について最も詳し も構いませんが、数が多く ましょう。ただし、通常の ユーザー⾏動フローのイ 流れを詳しくしていくイ いのは皆さん⾃⾝のはずで なるとその分制作にも時間 ペルソナとは異なり、より メージです。あくまでどう メージです。これをナラ す。ラフなブレストでも構 がかかります。洗い出した 内⾯(インサイド)にある、 いう局⾯でどんな動きをす ティブの原型と呼び、この いません、数を出すことを テーマやアイデアを組み合 考え⽅や価値観、ライフス るのかが分かるためのアウ 段階でフィードバックを集 ⽬指しましょう。 わせるなどして3つ以下に タイルなどの⾔語化をしっ トラインです。アウトライ めます。 かりと⾏うようにします。 ンを⼿かがりにストーリー 絞り込みましょう。 で詳細化します。

ペルソナ・インサイド 最初はラフに登場⼈物の内⾯ (インサイド)を書き表す。通常のペルソナに ⽐べて、⾏動よりも内⾯にある志向性や思考性に重点を置いて書き出す。 あくまでメインは取り組むチームで意⾒を出し合う時間を作り発散すること。 「誰か⼀⼈でまとめたもの」ではなく各⾃の持っている経験や知⾒を寄せ合う

ナラティブの原型 各シーンに対して、ペルソナ・インサイドを踏まえて、 具体的なストーリーをナ記述します。実際には「内容」の欄は、 通常3000⽂字程度、多い場合は軽く1万⽂字を超えます。 フィードバックは各ストーリーの節ごとに⾏います。おおよそ、 100-200⽂字ごとに節を分けて記述します。 ナラティブ・プロトタイピングの最も重要なのは、各ストーリー に対して、参画者がフィードバックを上記のように上げることで す。具体的になったストーリーを元に、よりイメージを深めるの が狙いです。 ①何が違うのか②何が合致するのか ①②について、ゼロベース で挙げていくのは難しくても、具体的なストーリーに対しては 意⾒としてコメントが出来るものです。 また、ストーリーになった時点でアイデアは特定の⼈物の⼿を離 れていきます。⼈に紐付いたアイデアには意⾒が⾔いにくい場合 がありますが、ストーリーになればハードルが下がります。

ナラティブ ≠ ストーリー Aさん Bさん Cさん… 個々個別の意⾒がフィードバックされる = 多様性を包含しつつ、最終的には⼀つのストーリーとして総合する 表現⼿段がストーリーであって、ナラティブ＝ストーリーなのではない。 ナラティブとは「語り」を意味する。構想を⾃分ごと化し、⾃分⾃⾝を当事者に近 づけていくことをこのプロトタイピングでは狙いの⼀つとしている。 ナラティブの原型に対する「⾃分はこう思う」「⾃分だったらこうする」そうした 個々の主張と意⾒が表出され、⼀つのモノに総合されていく。このプロセスを 「語り」として捉え、ナラティブ・プロトタイピングを称している。

ナラティブ・プロトタイピングの反復 ナラティブの 原型への フィードバック （繰り返す） ナラティブ・ ストーリーを 描く 前⾴のとおり、スプレッド フィードバックが出し切れ 原型を統合し、完成された 原型同様に、⽂書への 第一版として、ストーリー シートベースで、ナラティ るまで、フィードバックと ストーリーを作る。Word フィードバックを集めま を完成させます。 ブ原型へのフィードバック 整理を繰り返します。 ⽂書にまとめて、読み物と す。 フィードバックの取捨選択 どうしても意⾒が整わない この段階でも、フィード この段階でのフィードバッ もチームで⾏います。まと 場合は、ナラティブ⾃体を バックを必要に応じて集め クの取捨選択もまとめ役が め役は⼀⼈置いたほうがよ 分けることも⾏う。どちら ます。原型の頃は⼀部のプ ⾏います。ストーリーが破 いでしょう。誰かがまとめ の意⾒もありえるのであれ ロジェクト参画者だけの場 綻しないように整理しま ていかないと発散し続ける ば、どちらも残すようにし 合が多いですが、完成され す。 ためです。ただし、取捨選 ます。 を集めます。 択が参画者の意⾒と合わな いこともあります。フィー ドバックと整理を繰り返す 中で意⾒を調整していきま す ナラティブ・ ストーリーへの フィードバック して完成させます。 たストーリーについてはよ りフィードバックを集める 範囲を広げます（部⾨全員 など） ナラティブ・ ストーリーの 完成

ナラティブ・プロトタイピングの良さとは 形(⽂章)にすることで、ある程度解像度を⾼めつつ、構想を作っていく ことができる その過程で⾃分たちの理解⾃体を深めながら、思いを乗せられる 幅広く適⽤できる → toC や toB向け企画、働き⽅のデザイン、 プロダクトや組織のビジョン作り等 Photo credit: jjpacres on VisualHunt

でもストーリーが書けなかったら？ もちろん、とっても浅い語りになってしまうことは⼗分にある。 ⼀つは、段取りで⾏うワークを通じて段々と⾃分たちの 「⾔葉」を獲得していくこと。 もう⼀つは、⼀旦未熟でもストーリーとして完成させて、 より多くのフィードバックを集めに出ること。 Photo credit: Guudmorning! on Visualhunt.com

fi fi … “前提” がしょぼしょぼだと ありのままの ”写像” では分かっていることしか描けない Context Problem t 状況 Context Problem Solution t 課題 欲求 Problem 解決策 Solution

最終的には⾃分たちで新しい状況を作るという⽅向性になる Vision Context t fi fi fi 新たな「状況」を作る Context Problem t 世界観 価値観 状況 Vision Context Problem Solution t 課題 欲求 Problem 解決策 Solution

⾃分の中にある経験や知識をもとに 信条、思想、価値観、思いを持って いるからこそコンセプトが語れる 経験がない、思うこともない ではコンセプトは語れない …つまり、経験を得よ、思考を得よ ということ （だから観察/対話/体験で ⾃分の中⾝を得る）

新たな状況を現実に作る ↑ 新たなモノの⾒⽅を⽣み出す （世界観） ↑ ナラティブ・アプローチ

ナラティブ描いて、それからどうするの？ もちろん、仮説検証に出る！「妄想」を「仮説」に置き換えよう。 ⼗分にフィードバックが得られたら、「ナラティブ」から「仮説キャンバス」 にトランジションする。「原型」の段階で「仮説の観点」を埋め込んでおく ことで「仮説」を取り出しやすくする。 原型の段階で「仮説の観点」を埋め込んでおく

参考になる図書 ナラティブ・プロトタイピングは、デザインフィクションやSFプロトタイピングを 参考にしている。ただし、より「参加型」「フィードバック」を重視し、かつ ディストピアからの逆算ではなくよりリアリティのあるプロダクトメイキングを 想定して構成している。

プロダクトについて、もっと物語ろう ⻑話できるくらいに⾃分たちの企みを愛せ