「動き」をデザインする方法について

2013-11-25 06:52

表のブログに書きました。自分でも気が付かなかったが、７月に自分が書いたことの焼き直し（というか表向けに表現をまるめた）文章になっているな。

みんなでディスカッションするためのペーパープロトタイプがあって、役割分担のためのHTMLプロトタイプ、スタイルガイドがある。1日目はみんなで考えて、2日目にはそれを元にしてそれぞれが黙々と作っていく、といった流れでしょうか。このワークフローであれば、柔軟性のあるデザインシステムが構築できると思います。

via: これからのUIデザインのために、デザインカンプをやめてプロトタイプを作ろう（後編） | MEMOPATCH

こうしたことを考えていくと「ウォーターフロー開発」というのが一種の冗談としか思えなくなってくる。しかし考えるべきは

例えば飛行機とか自動車であれば、間違いなくウォーターフロー的な開発を行うわけだ。ではなぜそれらではそうした手法が成立するのか？モバイルソフトウェアの開発ではなぜそれが成立しないのか？これについて考えてみるのは興味深いことだ。

多分そのうち表のブログに書くと思うが、現在の仮説はこうである。

ウォーターフロー開発が成立するためには、仕様策定、基本設計の段階で最終形がどうなるかをある程度リアルに想像できなくてはならない。

例えば新人が図面を書くとする。ベテランがそれをチェックするとき頭の中ではそれが組み立て工程で何を意味するか、ユーザはどのように使うかをシミュレートし、それでダメ出しをするわけだ。

このプロセスが機能するためには、「ベテラン」の頭の中でそうしたシミュレーションが可能でなくてはならない。多くの機械設計ではこれが成立する。問題は例えばiOSのように年に一度大幅な機能拡張（同じ変更を機構設計に置き換えてみると、目が回るような変更だ）が行われる環境ではこの「頭の中のシミュレート」が機能しない、ということではないかと思う。

それ故仮にベテランであっても、実際にプロトを作成し触ってみないことにはそれが何を意味するのかがわからない。さらに厄介なことに、プロトを触ってみると、「本当の可能性は全然別のところにあった」ことを発見したりする。

それ故、仕様作成、概念設計、基本設計、詳細設計、製造、試験、という整然としたプロセスが成り立たなくなる、、とかそういう話ではないのかな。