プロトタイピングを超高速化する実装技術の研究がデザイン実践のために必要な理由

最近ようやくウェブ・スタートアップ界隈にもペーパープロトタイピングが普及してきた。

今後は「プロトと実装の差」が理解されていくといいな。

みなさんプロトタイピングを「設計フェーズ」でやってると思うけど、「設計フェーズ」「実装フェーズ」って分かれてるのがおかしい、という話。でも、これが変わるには十年かかるだろうな。

プロトタイピングに慣れてきた人は、プロトで設計を完璧に詰めようとする。でも実装して触ってみるとぜんぜん違うわけだ。

そりゃ、「動かないプロトから想像した触り心地」と、「実際の触り心地」が一致するわけないじゃん。

みなさんも経験あるでしょ？ 例えば、iPhoneアプリ作ってて、実装後のテスト段階でのUI仕様変更。リリース直前に手戻り。デスマ。お疲れ様です。（←嫌味じゃない。俺も経験あるから言ってんのよ。

そうなるのは当たり前。実機で実装を触らずに、事前の予想だけで完璧なデザインができたら、そりゃもう神様ですよ。無理無理。

実装したら、当てが外れて、作り直しになる。だから、それを減らすための手法がペーパー・プロトタイピング。なんだけど、しょせんは紙。実機には遠い。[Flinto](https://www.flinto.com)のようなインタラクティブ・モックでも、実装とはギャップがある。画面遷移する程度で「インタラクティブ」って言われても。そもそもiOSシミュレーターとiPhone実機にさえ、無視できないギャップがあるんだから。

実物を触ってプロトタイピングするのが重要。

これはまったく新しい話ではない。100年前にバウハウスでやってたし、50年前に柳宗理もやってた。

いつしかぼくらは*頭*で設計しすぎるようになってしまった。もっと*手*から形を生み出していかないといけない。物に触りながら、その物の心地よい形を見つけていく。それこそプロトタイピングの本質的な意味。

だから、プロトタイピングでの制作物は、最終製品に近い手触りがいい。とはいえ、低コストで高速な手法でなければ、試行錯誤の回数が足りず、よいデザインに到達しない。

ここにジレンマがある。ハイ・ファイ（高い信頼性）とロー・コスト（低い制作費）を同時に実現するのが難しい、というトレードオフ。

（ここでいう信頼性（フィデリティ）はデザイン判断の当てになる程度、という意味だ）

トレードオフだけど、やっぱりロー・コストでハイ・ファイなプロトタイプを制作したい。フィデリティ（信頼性）の極限は最終製品（プロダクト）そのものになる。これが理想。つまり、実機・実装・実製品開発（プロダクション）そのものが「プロトタイピング」になる。

そのためには実装技術を上げなければならない。「プロトタイピング」と呼べる速度で「プロダクション」するために。

以上のような思想で高速開発手法を研究してる。

https://www.facebook.com/events/547053972045328/

ちなみにiOSで同じことをやるなら、チーム全員でStoryboardingすることだと思う。Flintoなど使わずにStoryboardとsegueでインタラクティブ・プロトタイプを作る。Xcodeを使って複数人でワークショップするイメージ。もちろんペーパー・プロトタイピングも併用する。

ぼくは「ベンチャー・キャピタルのデザイン・フェロー」というスタートアップ支援者でもあるので、スタートアップの人たちの役に立ちたいと思ってる、みんな個別のビジネスの成功のために忙しくて、普遍的な手法研究の暇なんてない。ぼくの研究は、そういう人たちの役に立つものであって欲しい。

でもまあ普通に生産性向上には経済的合理性もあって、「短い時間で成果を出したら時間単価（時給）が上がるよね」っていうプロフェッショナル・サービス・ファーム経営的観点でも手法研究って大事です。幸せに働くためには効率良く稼ぐ腕が必要。

まあスタートアップとプロフェッショナル・サービス・ファームは、ちょっと違うけど。「一発あてれば一生分稼げる」みたいな世界観の人は、あんまり開発生産性向上に関心を持たない傾向があるなあと。アイデア偏重というか。でも**開発生産性向上をアイデア創造性向上につなげる道筋**がある。それをここで語ったわけです。

## 関連情報

- [デザイン・ファームが事業会社に提供できる価値の中核 - Memorandum by zerobase](http://zerobase.hateblo.jp/entry/2013/07/17/213930)

- [「デザイン思考」の神秘と欺瞞 - Zerobase Journal](http://zerobase.jp/blog/2012/03/design_thinking.html)

- [時間単価を重視する経営 - Memorandum by zerobase](http://zerobase.hateblo.jp/entry/2013/01/07/035516)

- [なぜ "Designing in the browser" ワークフローへの移行が必要なのか - Zerobase Journal](http://zerobase.jp/blog/2013/04/_designing_in_the_browser.html)

今回の話は「イン・ブラウザー」デザイン手法から「イン・アプリ」デザイン手法へ、という話でもあります。