これまでいくつかの記事で「プロトタイピング」について書いてきましたが、読んでいただいた方によっては「？？？」となっている可能性があると思っています。

なぜなら「プロトタイプ」が何を指すのかは、業界や個々の会社でバラバラだからです。
さらにデザイン部門と開発部門で違うものを指している場合や、研究部門と製品開発部門で違っていたりと、社内で混乱している会社もあるのではないでしょうか。

この記事では、ハードウェア、ソフトウェア、サービスを融合した複雑な製品開発をおこなわなければならないハードウェアメーカーでのプロトタイピングについて考えてみたいと思います。
３要素が融合したプロトタイピングを日常的に実施できているメーカーはほとんどありません。その理由や問題点を分析することでプロトタイピングの本質を考えてみます。

まずプロトタイプの種類を整理してみる

スケッチや図面、言葉などで実現したい世界を考えた後は、それを構成する要素に分解して、この世に無いもを作り、その世界が本当に実現できるかどうか確認するために「プロトタイピング」をおこないます。そしてそこで作るものを「プロトタイプ」と呼びます。

つまり未確認のモノゴトを考えるところにはどこにでもプロトタイプが存在するということになります。

私が思い付くだけでも下記の通りさまざまな場面や目的で、さまざまな名称で呼ばれるプロトタイプがあることが分かります。

原理モデル
ペーパープロト
ワイヤーフレーム
機能試作
クレイモデル
外観モデル
モックアップ
シミュレータ
製品試作
生産試作

少し前までは様々な表現で呼ばれてさまざまなものが作られてきましたが、最近ではデザイン経営・デザイン思考が部門を超えて取り組まれている中で、プロトタイプを作ることはプラス評価につながるため、各部門がこれまで作っていたものを「プロトタイプ」と称し自分勝手にプロトタイプを作ることになり、またそれに対して機能的体験や認知的体験というユーザー視点での評価を取り入れることで、書類上は似たような目的のプロトタイプがあちこちで作られるという奇妙な現象がおきています。

プロトタイピングとは

そこで、自称プロトタイプではなく「プロトタイピング思想」を考えることでこの状況を整理をしていきたいと思います。

デザイン思考におけるプロトタイピングとは、製品全体（＝システム）またはある部分と周辺との関係を事前に確認するための行為だと考えています。

その「関係性の確認」のために、機能的な作り込みや認知的な作り込みをしないと分からないことがあるため、頑張ってプロトタイプの作成をおこなうという考え方です。

従来のモノ作りにおける「試作」との違いは、その確認のタイミングが個別設計の前であるという点です。

つまり、小さなモジュールを作って最後にそれを結合するのではなく、大きなシステムを作ってからそれを分解して開発していくプロセスになります。

プロトタイプは開発途中とは違う

プロトタイプと混同されやすものに「開発途中」があります。最終設計のつもりで始めて、まだ50％とか70％とかの状態を指します。
まだ完成品では無いという意味では同じですが、一部の機能は動くようになっているかもしれませんがそれは単なる未完成品です。

それに対してプロトタイプは「完成した状態を想定したもの」である点が異なります。
ただ、見た目も機能も全て完璧なプロトタイプというものは存在しません。例えばペーパープロトタイプは見た目については一旦切り離して、画面遷移やユーザーの操作フローだけにフォーカスしています。提供する価値の中で重要なファクターに関して、一連の内容をシステム全体で確認している訳です。

アジャイル開発手法とプロトタイピングを混同している人も多いかもしれません。
どちらもクイックに作成して、評価をおこなっていくことは共通ですし、評価の結果問題があれば修正することになりますので、一見似ていますがアジャイルは対象としている範囲が「部分（部品）」である時点で、システムの体験（価値）確認を目的とするプロトタイピングとは違うものだと私は考えています。

プロトタイピングを計画する

プロトタイプは、一度だけやれば良いものではなく、何度もステップごとにおこなうべきものですし、作成の目的や、確認できる内容、作成のレベルが違っていれば、何種類も作る必要があります。

どのタイミングで・どのくらい時間かけて作るのか
誰が・どこで作るのか
どの範囲を・どのレベルまで作るのか
いくらで作るのか
何を確認するのか・何のためのために作るのか

これらの答えの組み合わせの数だけプロトタイプがあります。その中から最適なプロトタイピング計画を立てなければなりません。

特に最近はユーザー体験（UX）を重視しているため、システム全体の広い範囲を確認できるものや、ディテールの作り込みを確認できるものなど、新しいプロトタイピング技術に取り組んでいかなければならないと感じることが多くあります。

「既にやっている」を壊していく難しさ

もう一度ハードウェアメーカーについて考えてみたいと思います。
スタートアップをみてもハードウェアを作るということは投資が大きく、柔軟な進め方がしにくいという面があります。
これはハードウェアがソフトウェアに比べて途中での修正がしにくいことが原因の一つとしてあります。計画を途中で変えることが難しいのです。

そのため、ハードウェアメーカーは会議などのステップがキッチリと決まっていて、予算管理も枠組みが最初から決まっているため、従来やっていなかったことや、予定外のことはやりにくい体制になっています。
その結果、従来から作っているプロトタイプでは製品によって数千万円の予算が自動的につきますが、これまで作ったことの無いプロトタイプには例え数万円でも作ることができない場合もあります。

モノ作りを中心にしていたメーカーでは、ハードウェアのプロトタイプ・試作機を作る予算取りはできていますが、ソフトウェアやシステム全体のUXの確認のためのプロトタイプについては、ハードウェア開発の延長として、ソフトを組み込み、全体が結合したときに確認するに留まっているように思います。

ハードウェア中心のプロトタイプを既に作っているため、そのやり方を破壊して再構築することができず、ソフトウェアやサービスをハードウェアの周辺開発の位置に置いたままにしてしいる場合があるのです。

ハードウェアメーカーだからこそ、上流でのシステム全体の「体験プロトタイピング」が必要

その点では、Web・アプリ系の開発では、ワイヤーフレーミングによる評価から、実装後も何度もユーザーテストをおこなってブラッシュアップしていくサイクルが標準化しているところも多い印象です。

それに対してハードウェアメーカーが取り組めていないのが、上流段階でのハードとソフトの融合したプロトタイピングや、複数のハードが連携したシステム全体の、ワイヤーフレーミングです。

一般に、デザインパターンが確立しているWebやアプリの世界よりも、ハードとソフトの融合、複雑なフィジカル要素などによって、机上の予想通りにはいかないことが多いくなります。またハードの開発は、費用がかかり、やり直しがしにくいからこそ上流でのプロトタイピングが重要なのです。

上流での体験プロトタイピング手法を確立したい

ただ世の中には、そのようなプロトタイピングをおこなえるツールや手法、ノウハウがまだ少ないと思います。

各社の中でさまざまな工夫をして、努力している人はきっといるはずです。
それらをまとめることができれば、より良い未来にすることができるのではないでしょうか。

これから本格的なIoT／ロボティクスに取り組んでいくためにも、企業間の競争領域以外のところで、よりよいユーザー体験のために協力合うことができると思っています。