ASP.NET Webアプリ開発の裏事情 エピソード5：デザイナーとの飽くなき闘い！（本戦） ――　まだまだ続く、泥仕合　―― 小田原 貴樹（ハンドル・ネーム：うりゅう） 2005/03/03

Page1 Page2

筆者略歴 8年間のベンチャーIT企業勤務を経て、フリーのプログラマとして独立。専門はWebアプリケーションの設計・開発。「生涯一プログラマ」を目標に、常に中小事業者を対象とした現場に立ち続けている。仕事の半分は、社外デザイナーとの共同作業。

　

筆者：	「あのー、送ってもらった申込画面のフォームの件なんですけど……」
外部デザイナー：	「はい。顧客の要望どおり項目を入れてみましたが」
筆者：	「ええ。確かに項目は全部配置されてます」
外部デザイナー：	「ほかに何か問題がありました？」
筆者：	「いや……。フォーム内の各部品の名前（nameプロパティのこと）が全部同じなんですけど……」
外部デザイナー：	「えっ？ フォームの部品に名前を付けなきゃいけないんですか？！」
筆者：	「……できれば付けてください。いや、まぁこっちでも付けられますけど……」
外部デザイナー：	「よく分かんないんで、付けてほしいですー」
筆者：	「はーい、こっちで付けますー……」

　以前（エピソード2）紹介したのは、自社内のデザイナーとの闘いだったのだが、Webアプリケーションの構築では外部のデザイナーとの共同作業も非常に多い。自社の中での話であれば、コミュニケーションを緊密に取ったり、直接具体的な指示を出したりすることで回避できる問題も、外部の人間が相手となるとそう簡単な話ではなくなってくる。プログラミング言語を利用する場合には、最低限、コーディング規約という常識が存在するが、HTMLの記述ではそういったものが確立されていない場合が多く、Webデザイナーによって千差万別な部分がある。

　Webアプリケーションの構築の中で、外部のデザイナーと共同作業をする場合に鬼門となりやすいのが、冒頭の会話のような入力フォームが含まれているページの制作だ。フォームがあると制御しなければならないコントロールが多くなり、プログラミング上では特に気を使わなければならないページとなる。Webデザイナーにとっては単なるデザイン要素にすぎない各部品も、プログラマにとっては個別に制御が必要なコントロールである。

　作業上のこの感覚の違いは大きく、例えばデザイナーにとってテキストボックスは何個あってもテキストボックスなので、1つ配置したら残りはコピー＆ペーストでパッパッと配置して、サイズなどを変更すれば終わりということになるのだが、その結果は冒頭のように、すべての部品に同じ名前が付いてしまっていたりする。当然ながら各部品が同じ名前では、プログラム側で制御することはできない。デザイナーが、フォームの部品に名前を付けるという作業の重要性を理解してくれているケースは、筆者の経験上非常に少なく、5人に1人いるかどうかといったところだ。ひどいケースになると、<Form>タグそのものが入っていないフォーム・ページを渡されたことも結構あったりする。

　フォームにかかわる問題は、開発環境が違う場合にはさらに大きくなる。外部のデザイナーに「Visual Studio .NET（以下、VS.NET）かWeb Matrixを使ってください」と要求するのは非常に難しく、筆者も勧めてはいるのだが、使ってもらえたケースは皆無だったりする。そうなるとフォームに配置される部品のうち、特にコンボボックスやラジオボタンなどは、必要に応じてプログラマ側でWebサーバ・コントロールに配置し直さなければならない。仕方のないことなのだが、せっかくデザインされているページ内の部品を作り直すのは悲しい気持ちになる。

　ということで、今回は外部のデザイナーとの共同作業で発生する泥仕合の、ほんの一部をご紹介しよう。余談だが、筆者がこれまで一緒に仕事をしたデザイナーの8割以上が女性である。筆者の周りがたまたまそうだったのかもしれないが、Webデザイナーという職種は女性が多いようだ。そういった環境の中で、冒頭の会話のように女性デザイナーから甘えられると、免疫の足りない筆者などはどんどん自分の仕事の範囲が広がっていき、後で後悔したりする。

スライスの悪夢

　エピソード2でご紹介した、社内のデザイナーとの間に発生した問題というのは、デザイナーとプログラマという、思考方法が異なる人間同士が共同作業を行った場合に生じてくるものだった。HTMLデザイン・ツールはVS.NETを利用してもらっているという前提のうえでも、いろいろな問題が発生してしまうものだ。それが、上述したように外部のデザイナーとの共同作業で開発環境を合わせられない場合には、混迷の度合いが激増する。

　筆者としては大変残念なことながら、HTMLデザイン・ツールとしてVS.NETを利用しているWebデザイナーというのは極めて珍しい。昨今、HTMLをすべてテキスト・エディタで手書きしているようなつわものも減少してきていると思う。HTMLデザインに利用できるソフトウェアにもいろいろな種類があるが、プロフェッショナル・ユースではMacromedia社の「Dreamweaver」が最も人気があるようだ。

　Dreamweaverに限らず、最近のHTMLデザイン・ツールは大変よくできており、デザイン・センスさえあれば直感的にサイトをデザインしていくことが可能になっている。極端な話では、WebデザイナーがHTML言語に精通している必要性もほとんどない。HTMLデザイン・ツールの画面上でデザインが出来上がっていれば、ブラウザ上でもきちんと表示されるようになっているので、HTML言語のことを意識するケースが減ってきているといえるだろう。しかし、これは逆にいえば「画面表示は出来ているけど、HTMLソースはどうなっているか作った本人にも分からない」ということだったりする。そしてそれは、プログラマにとっては大問題であるのだ。

筆者：	「FAQページの外枠のデザインのことなんですけど」
外部デザイナー：	「ええ、顧客のパンフレットのデザインを踏襲してみました」
筆者：	「この外枠って、もしかしてスライスですか？」
外部デザイナー：	「もしかしなくてもスライスです」
筆者：	「このページの途中にプログラムを挿入して、データベースに格納された情報を読み取らなければいけないんですね。
	で、どこにプログラムを入れていいかまったく分からないんですが……」
外部デザイナー：	「えーっと、ページの最初の部分がこう段違いの枠が入っていて、その中にもう1つ別のテーブルの中に内枠のテーブルが入っているじゃないですか。その中に、文章のためのテーブルが入って……」
筆者：	「……す、すいません口頭では分からないので、HTMLの中にコメントを入れてもらえますか？」
外部デザイナー：	「……あまり自信ないですが、やってみますね……」
筆者：	「よ、よろしくお願いします……」

　HTMLデザイン・ツールの中には、「スライス」という機能を持っているものがある。大きな画像や複雑な図形などを分割し、自動的にHTMLソースを作成してくれるという素晴らしい機能だ。上記の会話のように、ページに複雑な外枠などを配置したい場合にも有効で、頭を悩ませてHTMLタグの構造を作らなくてもデザインが出来上がる。しかし、自動的に生成されるコードが、人間にとって決して見やすいものにはならないということをプログラマであれば知っている。

　上記の会話のようにスライスを利用して、ページの外枠などをデザインした場合、HTMLソースは大変なことになっていることが多い。「<TABLE>タグの乱舞」としか表現のしようがないほどネストが繰り返され、どの部分がどこから始まって、どこで終わっているのかを判別するのは下手なパズルの比ではない。そんなHTMLソースの中に、ループが必要となるようなプログラムを埋めなくてはならなかったら……。もはや悪夢としかいえない作業が待っていることになる。

　ページ内のある部分が（データベースから取得した複数のデータを埋め込むために）ループするということは、状況によってその部分が伸び縮みするということになる。伸び縮みが可能なデザインの大前提として、ループの開始部分と終了部分は正確に指定されていなければならない。指定がおかしかった場合、実際に表示してみると、繰り返しが起こるたびに内容が右にずれていってしまったりするのは序の口で、デザインが完全に崩れてしまったり、ループ部分がまったく表示されなかったりする。スライスという機能はデザイナーにとっては恩恵であるが、プログラマにとっては悪夢になることが多いという感想を筆者は持っている。

INDEX
	ASP.NET Webアプリ開発の裏事情
	エピソード5：デザイナーとの飽くなき闘い！（本戦）
	1．スライスの悪夢
	2．デザイナーにとってのaspxファイル

　

「ASP.NET Webアプリ開発の裏事情」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）