なんだか偉そうなタイトルをつけてしまいました。
「デザインが失敗してしまう理由」という記事を読ませていただき、「アメリカの事情はもはやわからないけど・・・そうなの？」と懐疑的になったので、少し日常的に思っていることをまとめてみようと思ったわけです（この記事の批判を書きたいわけじゃなくて、インスパイアされて自分の考えを書くということっす）。
エンジニアは、Webサイトのデザインをするデザイナー（以下、単にデザイナー）が作業として何をしているかはわかっています（photoshop/illustrator/flashなんかをごちょちょやってる）。
デザイナーも、エンジニアが、作業として何をしているかはわかっているはず（viやemacsでごちょごちょやって、cliでパコパコ）。
ただ、お互いに「なんでそうしているか」はわからないわけです（エンジニアのボクは、デザイナーがなんでその大きさで、そのマージンを設定したのかなんて皆目わからない）。
では、分かり合える部分や要素はないんでしょうか？
まず、「Webサイトを作る」って目的は相互に理解しているはずですね。
先に紹介した記事のように「（デザイナーが）テクノロジーの理解が不可欠」とか、「言葉でのコミュニケーションを十分に」とか・・・目的に対して「周辺のこと」にすぎないことは、すぐに考えることじゃないって気がします（もちろん必要なことだけど）。
「目的」というタイトルの次に来る最初のパラグラフは、「構成要素のリスト作成」じゃないかと。
これはエンジニア的なそれでもダメだし、デザイナー的なそれでもダメで・・・だれもが・・・顧客やユーザーもふくめたプレイヤー全員にとっての共通言語で作られた「構成要素のリスト」であるべきです。
多分、これを作る時が、エンジニアとデザイナーの最初のコミュニケーションになるはず。
で、これを作る過程で・・・「エンジニアとデザイナーがわかる構成要素リスト」が第1版としてできて、その後その他のプレイヤーにもわかるように版を重ねるってことになりますよね（多分）。
ここで失敗したら、「テクノロジーが」とか「デザイン知識が」とか「コミュニケーションが」とか言ってもしょうがないのに言わざるを得ない状況になって・・・つまりは「全部が失敗」になるんじゃないかと。
（とりあえず便宜的にマネージャーのこととかは省略ｗ）
じゃ、失敗しないためには・・・そもそも第1版をつくるアクションをするかどうかが重要だし（しない場合が圧倒的に多いよね！）・・・したとしてもその内容がさらに重要です。
具体的にはこのタイミングで「同じ言葉でしゃべれるか」ってことが大きなポイントになると思うんですが、大抵は手前勝手な論理で話してて、ずれまくるのがよくある光景。
ずれないために何が必要かってーと、共通の意識と言語なわけですが・・・それってなんだろ？って考えると・・・
オブジェクトって概念をベースに、オブジェクトの割り出しとオブジェクトの組み合わせ方を話せるかどうかってことが一つのやり方って気がします。
例えば、いきなり「ページが・・・」とか「サーバー構成が・・・」なんて話がはじまったらストップすべきです。
最小単位がなんだかわからないでそんな話をしても、後で苦しむだけですから。
もちろん、オブジェクトって概念を使うやり方をするには、いろんな情報が必要になります・・・「調査」ですね。
これをやらないと、デザイナーは「（先に紹介した記事にあるように）利用者中心のデザイン」を中途半端にすることになるし、エンジニアも無駄なコードを死ぬほど書く羽目になります。
「調査」をちゃんとやって、情報をそろえ・・・エンジニアとデザイナーがオブジェクトの概念をベースに「構成要素リスト」の第1版を作って・・・それをベースにすべてのプレイヤーがわかる言葉で書き直していく・・・そしてここで初めて「作り始める」。
これをやったら、エンジニアもデザイナーも自分の領域で思いっきり作業できるし、プロジェクト的にもリソースの見積もりを間違えるようなことにはならないだろうって思うんだけどどうでしょう？
「デザインが失敗」とか「システムデザインが失敗」かどうかなんて話している場合じゃないですよ。
もちろん、マネージャーや時間のせいにするのは・・・ま、それが楽なのはわかりますが。。。
「目的を達成するかどうか」が問題なわけですから、それをまず考えて手段の話をしたいってボクは思います。
もし、オブジェクト指向ができて、インタラクティブデザインもできるデザイナーさんがいたら是非連絡をください。
一緒にやりたい。
（何を？）
とりあえず、「一緒に焼肉食う」あたりから（ｗ
P.S.
これまた日常的にあることですが・・・「イチからきっちりやってる時間なんかないよ」とか言う人がいます。
ボクは「イチからきっちりやらないとダメ」なんて言ってないのです。
「きっちりパターン」を知らずして、どうして時間に間に合わせるための「省略ポイント」を判断できるんだ？と問いたいのです。
「基」がなくて、時間とかお金とかに振り回されて手抜き仕事している振りをするのはバカだし、ズルいよ。
（あ、自分に対しての戒めとして言ってますので、該当していると思った人も一緒にがんばりましょ）
One Comment
ってか、何を作る時でもチームでやるなら同じことが言えますね。
そもそも、ちょっと環境が違うだけで、エンジニアとエンジニアだって相当ズレまくります。
やっかいなのは・・・リアクションタイプの人。
こっちの出方待ってられるとかなり面倒くさいし、コミュニケーションする必要があるのか？って思うったりする。
バランスタイプの人は、人数が多い時には「いてくれてありがとう」って思うことがありますが、少ない時にはこれまた面倒（ｗ