もう、何年も前からWebの世界では、
『ロジックとデザインの分離』
が叫ばれてきた。
PHPならSmartyやXtemplateなど、
JavaではJSPなどで画面レイアウトをプログラムから切り離すことが当たり前になっている。
さて、では、デザイナとプログラマの役割分担はできるようになったのだろうか。
実際にはテンプレートファイルを編集するのは常にデザイナと言う開発手法はあまり見たことがない。
まず、ブログなどで動的なタグはだいぶ一般化したが、
プログラマと同じレベルでテンプレートを作成できるデザイナは多くない。
動的タグが含まれたファイルを見ただけで混乱するレベルのマークアップエンジニアもいるし、
そこまでいかず、動的タグが含まれたテンプレートを編集できる人であっても、
自力で動的タグを書いて、プログラマにテンプレートを触らせなくて済むデザイナはだいぶ少ない。
実際には、デザイナ（ディレクタ・マークアップエンジニア）が、
まず静的HTMLとしてデモ画面を作り、それをプログラマが動的タグに書き換えている、
実際のところはそれがやはり普通なのではなかろうか。
理由の一つは、動的タグと言うものがデザイナに普及しきっていないことがある。
もちろん、中には自分でタグを書けるレベルのデザイナもいるものの、
そのレベルの人はだいたいプログラマと見分けがつかないぐらいのスキルを持っている。
（つまり事実上技術者と言っていいタイプの技術に強いデザイナ）
もう一つは、デザイン、意匠という観点で見た目からサイトやシステムを考える、
デザイナさんの検討方法では、システム的な案件の仕様を考えるには十分ではないと言う面がある。
実際、デザイナさんの作ったデモ画面のまま、
最後まで開発が進んでいくことは殆どない。
どっかで、大幅に項目を増やしたり、画面遷移まで変わる場合がある。
プログラマやシステムエンジニアなら、画面の仕様はデータベースとリンクする。
実際には画面デザイン、プログラムの中のデータ構造、データベースに共通する、
データ捉えかたがあり、整合性を保つようにする。
これがデータベース設計の用語で言う概念データモデルである。
これを意識して画面設計ができるデザイナさんというのは極めて少ない。
（プログラマでも意識できない人がいるが・・・）
以上二つの理由から、実際のところ、「ロジックとデザインの分離」は、
ファイルとして分割されていても、担当者は分けられていない。
多くの場合、プログラマはデザイナの作ったデモ画面に、
ブツブツと文句を言いながら動的タグを書き込み、
データ構造上の矛盾を見つけては、レイアウトやフォーム項目を変更していく。
そして、その間にデザイナがデザインを変更したりしようとすると、
自分の作業が大きく影響を受け、時にそれまでのソースがごみになったりするので、
両者の関係は悪化の一途を辿る。
私の場合、自前のフレームワークはあえてこの常識化した、
「テンプレートはデザイナが書くべき」と言う流れに逆らった。
Smartyのユーザ定義関数などを用いて、動的タグを拡張し、
画面表示のための処理と言うものをほぼPHPで書かない形にした。
結果として、最初にデモ画面を受領した後は、
デザイナには一切テンプレートを触らせられない形となったが、
自分でテンプレートを書いて画面の動作を作っていく際には、
はるかに楽になったのである。
一方で、ユーザが見るのは画面である。
だから、デザイナが開発の中である程度デザインを変更できたほうが良い。
どうにかデザイナとプログラマの明確な分業が図れる仕組みを作れないか、
ずっと答えが出ていない問題だ。
『ロジックとデザインの分離』
が叫ばれてきた。
PHPならSmartyやXtemplateなど、
JavaではJSPなどで画面レイアウトをプログラムから切り離すことが当たり前になっている。
さて、では、デザイナとプログラマの役割分担はできるようになったのだろうか。
実際にはテンプレートファイルを編集するのは常にデザイナと言う開発手法はあまり見たことがない。
まず、ブログなどで動的なタグはだいぶ一般化したが、
プログラマと同じレベルでテンプレートを作成できるデザイナは多くない。
動的タグが含まれたファイルを見ただけで混乱するレベルのマークアップエンジニアもいるし、
そこまでいかず、動的タグが含まれたテンプレートを編集できる人であっても、
自力で動的タグを書いて、プログラマにテンプレートを触らせなくて済むデザイナはだいぶ少ない。
実際には、デザイナ（ディレクタ・マークアップエンジニア）が、
まず静的HTMLとしてデモ画面を作り、それをプログラマが動的タグに書き換えている、
実際のところはそれがやはり普通なのではなかろうか。
理由の一つは、動的タグと言うものがデザイナに普及しきっていないことがある。
もちろん、中には自分でタグを書けるレベルのデザイナもいるものの、
そのレベルの人はだいたいプログラマと見分けがつかないぐらいのスキルを持っている。
（つまり事実上技術者と言っていいタイプの技術に強いデザイナ）
もう一つは、デザイン、意匠という観点で見た目からサイトやシステムを考える、
デザイナさんの検討方法では、システム的な案件の仕様を考えるには十分ではないと言う面がある。
実際、デザイナさんの作ったデモ画面のまま、
最後まで開発が進んでいくことは殆どない。
どっかで、大幅に項目を増やしたり、画面遷移まで変わる場合がある。
プログラマやシステムエンジニアなら、画面の仕様はデータベースとリンクする。
実際には画面デザイン、プログラムの中のデータ構造、データベースに共通する、
データ捉えかたがあり、整合性を保つようにする。
これがデータベース設計の用語で言う概念データモデルである。
これを意識して画面設計ができるデザイナさんというのは極めて少ない。
（プログラマでも意識できない人がいるが・・・）
以上二つの理由から、実際のところ、「ロジックとデザインの分離」は、
ファイルとして分割されていても、担当者は分けられていない。
多くの場合、プログラマはデザイナの作ったデモ画面に、
ブツブツと文句を言いながら動的タグを書き込み、
データ構造上の矛盾を見つけては、レイアウトやフォーム項目を変更していく。
そして、その間にデザイナがデザインを変更したりしようとすると、
自分の作業が大きく影響を受け、時にそれまでのソースがごみになったりするので、
両者の関係は悪化の一途を辿る。
私の場合、自前のフレームワークはあえてこの常識化した、
「テンプレートはデザイナが書くべき」と言う流れに逆らった。
Smartyのユーザ定義関数などを用いて、動的タグを拡張し、
画面表示のための処理と言うものをほぼPHPで書かない形にした。
結果として、最初にデモ画面を受領した後は、
デザイナには一切テンプレートを触らせられない形となったが、
自分でテンプレートを書いて画面の動作を作っていく際には、
はるかに楽になったのである。
一方で、ユーザが見るのは画面である。
だから、デザイナが開発の中である程度デザインを変更できたほうが良い。
どうにかデザイナとプログラマの明確な分業が図れる仕組みを作れないか、
ずっと答えが出ていない問題だ。