「無知の知」では済まされないこと
顧客あるいはプロジェクト・リーダーからの相談内容が，筆者の相方（プログラマ）の耳に届くことがある。筆者は，技術無視の相談にも気長に耳を傾けられるが，相方は，そのような質問が生じること自体が，不思議でならないといった様子だ。
たしかに，拡張子の存在を知らなかったリ，存在を知っていてもWindowsマシンでの表示方法を知らなかったり，さらにJavaとJavaScriptを混同していたり…というのは困る。また，顧客の希望がローカル・アプリケーションなのかWebアプリケーションなのかを確認しないまま相談を持ちかけられても答えようがない。
筆者は，.NETをプラットフォームとする開発が多いが，その場合ならせめて下記の表のアプリケーションの種類については，確認しておいたほうがよい。
【表1】アプリケーションの種類（.NETをプラットフォームとする場合）
|
だが，デザイナーが知らなくてもやむをえない情報は，山ほどある。
筆者の経験からいえば，まず，デザイナーは往々にして，顧客側の前提条件を把握できていない。
(1) 独自開発案件か，一般に提供されているプログラムを利用したいだけなのか。 (2) 新規案件か，現在稼動中のアプリケーションの見直しか。 (3) すでに安価なレンタル・サーバーを借りていたり，レンタル・スペースを確保していないか。すでに専用サーバーを立てていないか。顧客の懇意なホスティング会社を利用する必要があるのか，あるいは特にこだわりはないのか。
(1)は，顧客が単にブログの使い方を知りたいだけであるのを，デザイナーが開発を依頼されたと勘違いして，相談してくるケースである。開発相談は徒労に終わる。 (2)では，リデザインの依頼であれば，既存アプリケーションのプラットフォームを確認する必要がある。 (3)も明確にしておかなければ，提案書すら作成できない。レンタル・スペースでは，サーバーへのデータ保存処理は許可されていない場合が多い。顧客が専用サーバーを持っている場合は，Windows系かUnix系かで開発方法が異なる。顧客の懇意なホスティング会社にハードウエアを依頼するなら，詳しい情報が必要であるし，デザイン会社がサーバー構築も含めて一任されたのであれば，予算の大枠を確認しなければならない。データセンターに置いたサーバーで運用すべきアプリケーションを，24時間サポートすら不明な安定を保証されないサーバーで運用できると，顧客に話してしまっていたら大変だ。
デザイナーの誤解，ベストスリー
次に，よく耳にするデザイナーの誤解を3点挙げておこう。
(1) プログラムは，どのプログラマが書いても同じコードになる
プログラムには，デザインと違い，コードの書き方という「決まり」＊1がある。技術に疎いデザイナーは，ベンダーが提供する資料や開発ツールのヘルプに載っている，それらの決まりを覚えさえすれば，どんな処理でもすぐに書けると思っている。
たしかに決まりを知らなければ，プログラムは書けない。だが，決まりを覚えさえいれば，コードを書けるわけではない。漢字や熟語を憶えたからといって，文章を書けないのと同じように。
使う決まりを選択し，いかに組み合わせ，どのような条件で処理を分岐させ，どの時点で何回処理を繰り返し，ユーザーが選択した値を次のWebページ（Webフォーム）にどのような方法で渡すか，などなど，プログラマが経験値として蓄えておかなければならないことは山ほどある。「プログラマ」とは，決まりを間違えずに記憶している，記憶力の達人を指す言葉ではないのだ。
また，いくらツールが進化しているからといって，ツールを操作できさえすれば，どのような処理でも確実に実装できるというわけではない。Illustratorの操作方法を知っていても，イラストを描けないのと同じである。
プログラマは，いくつものサンプル・コードを自分で考えて書いて試し，そのノウハウを蓄積している。試さなければならない処理があまりに多いので，納期に追われるプログラマたちは，お互いにWeb上でサンプル・コードを公開し合ったり，メーリング・リストで情報交換して助け合う。サンプル・プログラムの載った本や記事を利用することもある。それでも，新たな案件に取り組むとなると，1から考え出さなければならない処理があるものだ。
同じ条件で同じ素材を使ってデザインしても，デザイナーによって色使いやレイアウトが違うように，プログラムだって誰が書いても同じになるというわけではない。百人百様のコーディング方法がある。コードの書き方ひとつで，処理の効率が異なったりする。例えば，データベースに接続してデータを走査し，特定のデータを返す検索処理ひとつをとっても，決まりの組み合わせ方や書き方によって結果が返ってくるまでの待ち時間が異なる場合がある。
さらに，たとえ開発テーマが同じであっても，異なるプログラマと組めば，デザイナーが担当する部分にも影響の及ぶことがある。例えば，ASP.NETのコードを例にとると，単純なリンク・スイッチ一つをとっても，HTMLタグを使って書く場合もあれば，LinkButtonコントロール，ImageButtonコントロール，HyperLinkコントロールを使う人もいる。コントロール＊2によって見た目も異なるので，デザイナー側がコントロールを決めるか，具体的なビジュアル・デザインの指示をしておかなければ，デザイナーのイメージ通りにはならない。逆に，デザイナーが見た目を重視してコントロールをレイアウトしても，プログラマがコードを書くうえでそのコントロールが使いにくい場合は，差し替えることも考えられる。差し替えにより，見栄えが大幅に違ってしまったら，プログラマが単に面倒くさがっているのか，本当に実装が難しいのか見極めなければならない。この問題については，また後の回で解説する。
(2) データベースは，アプリケーションを開発した後でも，いつでも簡単に変更できる
技術に疎いデザイナーにとって，「データベース」という言葉の解釈は難しい。デザイナーは，データベースとは，沢山のデータが蓄積したもの，という漠然としたイメージしか持っていない。データそのものと，データを入れる器，その器の定義，データベース製品（例えばSQL Server 2005）の区別が付いていないのである。だから，開発後にデータを更新できるのであれば，データ型＊3やフィールド数，フィールド名＊4も，簡単に変更できると思ってしまう。データベースの構造の変更は，プログラムに影響を及ぼすにもかかわらず，である。
例えば顧客情報の住所を，郵便番号上3桁／下4桁／県名／市区町村／住所2／マンション名，というフィールドに分けて登録する処理を書いた後で，郵便番号／住所（県名＋市区町村＋住所2＋マンション名）という分け方に変更すると，コードの変更が生じる。入力ボックスのデザインを変更しないのであれば，郵便番号上3桁と下4桁，県名＋市区町村＋住所2＋マンション名を，一つの文字列に連結して登録するようコードを書き換えなければならない。また，郵便番号から自動的に県名を表示するということにでもなれば，プラスアルファの処理が必要だ。さらに，登録処理だけにとどまらない。ユーザーが入力ミスをした場合，データベースから登録済みのデータを抽出して画面に表示させ，修正する処理にまで影響が及ぶ。
検索処理でも同様だ。先の住所をまとめた例では，連結されて登録済みの住所の中から，住所2とマンション名を区別して抽出することは不可能に近い。
【図1】データベースの変更がプログラムに影響を及ぼす例
|
逆に，データベースに検索対象とするフィールドを追加した場合は，追加したフィールドを検索対象に含めるようコードを変更しなければならない。データベースのフィールド名（XML利用の場合は要素名あるいは属性名）＊5の変更が，コードに影響を及ぼすこともある。データベースの構造変更により，検索処理速度に影響が出る恐れもある。データベースの変更は，HTML内のテキストを書き換える程度の作業では済まないのだ。
(3) エンドユーザーの環境（OSやブラウザ）が違っても，プログラムは同じである
エンドユーザーの使うOSやブラウザに合わせて，CSSを書き換えなければならないことを理解しているデザイナーは多い。しかし，プログラムであれば，自動的にブラウザに合わせた表示になるはず，と過信している人も多い。
サーバーサイド処理のプログラムを開発したからといって，エンドユーザーの閲覧環境の違いを，完璧に吸収できるわけではない。パソコンの場合は，まだいい。違ったとしても，せいぜいボタンと文字のパディングであるとか，フォント，マージンや行間程度である。サーバーサイドでHTMLが吐き出された後にインライン・スタイルシートを適用するといった方法で，ある程度は解決できる。処理自体に深刻な影響を及ぼすケースは少ない。
しかし，携帯端末となると，メーカー，機種，発売時期，採用している言語，文字コード＊6や字数制限など，実際にテストしてみなければわからない問題が多々ある。プログラムで使うメソッドによって，動作する場合としない場合があったりする。
当然のことながら画面が小さいので，パソコン用に開発したプログラムをそのまま使えるわけではない。PDAともなれば，パソコン用のアプリケーション開発で使える「決まり」と，PDA用の開発に使える「決まり」が違う。ハードウエアの能力に差があるので，すべての「決まり」を使えるわけではないのも当然だ。
恥ずかしがらないで，わからないことは質問しよう
以上のような問題を，プログラマは「いくらデザイナーでも，このくらいはわかっているはず」と過信してはいけない。逆に，「デザイナーは，どうせ何もわかっていない」と見下してもいけない。プログラマは，コラボレーションに後ろ向きになるのではなく，何でも思いつくところを投げかけて，確認してもらいたい。
プログラマだって，新商品発売にあたって，印刷物と連動した静的なWebサイトのビジュアル・デザインを打診されたら，気づかないことが多々あるはずだ。例えば，リーフレット，パッケージ，ノベルティからWebに至るまでの，ロゴやイメージの統一。商品写真1枚のために，セットを組んでのスチール撮影が必要になることもある。イメージフォトの手配，フォントの問題。販売促進のため，広告やCM，展示会と連動させるなら，媒体や時間帯選択のための広告代理店との折衝。ロゴデザインひとつとっても，コンセプトワークやC.I.マニュアルの作成，商標の事前調査や登録まで詰めなければならない。これらのことに思い至る技術者は多くはないのではないか。紙見本やカラーチャートなど見せようものなら，その選択肢の多さに言葉を失う技術者ばかりだろう。それと同じで，デザイナーが前述の事項に思い至らないのは当然のことなのだ。
異なる分野の専門家を低く見たり，軽く扱う人は，おそらく本人が得意とする分野にも自信のない人だ。専門外の知識を持たないことは恥でも何でもない。それまでの人生で，専門を極めることに忙しかったのだ。特に，コンテンツ・デザイナーには気配りのできる控えめな人が多く，質問のレベルを気にするのだが，遠慮は無用である。また，自分の専門分野のことについてであっても，知らないことがあったなら，素直に耳を傾けて吸収しようとするのが，プロジェクトの一員として，あるべき姿ではないだろうか。
デザイナー側にも自己研さんは必要だが，デザイナーばかりが一方的に歩み寄っていては，協業体制を築くまでに時間がかかり過ぎる。第一回目にも書いたように，デザイナーは技術を身に付けて80歩進み，プログラマは20歩進んで，お互いに握手できる体制が望ましい。
プロジェクト内のコミュニケーション不全のために，誤解を重ねたまま実作業を開始して，顧客に迷惑をかけることだけは避けなければならない。
| 【デザイナーのための技術用語解説】 |
| ＊1 決まり プログラミングの決まりには，あらかじめ用意されている処理（メソッド，プロパティ，関数など）と，ユーザーが入力したり選択した値や，処理した値を入れるための器（変数）の宣言方法，処理の使い方の規定（文法）がある，とイメージしてみよう。 ＊2 コントロール ASP.NET Webアプリケーションの実開発作業では，まず，Visual Studio 2005のデザイン画面上で，.NET Frameworkで用意されている，入力ボックスや表形式表示，画像表示などのサーバーコントロールをレイアウトするとことから始める。 ＊3 データ型 データ型とは，整数，文字，通貨，日時など，データの種類を表す属性のこと。例えば整数は「Integer」，文字は「String」で規定される。 ＊4 フィールド名 フィールドは項目，レコードは1件のデータを表す。フィールド名とは項目名のこと。 ＊5 XMLの要素名と属性名 タグの名前を要素名という。要素の付随情報を属性という。例えばHTMLでも というコードでは、divが要素名、styleが属性名、color:redが属性値にあたる。 ＊6 文字コード 文字や記号をコンピュータで処理できるように，割り当てられた固有の数字。日本語の文字コードは，JISコード，EUC，シフトJIS。XMLではUnicode（utf-8，utf-16）が主流。携帯端末では，契約条件によって，データを送信する際の文字コードが異なる場合がある。 |
|
PROJECT KySS（プロジェクト・キッス） 薬師寺 国安（やくしじ くにやす，フリープログラマ）と，薬師寺 聖（やくしじ せい，個人事業所SeiSeinDesign自営，http://www.SeinDesign.net/）によるコラボレーション・ユニット。1996年，聖が勤務先で地域ポータルを企画制作，これを訪問した国安と知り合う。ActiveXユーザー同士で意気投合し，翌年「PROJECT KySS」結成。1999年よりXMLとDHTML利用のコンテンツ開発，2000年にはCMSツール開発と，一歩進んだ提案を行い続けている。XMLに関する記事や著書多数。両名ともMicrosoft MVP for Windows Server System - XML(Oct 2004-Sep 2005)。http://www.PROJECTKySS.NET/ |
