「体験設計プロトタイピング」について考えていること
デザインの意味が様々に用いられるように、プロトタイピングやプロトタイプもまた業種や業界によって実に多くの行為や物を指す言葉です。
メーカーでデザイナーをしていて一番困るのは、目的や実態の違うものをプロトタイプと呼び「やっている」ことになっている点です。一番多いのは部品試作（機能試作ではない！）をプロトタイプとしている場合です。
開発の中で多くの試作がおこなわれ、機能試験だけでなく、耐久性や生産性などのさまざまな評価がおこなわれます。それらは「設計管理（Design management）」によってユーザー要求から分解設計され個々の機能要求となったものを実現したものですので、理論上はユーザー中心設計の体裁をしていますが、多くの試作や評価の目的がユーザー要求に向けたものではなく、機能要求の部分に時間も費用も向けられているのが実態ではないでしょうか。
時間を節約して、作り込みやイノベーションに向かう
最終的にはユーザー要求通りのものができあがるので上記のプロセスで問題が無いように思えますが、それは当初予定していたものが出来上がるだけの状態だと言えます。予定したものが大したことの無いものであればそれ以上には成らない訳です。
デザイン思考を取りいれたデザイン経営の目標は、ユーザーの本質的欲求を発見し、それを新しい方法によって実現していくイノベーションにあり、それによって他社との差別化や顧客への高い価値提供をおこなうことにあります。
私たちはこれを「体験設計」と呼んでいます。製品設計の上位に体験設計を置き、開発上流に体験設計をおこない、開発の最終段階で体験検証をおこなうことを提唱し、その手法について研究をおこなっています。
開発下流のユーザビリティテストに重点を置くのではなく、上流で製品開発を始める前に体験システムのプロトタイピングを繰り返すことで、より優れた経験価値を効率的に生み出す手法に着目しています。
体験設計を中心として企業での実践を支援するコンソーシアムに私もメンバーとして参加しています。
開発の上流で、開発目標が優れた経験価値を提供しているか評価する
完成した製品を体験しその価値を評価することはそれはど難しいことではありません。ただ多くの場合はその段階で製品の根幹を改良することは難しく、ましてや経験価値を拡張したり変更したりすることはさらに難しいことになってしまいます。
そのため経験価値がユーザーの本質的欲求を満たすためには、開発上流（製品設計の前段階）での体験設計が重要となり、そのプロセスの中で「体験設計のプロトタイピングができないか」ということになってきます。
では体験設計のプロトタイピングと製品設計のプロトタイピングは何が違うのでしょうか。
コンセプトシートや構造化シナリオによって机上の空論を作り上げる手法の提案はありますが、それを「実際の体験」によって評価する方法は具体的に示されていません。つまりビジョンを体験し直接評価する方法が今のところ無いのです。
体験には身体的な体験と脳内での体験があり「体験とは何か」ということが明確になっていないため、そこを探りながら実際の開発の中で実施可能な手段に落とし込んでいく必要があります。
仮想体験（バーチャル・エクスペリエンス）が、言葉や文字を使ったシナリオ法から、映像を使ったもの、さらにVRゴーグルを使ったものまで仮想表現の技術はフィジカルな体験も取り込みリアルに近づきつつあります。
さらに、装置や環境が知性を持ち人格として存在するようになる未来の世界では、人間がそれぞれの装置や環境の役割を演じる「ロールプレイ・プロトタイピング」が有効になってくるかもしれません。
開発途中で、個々の機能が統合したときに経験価値を実現できるか評価する
設計という行為は上位の要求を実現するために細かい手段に分解していくことだと言えます。抽象的なユーザー要求が体験設計によって具体的な役割（機能）に分解され、それを実現するシステムが製品やサービスによって作られていくイメージです。
素晴らしい体験設計ができたとしても、それを確実にシステム設計に反映し、さらに個々の製品開発に展開していくことは難しいことです。そのため開発途中でもシステム全体が融合したときに体験設計が実現できるのかを検証しながら進める手法が必要になります。
現在は一度分解した機能を小さな単位だけで扱い開発を単純化するアジャイル開発手法が注目されていますが、設計という分解行為に対する評価にはなっていません。設計を本当に評価するためにはそれを統合して上位目標（要求）が満たされているかを検証する必要があるのです。
人間や利用環境を含めたシステム全体を想定し、分解した個々の機能モジュールが全体の中で適切な役割をはたせているかを検証するための手法はまだ分かっていませんが、まずはモデルベース開発によって機能分解を可視化し常に上位目標とのつながりを表すことで何かのヒントになると感じています。
人間や社会のような不確実性や複雑性を含むシステム要素をモデルに取り込むことによって部分と全体を同時に扱うことができるようになり、システム全体の最適化（融合）を確認しながら設計を進められるのです。
例えばMathWorks社のStateflowを使うことで、システムの関係性を定義することができるだけでなく、相関関係と変化の状態をシミュレーションすることができる。さらに大きなシステムから小さなシステムへモデル内部を分解設計していくことができるためシームレスに製品開発を進めていくことができる。
私が目指す体験設計プロトタイピング
プロトタイピングはさまざまなものを指す言葉ですが、体験設計プロトタイピングと言った場合には、システム全体の関係が生み出す価値やシステムの部分が全体の中で生み出す価値を、人間の体験を通して評価するためのプロトタイピングと定義できます。これは従来のモノ作りの中でおこなわれていたものとは目的も、作るものも、評価方法も違っています。
実証実験や試行運用といった手法は体験設計プロトタイピングの一つだと言えます。お金と時間をかけてほぼ製品と同じものを作り実際の利用環境の中でユーザーに使ってもらうことでユーザー要求や体験設計が正しかったかを評価することができるからです。
しかし実証実験には多くのアイデアを試してみることができないという欠点があります。私が現在目指している体験設計プロトタイピングの手法は、開発の上流、製品開発に入る前の段階で、ユーザーや利用環境を含むシステム全体を「体験する」ことができるようにすることで、時間もお金も無駄にすることなく多くのアイデアをプロトタイピングして、何度もブラッシュアップのサイクルを繰り返せるものが理想です。
システムの本質や体験とは何かを理解する
そんな都合の良いプロトタイピングがあるのでしょうか。私もまだ具体的な答えをもってはいません。ただこのような目標を持つことによって、これまでの開発を見直すことができ、より良い体験を提供できるシステムをデザインできるようになると考えています。
無駄なものを作る余裕はありませんので、体験設計にとってのシステムが持つべき本質や、またユーザーが要求する経験価値につながる体験とは何かということをドキュメントや会話の中心にしていくことで、たとえその評価が十分でなかったとしてもプロトタイピングという活動が意味を持つと思います。
またそのようなチームを運営し、何度も開発を経験することで手法と呼べるプロセスやツールを生み出していきたいのです。
この記事が気に入ったらサポートをしてみませんか？