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

デザイナーにとってのaspxファイル

　ここまでの話だと、あたかもVS.NETが素晴らしくて、ほかのHTMLデザイン・ツールは良くないというように感じられるかもしれないが、決してそんなことはない。筆者の場合、Webサイトを構築する際には、まずデザインをHTMLファイルでもらって、それからVS.NETを使ってプログラムを挿入し、aspxファイルに作り替えるという作業を行っている。だが、一度作ればそれで終わりということにはならないので、運用前にも運用開始後にもデザインの修正というのは局面に応じて存在する。

　しかしVS.NETを使わないデザイナーにとって、ASP.NETのaspxファイルというのは、修正の面で見ると非常に扱いづらい点があるようだ。

外部デザイナー：	「デザイン修正のために送っていただいたファイルなんですが……」
筆者：	「はい。何かおかしくなっているところがありましたか？」
外部デザイナー：	「私の使っているソフトだと、『aspx』っていう拡張子のファイルは開けないんです」
筆者：	「……あー、お手数ですが拡張子を『html』に替えてください」
外部デザイナー：	「あ、開けました。……私、何か変なことしちゃったかな？ ページの先頭に変な文章が入ってるんですけど……」
筆者：	「え？ どんな文章ですか？」
外部デザイナー：	「『<%@』とか変な記号が入っています」
筆者：	「……あー、無視してください……」
外部デザイナー：	「あ、そうなんですか。あと、ページの所々に同じような記号の文章が……」
筆者：	「……それも無視してください……」

　上記のような会話は、取り立ててASP.NETの問題というわけではなく、プログラムが挿入されたHTMLファイルでは、どのWeb系システム言語でもよくある話だろう。プログラマにとっては当たり前のことだが、HTML言語以外のタグは、デザイン作業上、邪魔なことこのうえない。お互いが同じ作業環境（デザイン・ツール。例えばVS.NET）を利用していれば、上記のような問題が発生すること自体ないが、作業環境が異なるというだけで、お互いに何かと作業が難しくなってしまうということになる。

　今年中に発売される予定の「Visual Studio 2005」は、ASP.NET 2.0と相まって、HTMLデザインの面も相当に改善されているように筆者は感じて期待している。外部デザイナーとの共同作業が多い筆者からしてみると、Visual Studio 2005が普及し、HTMLデザイン・ツールの標準になってくれたりすると最高なのだが。

解決策は事前のルール決め

　今回のテーマから発生する問題は意外と根が深く、解決は難しい。自社内のデザイナーであれば、適宜打ち合わせを行ったり、作業内容を確認し合ったりすることで解決できるだろうが、外部のデザイナーとそれだけのコミュニケーションの密度を保つことは難しいからだ。また、作業環境の問題についても社内のことなら「これを使って」と依頼（もしくは強要）すれば済むが、外部に対してはそこまで要求できない。

　何よりも、外部との共同作業の場合には、前提として「成果物の結果」だけで判断を行うのが普通であり、作業の過程について指示を出すのは難しいだろう。また、外部との契約は基本的に「この作業がいくら」という基準で行っていると思われ、HTMLソースが少々おかしいからといって、再度作業をしてもらうのは気が引けるということもある。そうした難しい状況下で、極力トラブルを回避する方法があるとすれば、大きく分けて以下の3つの方法になるだろう。

1. サイト構築上のルールを決めておく。また、プログラミング言語上のルールなどを早い段階で伝達しておく。
2. 前もってお互いの作業範囲をはっきり区分けしておく。
3. サイト内の各ページの役割（デザイン優先か、プログラム優先か）をはっきり決める。

　特に1と2が、外部のデザイナーとの共同作業で最も重要なことだと思われる。例えば、「フォームの各部品には名前を付けてほしい」とか、「サイト内のフォルダ構造はこうしてほしい」とか、ある程度細部にわたってでも後々の作業で問題になりそう部分は、依頼しておく方が望ましいだろう。また、上述の会話の中でも出てきたが、プログラミング言語上のルールも伝達しておくべきだ。ASP.NETの場合であれば「<%〜%>」で囲まれた部分は編集しないようにしてほしい、などと伝達しておけばトラブルは回避しやすい。また、構築段階ではそれほど関係ないが、運用開始後の修正段階に入るとお互いの作業範囲があいまいではトラブルのもとになる。修正のパターンを大まかでよいので列記し、「この部分の修正はデザイナーがやる」「この部分はプログラマが修正する」といった具合に、区分けをすればよいだろう。

　3に関しては、筆者の経験上の対処法なのだが、極論すれば「共同作業の範囲をなるべく減らす」ということになる。どうしてもプログラムが入るページというのは、デザイン上の制約が大きくなる。本当であればデザイナーの感性のおもむくままに、デザインをしてもらうのが最も良いのだが、そうなるとプログラムが難しくなったり、不可能になったりすることになる。そこで、プログラムが入るページ（プログラム優先のページ）と、まったくプログラムが入らないページ（デザイン優先のページ）にサイト内の役割を分割すると、サイトの質も上がり、作業もしやすくなる。

　例えば、ショッピング・サイトの場合であれば、商品の購入ページにはプログラムが入らざるを得ないので、あっさりしたデザインにしておく（プログラム優先のページ）。そのうえで、各商品の詳細な紹介ページにはプログラムを一切入れず、購入ページにリンクすることで、デザインの自由度・メンテナンス性を高めるということになる（デザイン優先のページ）。ページ数が増え、冗長に思えるかもしれないが、意外と効果的な方法であるのでお試しいただきたい。

■

　最後にハッキリさせておきたいのだが、筆者はデザイナーをばかにしているつもりは毛頭ない。確かに、筆者自身はプログラマであるので、どうしてもそちらの観点からの表現になってしまっているとは思う。ただ、し好も思考も指向もまったく異なるデザイナーとプログラマという複数の人間が、1つの物を作り上げる際には、どうしたところでさまざまな問題が発生する。それは当たり前のことであって、どちらが悪いという問題ではない。そうしたトラブルを極力回避し、円滑な構築作業を行っていくためには相互理解が欠かせないと訴えてきているつもりだ。

　今回のテーマのような、外部のデザイナーとの共同作業の場合、頻繁にコミュニケーションを取るのは、現実的には難しいだろう。しかし、それだからこそ事前にルールを決めておくことが重要になる。そして、何よりも大事なのは「お互いの尊重」ということになるだろう。その中には、作業分担上の割り切りと妥協も必要になる。できないことを補完しあう関係である以上、相手にすべてを求めることは難しいからだ。

　デザイナーに限らず、外部の人員との共同作業には何かと苦労が付きまとう。Webアプリケーションの構築では特に顕著であるが、お互いがまったく顔を合わすことなく、メールと電話だけで共同作業を行っていくケースも、このネットワーク時代では増えてきている。そうした中で、成果物の品質に妥協しない構築を行い続けるのは難しいことではあるが、筆者の経験が少しでもお役に立てば幸いである。

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

　

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

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