プロトタイプの限界

以前 [社会的プロブレムと個人的プロブレム〜デザインは人のニーズを満たして然るべき〜]
の中でも少し触れた話なのだが、今回は「プロトタイプの限界」についての議論を進めていく

そもそもプロトタイプとは？って人のは…さっきの記事の中か、
プロトタイプは状況に応じて時にラフに、時に詳細に
という記事を読んでいただくことをおすすめします。

一応簡単に書くと

何かの疑問を解決するために作るもの

ということになります。

そんなプロトタイプにも限界があるというのが個人の考え。
ではどういうところに限界があるのか？それは前回の記事でも触れたような話。前回はこんなふうに書いていた。

プロトタイプの限界の章にあるように、プロトタイプは形にしたものを改善する、もしくは評価するのはとてもいい。ただそれ自体が本当にいいものかどうかってのは測れない・・・かもしれない。

つまりそれはどういう事か？
プロジェクトが例えば、「飲み会のエクスペリエンス向上」というお題であったとする。
そして問題点として「お酒をあまり飲まない人が居る」という問題を発見したとする。

それを解決するためにお酒を人に飲ます事のできるソリューションというのを例えばいくつか思いつく、それはアプリケーションなどであったりツールであったり、もしかしたらメニューの構成であったりメンバーであったり席順であったり・・・

そんななかでプロトタイプを作成してテストする。
例えばプロトタイプでお酒を飲ますためのアプリケーションなどを考えたとしよう。そしてそこで「どのインターフェイスがもっとも人を飲む気にさせるか」的な疑問を持ったとする。
そのプロトタイプを通じてどのようなことが分かるだろうか？それはせいぜいどのような要素が飲む気にさせるか程度であり、そもそもそこに疑問を持ったことは正しかったのか？というような一歩引いた意見は出てこなくなってしまうのだ。

もちろんそれは、プロトタイプの失敗という形でみえてくるかもしれない。プロトタイプってのは失敗してなんぼのものであり、それを恐れてプロジェクトは進められない。ただもしも、もっと早くから失敗してしまうかもと見えていれば、というふうに思ったりもする。
まー失敗の定義も難しく何が失敗であるかなど誰にも言えないのだが・・・


失敗の定義がわからない以上、この話を進めるのもナンセンスかもしれない。ただもしよければもう少しお付き合いいただきたい。

自分だったら今回発見した「お酒を飲まない人が居る」という問題について進めることはしない。なんとなく。ではどうするか？
たとえばここで設定した問題を、もう少し深く掘り下げていく。もしかしたらもう少し良い疑問を持てるのかもしれないという期待を込めて。

1. 「お酒を飲まない人が居る」
↓
じゃぁそれはなぜ問題なのか？
↓
それが例えば  2. 「会話に対して同じようなテンションで盛り上がれないから」だとする
 ↓
じゃぁなぜそれも問題なのか？
↓
3. 「みんなで盛り上がりたいから」
↓
 ・・・・

という様に問題というのは基本的にはどんどん深くまで掘り下げることが出来る。ただ掘り下げれば掘り下げるだけ抽象的になってしまうこともあるので注意なのだが、例えば途中の2. の段階で
「じゃぁどうやったら盛り上がれる？」「あまり盛り上がらない、と言われている人が盛り上がるのはどんな時？」「話したくないの？話したいけど話せないの？」「話したいのに話せない、という人は何を考えている？」
などともう少し派生した問題点、もしくはニーズに行き着くことが出来るのも事実。

もしくは1. の段階で「なぜ飲めないのか？」を考えることで
↓
「お酒嫌い」「みんなと飲みたいお酒の種類が違って頼みづらい」

などどの階層にもある

ちなみに最初に設定した問題「お酒を飲まない人が居る」ってのはある意味「個人的プロブレム」ではなく「社会的プロブレム」（こんな場合は環境的プロブレムとでも言うべきなのだろうか？） ( [社会的プロブレムと個人的プロブレム〜デザインは人のニーズを満たして然るべき〜] 参照) であり敢えてへんな問題点を設定したのだが・・・
ただここで後述した問題点、それらはもう少しユーザーに近いニーズなのではないかと自分は考える。見つけた問題点に自信を持つ。そしてそこから「どのように〜」といった疑問をプロトタイプで解決していくことが個人的に考える「良い流れ」だと思う



まとめると、プロトタイプってのは設定した疑問の外側、もしくはそれよりも上層の問題（問題とニーズの階層参照）にはたいてい出得ないものであるのだ。
Build to Think, Think to Build の章で書いたように、もちろんプロトタイプを作ることで、想定した以上のフィードバックに出会うことはある。ただそれでもそれはたいてい設定した疑問よりも上層の問題を解決、発見するには至らない。
これははじめのプロブレムを見つける段階、ニードを見つける段階が如何に大事かを裏付ける事実だと捉えて欲しい。

（この記事は [KNLog: ME310 を通じて自分なりのまとめ] の中の１記事です）

読んでいただきありがとうございます^^
コメント、もしくは評価ボタンを押していただけると幸いです。
↓↓↓↓↓