![]() |
ASP.NET Webアプリ開発の裏事情エピソード2:デザイナーとの飽くなき闘争(前哨戦)―― 芸術系人間と付き合うための処方せん ―― 小田原 貴樹(ハンドル・ネーム:うりゅう)2004/11/27 |
|
|
デザイナー: | 「小田原さん、何ですか、このページは!?」 |
筆者: | 「何って、君がデザインしたページに、プログラムを埋め込んだものだけど」 |
デザイナー: | 「……いいですか? トップページからほかのページに移動したら、メニュー部分が下に3ピクセルもずれてるじゃないですか!!」 |
筆者: | 「えっ、そう!? 僕にはよく分かんないけどなぁ。ま、細かいことはいいじゃん」 |
デザイナー: | 「イイワケあるか!!」 |
インターネット系のWebアプリケーションの開発には、いわゆる「Webデザイナー」と呼ばれる人たちがかかわってくることが多い。クライアント/サーバの業務システム(=VB 6などによるWindowsアプリケーションを意味する)では各画面のデザインもプログラマが行うのが一般的だが、いわば「企業の顔」ともいえるホームページやショッピング・サイトにおいてはそういうわけにもいかない。
その結果、機能性優先で芸術性が二の次である(ことが多い)プログラマと、何よりも芸術的完成度を追求してやまないデザイナーとの共同開発が現場レベルでも増えてきている。かくして、冒頭のような会話が日常茶飯事として繰り広げられるわけだ。そこで今回は、感性が違う人間同士の奇妙なコラボレーションの現場風景をご紹介し、そしてそれに対する筆者なりの解決策を示そう。
デザイナー泣かせ? 「芸術」神経の悪いプログラマ
デザイナー: | 「小田原さん、ちょっといいですか?」 |
筆者: | 「こ、今度は何?(ちょっと、おびえ気味)」 |
デザイナー: | 「何で、このテーブルは列ごとに色が変わっているんでしょうか?」 |
筆者: | 「えっ??? 全部、紫色にしてあるじゃない!?」 |
デザイナー: | 「この色は紫色じゃありません! 『パープルピンク』です!」 |
筆者: | 「そ、そうなんだ……」 |
よく「理系」だの「文系」だのと、人間をカテゴライズする言葉がある。あくまで筆者の持論なのだが、これはその人の思考方法の手段の違いなのではないかと思っている。要するに、「理系人間」というのは何かを考えるときに、数字をベースにしてものを考える人であり、「文系人間」というのは文章をベースにして考える人なのではないかということだ。筆者は自分では文系だと思っているが、プログラマといえば一般的には理系の方が多いだろう。
しかしデザイナーは「理系人間」でも「文系人間」にも当てはまらない。彼らは「芸術系人間」なのだ。彼らの頭の中にはキャンバスが内蔵されているのではないかと筆者は感じる。思考の根幹にイメージ&ビジュアルがあり、画像的・映像的な表現が自然に出てくる人たちだと思える。
筆者の頭の中には、そのような芸術的な表現を生み出すキャンバスがないらしい。子どものころから相当に苦手だったが、大人になったいまでも何かの折に絵を描いたりすると、「幼稚園児も驚く」とか、「古代に描かれた壁画をほうふつとさせるね」と褒められるくらいだ。「運動神経が悪い」などとよくいうが、そういった意味では筆者の「芸術」神経は壊滅的に悪いといえる。
そんな、筆者がデザインしたホームページだの、ショッピング・サイトだのを、人前にさらせるわけがない。というか、そんなサイトを納品させてくれるクライアントはいない。かくして、プログラマとデザイナーが組んでWebアプリケーションを開発することになるが、筆者のような「芸術神経の悪いプログラマ」は今日もデザイナーを大いに嘆かせることになる。
プログラマ殺し? 「センス優先のデザイナー」
センスのないプログラマが、デザイナーを泣かせているばかりかといえば、そんなことはない。一般的に、デザイナーと呼ばれる人たちの多くはプログラミングに関する知識や興味をほとんど持っていない。そんな人間がセンス優先でデザインをした場合、プログラミングの余地もない(プログラミング不可能とも思わせる)ページがプログラマの元にやってくることになる。
ある案件で、商品一覧ページのデザインをデザイナーにしてもらったときのことだ。
筆者: | 「……。ねぇ、この商品内容が入っているテーブルって、商品ごとに枠組みが変わってない?」 |
デザイナー: | 「格好よいでしょう!? やっぱり商品に応じて表現(デザイン)を変えたいじゃないですか」 |
筆者: | 「いや、このページって一覧ページだから、1つのパターンを繰り返さなきゃいけないんだけど」 |
デザイナー: | 「それじゃあ、どの商品も同じ表現になるじゃないですか!」 |
筆者: | 「各商品が違った表現じゃ、プログラミングできないんだよ!」 |
データベースから動的に商品情報を取得するようなサイトの場合、特に一覧系のページでは決まったパターンを繰り返すページ・デザインでなければプログラミングは難しい。もし一覧表の行ごとに表現を変えるならば、静的なページ構成にしなければならなくなるし、見やすいページにはならないのだが、筆者のこれまでの経験ではこのことがなかなか分かってもらえなくて苦労している。
一覧系ページ以外にもトップページというのは鬼門だったりする。サイトの顔となるトップページのデザインについては、デザイナーもこだわりを持っていて、力が入りすぎてしまうようだ。
筆者: | 「こ、このトップページって、全部(Macromedia)Flash!?」 |
デザイナー: | 「そうです! ほら、メニューにマウスを持っていくと光が誘導してくれるんですよ!」 |
筆者: | 「いや、メニュー部分はいいんだけど、『新着情報がクルクル回ってる』のは……」 |
デザイナー: | 「目立つでしょう! やっぱりFlashで統一するといい感じになるんですよねー」 |
筆者: | 「あー……、Flashの内容はプログラミングで変更できないんだけど……」 |
デザイナー: | 「えぇーーー! プログラミングも万能じゃないんですね……」 |
声を大にしていっておきたい。
『プログラミングは万能じゃありませんからっ!残念』
まぁ、それはさておき、ホームページに配置したFlashムービーの内容をプログラミング側から操作できるかどうかについては、筆者は勉強不足でよく知らない。もしかしたら、一部のサーバ・ソフトとの組み合わせや、最新のスクリプトを利用することで実現可能かもしれない。だが、データベースに登録された新着情報をトップページに表示するためだけに、そんなチャレンジしたくもないし、採算も合わない。
以上はちょっと極端な例なのかもしれないが、デザイナーは「より格好のよいデザイン」を目指そうとして、どうしてもセンス優先になってしまう。付き合いが長くなってくると、「プログラミングでできること/できないこと」を理解してもらえるのだが、最初のうちはなかなかどうして泣かされたりもする。
こんな状況だからこそのASP.NET
あえて主従の話をするならば、インターネット系のWebアプリケーションにおいては、プログラミングというのはあくまで裏方にすぎない。クライアントにしてもエンドユーザーにしても、第一に評価する点は「デザイン」である。「いやー、このサイトは素晴らしいプログラミングだね!」なんていうのは業界人だけだろうし、どんなに卓越したすさまじいプログラミングを施したとしても、筆者がデザインしたサイトにお金を出すクライアントがいるとは思えない。
それが分かっているからこそ、IDC/HTX*やASPの時代からずっとデザイナーとの共同作業を、苦労しながら、苦労させながら行ってきた。しかしASP.NET、特にVisual Studio .NETという開発環境が登場してから、この問題は大きく改善されてきている。コードビハインドという技術は完全ではないにしても、デザイナーとプログラマの分業をかなりのレベルで実現していると思われる。
* IDC/HTX:IDC(Internet Database Connector)/HTX(HTML Extension)は、IIS 1.0から搭載されていたマイクロソフトのインターネット用データ・アクセス・モジュールで、データベースへアクセスするSQLクエリを記述したIDCファイル(拡張子「.idc」)と、そのクエリ結果を表示するための特殊な構文を埋め込んだHTML形式のファイルであるHTXファイル(拡張子「.htx」)の2つを組み合わせて使用する。IDC/HTXは、機能的な制限が大きく、VB互換でもないため制約は大きかった。ちなみにASPがIISに標準搭載されたのはIIS 4.0から。 |
こんなことをいうと、さもマイクロソフトの宣伝のように受け取られてしまうかもしれないが、実際に、Visual Studio .NETのデザイナ画面はHTMLデザイン・ツールとしても相当によく出来ている。WYSIWYGタイプのホームページ作成ソフトを利用したことがあるデザイナーであれば、それほど問題なく習得できる。あとは要所でのWebフォーム・コントロールの使い方さえ覚えてもらえれば、プログラマがデザインをいじらなければならない部分はほとんどなくなる。
デザイナーがデザインしてくれたASPXファイルを受け取り、あとはそれぞれのイベントをソース・ファイル側に書いていけばよい。ほとんどのケースでHTML内にコードを埋め込む必要がないため、デザインを破壊する心配は大幅に減るだろう。
ここまで書いてきたようなトラブルの大部分は、お互いの領域にお互いが踏み込んでしまうからこそ起こる問題だといえる。Visual Studio .NETを共通に利用することで、「もちはもち屋」式の共同開発が可能になり、作業効率は大幅に改善するだろう。デザイナーとの共同作業に苦労しているプログラマの方には、ぜひお勧めしたい解決方法である。
ただ、そうやってプログラミング環境とデザイン環境を統一すればすべての問題が解決するというわけではない。感性や思考方法が違う人間同士のコミュニケーションには、どうしても誤解や行き違いが発生しがちであるからだ。しかし、そういった土壌でこそ、これまでにない新しい発想のものが生み出されることもあり得る。以前に連載していた「実例で学ぶASP.NETプログラミング」で紹介した「検索画面」などは、筆者にとってはその典型的な例だ。
筆者の知り合いのプログラマに、デザイン・センスは抜群で、コピー・ライティングも玄人級、もちろんプログラミングも一流という人がいる。純粋に「すごいなぁ」と思っているし、尊敬もしている。しかし、ふと考えてみると、それはとても悲しいことなのかもしれないと思ったりもする。筆者はデザインに関しての自分の欠点をこの上なく知っているので(まぁ、ほかも大したことはないが)、自分と一緒に作業してくれるデザイナーの存在に感謝してやまない。その結果として、自分1人でできることをはるかに超えたものを作ってこられたのではないかと確信している。
感性や思考方法の異なる他人と一緒に何かを生み出す。モノ作りの楽しさの本質は、そういったところにもあるに違いない。だからこそ、今日も苦労したり、させたりしながらコミュニケーションを取り続けるのだろう。デザイナーという「違う畑のプロフェッショナル」と付き合う最善の方法とは、「お互いの尊重」に尽きるのではないだろうか。
![]() |
![]() |
![]() |
「ASP.NET Webアプリ開発の裏事情」 |
- 第2回 簡潔なコーディングのために (2017/7/26)
ラムダ式で記述できるメンバの増加、throw式、out変数、タプルなど、C# 7には以前よりもコードを簡潔に記述できるような機能が導入されている - 第1回 Visual Studio Codeデバッグの基礎知識 (2017/7/21)
Node.jsプログラムをデバッグしながら、Visual Studio Codeに統合されているデバッグ機能の基本の「キ」をマスターしよう - 第1回 明瞭なコーディングのために (2017/7/19)
C# 7で追加された新機能の中から、「数値リテラル構文の改善」と「ローカル関数」を紹介する。これらは分かりやすいコードを記述するのに使える - Presentation Translator (2017/7/18)
Presentation TranslatorはPowerPoint用のアドイン。プレゼンテーション時の字幕の付加や、多言語での質疑応答、スライドの翻訳を行える
![]() |
|
|
|
![]() |