筆者は，「プログラマがデザインセンスやセールス・プロモーションのノウハウを身に付けるよりも，デザイナーが技術を身に付けて80歩進み，プログラマには20歩進んでもらって握手するほうが合理的だ」と思っている（第1回目， 第4回目を参照）。Web制作者の世界では，通常，プログラマがデザイナーに歩み寄るほうが手っ取り早いと思われているにもかかわらず，なぜ筆者は，その逆のことを主張するのか。
良いデザインとは「成功するデザイン」
デザイナーがプログラマに歩み寄るべきと考えるには，ちゃんとした理由がある。詳しく説明しよう。まずは，次のAからEの項目を読んでほしい。
A） 誰が見てもほっとしたり，心安らぐようなWebデザインを目指すべきだ
B） 美しい，いわゆる統計上人気のある色だけをこだわって選び，うまく組み合わせることができれば，素晴らしいデザインに仕上がるだろう
C） 対象に合った色彩を使うこと―――例えば，ユーザー層が若い女性ならさわやかなパステル系，子供なら楽しいキャラクターを使い，高齢者向けなら落ち着いた色にすることが，常に効果を出す秘訣だ
D） 誰からも反感をかわないデザインが，良いデザインといえる最低の基準だ
E） 優れたデザインなら，どんな顧客でも，何の説明もしなくても，即座にその良さを認めて了解してくれる。逆に，顧客が難色を示すデザインは，やはりどこかに落ち度があるものだ
以上を，プログラマが「そうだ，そうだ，もっともだ」と，うなずきながら読んでいたら，コラボレーション相手のデザイナーは嘆くだろう。A～Eは，100パーセント正しいわけではないからだ。その理由は，次の通り。
A）ユーザーの行動を即座に喚起したいケースでは，ほっとして和むだけでは効果薄だ
B）統計上「美しい」とされる色だけを使う必要はない（現代美術や不協和音ばかりの音楽をイメージするとわかりやすいだろう）
C）性別や年齢からステレオタイプの解釈をしても，功を奏しないことがある。社会が付加したイメージが，ユーザーに内在するイメージと同じとは限らない。むしろ，ユーザーの中にあって，ユーザー自身が気づいていないイメージを引き出すようなデザインが求められることがある
D）誰からも反感をかわないということは，個性的でないということと表裏一体なので，ユーザーの記憶に残らない場合もある
E）良いデザインには非常に斬新なものもあるので，顧客の頭が固ければ，喧嘩ごしの説得を覚悟しなければならない
最初のA～Eの前述のリストをうなずきながら読んだプログラマは，「良いデザイン」とは，「誰が見てもキレイな色を使って，イヤな印象を与えないようにレイアウトすること」だと誤解している。
だが，それは違う。「良いデザイン」とは，一言でいえば「成功するデザイン」である。業務を効率化する，商品の特徴を伝える，集客する，会員登録数を増やす，情報を広く告知する，といった，Webアプリケーションの各々の目的を達成できるデザインのことだ。
「成功するデザイン」には，欠かせない要素がある。セールス・プロモーションと広告宣伝の視点である。そしてその視点は，書籍を読んで講習を受ければ即座に身に付くというものではない。企画や広告宣伝や販売促進の現場で，毎日，広告の反響やリピート数にさらされ，ノルマを達成するために工夫を重ね，何年かの試行錯誤を経て，初めて身に付くものである。結果を出すことのできるデザイナーは，必ずこれらの視点を身に付けているはずだ。
ところが，プログラマの目の前には納期の迫った案件があるわけで，開発の現場を離れて，広告宣伝や販売促進等の仕事を体験する回り道はできない。一方，デザイナーはといえば，開発の現場に出入りして，技術者の仕事を見聞きしたり，疑似体験することができる。だから，デザイナーからプログラマに歩み寄るほうが，多少なりとも現実味がある。
デザイナーは，開発現場の空気に触れ，プログラマの仕事に踏み込み，どのような方法で説明すれば，プログラマにデザインの目的や意図を伝えられるかを考えてみよう。プログラマが，是が非でもデザインをコードに反映させたいという意欲的な気持ちを持てるように，説得して鼓舞する方法を会得しよう。
独習では難しい，デザインセンスの獲得
もう一つ，プログラマがデザイナーに歩み寄ることを阻む「壁」がある。それは，デザインセンスという壁だ。
プログラマが，レイアウトや配色や色彩心理の書籍やWeb上の情報を読み，それらを知識として身に付けることはできる。それらの理論は，プログラムでいえば，文法やクラスやメソッドにあたるものだ。
デザイナーが，文法やクラスやメソッドを覚えたとしても，すぐにプログラムを書くことはできない。だが，プログラミングを独習し続けることはできる。なぜなら，プログラムには「正確な動作」という最低の基準があるからだ。計算結果が誤っていたり，入力した情報が登録されなかったら，最低の基準もクリアできていないことは一目瞭然だ。ところが，プログラマがレイアウトや配色や色彩心理の知識を得ても，独習を継続するのは大変だ。デザインの世界では最低の基準すら不明確で，評価するモノサシもないからだ。
デザイナーが最低数カ月間，熱心にコードを書き続ければ，プログラミングの感覚はつかめてくるはずだ（あくまで感覚である。プロのプログラマになれるわけではない）。しかし，プログラマが最低数カ月間，一人でデザインの課題に取り組んだとしても，デザインの感覚をつかむことは，難しいのではないだろうか。
例えば，本稿の最後に質問を挙げているので（本稿末の図1と図2を参照），プログラマの皆さんは，ぜひ読了してから試してみてほしい。デザイナーの皆さんは，コラボレーション相手のプログラマに試してもらうといい。プログラマが「デザインのルールから外れていること」や「間違っていること」を学び，知識として理解することはできるだろう。だが，それらに，生理的嫌悪感にも似た「気持ち悪さ」を瞬時に持つ感覚は，学習で身に付くものではないと思われる。
さらに，サンプル・プログラムの利用よりも，サンプル・レイアウトの利用のほうが，格段に難しい。デザイナーがサンプル・プログラムを利用しても，バックエンドの処理やプログラム・コードそのものが，顧客の目に触れることは，まずない。ところが，プログラマがレイアウトのサンプルを利用すれば，類似のデザインが存在する可能性が出てくる。顧客から「これ，どこそこのサイトと似てるよね，見たことがあるような気がする」という評価が下される恐れがある。
では，サンプルをカスタマイズすればよいのではないかということになる。デザイナーが，書籍などで知識を身に付けてコードを書き，プログラミングの感覚をつかんだうえで，サンプル・プログラムをカスタマイズすることは不可能ではない。なぜなら，カスタマイズが正しくできたかどうかは，動作を確認すればわかるからだ。ところが，プログラマがレイアウトのサンプルをカスタマイズするのは難しい。色の使い方や組み合わせ方やレイアウトの「正しさ」を確認する方法がないのである。
デザインには，評価方法や，客観的な基準が存在しない。それがプログラマ側からの歩み寄りを阻む（デザインセンスのあるプログラマは別である）。一般的にプログラマが，デザイナーを「違う世界の人」だと感じる理由も，言葉では言い表せない，定義することすら難しい，いかんともしがたい“センスという壁”にあるのではないだろうか。
さらに難しいことには，仮に，プログラマが，ビジュアル・デザインに関するセオリーを熟知し，デザインセンスを獲得できるとしても，顧客が求めるデザインは，セオリーを離れたところにあるということだ。中小規模案件では，顧客側も，費用対効果の期待度の面から，制作や開発や広告宣伝に潤沢な予算を準備できないことが，ままある。そうなると，低予算でも効果を出せるような，セオリーによらない，デザインセンスを超えた「デザインをベースとした発想力」が，必要になる。
この発想力を発揮するには，前述のセールス・プロモーションや広告宣伝の視点だけでなく，デザイン以外の視点や知識が必要になってくる。それこそ一朝一夕に身に付けられるものではない。
たしかに，プログラマにおいても「プログラミング・センス」というものは存在する。標準以上の品質のプログラム―――例えば，コードが非常に美しく，処理速度が圧倒的に速く，メンテナンスが容易で，革新的なアルゴリズムに基づく―――を開発したり，プラットフォームや言語や開発ツールを生み出すには，知識やプログラミング経験だけではなく，センスが必須である。
だが，こと中小規模のWebアプリケーション開発に限っていえば，よほど技術アレルギーのあるデザイナーでない限り，最長でも1～2年熱心に試行錯誤すれば，プログラマの作業を理解し，共感できる程度の技術を身に付けることはできる，と筆者は考える。開発ツールも進化している。基本的なレベルであれば，プログラマがデザインの知識やセンスを身に付けるよりも，デザイナーが技術を身に付けるほうが迅速かつ確実であり，コラボレーションの実践に役立てることができるのではないだろうか。
