プロトタイピングのあるある話

プロトタイピングに携わったエンジニアであれば、以下のような状況に直面し、頭を抱えた経験があるのではないだろうか。

• 「このプロトタイプを、そのまま正式に使いたい」と言われたが、そんな想定はしていない
• 「このプロトタイプを、お試しでもいいから使い始めたい」と言われたが、そんな想定はしていない
• 「このプロトタイプをベースに、機能追加して使いたい」と言われたが、そんな想定はしていない
• 「このプロトタイプでいいからリリースしてほしい」と言われたが、プロのエンジニアとしてそんなことはできない

最近プロトタイピングで悩ましいと感じる場面があったため、改めて教訓として言語化しておきたい。

思考実験：住みたくなるデザインの家を短期間でプロトタイピングする

ソフトウェアだと専門的な話になりやすいので、一般人でもイメージしやすそうな例を妄想してみる。

ある設計者は、顧客が住みたくなるような斬新なデザインの家をプロトタイプとして作成することにした。

• プロトタイピングに使える期間は1週間
• プロトタイプは、実際に顧客に見てもらいリアクションを収集する
• 顧客にリアリティを感じてもらうため、プロトタイプは実サイズで作り、内部も見られるようにする

プロトタイプの作成は順調に進み、プロトタイプとして顧客に見せられることになった。しかし…

• 設計者「この家がプロトタイプです。このデザイン、いかがでしょう？」
• 顧客A「この家、まさに欲しかった家だ。この家に住みたいな」
• 顧客B「いいね、この家に住みたい！明日からでもここに住めないかな？」
• 設計者「この家は1週間くらいで作ったものです。雨にも弱いしすぐ壊れちゃうから、住むことはできないですよ」
• 顧客A「住めないんだ、がっかり。この家をベースに、住めるようにしてほしいな」
• 顧客B「1週間でここまでできてるなら、このままいけばあと1ヶ月くらいで住めるようになるのかな？？」
• 設計者「（この家をベースにすることなんてできないし、そもそも住むことを想定していないし、1ヶ月で住めるようになんて到底できないよ…）」

設計者は困惑してしまった。

プロトタイピングにおける重要な観点

思考実験や自身のこれまでの経験を元に、プロトタイピングで重要な観点をまとめる。

プロトタイピングの目的は明確か？

あらゆる仕事に言えることだが、まず目的が何かを明確にすることが重要だ。 「プロトタイピングで何を検証したいのか」が明らかになっていなければ、どこに力を入れればいいかもわからないし、各人にとって都合よく解釈されてしまう。
「プロトタイピング」のDoではなくWhyこそが本当に重要であり、ここが合っていなければ関係者の期待が噛み合わなくなる。

プロトタイピングの目的は「プロダクトの需要がありそうか？」「プロダクトの方向性は正しそうか？」といったことを検証することにある。 思考実験の例で言えば「こういうデザインの家は需要があるのか」といった市場調査であり、その家を販売することではない。だから素材はダンボールでもよいし、耐久性なども気にしなくてもよい。

目的を明らかにする際には、あえて「目的外」のことを明記するのも効果的。
XXのスコープや境界を明確にするためには、「XXであるもの」と「XXでないもの」を記述したほうが共通認識を作りやすい。
議論して「これはプロトタイピングの目的外だよね」と話した内容も、きちんと整理していくとよいだろう。

そのプロトタイプを捨てる条件は定まっているか？

プロトタイプはコスト（お金・時間）を抑えられるのでハードルが低いが、プロトタイプを捨てる条件が明確になっていないことも少なくない。もしプロトタイプを捨てる条件が存在しないなら、その思考の背後にあるのは「コストを掛けずに、良いものがほしい」という、ないものねだりだ。 またプロトタイプを捨てる条件が定まっていないことは、プロトタイピングの目的が不明確であるという裏返しでもある。

「せっかくプロトタイプを作ったのに」という思考はアンチパターン。そもそもサンクコストを抑えるためにプロトタイピングをしているのだから、サンクコストを気にするのは本末転倒である。 「プロトタイプを捨てるのは作ってもらった人に申し訳ない」という気持ちも全く必要ないし、プロトタイプに対して愛着を持たないようにしたい。

もしプロトタイプをベースに正式利用や製品化へ進むことが前提となるのであれば、プロトタイピングは止めたほうがよい。
「こんなに短期間・低コストで作れるんだ」と勘違いされたり、うっかりプロトタイピングの内部仕様をそのまま流用してしまうリスクを高めるくらいなら、最初から製品版としてリリース可能な水準で開発することに注力したほうがよい。

そのプロトタイプの延長線上に、完成形は存在するのか？

「このまま行くとあとどれくらいで完成するの？」といった、プロトタイプをベースに製品版を開発する前提の話が挙がることがある。 しかしプロトタイプの延長線上に完成形が存在しない可能性は常にあるし、むしろそのほうがプロトタイピングとしては適切な場合もある。

思考実験の例で言えば、果たして世の中に、ダンボールをベースに補強して住めるようになった家が存在するだろうか？
ダンボールは安価・軽量で加工もしやすく、プロトタイピングには適している。しかしプロダクトとして備えるべき耐久性を考慮した場合はむしろ邪魔な存在であり、ゼロから作り直したほうが結果的に早いし高品質ではないだろうか？

ソフトウェア開発の文脈で言えば、例えばいまや生成AIをプロトタイプとして用いることも容易になっている。 しかし生成AIの出力には常に不確実性が伴い、再現性を担保することが難しいという特性がある。 このような特性を持つ以上、プロダクトとして提供する際には生成AIを使わずにきちんと実装したほうがよいことは多々あるだろう。

リアクションの対象は外部仕様か、内部仕様か？

「プロトタイプをベースに製品版を開発してほしい」といった声には、外部仕様と内部仕様を区別して考える必要がある。

思考実験の例で言えば、顧客は外部仕様しか知らず、設計者は外部仕様と内部仕様の双方を知っているという、情報の非対称性が存在している。 このとき顧客は外部仕様に基づくアクションしかできないし、設計者は無意識のうちに外部仕様と内部仕様の両方を踏まえたリアクションをしてしまいがちだ。 しかし顧客は「この（デザインの）家に住みたい」とは言っているが「この（ダンボールでできた）家に住みたい」とは言っていない。

ソフトウェア開発のプロトタイプに対する「そのまま使いたい」というリアクションは「（この外部仕様なら受け入れられるので）そのまま使いたい」という意味にすぎない。 エンジニアは反射的に「（この内部仕様を）そのまま使うなんてとんでもない！」と反応しがちだが、これを表明すべきかどうかは状況次第だ。 もしこのまま実利用したいという話になったのなら、エンジニアの人は内部仕様に基づく課題をきちんと主張する責任があるし、エンジニア以外の人はその主張を受け止めてきちんと吟味することが求められる。