オルタナティブ・ブログ > イメージ AndAlso ロジック >

ヴィジュアル、サウンド、テキスト、コードの間を彷徨いながら、感じたこと考えたことを綴ります。

プログラマ or デザイナから、"デベロッパー"へ ~メルマガ連載記事の転載 (2011年12月05日配信分) ~

»

この記事は、メルマガ「デジタル・クリエイターズ」に月1回連載中の「データ・デザインの地平」からの転載です。

連載「データ・デザインの地平」
第13回 「
「プログラマ or デザイナから、"デベロッパー"へ」
(2011年12月5日配信分)

RIA開発では、プログラミングとデザインは相互に強く関わり合っています。開発ツールは分業を可能とする方向に進み、作業そのものは分担しやすくなりましたが、アプリケーションのクオリティを高めようとすると、双方の仕事への理解がもとめられます。
今回は、RIAデザインについて、思うところを述べてみます。

ヴィジュアルデザインは、それ単独では成立しない

RIA開発におけるデザインの実作業は、三層構造になっています。
すべての基盤となる「企画」の上に、デザインがあります。一層目は機能設計、二層目は操作設計、三層目が表現設計です。おおまかに言えば、一層目と二層目はユーザーインタフェースデザインで、三層目がヴィジュアルデザインです。

これら三層の作業は深く関わり合っています。上の層の作業は、下の層から独立しているのではなく、下の層の上に重なっています。三層目のヴィジュアルデザインは、一層目と二層目の上に構築されるものであり、それ単独では成立しません。上の層を下の層から切り離すことは、非常に困難です。
それは、プログラミングにおいて、技術仕様が固まっていない状態で詳細設計を進めたり、データベース設計が固まっていない状態でデータ処理のコードを記述するのに似ています。下の層が固まっていない状態で、上の層の作業を進めると、トラブルが発生しやすくなります。
また、下の層をないがしろにして、表層の作業だけにこだわっても、クオリティを根本から高められるわけではありません。
これは、プログラミングにおいて、名前付けにこだわっても、プログラムの本質的なクオリティが向上するわけではないのと同じです。

もうすこし具体的な説明を試みましょう。
たとえば特定のユーザー層をターゲットとするために、1ページに盛り込む要素を最小限に抑えた方が良いUIである、アプリケーションがあるとします。
1ページに多数の機能を盛り込んだプロトタイプに対して、一画面上の色やレイアウトを変えたところで、それは表面を取り繕ったことにしかなりません。
デザインのクオリティを高めるには、搭載機能や手順を見直すか、省略できる機能も手順もないならば、複数のページに分割したり、フリックして次のアイテムを表示するなど他の方法はないかを検討し、一層目と二層目の設計を見直さなければなりません。
大量の塩と砂糖を入れたスープをユーザーが食べられるようにするには、美しい食器に盛り付けてもだめで、調味する前の状態に戻す必要があります。

部品の配置、色やフォントの設定といった、ビジュアルプロパティにかかわる作業を、一層目や二層目の根拠なく行っても、それは表現の調整であって、表現の設計ではなく、もとよりUIデザインではありません。
さらに言うなら、デザインの実作業自体は3層ですが、技術進化を鑑みると、その下の「企画」もデザインに含める方が妥当です。デザインとは、その言葉の本来の意味通り「設計」です。ことRIAデザインに関しては、プランニングとアートディレクションも含む一連の作業を「デザイン」として捉えた方がよいと思います。

もし、プログラマの皆さんが協業相手のデザイナーの作業をかいま見た時、またデザイナー自身が自分に問いかけた時、表面的な美しさだけを取り繕ってお茶を濁してしまっているのではないか?と感じたなら、その根底にある、一層目と二層目、その下に横たわる企画について言及する必要があります。
その姿勢は、必ず、UIのクオリティを高めてくれます。

自分のゴールデンルールは、ユーザーのそれではない

小規模アプリケーション開発の現場では、すでに開発形態そのものが大きく変わりつつあります。とくに、スマホアプリではその傾向が顕著です。
プロデューサー不在でプログラミングとデザインの両方を理解した者同士がコラボレーションし、開発テーマに応じて分担方法を変更したり、両者を一人で兼ねるケースも目立ちます。

プログラマがデザイナを兼務するには、デザイナーの視点をあわせ持つことが必要でしょう。
デザイナーには、「自分対それ以外」という感覚をもって、対象を外から眺める傾向があるように思います(全員がそうだというわけではありません)。外から、世界を、社会を、人々を観察するのです。「自分を含む社会」という視点では、自分のゴールデンルールと他者(主にユーザー)のそれを混同してしまうからです。
技術力のあるプログラマほど、この視点が必要です。

技術に明るくガジェットに慣れているプログラマは、新しいインタフェースのアプリケーションが目の前に現れても、興味深く感じて触ってみます。使えるようになるまでの過程を楽しむ人すらいます。
もし、対象とするユーザーが同じ技術レベルの人々ならば、プログラマが自分のゴールデンルールとユーザーのそれを同一視しても問題はありません。
しかし、ユーザー層によっては、新規なものに触れること自体が苦痛だという人々も、少なからずいます。
ユーザーの利便性を考えて新しい技術を使ったところが、新技術の使用それ自体を目的化しているように受け取られる可能性もあります。
「自分ができるからユーザーもできる」とは限りません。「自分が気にならないからユーザーも気にならない」とは限りません。
「使うことができる」と「使いやすい」は違いますし、「使いやすい」と「使ってみたい」は違います。さらにいえば、「使ってみたい」と「対価を払ってでも使おうとする」は異なります(これが非常に厄介なのですが)。

外からの視点を持ってデザインにのぞまなければ、ともすれば、頭の中に蜘蛛の巣が張りそうな画面遷移や、ヘルプを読まなければ手順を推測しにくいレイアウト、ナビゲートするメッセージの多用を、スルーしがちになります。
デザインの基本は、機能も、操作も、表現も、すべての層において、引き算です。機能を絞り込み、操作手順の無駄を省き、色の数やフォントの数を絞り込むことから始めなければなりません。

デザイナーを兼務するなら、配色の知識を学んで表現設計に没頭するよりも、まずは、プログラマであることの利点、処理を理解してい強みを生かし、機能設計、操作設計に注力する方がよいと思います。それらが優れていれば、色なんぞは、白バックにモノトーンでまとめ、彩度の高い色を一つ決めて、その色をポイントとしてあしらう程度でもかまわないのです(むしろ、下手に色を使いすぎると、良い設計が台無しになります)。その方が、配色やフォントに凝っただけのデザインより、何倍も良いデザインになるでしょう。

問題は職種ではなく、「世界をまなざす感性」

プログラマから見れば、デザインは、ずいぶん性質の異なる職業のように思われるかもしれません。しかし、プログラミングとデザインは決して離れてはいません。その隔たりは微々たるものです。

たとえば、真っ赤な紅葉の1枚を日にかざすとき、美しいその色その形は、三層目の表現設計にあたります。
どのタイミングで芽吹き、色付き、枝から切り離され、朽ちていくかという流れは、二層目の操作設計にあたります。
1本の樹木の生涯の機能を決定付けているのが、一層目の機能設計です。
そして、その下の層に、紅葉が紅葉として成立するための、世界の企画があります。

筆者は―――そして多くの人々が―――紅葉を美しいと感じます。その表面の色だけが美しいのでしょうか。それが美しいのは、その企画が、なにか「エレガントな概念」に基いてデザインされ、計算されて、我々の眼前に現れているからではないでしょうか。

デザインとは、この世界を成立させている「エレガントな概念」に基づく着想を、この社会の中に、この日常生活の中に、他者に伝わる信号に変換して出力する仕事だと、筆者は思います。デザインがプログラミングと異なるのは、その変換形式が、計算機に与えるコードではなく、色や形だということです。

「プログラマ」や「デザイナー」という5文字のテキストには、職業上の利便性以上の意味はなく、デザインを理解できるかどうかは、職業名には関係ありません。職務経験にすら関係ありません。それはひとえに、エレガントな概念への気付きを得るための、「世界をまなざす感性」にかかっています。
その概念にもっとも近い位置にあるのは数学(あるいは物理学や、メタ哲学ではない哲学)であり、そう考えれば、むしろ、デザイナーよりも、プログラマの方が、気付きやすい近い位置にいるはずです。

この世界のあらゆる情報を、より深く、強く、受けとめる感性を持てば、職業に関わらず、デザインを分かるようになります。その感性は、物理的に地理上の広い範囲の多くの現象を五感で受信するという経験ではなく、時間的に遠い範囲を見渡して深く概念を突き詰める経験によって磨かれるようです(もちろん前者は、職務スキルやコミュニケーションスキルを磨く上で非常に重要な経験です)
ただし、それは自ずと磨かれるものであって、自分で意図して磨こうとすると、逆に擦り減ってしまうので、厄介ですが。

デザインを分かるうえでは、この感性が磨かれるような生活をおくることの方が、セオリーに関する知識を蓄積することよりも、表現手法を磨くことよりも、はるかに重要です。
そんな悠長な、そんなことのために人生の多大な時間を費やしてしまい、デザインが形にならないまま一生を終えてしまったら元も子もないではないか?と思われるかもしれません。が、それはそれでいいのではないでしょうか。世界に対する見方が変わらないまま、場数だけこなしても、器用さが身に付くだけで、逆にデザインから遠ざかってしまいますから。この世界は既にデザインされており、我々の最小限の生のために追加した方がいいものなど、実のところ、さほど多くはないでしょうから。

プログラミングとデザインの両方の最新情報をチェックしたり、人生の物理的な時間制限のあるなかで一人で二人分の作業をこなすことは不可能です。それ以前に、プログラミング環境とデザイン環境の両方を揃えた日には、グレードアップ貧乏になってしまうかもしれません。
しかし、世界をまなざす感性が磨かれたなら、一人二役で開発する際に、自分自身の中での対話が可能になります。

これからは、プログラマやデザイナーではなく、一人の「デベロッパー」を名乗るべき時代なのかもしれません。
「プログラミングに軸足を置くデベロッパー」か「デザインに軸足を置くデベロッパー」のいずれかです。
そのどちらに軸足を置くにせよ、今、デベロッパーは、世界に対する感度を高め、デザインという言葉の本来の意味を問いただす地点に立っています。

「データ・デザインの地平」バックナンバー

≪ 第1回 UXデザインは、どこへ向かうのか? (2010/12/20)
≪ 第2回 そのデータは誰のもの? (2011/01/24)
≪ 第3回 子ノード化する脳 (2011/02/20)
≪ 第4回 多重CRUDの脅威(2011/03/14)
≪ 第5回 震災は予知できなかったのか(2011/04/18)
≪ 第6回 永代使用ポータル、クラウドがつなぐ生者と死者の世界(2011/05/16)
≪ 第7回 脳活動センシングの進化が、作曲を変える(2011/06/13)
≪ 第8回 死にゆく者の意思は守られるか (2011/07/11)
≪ 第9回 Windows Phone 7.5 に見る"ヒトとコミュニケーションの形"(2011/08/29)
≪ 第10回 データ設計者は、ヒトを知れ、脳を知れ(2011/09/26)
≪ 第11回 設計者であるための、日々の心得(2011/10/24)
≪ 第12回 センサーの進化がユーザー・インタフェースを変える(2011/11/14)

Windows Phone アプリ公開中。俳句・川柳を、ローカル保存、facebook投稿対応。英語俳句作成支援、季語検索、月別ソート表示機能付き。月別XMLファイルで登録俳句の再利用可能。句数制限なし(365句詠んでも数百KB。Phoneのディスク空き容量次第)。字数制限、行数制限なし。

Largeapplication_tile_2

Comment(0)