- Column
- 〔誌上体験〕IBM Garage流イノベーションの始め方
Envision：偶然に頼らずにイノベーションをデザインするための実践ポイント【第8回】
手法2「プロトタイプ」：検証を加速させる
「目標の丘」を使って定義した価値は仮説にしかすぎない。そのため、前回紹介したスポンサーユーザーに相当する利用者から評価を受け、学びを得ることで「必要とされるもの」にしなければならない。そこで有効なのがプロトタイプを用いることである。
プロトタイプは、単純に利用者からの評価を得るためだけでなく、利用者自身でも言語化できない真のニーズを明らかにするための触媒として使うことも重要だ。時には自らが考えるために作成することで、チーム内で価値をより具体的に深く考えたり、意識合わせをしたりするのにも役立つ。
プロトタイプは、どのようなことに気をつけて作るのがよいだろうか。
アクションa ：使い勝手や色使いなども含めて細部にまでこだわる
アクションb ：検証したいことを決め、必要な機能に絞って一連の体験ができるようにする
アクションc ：利用者が正確な評価を下せるように、多くの機能を備える
IBM Garageではアクションbを重視する。具体的にみていこう。
実践ポイント：プロトタイプでは“体験”を検証する
よくあるケースとして、インタビュー中にニーズや課題を尋ねても、本人が自覚している顕在的、あるいは表層的な回答しか得られないということがある。一方で、目に見える形にすると、体験することが可能になるため、様々なフィードバックを得やすくなる。
プロトタイプというと、「作り込まれており、機能も品質も完成度が高いもの」と考えがちだ。だがプロトタイプには様々な種類が存在する（図2）。粗いレベルであっても、検証項目を明らかにして学びを得るのが目的であれば、立派なプロトタイプになる。実際には、製品／サービスの特性や、どの段階を検証しているのかに応じてどのレベル感のプロトタイプがよいかを検討する。
プロトタイプの作り込み度合いは、利用者の反応を引き出すために、一通りの体験ができるリアルさは重要になる。だが、その裏側のアーキテクチャーやコードは初期段階で作り込む必要はない。
あるプロジェクトでは、価値検証の段階にも関わらず、過剰に作り込んでしまったことでプロダクトに対する愛着が湧き、軌道修正が難しくなってしまった例がある。
こうした問題を回避するためには、使い捨てる前提で気軽に作り、あくまでも利用者の理解を深めたり、アイデアの有効性を評価したりするために用いる。前回紹介したプレイバックを定期的に行うことで、目標の丘をより具体化する、あるいは見直しを図ることができる。