EDP-C

1. プロトタイピングとユーザーテスト
2016‑12‑10
エンジニアリングデザインプロジェクトC
東京工業大学環境・社会理工学院特任講師
角征典<kado.m.aa@m.titech.ac.jp>

2. なぜプロトタイピングをするのか？
「学習するため」以上
先に「何を学びたいか？」を明らかにする
労力をかけずに学習できるとコスパがいい
最小のコストで何かを学習できるプロダクト
→ MVP（MinimumViableProduct）
動画型MVP：Dropbox
コンシェルジュ型MVP：AirBnB
2

3. プロトタイプの種類（時系列）
引用："A Method for the Management of Service Innovation
Projects in Mature Organizations" Figure7. Overalldesignprocess
depictingdivergingandconvergingstages
3

4. P1：CriticalFunctionPrototype
顧客のニーズや課題を理解するためのプロトタイプ
プロダクトを「ひとこと」で表現するなら？
これが外れていると、まるで意味がないような機能
チラシのキャッチコピーに使えるような代表的な機能
まだ動かなくても大丈夫（ニーズや課題の理解が目的なので）
ダンボールやプレゼン資料でもOK
まずはこれを当てましょう
一発では当たらないので、松・竹・梅を出して比較するとよい
4

5. P2: DarkhorsePrototype
これはどうなんだ？みたいな実験のプロトタイプ
「改良」ではなく「イノベーション」を目指すための思考実験
「ないわー」と思うものでも、とりあえず作ってみましょう
最初のうちにリスクが高いものを検証しておくとコストが安い
議論する暇があったら手を動かそう
ふざけた気持ちでやるといいと思う
5

6. P3: FunKtionalPrototype
これまでのプロトタイプを統合したプロトタイプ
まずはとにかく一気に放り込んでみよう
とりあえず何とか動く、みたいな状態を目指そう
このへんから「プロダクト」の影がちらつき始める
機能の取捨選択のための「製品コンセプト」が必要になるかも
スタートアップでは「Why this?」「Why now?」「Why you?」の
「3つのWhy」に答えることが重要と言われている
6

7. P4: FunctionalPrototype
実際に動く/機能するプロトタイプ
FunKtionalから機能を厳選したもの
「機能増えすぎ」にならないように注意して作ろう
機能はシンプルなほうが美しい！
ここで動くかどうかわからない……は避けよう（feasiblityを確保）
このあたりからそろそろ「最終プロダクト」を意識しよう
ここで大きく転換すると、いろいろコストがかかりすぎる……。
7

8. P5: X‑is‑FinishedPrototype
中心的な機能がきちんと動くプロトタイプ
まずは中心的な機能だけに注力しよう
そこだけ動けば、あとは想像力で補ってもらう
EDP‑Cの最終発表はこのあたりを目指したい
8

9. P6: FinalPrototype
すべての機能がきちんと使えるプロトタイプ
ユーザーがひととおり利用できるプロトタイプ
本格的なユーザーテストが可能になる
ここまでできれば、すごい!!
9

10. プロトタイピングとユーザーテスト
1つのプロトタイプにつき5人にインタビューする
参考：5ユーザーでテストすれば十分な理由
<https://u‑site.jp/alertbox/20000319>
インタビューの結果：
成功しているパターンが見つかれば、次のプロトタイピングへ
ダメそうなパターンが見つかれば、もういちどチャレンジ!!
※ パターンについては、KJ法やCJMを使って分析しましょう
2週間ごとにイテレーションをまわせれば理想的
1月末までにP3 / P4 / P5
最終発表会までにP4 / P5 / P6
……あたりを目指すのはどうだろう？
10

11. ユーザーテストのヒント
課題やニーズの強い人にテストしよう（アーリーアダプター）
何度もテストに協力してもらおう（毎回見つけるのは大変）
あんまり説明しないようにしよう（Show, don't tell）
実際の状況で使ってもらう（仕事のツールなら仕事場で）
複数の案を比較してもらおう（1つだけを評価するのは難しい）
オープンエンドクエスチョンで質問しよう
11

12. ユーザーテストのフォーマット
あくまでもサンプルのフォーマット。自由に調整してください。
1. 温かい歓迎と感謝の言葉（2分間）→ 雰囲気と場作り
2. ユーザー情報の収集（2分間）→ アーリーアダプターか？
3. 課題やニーズの確認（2分間）→ 簡単に説明（説明しすぎない）
4. プロトタイプを使ってもらう（10分間）→ 思考発話法
5. 実際の利用状況を意識した質問（10分間） → before/ after
6. 成否を判定する質問（2分間）→ 次のステージ？ 再挑戦？
7. 次回のテストの予約or 誰か紹介してもらう（2分間）
（時間）は目安。これは全体で30分になるように調整したもの。
12

13. 参考文献
『RunningLean』（オライリー・ジャパン）
『リーンエンタープライズ』（オライリー・ジャパン）
『Sprint: How toSolveBigProblems andTest New Ideas inJust
FiveDays』（Simon& Schuster）
BernhardSchindlholzer (University ofSt. Gallen, Switzerland),
FalkUebernickel(University ofSt. Gallen, Switzerland) and
Walter Brenner (University ofSt. Gallen, Switzerland) "A Method
for the Management of Service Innovation Projects in
Mature Organizations"
13