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

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

市⾕聡啓
Ichitani Toshihiro
DX伴⾛⽀援 (株式会社レッドジャーニー)
特に専⾨は

・仮説検証、アジャイル開発

・組織アジャイル
https://ichitani.com/
株式会社リコー CDIO付DXエグゼクティブ

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

本⽇のテーマ

「仮説が⽴たない、浅い問題」

プロダクトづくりがより広がる中で、直⾯するのは「そもそもの仮説が

⽴たない」という問題です。プロダクトの対象とするユーザーやその状況が

わかっているようでわからない。あるいは、わかっているつもりで実は解像度
が⾜りていない。もしくは作り⼿それぞれの中にユーザー理解のヒントは

あるかもしれないがチーム内で連結できていない。

結果として「浅いプロダクトづくり」に多⼤な時間を費やしている

ということが起こってしまう。

最初の構想は「グズグズ」であるもの
・何がどうなれば正解か分からないものを⾔語化、イメージ化

しようとしているのだから、グズグズであって然るべき

・むしろ中⾝がよく分かるものは⼤した企画ではない

よく分かる = 既知のもの = 誰でも思いつく = 競争者が多い

・ただし、何も整理がついていない状態や何⼀つ「切り⼝」がない

としたら、進めようがなくなる。

切り⼝ = 新たな発⾒ = 新たな視点 = コンセプトとなるもの

※切り⼝がないとしたら「仮説⽴てから始める」ということ！

WHAT
HOW
どのレベルで「グズグズ」になっている？
WHY
なぜやるのか？

何のためにやるのか？（⽬的）
どうやって実現するのか？
最初に何をするのか？
①そもそものプロダクト・事業の狙いがあいまい

②顧客の視点がない

③数字しかない

④既存事業の延⻑線でカイゼンレベルでしかない
①どうやって実現するかの算段が全く無い

②むしろよくある実現⼿段しかない (=裏返すと狙いが平凡)

③⾃分たちのケイパビリティが活きる観点がない

(=他社でもできる)
①最初の作戦が全く⽴っていない、何するか認識合ってない

②いきなり開発⽴ち上げになっている(いきなりスプリント1)

③顧客の声や反応を取る予定が全くない

④⾃組織内での合意が取れてないまま始めるなど

というわけで、皆さん

そもそも「仮説」⽴てていますよね

前提(事実)が少ないほど、

仮定(想像)の部分が多い
ゆえに仮説検証で仮定(想像=分からん)を

減らし、前提(事実=分かった)を増やす
前提
仮定
期待結果
前提
仮定
期待結果
仮説

検証

選択の幅最⼤

（セットベース）
検証

計画
仮説⽴案

(モデル化)
検証
評価
価値探索

（正しいものを探す）
MVP特定
開発計画

(リリースプラ
ンニング)
スプリントプ
ランニング
スプリント

開発
スプリント

レビュー
スプリント

レトロスペク
ティブ
MVP検証
アジャイル開発

（正しくつくる）
次の検証計画

(価値探索)へ
選択の振れ幅最⼩

（ポイントベース）
探索適応型の事業・プロダクト開発

仮説検証型アジャイル開発
仮説検証

選択肢を⼗分に広げた後に
検証によって絞り適応
アジャイル

検証結果を早期に形とし

フィードバックを得て適応

ベースは「リーン製品開発」
課題仮説機能・形態仮説 MVP特定
MVP検証
リーン製品開発とは、トヨタ製品開発(⽣産⽅式ではない)を源流とする、

海外におけるプロダクト開発の⽅法論。

初期段階では「取り得る選択肢」を広くとり、その後に段階的に絞り込んでいく

ことで「当たり」を引こうとする考え⽅(セットベース／集合ベース)。
(逆に、最初から決め打ちで⼀点集中する考え⽅をポイントベースと呼ぶ)
※ 漏⽃が選択肢の幅をイメージしている ※MVP検証段階でユーザーのリアルな反応

によって再び仮説(選択肢)が広がる
○
○
○
☓
☓
☓
☓
☓
☓
☓
☓
☓
☓
☓
☓
☓ ☓
○
○
○

セットが広すぎるまま = 判断基準が壊れている
採⽤の失敗
選択肢への判断基準がゆるく絞りきれていない

何でも有りになりがちで、後々でも思いつきで

⽅向性が⼤きく変わる
判断基準がないため、なんでもかんでも採⽤してしまう失敗
○
☓
○
☓
☓
☓ ☓ ☓
☓
☓ ☓
☓
☓
☓ ☓
○
○
○
☓
☓
☓
☓
☓

最初から絞りすぎ = 過去の経験と判断が全て
却下の失敗
最初から絞れる = 過去の経験や判断基準に基づく絞り込み
ゆえに、新たなユーザー体験など新規性の⾼い取り組むでは

その後の成否はほぼ⼀か⼋かになる
判断基準が過去に依っており、新規性の取り組みはだいたい

リジェクトになってしまう失敗
☓ ☓ ☓
☓
☓
☓
☓
☓
☓
☓
☓
○
○
○
○

分からないこと分かるようにする =「学びの積み上げ」
採⽤の失敗

(基準が無い)
却下の失敗

(過去の基準のみ)
仮説検証による意思決定
プロセスに取り組む
仮説検証による「学び」

の積み上げ = 基準作り
選択肢(仮説)を広げて可能性を

⾼めるセットベースの啓蒙

仮説を⽴てる

(仮説キャンバス)
探索的検証

(顧客インタビュー)
仮説の再定義
1周⽬⽬標は最初のPS
fi
tの⼿がかり(顧客は誰か？課題は何か？)を得ること
2周⽬⽬標はストーリーの解像度を⾼めて、PS
fi
tの確からしさを上げること (価値があるか？)
イメージを作る

(ストーリーボード等)
イメージを伴う検証

仮説の再定義
3周⽬⽬標はソリューションの解像度を⾼めて、PS
fi
プロトタイプを作る

(No Code Prototyping)
操作を伴う検証

(プロトタイプ検証)
仮説の再定義
4周⽬⽬標は実際に使えるプロダクトを提供して、PS
fi
tを確かめること
MVP特定と開発

(ユーザー⾏動フロー)
利⽤体験を伴う検証

(MVP検証)
仮説のPivot

もしくは事業化
仮説検証の周回によって「学び」積み上げる

仮説には「構造」がある
課題仮説
機能仮説
形態仮説
本質的な課題や要望
課題の解決や

要望を充⾜する⼿段
⼿段を利⽤可能

とする形
問い
⼿段
形
まず解くべき「問い」を発⾒する

次に、問いに答えられる「⼿段」を模索する

そして、⼿段を扱えるようにするための「形」を⽤意する
=
=
=
=
=
=
「形は⼿段に従い、⼿段は問いに従う」

仮説を⽴てる

探索的検証

仮説の再定義
fi
tの⼿がかり(顧客は誰か？何が必要？)を得ること
検証の周回によって確かめる仮説が異なる
課題仮説の検証
顧客は誰か？
課題は何か？
最初のインタビューは

ほぼ実地調査に近い

想定ユーザーの状況把握に務める

fi


仮説の再定義
機能仮説の検証
ストーリーボードなどで

イメージを伝えて反応をもらう

ゆえに機能の検証を伴う

fi


仮説の再定義
プロトタイプによって

ユーザーが検証に参画できる

より機能の検証度合いが⾼められる

fi
MVP特定と開発


(MVP検証)
仮説のPivot

形態仮説の検証
単体で動作するMVPを⽤いて

検証するため、想定ユーザーが

⾃⼒で使いこなせるか否かをみる

Photo on VisualHunt
探索と適応
この繰り返しで⾏っていることは？
選択肢を広げるため

の仮説⽴案と検証
結果から分かったことで

次の判断と⾏動を変える
たいてい1Week=1スプリントで検証活動を進める

1周回をだいたい6スプリント程度で回す

仮説を⽴てる

探索的検証

仮説の再定義
fi
tの⼿がかり(顧客は誰か？課題は何か？)を得ること
fi


仮説の再定義
fi


仮説の再定義
fi
MVP特定と開発


(MVP検証)
仮説のPivot

仮説検証の周回によって「学び」積み上げる
まずもってやるべきことは

「仮説」を⽴てること

仮説キャンバス
われわれはなぜこの事業をやるのか？
⽬的ビジョン
実現⼿段優位性
評価指標
提案価値顕在課題
潜在課題
代替⼿段
チャネル
状況
収益モデル市場規模
中⻑期的に顧客にどういう状況に
なってもらいたいか？
提案価値を実現
するのに必要な
⼿段とは何か？
提案価値や実現
⼿段の提供に貢
献するリソース
(資産)が何かあ
るか？
どうなればこの
事業が進捗して
いると判断でき
るのか？

(指標と基準値)
われわれは顧客
をどんな解決状
態にするのか？

(何ができるよ
うになるのか)
顧客が気づいて
いる課題に何が
あるか？
多くの顧客が気
づけていない課
題、解決を諦め
ている課題に何
があるか？
課題を解決するた
めに顧客が現状
取っている⼿段に
何があるか？

(踏まえて現状⼿段
への不満はあるか)
状況にあげたひ
とたちに出会う
ための⼿段は何
か？
どのような状況
にある顧客が

対象なのか

(課題が最も発⽣
する状況とは？)
どうやって儲けるのか？対象となる市場の規模感は？
傾向
同じ状況にある
⼈が⼀致して⾏
うことはある
か？

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

課題
解決策
欲求
状況
Context -
Problem
fi
t
Problem -
Solution
fi
t
課題に対して、解決策で打ち返す構造になっているか
①課題仮説

を⽴てる
②課題に適した
解決策の

仮説を⽴てる

課題
解決策
欲求
状況
Context -
Problem
fi
t
Problem -
Solution
fi
t
課題が、より先鋭化する状況を仮説⽴てられているか
対象者を仮決め

して、その状況を
探索、理解深める

どこまで掘れているか
（レベル1）デスクトップリサーチで分かるレベル
ちょっと調べたら類似サービスや競合、事例が

分かるのに調べられてないということはないか
（レベル2）有識者や顧客ヒアリングで分かるレベル
実際に話を聞いてみる、領域に詳しい有識者に

ヒアリングをしてみる、が出来ているか
（レベル3）コンセプトを作って叩いているレベル
収集した情報から⾃分たちなりの「切り⼝」を

決めて、社内外での磨き込みを⾏っているか
とっとと調査

(⼿段は選ばない)
なんだかんだ

⾜で稼げ
多様な意⾒を

集めて磨く

⽬的ビジョン
評価指標
潜在課題
代替⼿段
チャネル
状況
るか？
るのか？


(何ができるよ
うになるのか)
あるか？
があるか？
何があるか？

か？
にある顧客が

対象なのか

傾向
うことはある
か？
よくある仮説キャンバスの状態

⽬的ビジョン
評価指標
潜在課題
代替⼿段
チャネル
状況
るか？
るのか？


(何ができるよ
うになるのか)
あるか？
があるか？
何があるか？

か？
にある顧客が

対象なのか

傾向
うことはある
か？
課題が⼀般的すぎる

(誰にでも思いつける)
ユーザーの状況が分からない
ため潜在課題が無い、浅い
課題の裏返しでしかない

「Aできない」→「Aできる」
ユーザーの解像度が荒すぎて

誰にインタビューすれば良いか

分からない
⽬的⾃体が浅い

(やらなくても良いのでは)
安易な想像
“サブスク” くらいしか

書いていない

⽬的ビジョン
評価指標
潜在課題
代替⼿段
チャネル
状況
るか？
るのか？


(何ができるよ
うになるのか)
あるか？
があるか？
何があるか？

か？
にある顧客が

対象なのか

傾向
うことはある
か？
課題が⼀般的すぎる

(誰にでも思いつける)
ユーザーの状況が分からない
ため潜在課題が無い、浅い
課題の裏返しでしかない

「Aできない」→「Aできる」
ユーザーの解像度が荒すぎて

誰にインタビューすれば良いか

分からない
⽬的⾃体が浅い

(やらなくても良いのでは)
安易な想像
“サブスク” くらいしか

書いていない
なぜ仮説が浅くなるのか？

① 想定ユーザーを知らなすぎる
② プロダクトアウトに偏りすぎ

なのでユーザー⾏動フロー

(Orカスタマージャーニーマップorユーザーストーリーマッピング)

で、想定ユーザーについての理解を深めよう！



カスタマージャーニーマップでは

仮説を語るには解像度がまだ⾜りない

(浅いものがそれっぽく⾒えるだけ)



この箱だけでどのくらい語れる？
前の箱と次の箱の間で

何が起きているか語れる？
このソリューションの使われ⽅について

どれくらい”⻑話”ができるか？

(⻑話ができる=想像ができている)
この後どうなっていくの？

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

ナラティブ・プロトタイピングとは？
ストーリー形式 (⼩さな物語) で「問題が解決されていく状況」

や「ニーズが満たされていく様⼦」を表現する
なぜストーリー形式を取るのか？

① 想定ユーザーの取り巻く状況を「線と箱」でラフに表すのでは
 
なく出来るだけ詳細に分かるようにしたいから

② 説明⽂ではなく物語であることで登場⼈物(想定ユーザー)の
 
⼼情まで表現することができるから

③ ⽂章なので消したり書いたり、作り直しが容易いから

④ ⽂章なので「絵で表現する」より参加しやすいから

⑤ 読めば分かるのでフィードバックが⾏いやすい
いつ作るのか？仮説を⽴てる前に作る。作ったストーリーを

元に仮説キャンバスで仮説を⽴てる。

プロトタイピング

(作って壊しが容易い)
ストーリー

(ユーザーの内⾯まで表現できる)
参加型

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

(読めば分かるので誰でもできる)
「モデル」でも「説明」で

も無い為「⼼情」まで表現

できる

そもそもコンセプト作り⾃体を

外部の⾼邁なデザイナーやコンサルタントに丸投げして

これから⻑く取り組むプロダクトの「構想」を

⾃分のものにできるのか？

すごそうなそれっぽい解答を外から買ってくるのではなくて

⾃分で考え、⼿を動かし、形にする感覚を取り戻そう

ナラティブ・プロトタイピングの段取り
テーマや

アイデアを

洗い出す
対象テーマや

アイデアを

絞り込む
まずコアとなるテーマや

アイデア群を洗い出しま
す。ここはナラティブ・ス
トーリーを描く前段階で
す。まずは断⽚的でもアイ
デアを挙げます

今、事業として取り組んで
いる領域について最も詳し
いのは皆さん⾃⾝のはずで
す。ラフなブレストでも構
いません、数を出すことを
⽬指しましょう。
登場する⼈物の

ペルソナ・イン

サイドを描く
登場シーンの

整理を⾏う
ナラティブの

原型を描く
ナラティブ・プロトタイピ
ングでは、ナラティブ・ス
トーリーと呼ぶ、新たな
サービスがリアリティを
もってイメージできる⼩さ
な物語を描いていきます。

ナラティブは複数本描いて
も構いませんが、数が多く
なるとその分制作にも時間
がかかります。洗い出した
テーマやアイデアを組み合
わせるなどして3つ以下に
絞り込みましょう。
ナラティブ・ストーリーは
物語です。新たなサービス
を先⾏して享受し、その価
値を体現してくれる存在と
して「登場⼈物」の設定が
重要です。

登場⼈物のペルソナを描き
ましょう。ただし、通常の
ペルソナとは異なり、より
内⾯(インサイド)にある、
考え⽅や価値観、ライフス
タイルなどの⾔語化をしっ
かりと⾏うようにします。
ペルソナ・インサイドを描
いた後は、新しいサービス
をどのような流れで利⽤す
るのか、想定します。登場
⼈物の動きを概要レベルで

書き出します。

アウトプットは簡易的な
ユーザー⾏動フローのイ
メージです。あくまでどう
いう局⾯でどんな動きをす
るのかが分かるためのアウ
トラインです。アウトライ
ンを⼿かがりにストーリー
で詳細化します。
ペルソナ・インサイドと、
登場シーンと⾏動の流れの
想定を元に、ストーリーを
作ります。と⾔っても、い
きなり完成した⽂章を作る
わけではありません。

箇条書きレベルで、⾏動の
流れを詳しくしていくイ
メージです。これをナラ
ティブの原型と呼び、この
段階でフィードバックを集
めます。

ペルソナ・インサイド
最初はラフに登場⼈物の内⾯ (インサイド)を書き表す。通常のペルソナに

⽐べて、⾏動よりも内⾯にある志向性や思考性に重点を置いて書き出す。

あくまでメインは取り組むチームで意⾒を出し合う時間を作り発散すること。

「誰か⼀⼈でまとめたもの」ではなく各⾃の持っている経験や知⾒を寄せ合う

ナラティブの原型
各シーンに対して、ペルソナ・インサイドを踏まえて、

具体的なストーリーをナ記述します。実際には「内容」の欄は、
通常3000⽂字程度、多い場合は軽く1万⽂字を超えます。

フィードバックは各ストーリーの節ごとに⾏います。おおよそ、
100-200⽂字ごとに節を分けて記述します。
ナラティブ・プロトタイピングの最も重要なのは、各ストーリー
に対して、参画者がフィードバックを上記のように上げることで
す。具体的になったストーリーを元に、よりイメージを深めるの
が狙いです。

①何が違うのか②何が合致するのか ①②について、ゼロベース
で挙げていくのは難しくても、具体的なストーリーに対しては

意⾒としてコメントが出来るものです。

また、ストーリーになった時点でアイデアは特定の⼈物の⼿を離
れていきます。⼈に紐付いたアイデアには意⾒が⾔いにくい場合
がありますが、ストーリーになればハードルが下がります。

ナラティブ ≠ ストーリー
表現⼿段がストーリーであって、ナラティブ＝ストーリーなのではない。

ナラティブとは「語り」を意味する。構想を⾃分ごと化し、⾃分⾃⾝を当事者に近
づけていくことをこのプロトタイピングでは狙いの⼀つとしている。

ナラティブの原型に対する「⾃分はこう思う」「⾃分だったらこうする」そうした
個々の主張と意⾒が表出され、⼀つのモノに総合されていく。このプロセスを

「語り」として捉え、ナラティブ・プロトタイピングを称している。
個々個別の意⾒がフィードバックされる

= 多様性を包含しつつ、最終的には⼀つのストーリーとして総合する
Aさん Bさん Cさん…

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

原型への

（繰り返す）
前⾴のとおり、スプレッド
シートベースで、ナラティ
ブ原型へのフィードバック
を集めます。

フィードバックの取捨選択
もチームで⾏います。まと
め役は⼀⼈置いたほうがよ
いでしょう。誰かがまとめ
ていかないと発散し続ける
ためです。ただし、取捨選
択が参画者の意⾒と合わな
いこともあります。フィー
ドバックと整理を繰り返す
中で意⾒を調整していきま
す
ナラティブ・

ストーリーを

描く
ナラティブ・

ストーリーへの

ナラティブ・

ストーリーの

完成
フィードバックが出し切れ
るまで、フィードバックと
整理を繰り返します。

どうしても意⾒が整わない
場合は、ナラティブ⾃体を
分けることも⾏う。どちら
の意⾒もありえるのであれ
ば、どちらも残すようにし
ます。
原型を統合し、完成された
ストーリーを作る。Word
⽂書にまとめて、読み物と
して完成させます。

この段階でも、フィード
バックを必要に応じて集め
ます。原型の頃は⼀部のプ
ロジェクト参画者だけの場
合が多いですが、完成され
たストーリーについてはよ
りフィードバックを集める
範囲を広げます（部⾨全員
など）
原型同様に、⽂書への
フィードバックを集めま
す。

この段階でのフィードバッ
クの取捨選択もまとめ役が
⾏います。ストーリーが破
綻しないように整理しま
す。
第一版として、ストーリー
を完成させます。

ナラティブ・プロトタイピングの良さとは
形(⽂章)にすることで、ある程度解像度を⾼めつつ、構想を作っていく
ことができる

その過程で⾃分たちの理解⾃体を深めながら、思いを乗せられる

幅広く適⽤できる → toC や toB向け企画、働き⽅のデザイン、
 
プロダクトや組織のビジョン作り等

Photo credit: Guudmorning! on Visualhunt.com
でもストーリーが書けなかったら？

もちろん、とっても浅い語りになってしまうことは⼗分にある。

⼀つは、段取りで⾏うワークを通じて段々と⾃分たちの

「⾔葉」を獲得していくこと。

もう⼀つは、⼀旦未熟でもストーリーとして完成させて、

より多くのフィードバックを集めに出ること。

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

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

価値観
Vision -
Context

fi
t
Vision

⾃分の中にある経験や知識をもとに
信条、思想、価値観、思いを持って
いるからこそコンセプトが語れる
経験がない、思うこともない

ではコンセプトは語れない

…つまり、経験を得よ、思考を得よ

ということ

（だから観察/対話/体験で

⾃分の中⾝を得る）

新たな状況を現実に作る

↑

新たなモノの⾒⽅を⽣み出す

（世界観）

↑

ナラティブ・アプローチ

ナラティブ描いて、それからどうするの？
原型の段階で「仮説の観点」を埋め込んでおく
もちろん、仮説検証に出る！「妄想」を「仮説」に置き換えよう。

⼗分にフィードバックが得られたら、「ナラティブ」から「仮説キャンバス」

にトランジションする。「原型」の段階で「仮説の観点」を埋め込んでおく

ことで「仮説」を取り出しやすくする。

参考になる図書
ナラティブ・プロトタイピングは、デザインフィクションやSFプロトタイピングを
参考にしている。ただし、より「参加型」「フィードバック」を重視し、かつ

ディストピアからの逆算ではなくよりリアリティのあるプロダクトメイキングを

想定して構成している。

プロダクトについて、もっと物語ろう

⻑話できるくらいに⾃分たちの企みを愛せ

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

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

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

Similar to ナラティブ・プロトタイピング (20)

More from toshihiro ichitani

More from toshihiro ichitani (18)

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