デザイナとプログラマの距離

Teeda Webデザイン

Teedaで開発する具体的なノウハウとか書いていましたが、最初はちょっと抽象的な話です。
自分の最近の一番の興味は、デザイナとプログラマ（デベロッパ）の距離感についてです。ここでいうデザイナというのは配色・レイアウト・などWEBサイトの見た目を考え、それを画像やHTML,CSSなどに落とし込む人、プログラマはデータベース設計やWEBサイトの動的部分、バッチ処理などを作りこむ人という感覚でとらえてください。デザイナとプログラマは求められるスキルも違いますので、これまでは「デザイナとプログラマの分業」なんて話題であがる事が多かった話です。

さて、これまで自分は業務アプリの開発をメインに携わってきましたが、画面のデザインを専門のデザイナが行うというケースはほとんどありませんでした。いわゆる業務アプリの世界では、基本設計の頃に画面設計という形で定義する事が多いと思います。傾向としてデータベースへのCRUDがほとんどの為、どんなデータが必要か？という設計と同時に画面レイアウトも決めていくスタイルかと思います。これは画面の項目定義を行い後はハードが専用のインターフェイスを表示する時代に確立した設計スタイルですから、画面の見栄えを考慮する必要はなかったのです。当然、設計の段階で各項目が何桁でどんな種類（テキスト入力かプルダウンか等）で、といった入出力項目の属性は重要です。
そんな上流工程でWEBデザインの専門家が入ることのない画面デザインは、ユーザビリティの観点から考えるとお粗末な代物が多いと感じます。必要以上に１画面に詰め込もうとしたり、画面からオペレーションが予測できない不思議なインターフェイスになったり、HTMLでは実現が困難なインターフェイスが平気で設計されていたり、といった感じです。そして、そんな上流工程で決まった画面設計を元にデザイナに画面を作ってもらう場合もあります。この時、専門家からすれば信じられないような不思議な画面の見栄えだけを整える作業となるわけです。おまけにアプリ開発も平行で進められる事もあり、開発工程において「デザイナが作成したデザインをJSPに取り込む」などといった不毛で見積もられていない作業が発生したりします。
逆にWEB制作側が手動で画面デザインありきで開発が行われると、デザインだけは決まっているが業務的な設計が一切行われていないという事になります。自分が経験した案件では画面デザインの設計とミーティングは行われていても動的部分に関して設計なしで画面デザイン設計書から行間を読んで作るという代物でした。

このように開発においてプログラマとデザイナの扱いや問題をまとめると次のような事です。

  • 業務アプリ開発の上流工程では画面デザインは軽視される傾向がある
  • 画面デザインは設計の一部なので、設計者が上流工程でやると考えている
  • 専門のデザイナを使う場合でも、詳細設計より後に「実装」の一部として組み込まれる
  • WEB制作の上流工程では動的部分（アプリ）は軽視される傾向がある
  • WEBの動的部分はWEB制作の設計の一部なので、設計者が上流工程でやると考えている
  • 専門のプログラマを使う場合でも、デザインより後に「実装」の一部として組み込まれる
  • プログラマ-デザイナ間の調整に関して考慮しない

つまり、プロジェクトが業務アプリ寄りかWEBサイト寄りかで異なりますが、どっちかがどっちかを軽視しているという事です。最近ホットな元請・下請問題の件にも関連しますが、プログラムが書けない人が設計するのと同様に、WEBデザインできない人が画面デザインを行っているわけです。逆に経験は少ないですが、プログラムが解らない人が動的部分のWEBデザインも行っているのでしょう。ですが、WEB制作の現場でもアプリ開発の現場とフローでは大きく変わりません。つまり、要件定義から始まり、デザイン等の設計を行い、HTML（CSS,FLASH）でコーディングを行い、検証（テスト）をするというフローです。
また、５〜６年前に業務アプリを作るならば、今ほどはCSSが発達しておらず、プログラマがHTMLを習得してテーブルレイアウトを行い・・・という手順でも、専門のデザイナを確保しても大きな差はなかったと思います。WEB制作では今ほど動的なサイト構築への要求は少なかったかと思います。ところが、現代では技術的にもWEB制作と業務アプリ開発は近いものになってきています。これまでの考え方・やり方で、デザイナとプログラマの作業を簡単に分離できないのです。分担はするのですが、Ajaxや動的部分の作成など作業が重なる部分があるという事です。例えば、TeedaであればHTMLはフレームワーク上のソースコードであり、デザイナが実装するHTMLコードでもあります。

同じHTMLを編集することになるので、ソースコードのバージョン管理という概念が生まれるでしょう。先日のWEBコンでの話でもありましたが、現在のWEB制作会社でソースコードのバージョン管理を行っている会社は少ないそうです。ですが、Teedaで開発を行う開発会社であればSVN等で管理するのは当たり前かと思います。ここはデザイナがプログラマに歩み寄り、バージョン管理のノウハウを吸収すべきところです。
また、TeedaではLayout機能があります。業務アプリを作成する場合、Lyaoutで共通部分を切り出して再利用を図るでしょう。ところが、WEB制作の現場でスタンダードであるDreamweaverを使用してみると、Dreamweaverのテンプレート機能を使うことがヘッダ部などを管理する方法ということが解ります。また、選択されているメニューに対しCSSで画像を変える為にselectedというclassを動的に付与したい場合、Teeda的に言えばダイナミックプロパティを使ってclass属性をPageクラスで返す実装を行うでしょう。ですが、Dreamweaverのテンプレート機能では各ページに動的な属性を付与する機能があります。テンプレートのネストも可能なので、共通ヘッダとサイドメニューを分離することも可能です。つまり、プログラマがデザイナに歩み寄り、TeedaのLayout機能を使用しないべきなのです。TeedaのソースコードとしてのHTMLには重複が生まれDRYに反するかもしれませんが、結果として共通部分が管理されており、選択ページによってclassが変わる事が重要なのであり、ユーザが見るページは同じです。むしろ、ダイナミックプロパティでCSSを返すような処理を書かなくて済むので作業量が減るわけです。デザイナにHTMLを依頼した場合はLayout部分を切り出す作業も発生しません。

このように業務アプリを作成する場合でも、デザイナとプログラマの作業が被る部分は重要です。単純にプログラマ視点で考えてもダメですし、デザイナも「HTMLだけ納品すればいい」という姿勢ではダメです。最後まで一緒に作る気持ちが重要です。
尚、このようにデザイナとプログラマが上手く仕事を共有できるという点においてTeedaは理想のフレームワークの１つです。理由は簡単でXHTMLベースであり、デザイナ側への負担が最小限で済みます。jsp等でもタグライブラリを使っていけば良いのですが、Dreamweaverを使うという前提となるとJSPは完全に対応しているとは言い難く純粋なXHTMLで記述できるTeedaがベターです。Railsなどは向かないと思います（XML系のテンプレートもあるが、メジャーではない）。DjangoだとGenshiを使えばXHTMLで記述できるので親和性が高いでしょう。