事業を作り始める時、まずは小さく始めるべきという話は何度かお話させて頂きました。
でも、小さくってどうするの？と疑問に思う方もいらっしゃるでしょう。

そこで重要になってくるのが、プロトタイプです。
事業の可能性を掘り下げ、ブラッシュアップするために、プロトタイプは非常に有用です。

プロトタイプと聞いて、みなさん、何を思い浮かべるでしょうか？
本物の製品に近いものを思い浮かべるかもしれません。
完成形に近い商品で、そこそこ使えるような形まで作ってあったり。

確かに、製品に近いプロトタイプもあります。
一般的にイメージできるプロトタイプは、実際の製品に近いものでしょう。

しかし、プロトタイプを作る目的を考えると、少し見え方が変わってきます。
そもそもプロトタイプとは何のために作るのでしょう。

例えば、自分自身が事業で解決したい問題や仮説があったとします。
こうした仮説や問題が正しいと、一体どうやって確認すればよいのでしょうか。
プロトタイプで理解すべきは、こうした仮説を検証すべき時に使うものだということです。

例えば、自分自身が設計したUIがあったとします。
こうすれば、最も使いやすいだろうと考え、画面を設計したとします。
しかし、実際に思い描いた通りに、ユーザーが使ってくれるかは、また別です。
自分が信じて作り上げたものが正しいか、検証しなければなりません。

そこで、一旦形にしてみようと考え、プロトタイプを作り始めます。
ここで注意すべきは決してプロダクトを作り始めるのではない、ということです。
プロトタイプの目的は「仮説が検証できれば良い」のであって製品を作ることではありません。
自分が意図した通り顧客が使ってくれるか、そうでないなら何が問題かを検証できれば良いのです。
例え、本物そっくりのプロダクトがなくても、検証はできます。

では、どんなプロトタイプを作れば良いでしょうか。
パソコンを開いてコードを打ったり、技術者にお願いする間でもありません。

まず、紙とペンとハサミを用意します。
画面設計を紙に描き、切り取り、第三者に渡します。

あとは上手くファシリテートしさえすれば良いのです。

テストを始める前に、今回のプロダクトのコンセプトを伝えます。
そして、実際に触って、試してもらいます。
紙の設計で、何をどう押すか、どこで迷うか、観察すれば良いのです。

後に、ヒアリング、インタビューで意見を聞いて、問題点を洗い出します。
意図した通りに動作した点もまとめて、改めてブレストします。
試してもらったユーザーも交えて、ブレストすると良いでしょう。
新しい議論や意見も生まれ、だいたいの仮説は検証できるはずです。

プロトタイプと聞くと、すぐに技術やコードを書くことを思い浮かべます。
しかし、実際は仮説の検証ができればさえ良いのです。
何も、本物のプロダクトを作りはじめる必要はありません。

もちろん、本物に近ければ近いほど、有益なデータはとれるでしょう。
プロトタイプも色々なので、もちろん本物に近いプロトタイプもあります。
ただ、どちらも共通しているのが、完全な製品を作ることが目的では無い、ということです。
ソースコードも、作り上げたものも、再利用するために存在しているわけではありません。
仮説を検証するためであり、作ることに対して意識を置くものではないのです。

事業デザインの思考、デザイン思考を教える教育機関が、スタンフォード大学にあります。
d.schoolと呼ばれ、世界中の事業デザインを学ぶ人が集まります。

d.schoolには、プロトタイプを作るために部屋があり、様々な道具が置いてあります。
ただし、おしゃれなmacではなく、工具を中心としたアナログなツールです。
ドリルやノコギリ、板、その他諸々。
コードを書くことなく共同で作業し、すぐさまアイディアを検証できるようになっているのです。

話題のスタンフォード大学デザインスクール -d･school- に行ってみたぞ
http://blog.btrax.com/jp/2012/07/22/dschool/

d.shoolのような場所は、まさに私たちクオンカレッジβテストが目指すところでもあります。

ともかく、意識すべきは「どれだけ低価格で、短時間で、仮説を検証できるか」です。
どれだけ本物のプロダクトを作るか、ではありません。

この意識は、自分自身で技術を習得したあとも、持つ必要があります。
自分自身で作る際も、最初から完璧を目指す必要がありません。
簡易的な内容を、最小限、短時間で作り、とにかく高速で検証していきます。
さっと作り、最小限で試すという意識を持ち続ける必要があります。

自分自身で事業を作る際も、最小で試す意識は、常に持っておきましょう。
決して最初から大きな労力とコストをかけてはいけません。
小さなコストと短時間で、いかに可能性や仮説を確かめるかを意識しましょう。
小さな失敗と成功の繰り返しが、よりプロダクトの失敗を防ぐことに繋がります。