PR

デザイナーが担当したほうがよいこと

 以上のように,デザイナー同士ならツーカーでわかり合えることも,プログラマにはわからないことがある。プログラミングについては細かいことでも気になるが,ビジュアル・デザインやユーザー・インタフェースについては大雑把になるらしい。

 Webアプリケーションのレイアウトといえば,基本的には,ラフデザインや画面遷移図や設計図に従って,切り出した画像を貼り付け,コントロールをドラッグ&ドロップするだけの作業である。また,色やフォントサイズの指定も,開発ツールの中からプロパティを変更するだけで済む。そのため,Photoshopでデザインを起こして画像を切り出すまではデザイナーの作業で,後はプログラマが担当してもよいと思うかもしれない。しかし,それはやめておいたほうがお互いのためだ。餅は餅屋である。

 もっとも,最初から表示状態にあるコントロールだけをレイアウトしたのでは済まない場合もある。処理上の必要性から,コンテナだけをレイアウトして,その中にプログラムでコントロールを生成して追加するようなケースもある。また, プログラムの見通しをよくするために,非表示のTextBoxコントロールをレイアウトして値を代入しておき,その値を複数の処理で利用する場合もある。

 レイアウト時には,絶対座標と相対座標の使い分けにも注意が必要だ。表示させるデータ件数によってコントロールのheightを変えたいときは,その下方に絶対座標で文字や画像をレイアウトしてはいけない。heightが変わると,重なってしまいかねない。

 これらは,慎重を要するが,難しい作業ではない。通常,設計書に書かれているから,確認しながら進めればよいだけの話だ。

 このようなことを踏まえたうえで,前回も書いたように,デザイナーも開発環境を持ち,プログラマと同じ開発ツールを使おう。そして,自らの手でデザインと修正を行うように心がけよう。表1は,デザイナー自身が担当したほうがよい作業の一覧である。

【表1】デザイナー自身が担当した方がよい実作業

でもしかプログラマに,丸め込まれるな

 これまで書き連ねてきたような,デザイナーとプログラマ間の無理解から生じる問題は,双方に「協調性」「責任感」「取り組み姿勢」があれば,解決することは十分に可能だ。知識や経験や能力の差は,工夫次第で乗り越えられる。

 だが,もし半年経っても1年経っても両者の距離が縮まらないとしたら,その原因は職種や作業能力の違いよりも,“プロ意識”の差にあるかもしれない。どちらか一方,あるいは両方が,早く作業を済ませて納期をクリアして回転率を上げればよい,品質は二の次で儲かりさえすればいい,という意識で仕事に取り組んでいたなら,お互いを尊重し合うことは難しいのではないだろうか。

 デザイナーには,「デザイナーにでもなるか,デザイナーしかやることがない」という理由で,この職業を選んだ“でもしか”デザイナーは極めて少ない。デザイナーという仕事は,けっして生活の安定という面では有利ではない。デザイナーになりたい!という志だけで,この世界に飛び込むのは,一種の賭けである。にもかかわらず,絵を描くのが好きだったり,美しいものを見るのが好きだったり,好きな画家やクリエーターに憧れるなどしてこの職業を志したのだ。だから,もし働かずとも生活できる環境に置かれたとしても,多くのデザイナーは何らかの作品を創らずにはいられないだろう。

 しかも,デザイナーは,就職して早い段階で,アートとデザインの決定的な違いという,手厳しい洗礼を受ける。自らの内面や個性を表現するのではなく,対象を的確に捉えて伝え,結果を出すことが要求される仕事であることを思い知る。「職業の意味自体に悩む」洗礼の時期を乗り越え,さらに数年以上仕事を継続して生き残っているデザイナーは,少なからずプロ意識を確立している。

 一方,プログラマは,少なくとも,デザイナーよりは生活の安定という面で有利な職業である(と筆者は思う)。だから,プロ意識の強い責任感のあるプログラマもいれば,“でもしか”プログラマがいてもおかしくはない。仕事に就いた当初は意欲的であったのに,長時間労働と技術進化の速さに意欲を失いがちになる人も出てくる。また,プログラマは,自己表現と仕事のバランスといった強烈な洗礼を,デザイナーほど受ける機会がないだろうから,目的意識が薄らぐこともあるかもしれない。

 もし,プロ意識と責任感を持つデザイナーが,利益と効率のみ優先のプログラマとのコラボレーションを余儀なくされたら,「これ以上はゆずれない」という境界線を明確にして,けっして丸め込まれてはならない(もちろん,でもしかデザイナーとプロ意識の強いプログラマといった,逆のケースでも同様である)。お互いの感情に配慮ばかりしていたのでは,プロジェクト内部の「見せ掛けの和」を保つことはできるかもしれないが,品質がおざなりになり,成果は上がらなくなってしまう。

 視線を開発目的の達成にのみに向けて,歩み寄り,共に努力していこうではないか。


PROJECT KySS(プロジェクト・キッス)
薬師寺 国安(やくしじ くにやす,フリープログラマ)と,薬師寺 聖(やくしじ せい,個人事業所SeiSeinDesign自営,http://www.SeinDesign.net/)によるコラボレーション・ユニット。1996年,聖が勤務先で地域ポータルを企画制作,これを訪問した国安と知り合う。ActiveXユーザー同士で意気投合し,翌年「PROJECT KySS」結成。1999年よりXMLとDHTML利用のコンテンツ開発,2000年にはCMSツール開発と,一歩進んだ提案を行い続けている。XMLに関する記事や著書多数。両名ともMicrosoft MVP for Windows Server System - XML(Oct 2004-Sep 2005)。http://www.PROJECTKySS.NET/