iPhoneのアプリケーションデザインの本を読んでいたら、デザインをする時の指針として、こんな言葉が使われていた。
「愛するものを殺せ」
刺激的なタイトルにびっくりするが、文筆家の好む金言だそうだ。
「いつになく見事な文章を書いてしまいそうな衝動を覚えたときは、いつでもそれに従え。全身全霊を傾けて。
そして、原稿を出版社に送る前に捨ててしまえ。」
-アーサーキラークーチ
新しい試みについてプレストを行うとき、多くのエンジニアは既存の技術の延長線と応用で考える。
オープンソースとクラウドサービスの時代において、不特定多数のエンドユーザーを対象にしたサービスは、既存のフレームワークとサービスの組み合わせになるので、ある意味それは正しい。
極めてプライっベートな用途に使うスマートフォンのアプリケーションについて、非技術系の人間の要望はとても面白い。
欲望に飾りがないからだ。
技術畑の人間は、それを聞くと鼻で笑う事が多い。
そして、
夢より現実を見た方がいい、というように。
僕もそういう見方をする事が多かった。
単なるiPhoneアプリケーションといっても、iOSのAPIレイヤーから、バックエンドのWebプロセスに至るまで、その外見の裏側では、膨大な実証技術の蓄積に成り立っている。
エンジニアは、その膨大な暗黙知の上に考える癖がついているので、その前提を飛ばして議論が飛躍する事を好まない。
でも、既存の技術と常識の蓄積だけでは、本当にインパクトのあるブレイクスルーが生まれにくいのも確かだ。
なぜなら、現状から逆算した未来だと、既存の技術が想定しているパラメータの組み合わせの範囲内になり、すぐに競争の中で淘汰されやすい。
初代iPhoneの発表時、事前の報道では
「iPod機能のついた携帯電話をAppleが開発中」
というものだった。
今になってみるととても可笑しい話だけど、スマートフォン（あるいはPDAフォン）という概念で予想していたメディアはなかったように思う。
当時、iPodは破竹の勢いで、ユーザーとしてみても、ケータイにiPod機能がつくのは魅力的だった。
考えてみれば、Appleがケータイを出すのにそんな単純な回答を用意するわけはないのだけど。
発表の夜、ニュースサイトで最初にiPhoneの外観を見たとき、正直僕は不安になった。
それは全面タッチスクリーンのケータイで、それまでの記憶では、いくつかそういう端末は登場していたが、成功例はなかったからだ。
（スマートフォンは存在したが、当時の主流は今では少数派のキーボード付きタイプだった）
しかし、ジョブスによるiPhoneのデモは衝撃的だった。
一番の驚きは、Mapのデモだ。
Mapでサンフランシスコを表示し、スターバックスを検索。
画面内のスターバックスの場所に赤いフラッグが表示される。
そして、一つのフラッグをタップすると、その店舗の電話番号、住所情報が表示される。
驚いたのは、そこに表示された電場番号をタップして、直接スターバックスに電話をかけたことだ。
「会場の皆さんにラテのトールを。」
この時の衝撃は、今スマートフォンを使っている人には理解出来ないかもしれない。
その当時のスマートフォンの主流の機能は
電話＋PDA（いわゆる電子的な手帳）
だった。
スケジュール、カレンダー、連絡帳という基本機能は今のスマートフォンと同じ。
だけど、あくまで主機能は「電話」であり、PDA機能は副次的機能だった。（連携するアプリは連絡帳ぐらいだったと思う）
Mapのデモを見てもわかるように、iPhoneの場合は、電話すら機能モジュールの一つであり、アプリケーションが「電話機能」として呼び出す事もあるのだ。
iPhoneはケータイ「電話」ではなく、ケータイ「コミュニケーションツール」として設計されている事がとてもよく分かるデモだった。
レガシーケータイ（いわゆるガラケー）は、とても操作と設定が複雑だった。
素晴らしく高機能ではあったのだけど、複雑なキーバインドが必要だったり、目的の機能をONにする設定がとても深かったりした。
目的は単なる写真の移動なのに、そこに至るパスが険しすぎた。
それは文筆家の「見事な文章」だったのかもしれない。
iPhoneの場合、実装基準は機能ではなく、
「ユーザーのやりたいこと」
だったように見える。
ユーザーがiPhoneでやりたい事を明確に決め、目的に至るパスを最短にする。
そして、ユーザーのやりたい事ではない、あるいは優先順位が低いと目された内容は、たとえ「コピー＆ペースト」ですら、初期のヴァージョンから切り捨てる。
逆に、タッチスクリーン操作に実際に触っているかのような感覚を付与するため、UIデザインには過剰ともいうべきこだわりがある。
iPhoneの曲目リストや住所録は、ローロデックスのように、ユーザーが指でめくるとスクロールし、しかも最初は早く、次第に、まるで本物のローロデックスの回転が抵抗でゆっくりになるかのうように、回転が遅くなる。
しかも、最後のリストになると、回転停止のショックで、若干リストが上に跳ね返るぐらいの凝り方だ。
一見無駄な工数をかけて、自己満足しているだけに見える。
だけど、前述のスクロールの物理法則運動は、おそらく、使っている人の多くは気がついていない。
それは実装が無駄だったからではない。
気がつかないほど自然だからだ。
細部のこだわりによって、実際に物理的媒体に触っている感覚になっているからだ。
おそらく、開発プロジェクトの途中で、実装目前に捨てられた機能は膨大な数に登るだろう。
それをあえて捨てる事ができるのも、設計目的がブレてないからだ。
目的のない「シンプルさ」は逆に「装飾」だ。
写真もそうだと思う。
目的がなければ、
ハイキー＝優しい
ローキー＝荘厳
というパターンをなぞるだけだ。
行き場のないパターンは過剰になり、目的を失ってさまよい、そして淀んでしまう。
シンプルさは自然体からは生まれないと思う。
膨大な挑戦と実験と失敗から生まれるのだ。
