Visual Studioを使えば、ヴィジュアルコードとロジックのコードを分離することができます。 Webアプリケーション開発において、通常は、デザイナとプログラマの作業分担は、次のようになるでしょう。既にヒアリングは済み、基本設計、詳細設計、画面遷移図は出来ているものとします。
では、ボタンの表面のテキストを判別して行う条件分岐処理や、ユーザのアクションにより選択の可否を決める処理、ボタンやテキストの色や表示｜非表示といったヴィジュアルデザインを変更する処理は、どちらが担当すべきでしょうか。
また、スパイラル開発の場合、プロトタイプが完成した後で、顧客から処理の追加を依頼され、これをSEが二つ返事で請けてしまった場合、デザインの変更は、どちらが担当すべきでしょうか。
たとえば、Webアプリケーションの何らかのデータ入力画面で、ユーザが[OK]ボタンをクリックしたとき、クリックされたことを明示するために、ボタンの色を変える、という最も基本的な処理について、考えてみましょう。
プログラマが担当した場合は（デザインに配慮する人は別として）、悲惨なヴィジュアルになりかねません。
全体をモノトーンでまとめて、重要な箇所にだけコーポレートカラーのグリーンをポイントとして使っているとします。プログラマに任せると、こういう思考になるようです。「クリックされたことを明示する」＞「分かりやすい目立つ色にすればいい」＞「目立つ＝赤」＞「文字もハッキリした色がいいのでは」＞「文字＝青」＞「さらに分かりやすくするには文字サイズを大きくして太字にしよう」。
かくして、モノトーンとグリーンでまとまっているWebアプリケーションが、ユーザがボタンをクリックするという行為1つで、赤の背景色に青色の太字テキストといった、目がチカチカするような色彩になり、クリックした途端に、ボタンの文字が小見出しと同じ文字サイズに変化してしまうのです。同じ色を使っても、画面上で各色の占める割合やバランス、使い方を工夫することで、まとまることもありますが、それにはさらに高度なセンスが要求されます。
実はこれ、PROJECT KySSの相方のプログラマが、よく使う色です。「赤に青を使うなーっ！！」と、その都度意見するのですが、処理優先のプログラマは、色まで気配りする必要はないと思っています。仕方なく、わたしがコードを修正していると、「どうして？色なんて、どうでもいいじゃん、動くんだから。そんな作業するから、忙しくなるんじゃん」
「．．．．．．」（ストレスmaximum）。
では、デザイナが担当するとどうなるでしょう。仮にHTMLとJavaScriptを少しだけ書いた経験のあるデザイナがいるとします。そういう人は結構いると思います。そんなデザイナがコードを変更すると、それまで正常に動いていたプログラムが誤動作する状況になりかねません。
ユーザのクリックするボタンのIDが、button3だとします。これは、HTMLを書けるデザイナなら、デザインコードを見れば分かります。そこで、ロジックのコードのbutton3がクリックされたときの処理を探して、そこに色変更のコードを追加します。もちろん、デザイナが作業するのですから、目立ちながらも全体の雰囲気を損なわない色の組み合わせとなり、見た目はバッチリです。
そして、この状態で、[デバッグ／開始]をし、動作を確認すると、クリックされたら、色が変わりました。コードを少しだけ分かる、というところが問題で、「あ、できた、正常に動作している」と思ってしまいかねません。
しかし、プログラマなら、これではダメだということに、すぐ気付くはずです。
ユーザが[OK]ボタンをクリックして色が変わった。では、そこで[取消]ボタンをクリックしたときも、その色のままにしておくのか。[クリア]ボタンをクリックしたときは、どうするのか。入力ミスがあり、Validation Controlによる検証で不備が発見され、別のフォームページにジャンプしてエラーメッセージを表示した後にはどうするのか。button3が間接的に関わる各プロシジャの中に、処理を書くかどうかまで、デザイナは気付いていないかもしれません。
これは、非常に単純な、ボタンクリック時のスタイル変更という処理ですが、ボタンの表面のテキストを判別して行う条件分岐処理についても同様の状況が起こりかねません。
ボタンの使用の可と不可を切り替える処理ともなれば、うっかりコードを修正し忘れると、ボタンが使用不可になったままでユーザがクリックすることさえできなくなります。また、逆に、使用可となっていたために、クリックしてはいけないときにクリックされると、誤動作の原因になりかねません。入力したデータが、データベースに、重複して登録されるような事態になりかねません。
さらに深刻なのが、プロトタイプが完成した後で、顧客から処理の追加を依頼された場合です。
VSを使っている限り、IDが重複することはありません。しかし、コントロールを何度も削除したりレイアウトしていると、当然のことながら、IDやコントロールのコードの並びが、変わってくることがあります。追加したコントロールのIDを参照して処理を書く際に、IDの記憶違いや思い込みから、別のIDを持つコントロールの処理を書いたプロシジャ内を変更してしまうと、全く違った動作になります。また、誤動作を引き起こす危険性が非常に高まります。
デザイナに、プログラミングの複雑さを理解していない人がいるように、プログラマの中には、ヴィジュアルデザインの重要性を認識していない人もいます。しかし、ちょっと考えてみてください。
たとえば「電車男」が「エルメス」を好きになったのは、まず、「エルメス」の外見が、自分にとって好ましいものであったからではありませんか。ヘアスタイルや化粧や服装が、彼女の内面を反映したものになっていたからではありませんか。
もし、ヴィジュアルデザインがどうでもよいという人がいたら、お尋ねします。「あなたは、女性（あるいは男性）の内面を、見た目から推測したことは一度もないのですね？」
あなたは、青紫の部屋で青紫の食器にご飯を盛られたら、食欲が湧きますか？白い壁の部屋で、落ち着いた磁気に盛られたご飯の方が、おいしく感じませんか？
視覚情報というのは、感情を動かす重要な要素です。また、Webアプリケーションでは、操作性にも影響します。
では、どうすればいいのか、というと、餅は餅屋で、専門の領域を侵害することなく、逆に相手の専門を無視することなく、円滑なコミュニケーションをはかればよいのです。
まず、プログラマは、ヴィジュアルデザインが必要になった部分の処理をデザイナに分かりやすく図解したり、開発途中の画面を見せるなどして説明し、色を聞きます。そのとき、きちんと16進数で指定してもらいます。「明るい青」とか「淡い感じにして」といった、曖昧な指示では、イメージ通りの色にできる保証がないことを伝えましょう。
そして、その際に、フォント、文字サイズ、paddingなど、必要になりそうなプロパティ値があれば、事前に全て聞いて詰めておきます。
そこで、プログラマがコードを追加あるいは変更します。
ここで一度デザイナに確認してもらい、イメージ通りであるという返事をもらったら、あとは、関連するプロシジャを全て修正しますが、その前に、ヴィジュアルデザインに関わる処理が出てきそうな場合は、あらかじめ、デザイナに、プロパティ値を確認しておきます。
このように、プログラマが「慎重に色を扱い、デザイナの立場を軽視しない」ことが大事です。
また、デザイナ側も「ヴィジュアルデザインなんて簡単に修正できるはず」などと考えないことです。プログラマが書いたコードを動かしてみては、「ここの色をもう少し抑えてほしい。文字も10.5ではなく10にしてほしい」などと、指示の変更を繰り返さないことです。1箇所の色を変えただけで、関連するプロシジャすべてを見直さなければならないことを理解する必要があります。単純な一箇所の色変更が、全体の動作確認のやり直しにつながる事態だって、ありえるのです。
円滑なコミュニケーションをはかるためには、プログラマとデザイナがお互いの作業の重要性と専門性を尊重すること、１つのプロジェクトに参加する仲間への配慮が必要です。
GUIを考えたアプリケーションでは、一見ヴィジュアルの変更に見える処理でも、ヴィジュアルコードの中ではなく、ロジックのコードに記述するということを忘れてはいけないでしょう。ヴィジュアルコードとロジックのコードは、密接に関連付いています。
アプリケーションは何より、安定性を重視しなければならないはずです。かといって、見た目がどうでもいいというわけではありません。
だからこそ、プログラマは見た目を軽視することなくデザイナの意見に耳を傾け、デザイナも、コードを読み理解できるスキルを身に付ける必要があると思うのです。（2005年7月23日）
