プログラマが知らない，デザイナーの苦労？
第11回 プログラマが知らない，デザイナーの苦労 | 日経 xTECH（クロステック）
プログラマの自分が感想を書いてみる。
今回は，デザイナーとして，世間やプログラマに対して言いたい放題書かせてもらう。どうか怒らずに最後まで読んでもらいたい。デザイナーの皆さんには，大いに賛同していただける内容になっているはずだ。
たまには吐かないとね。
デザイナーだって，タイヘンなんだ！
今回は，デザイナーとして，世間やプログラマに対して言いたい放題書かせてもらう。どうか怒らずに最後まで読んでもらいたい。デザイナーの皆さんには，大いに賛同していただける内容になっているはずだ。
営業に不満を持っているプログラマが多い様に、プログラマに不満を持ってるデザイナーの方も多いでしょうね。
1) デザイナーという職種に対する，先入観がある
世間（顧客やエンドユーザー）には，「すべてのデザイナー」＝「技術に無知」だという先入観がある。「デザイナー」とは「Webページの配色とレイアウトをする人」だから技術を知らなくて当然，むしろ知らなくてよいとする傾向すらある。
ここで指してる「技術」が曖昧かも。デザイン力も技術の一つだと思うので、ここでは「ソフトウェア開発の技術」みたいなのを指しているのかな？
それともデザイン力すら「技術」と思っていない人が居ると訴えているのかな・・・。
プログラマの中には，設計＋GUIのデザインだけでなく，表示に関するプログラミングを，デザイナーに分担してほしいと思っている人たちもいる。色や座標値を扱う描画にかかわる処理を，プログラマがデザイナーと刷り合わせつつ実装するよりも，デザイナー自ら実装したほうが手っ取り早いと考えている人たちだ。
JavaのWebアプリ等だと、Velocity等を使用してデザイナー自ら画面作成が出来る様にするなど、そういう方向に向かってはいますね。
手っ取り早くなるかどうかは、プログラマとデザイナーの質によると思いますが。
「良いものを作りたい」ではなく「丸投げしたい」プログラマだと、デザイナーに負担がかかるだけかも。
筆者自身，デザイナーというだけで，何度も不利益を被ってきた。企画設計担当者としてヒアリングに出向いた先で，技術に関する質問をことごとく無視されたこともある。
こんな事があるのか・・・。
もしや、相手の方が、わからないから答えられなかったんじゃ・・・。
2) 「デザインされていることに気づかせないデザイン」の意味が，理解されない
例えば，参加したプロジェクトの中で筆者がデザインを担当し，「使いやすく，レスポンスが良く，目的の結果にピンポイントでたどりつける」と顧客に感謝されているWebアプリケーションがある。
「機能美」というやつですね。シンプルザベスト。業務用アプリとしてはこれがベストだと思う。
但し、何らかのプロモーションやプレゼン、デモに使用する場合、少々無駄に派手なほうが良い場合もあるかも。
このあたりのさじ加減って難しいですね。
3) 処理のみ重視で，ビジュアル・デザインの意義が否定される
ところが技術者の中には，ビジュアル・デザインの必要性を否定する人がいる。動作しさえすれば，見た目によってアプリケーションの効果が変わったりしない，と言うのだ。人間の心理を全くわかっていないと言わざるをえない。
アプリケーションの効果は変わらないとは思う。
但し、操作する側の人間は、デザインによって操作性が変わるわけで。
結果、アプリケーションの使い勝手自体が変わってしまう。
4) ゼロからの仕事を急かされる
ところが，試行錯誤中のラフを見て「結構きれいだ。できてるじゃないか。それでいいから，すぐにGIF形式で切り出してもらえないかな，プログラムを書くから」などと言うプログラマがたまにいる。ここでデザイナーが妥協してしまうと，生煮えの状態のままのデザインで納品することとなってしまう。
完成品の画像がないとコーディング出来ないようなコードは、画像の変更があった場合どうなるんだろう。
デザイナーはここでプログラマに危機感を覚えて良いと思う。
デザイナーが工程を守っている限り，プログラマがデザイナーを急かす言動は，逆効果にしかならない。たとえ顧客が満足しても，デザイナー自身は納品物に満足していないがゆえに，実績をPRしないということになりかねない。
同意。
満足してない物の納品って自己嫌悪になったりします。
まあ自分の場合は「時間足りない・能力足りない」ために起こってるんですけどね。
納期より前に急かされるってことは余りないです。まあ最初から納期が短い事は多々ありますが。
5) 高品質を追求する姿勢を，効率の面から脅かされる
ところが，デザイナーにとっては“繊細”な作業が，プログラマから見れば“神経質”な作業に映るらしい。筆者の相方など「細かいところまで気にし過ぎだ。早くデザインを切り上げて納品すればいいのに」とまで言う。
「そこまでやるのか！」と感心することはあれど、「そんなことやらなくていい」なんてとても言えない。自分はデザインを知らないから。
あと、顧客が求めてない限り、納期前に納品する必要性は皆無だと思う。
創造的でない作業を効率化して，空いた時間を創造的な作業に使うことには意義がある。だが，創造的な作業を効率化してまったら，仕事には“むなしさ”しか残らなくなる。品質より効率，美学より利潤，ではなく，品質向上のために効率化をはかり，美学を追求するために利益を還元することが必要ではないだろうか。高品質を追求する「姿勢」は，社会人としての義務である。
創造的な作業の効率化って思いつかないけど。ここでは「妥協」みたいな事かな。
妥協も必要だけど、あくまで妥協せざるを得ない状況になった場合のみかな。
妥協だらけだと"むなしさ"しか残らなくなるのは同意。極端な話、誰でも出来る事ばかりになってしまう。
社会人の義務かどうかは判らないけど、高品質を追求しないと詰まらないしね。
プログラマに通用しないデザインの常識
1) 依頼した以外のフォームまで気配りすること
開発途中で，申し込みページのボタンの背景色を「PALETURQUOISE」から「SKYBLUE」に変更することになったとしよう。この修正をプログラマに頼むと，申し込みページのボタンの色は修正してくれるが，申し込み内容確認ページのボタンの色は修正しない場合がある。
ここはちょっと批判的に。
プログラマとして、同じ修正を数箇所に書くようなコーディングはNGです。
同じようなボタンのデザインなら、スタイルシートでクラスを定義しておくなどして頂きたい。
もちろん、その方法ではデザイン上不都合があるならば、その限りではありません。
その場合は、修正箇所を指定するべきだと思います。
これは相手がデザイナーでも必要なコミュニケーションでしょう。
デザイナーなら「ここも直すのかな？」と気付く人は多いでしょうが、勝手に直すようなことはせずに、恐らく直すべきなのか聞いてくるでしょう。
とはいえ、
なぜなら，サイト全体の統一感について，デザイナーとの間に微妙な温度差があるからだ。「違うページだから同じ色にする必要はないと思う」あるいは「どっちも同じ水色なのに，なぜ直さなければいけないのか？」と，考えているのである。
上記のような事を言うプログラマはどうかと思う。
2) 類似個所の修正に気づくこと
プログラマによっては，「使用不可」のボタンの文字サイズを12ptに変更しても，「使用可」になった場合の文字サイズの修正を見落としている場合がある。
これも1と同じ様に、クラスで何とかなるかも。
ただ、自分はボタンの文字だけ動的に変更するからあまり見ない例です。
というかボタンが変わるのか。disableにするんじゃダメ？
3) Webフォームのタイトルを適切に書き換えること
適当なタイトルを設定しているケースもある。例えば商品紹介コーナーの「パソコン」のページや「プリンタ」のページで，「○○商店／商品紹介／パソコン」「○○商店／商品紹介／プリンタ」のように書くべきところを，どちらのtitle要素も同じ「○○商店／商品紹介」にしてしまっているのである。これでは，ユーザーがブラウザのお気に入りに追加する際，名前が重複してしまう。
これは耳が痛い。
業務用Webアプリしか作ったことないから、トップページしかお気に入りに追加されないので、気にしていなかったところ。
4) コントロールを上から順番に並べること
処理を書くうえで重要なのは通常，コントロールのidであって，レイアウト順序ではないから，プログラミングには支障がない。そのため，idが「TextBox2」のテキストボックスが，idが「TextBox1」のテキストボックスよりも上にレイアウトされる，という事態が生じる。
そもそもこのidがまずい。
スタイルシートのクラス名もそうだけど、「box1」とか「button1」とか書かれても、わからない。
何のテキストボックスなのか、どんな場所で使われているクラスなのかがわかる名前がよいなぁ。
デザイン上何か意味があるのかな？
あ、javascriptで動的に処理する際に、数字がよいとかあるのか。
また，各ページのレイアウトは似通っているにもかかわらず，処理を共通化できないケースでは，同じ表現で類似の意味を持つ部品のidがページごとに異なっていたりする。例えば，メニューのページでは「トップに戻る」ボタンのidはButton1なのに，商品紹介ページではButton3だったりする。処理が共通化できないとしても，デザイナーの立場からすれば，同じidでなければ不便きわまりない。
そんな名前付けるプログラマが居るのか。
5) ビジュアル・デザインの統一感を保つこと
プログラマの言い分はこうだ。「ユーザーがボタンを押し忘れて次の処理に移った場合はエラーが出るので，ボタンはもっと目立つ色にしたほうがいい」。さすがに，この発言には，コア・デザイナーはキレる。「だったら，デザインを変えずに，エラー処理を追加する方向で考えるべきだろう！」
ボタン押さずに次の処理いけるのか。
それも驚きだが、エラー処理を入れないのもびっくりだ。
デザイナーが担当したほうがよいこと
以上のように，デザイナー同士ならツーカーでわかり合えることも，プログラマにはわからないことがある。プログラミングについては細かいことでも気になるが，ビジュアル・デザインやユーザー・インタフェースについては大雑把になるらしい。
責任問題の部分もあると思います。
デザイン部分で怒られても、プログラマのせいではないと思ってるプログラマが多いのでは？
表示確認 Macintoshでの表示確認
表示確認って、Windowsの各種ブラウザでもやらないとダメじゃないかな？
でもしかプログラマに，丸め込まれるな
だが，もし半年経っても1年経っても両者の距離が縮まらないとしたら，その原因は職種や作業能力の違いよりも，“プロ意識”の差にあるかもしれない。
変なプライドを持ってるプログラマは多い。
それ以上にプロ意識が無いプログラマが多い。
一方，プログラマは，少なくとも，デザイナーよりは生活の安定という面で有利な職業である（と筆者は思う）。だから，プロ意識の強い責任感のあるプログラマもいれば，“でもしか”プログラマがいてもおかしくはない。
デザイナーはわからないけど、満足にプログラミングが出来ないプログラマは居る。
この辺がプロ意識に差が出てるかもしれない。
しかし、生活面の安定はどうなのかなぁ。自殺する人多いよ？
仕事に就いた当初は意欲的であったのに，長時間労働と技術進化の速さに意欲を失いがちになる人も出てくる。
長時間労働はまだいいんですけどね。長時間労働になる理由が馬鹿らしくてやってられない。
もし，プロ意識と責任感を持つデザイナーが，利益と効率のみ優先のプログラマとのコラボレーションを余儀なくされたら，「これ以上はゆずれない」という境界線を明確にして，けっして丸め込まれてはならない（もちろん，でもしかデザイナーとプロ意識の強いプログラマといった，逆のケースでも同様である）。お互いの感情に配慮ばかりしていたのでは，プロジェクト内部の「見せ掛けの和」を保つことはできるかもしれないが，品質がおざなりになり，成果は上がらなくなってしまう。
自己主張はしっかりと。
しかし押し付けにはならないように。
この辺のさじ加減が難しい。
視線を開発目的の達成にのみに向けて，歩み寄り，共に努力していこうではないか。
目的は納品とノウハウの蓄積ですからね。いがみ合いが目的ではないし。
以上、長かったので読み違いや勘違いもあるかも。
