ときどき、新規事業担当者やスタートアップから、プロトタイピングに関して相談されることがあります。比較的多いのが、「プロトタイプとして、何を、どこまで、どのようにつくればいいのか？」という質問です。一般的にいって、プロトタイプの製作にお金をかければ完成度は上がります。しかしながら、新規事業やスタートアップの場合、初期段階において使える資金は限られています。そのため、何を、どこまで、どのようにつくればいいのかの見極めは非常に重要なのです。

まず、混乱を避けるためにプロトタイプという言葉を定義しておきたいと思います。次の図は、プロダクトの開発プロセスの一例です。ここでコンセプトプロトタイプとは、プロダクトのコンセプトを、見る、触れる、感じるなど、体験できるようにしたものです。これに対して量産試作とは、コストや法規制などさまざまな制約条件の下で実際に製造できるよう設計する量産設計の段階においてつくるものです。両者の間では、必要とされる段階も目的も大きく異なりますので、混乱を避けるために前者をカタカナで、後者を漢字で表記しています。

この図のプロセスに基づいて冒頭の質問を正確に言い換えれば「コンセプトプロトタイプとして、何を、どこまで、どのようにつくればいいのか？」のようになります。この質問に答える上で鍵となるのが、コンセプトプロトタイプの目的です。

コンセプトプロトタイプの目的とは、バリデーション（validation）です。validationはかつて「検証」と翻訳されていたこともありますが、同じく検証と翻訳され、恐らくは多くの方にとってなじみがあるであろうverificationと混同されることを避けるためカタカナで表記します。verificationとvalidationの違いについて、ウィキペディア英語版の記事では、アメリカのソフトウェアエンジニアBarry W. Boehmによる説明が引用されています（括弧内の翻訳は筆者）。

• Verification: Are we building the product right?（我々はプロダクトを正しくつくっているだろうか？）
• Validation: Are we building the right product?（我々は正しいプロダクトをつくっているだろうか？）

verificationは、あくまで要件定義に基づく確認であるため、そもそもの要件定義が間違っている場合、そのレイヤーにおける問題を見つけることはできません。そのため、誰も必要としない（あるいはいっそ使わない方がマシな）プロダクトを、正しく実現してしまうことも可能で、その結果が悲惨なものになるのは当然のことです。これに対してvalidationは、（多くの場合には間違っている）仮説としての要件定義に基づいたプロダクトが本当に顧客に対して価値を生み出すかどうかを確認し、その誤りから学ぶことによって、正しい要件定義へと導きます。具体的には、顧客として想定するプロフィールに当てはまる人々にコンセプトプロトタイプを触ってもらい、本物の反応を観察とインタビューによって詳細に引き出し、分析し、（多くの場合には失敗から）学ぶのです。コンセプトプロトタイプとは、このvalidationにおいて本物の反応を引き出すために必要となるタッチポイントを具現化したものです。

タッチポイントとは、対面、ウェブサイト、アプリなど様々なコミュニケーションの形態における人々とビジネスとの接点です。それを見たり、触れたり、感じたりすることによって人々の認識や意見、感情が形成されます。ハードウェア、ウェブサイト、アプリ、広告など、プロダクトと顧客のさまざまなタッチポイントの中から重要なものを取り出し、バリデーションの参加者から本物の反応を得るために必要十分なところだけに焦点を定めてつくるのです。焦点を定めることにより、何を、どこまで、どのようにつくるかの見極めができるようになります。

コンセプトプロトタイプをつくることに慣れていないエンジニアの場合、プロダクトと同じ方法で実現しようとしてしまいがちです。すると、当然のことながらそのために必要なコストは非常に高額になります。しかしながら、コンセプトプロトタイプにおける実現方法は最終的なものと異なっても構わないのです。例えば、ウェブサイトやスマートフォンであれば、プロトタイピングのためのツールは豊富にありますし、PowerPointやKeynoteのようなプレゼンテーションツールでもかなりのレベルのプロトタイプをつくれるでしょう。ハードウェアの場合、Arduino、Raspberry Pi、M5Stackなどのツールキットで実現できる場合も多いでしょう。それでは、もっと複雑なプロダクトの場合はどうでしょうか？

例えば、機械学習による高度なモデル構築が必要になるプロダクトであれば、「もし実現できたらこうなる」という振る舞いを背後に人が隠れて操作しても構いません。あるいは、次世代のセンサーと情報処理技術により、暗所でも非常に明るい写真を撮影できるカメラをつくろうとしているのであれば、「もしこの技術が実現したらこんな写真が撮れる」というシミュレーション結果を示すのでも構いません。

このように、バリデーションという目的を設定することにより、コンセプトプロトタイプとして何を、どのように、どこまでつくればいいのかが、現実的な範囲の中で決めることができます。プロダクトと同じ手法でつくったら数ヶ月（あるいは数年）単位の長い期間と数千万円（あるいは数億円）単位の大きな投資が必要になるのに対して、数時間という極めて短い期間とわずか数万円の投資で実現できる場合だってあるのです。繰り返しになりますが、多くの場合において最初の仮説は間違っているのですから、バリデーションから学び、コンセプトをつくりなおし、コンセプトプロトタイプとして表現することを繰り返して探索することを、大きな投資が必要となる前の段階で行うことが非常に重要なのです。これにより、間違ったプロダクトに投資してしまうリスクを最小限にできるのにくわえて、説得力のあるプレゼンテーションにも繋げられるでしょう。

もし、冒頭に述べたような問題に直面しているのであれば、まずはバリデーションのセッションをどのように行うかを考え、さまざまなタッチポイントの中で焦点を定め、コンセプトプロトタイプとして、何を、どこまで、どのようにつくればいいかを考える、という複数の段階に分解して考えることで、解が見えてくるのではないでしょうか？

リファレンス

・Wikipedia contributors, "Software verification and validation," Wikipedia, The Free Encyclopedia, https://en.wikipedia.org/w/index.php?title=Software_verification_and_validation&oldid=870007870 (accessed November 24, 2018).
・ジェイク・ナップ（著）、ジョン・ゼラツキー（著）、ブレイデン・コウィッツ（著）、櫻井祐子 （翻訳）『SPRINT 最速仕事術—あらゆる仕事がうまくいく最も合理的な方法』ダイヤモンド社（2017年）
・奥出直人『デザイン思考とヴァリデーション』品質月間テキスト432、日本規格協会（2018年）