プロトタイピングの定義、用語を説明したので実際の仕事/プロジェクトでの利用方法について書いていきます。

プロトタイピングとサービス開発の関係

プロトタイピングを実際の事業/サービス/プロダクト開発のフローをウォーターフォール開発と合わせた図が下記です。

大きく『サービス設計フェイズ』『システム設計フェイズ』『量産設計フェイズ』に分かれます。

サービス設計フェイズ

新サービス/プロダクトを企画し、そのサービスのディテールと全体像を詰めるフェイズです。その際に映像試作や体験試作を制作し、サービスの体験としての全体像の把握や、情報共有を行っていきます。次のフェイズに繋げる場合、体験試作と共に実際のサービスとしてローンチするのに必要な要求まで作っておくと次のステップにスムーズに進むと思います。

システム設計フェイズ

体験を確認しながら要求を仕様に落としていくフェイズです。のちの量産設計とシステム設計は同時でも可能なのですが、体験ありきのゼロベースで仕様を検討する場合は量産設計の前に大枠を固めておくと話がスムーズです。筆者の所属する会社は『サービス設計フェイズ』と『システム設計フェイズ』を主に相談される場合が多いです。端的に言ってしまうと『体験を仕様に翻訳する仕事』であり、『体験をテクノロジーでどう解決するか試行錯誤する仕事』であり、『デザイン言語とSIer言語の翻訳を行う仕事』となります。

一般的にエンジニアが試作を相談される場合はこのフェイズなのですが、多様な試作のバリエーションがあり、前のフェーズでも試作をやるような状況になっているため、ある程度デザイン的な手法に理解がある方に頼む場合でも試作する前に体験シナリオや要件の共有は必須です。

ちょっと脱線しますが、任天堂が『ゲーム企画を検証するための試作の際、画面の作りこみや音の作りこみを評価軸に入れない』というのはCGや音などのメディアのリッチさは量産のフェーズと考えている、ということだと思ってます。つまり任天堂が作っているのは名称分類で言うと最終体験試作と捉えられるかと思います。ゲーム業界でレベルデザインが重要になってきたのもレベルデザインが体験と仕様をつなぐ架け橋であり、ゲームの骨格をなす最終体験試作として作られるからでしょう。非常に重要だが開発費用のかかるCGやサウンドは肉の部分と捉えていると思います。

量産設計フェイズ

体験に紐づいた仕様を叩き台として、量産にどう落とせるかを話し合し、試作するフェイズになります。よくあるT-1とかT-2とかいう試作はこのレイヤになります。また、バッテリ消費電力削減のための『体験に直接関係のない部分の設計』やサーバのスケーリングなど『個人の体験にあまり紐づかない体験』もこちらに回されることが多いです。

プロトタイピングをしながら仕事を進める際の注意点

プロトタイピング（試作）をすると普段より多くの人を巻き込みながらより質の良い議論ができますが、運用に当たっていくつか注意点があります。

試作する前に『何を体験/検証したいか』を明確にする

最終製品と同じ『技術』『同じサイズ』『同じ体験』を厳密に作るならば、それは最終製品そのものと同じだけの予算がかかります。従って、何にフォーカスした試作を行うのかを明確にすることが重要です。検証したいポイントを絞ることで、低コストでしかも高速にプロトタイピングすることが可能になります。
『企画をみんなで検証したいため、実現可能性を無視して理想形を作って欲しい』のであれば体験試作が最適でしょうし、『作りたいものは見えたので全体的な話ではなく、キーになる機能について相談したい』のであれば技術試作が最適でしょう。

エンジニア/作り手に向けて

一言に『試作』と言ってもこのように多種多様な種別があります。変なものを変な予算にならないように↑の表の単語を使って話し合いをするとデザイナや企画/マーケティングのチームと会話しやすくなるでしょう。

最後に

UI/UXのメソッドではプロトタイピングの重要性を説いてますが、まだ体系化されているのはアプリケーションなど画面の中の話が大多数です。

しかしプロトタイピングという、自分の感覚を評価値としてサービス/製品開発を進めるという基本的なアプローチはGUIのみならずプロダクト/サービス、その他アナログな製品開発の場面でも非常に役に立ちます。また、『ユーザ』になる前の『通りすがりの人』への体験設計でも利用可能です。

追記

ウォーターフローではない、実際の仕事のフローに沿った仕事の流れの図も制作しました。
イテレーション / ブラッシュアップの流れが分かりやすいかと思います。