プロローグ～連載を始める前に～

　筆者（薬師寺 聖）は，四国在住の，一介のデザイナーである。デザインを生業として23年，印刷媒体からWebに転じて10年。プログラマの薬師寺 国安（本稿では「相方」と呼ぶ）と，コラボレーション・ユニット「PROJECT KySS」を結成し，コンテンツやツールを試作してきた。数年前に相方がフリーになってからは，開発案件を分担受注している。

　周りからは，息の合ったコンビだと思われているが，感性は180度違う。デザイナーとプログラマはケンカするもの，と相場が決まっている。

　「画面遷移図にないボタンが付いている！どうして勝手に付けるんだよ！？」「ボタンクリックという手順をワンクッション挟んだほうが，処理が簡単だ。」「コードを端折る目的で，デザインを無視するなよ！ユーザーに不親切だろ」「ボタン一つ追加したぐらいで，そう怒るなって。動けばいいだろ，動けば！」とまあ，しょっちゅう口論をしている。1pxの微調整を「気にし過ぎ！」と言われた日には，「実録鬼プログラマ日記」を書いてやる！と息巻いてしまうが，その1pxのズレに気づかない感性の持ち主に，何を言っても始まらない。

　そんなこんなでも続いているのは，「プロジェクトを成功させなければ」という気構えがあるからだ。デザイナーとプログラマに，相互理解は必要だが，譲り合いは不要である。優先すべきは，1に「達成目標」，2に「顧客の満足度」。デザイン重視のWebが機能優先になったり，その逆にならないよう，大いに意見交換したほうがいい。

　コラボレーションによる開発は，音楽のジャムセッションに似ている。異なる楽器のプレーヤーがお互いに譲り合わず，前へ前へ出ようとしてインプロビゼーション（即興演奏）のバトルを繰り広げているのに，なぜかリスナーの耳には統一感のあるメロディーが届く——そういう形が望ましい。デザイナーとプログラマは違うパートを担当しているのだから，同じリズムで同じ音を出す必要はない。そう考えれば，お互いにラクに付き合えるのではないだろうか。

　デザイナーの皆さん，スカイブルーとターコイズブルーの区別もつかないコード書きに遠慮することはない。デザイナーが一歩前に出て，プロジェクトを牽引する時代が，もうそこに，やってきている。

もはやWebアプリケーションを包含する“Webサイト”

　そもそもWebアプリケーションも一つの“商品”であり，機能の実装と動作保証だけでは顧客も満足しなくなっている。ビジュアル・デザインやセールス・プロモーションといった付加価値こそ重視され始めているのだ。さらに，データ入力や更新のしやすいユーザー・インタフェースも求められている。実際，筆者のもとに舞い込む相談メールの相手は，開発者からデザイナーに変わりつつある。顧客が，従来ならシステム・ハウスに依頼したであろう案件を，デザイン会社に打診しているのだ。

　一方，デザイン会社のほうも，Webの仕事に積極的である。紙媒体だけでは受注が難しいから，Webをセットにした営業展開をはかる。しかしブログ全盛の今，静的なホームページ制作は印刷物受注のためのサービスにしかならず，利益にはつながりにくい。クールなFlashコンテンツをウリにしても，顧客とのイメージの刷りあわせに時間がかかり，粗利確保に営業手腕が問われてしまうこともある。

　Webサイトの仕事で利益を生むには，顧客の求めそうな処理を先回りして提案するしかない。その結果，一般的な掲示板やサイト内検索ではなく，顧客固有の機能を実装するWebアプリケーション開発に触手を伸ばすことになる。

　デザイン会社にとって，Webアプリケーション開発は新規事業のようなものだ。予備知識を得るため，技術書を片端から手に取り，つっかえながらも読み進め，ステップアップをはかろうとする意欲的なデザイナーがいる。逆に，外注に丸投げすればいいという考えのデザイナーもいる。登録や検索機能付きのクールなホームページ制作を請けただけ，という認識であり，プログラム開発に取り組むという意識は薄い。

　いずれのケースでも，受注が確定すると，成り行きからデザイナーがプロジェクト・リーダーを務めることになる。それが，バックエンドで膨大なデータベースを処理するような案件であってもだ。「Webサイト」は，「Webアプリケーション」を包含しつつある＊1。

デザイナー主導型のプロジェクトを考えてみよう

　一般的に，ビジュアル・デザイン重視のWebサイトでは，Webアート・ディレクタが陣頭指揮をとる。かたやデータ処理が必要なWebアプリケーション開発のプロジェクトでは，IT技術者がプロジェクト・リーダーを務める。その場合，Webデザイナーは配下で動くようになる。

　しかしながら，デザイン会社でも，開発案件を請けて出来ないことはない。筆者が協力してきた仕事の中で，非常に作業が円滑に進んでいるケースがある。そのプロジェクトの形態は下記の通り。ちなみに，筆者と相方のいる「開発」は四国在住。それ以外のメンバーは東京在住である。

　驚くなかれ，ネットワーク管理者とプログラマ以外は，デザイナーである。プロジェクトを統括しているのは「技術者」ではない。そのような集団が，普通ならIT技術者が中心となるような中小規模のWebアプリケーションを手がけてきている。

　それぞれの役割をざっと説明すると次のようになる。

●プロジェクト・リーダーは，営業，ヒアリング，要件定義＊2，プロジェクト管理を行う。

●コンテンツ・デザイナーは，HTMLページやコンテンツのデザインおよび制作管理を行う。

●サーバー管理は，経験豊富なネットワーク技術者が担当し，ハードウエアの選定，設置，各種設定，メンテナンスを行う（ちなみに筆者は，このネットワーク技術者とは8年来の知り合いだが，名前以外何も知らない）。

●デザイナー（筆者）は，企画/設計を担当している。ビジュアル・デザインを手がけ，プログラミング，テストに協力することもある。

●プログラマ（筆者の相方）は，プログラミング，配置＊3，テストを行う。

　このプロジェクトの場合，開発方法としてはスパイラル型＊4が多い。基本設計＊5だけで実作業に着手しなければ間に合わない納期であれば，詳細設計＊6をプログラマがコーディングしながら詰めていくこともある。プロジェクト・リーダーが意図してこのようなチームを編成したわけではない。偶然の産物でできあがった組織である。

案件の数だけ，プロジェクト構成がある

　付加価値要求が強まるにつれ，デザイナーとプログラマのコラボレーション熱も高まっていく。プロジェクトの形態は，より柔軟になり多様化していくだろう。さらに，開発環境の進化がそれを後押しする。すでに，マイクロソフトのVisual Studio 2005のような，ウィザードに従うだけでデータベース接続機能を実装できる開発ツールも登場している。ピラミッド型にこだわる必要はない。参加するメンバーの価値観や能力や経験が，うまくかみ合うような構成ができれば，プロジェクトは成功するだろう。

　例えば，下記の図の右側のように，技術に抵抗感のないデザイナーが核となって（これを表す用語がないので，本稿では仮にコア・デザイナーと呼ぶ），情報を取捨選択／整理し，プロジェクト・リーダーが方向性を決定するという方法である。

　図中の矢印は，連絡網を表す。トップダウンではなく，ボトムアップでもなく，参加メンバー全員が情報を共有する。非常に風通しのよい形態であるといえるだろう。コア・デザイナーは，技術陣からのフィードバックをかみくだいてデザイナーに伝える。そのやりとりの中で，デザイナーたちは自己研さんもしながら技術的知識を吸収していく。この作業の反復により，デザイナーとプログラマの距離は徐々に近付き，プロジェクトは強固になり，デザインと技術の両輪がうまく回り始める。

　筆者から見れば，プログラマがデザインセンスやセールス・プロモーションのノウハウを身に付けるよりも，デザイナーが技術を習得したほうが現実味がある。デザイナーとプログラマがお互いに50歩ずつ進むのではなく，デザイナーは技術を身に付けて80歩進み，プログラマには20歩進んでもらって握手するほうが合理的だ。

　デザインと技術を接続するコア・デザイナーの役割は，重責である。顧客の希望をできるだけ叶えられるよう，コード変更に難色を示すプログラマに必要性を説いたり，逆に，顧客からの要求が技術的に困難であったり危険であればプロジェクト・リーダーに進言しなければならない。それでも，コンテンツ・デザイナーやネットワーク管理者にメールしながら，プロジェクト・リーダーに電話で指示を仰ぎ，メッセンジャーでプログラマからの相談を受けるという仕事は，多くのメンバーに支えられているという実感を湧き立たせ，人に対する信頼と感謝の念を呼び起こしてくれる。

　ただし，注意点が一つ。このデザイナー主導型プロジェクトで対応できるのは，コンテンツ制作を除く開発工期が3～6人月＊7での，中小規模の案件までである。複数のWebサーバーを連携して大量のデータを処理する大規模な案件や，厳密なセキュリティを要する顧客情報・金融情報･機密性の高い技術情報を扱うシステムやWebサービスの開発には，ネットワークとデータベースとプログラミングのすべてに通じたシステム・エンジニアや，複数のプログラマが必要だ。そのようなケースでは，コア・デザイナーは技術に明るいデザイナーとして，デザイナーとシステム・エンジニアを接続するコーディネータを果たすようになるかもしれない。

【デザイナーのための技術用語解説】
＊1　WebアプリケーションとWebサイト
　例えばVisual Studio 2005でのテンプレート選択においても，「ASP.NET Webアプリケーション」ではなく「ASP.NET Webサイト」という表記になっている。単なる呼称の問題ではあるが，時代の流れをよく反映している。

＊2　要件定義
顧客の希望をヒアリングしてリストアップし，効果を分析して，実装する機能を固めること。デザイナー主導型プロジェクトでは，エンドユーザーの層や設定アクセス数などは，企画の範疇に入る。ここでいう「効果」とは，いわゆる広告宣伝効果と同じ意味を持つ。

＊3　配置
開発したWebアプリケーションをWebサーバー上で動作可能にすること。アプリケーションのアップロードだと思えばよい。.NET Webアプリケーションではアクセス権の設定，SQL Serverを使う場合はその設定等も必要。スパイラル型開発では，本番とは異なるプロジェクト名で開発したプロトタイプを配置して顧客に試していただき，実運用は別のプロジェクト名で開発を進めることが多い。デプロイメントともいう。

＊4　スパイラル型開発
デザイナー主導型プロジェクトでは，実運用後の不備を避ける意味でも，スパイラル型が向いている。HTML＋Photoshopによるモックアップをベースにプロトタイプを作り，精度や使い勝手を十二分に検討してから，実運用するアプリケーションの開発に着手するという，2段階（2巡）の工程を踏む。筆者と相方のユニットは，発注を得るためのプレゼンテーション用サンプルや仕様固めのための試作が専門なので，プロトタイプまでを担当して引き渡すこともある。スパイラル型とは別に，完全な設計を起こしてから実装に移る「ウォータフォール」という方法もある。スパイラル型は，あくまで完成度を高めていくための手法であって，仕様を変更するのに便利だという理由で用いるべきではない。

＊5　基本設計
デザイナー主導型プロジェクトが受注する，ビジュアル・デザイン重視の中小規模のWebアプリケーションでの基本設計書とは，システム・ハウスが受注する大規模案件や，顧客側に技術者がいるケースとは異なり，企画書と詳細な画面遷移図のセットを指す。ユーザーのアクションに伴うWebフォームの遷移と，データベースからの読み込み／書き込みなどのデータ処理の流れ，フォルダ構成やファイル名，SSLやロボット避けの範囲，データ作成方法と更新方法などを記載したものになる。画面遷移図には，ユーザーが誤操作した場合のエラー・メッセージ表示，変換表示用のXSLTスタイルシート，内部的に一時的にDOMツリーを生成する場合はその構造，XML←→RDB間でシリアライズを必要とする場合は，その詳細まで記載する。

＊6　詳細設計
デザイナー主導型プロジェクトでは，基本設計書に記載している，各Webフォームごとの設計書を指す。筆者の場合（.NET＋XML），使用するコントロール，XMLの場合は構造の定義（スキーマ），SQL Server利用の場合はデータベースの定義，クラス化やスニペット化する処理，変数とデータ型とパラメータ名，各フォーム間の値やインデックスの受け渡し方法，ポストバックの有無，インスタンスの破棄とメモリー開放のタイミング（特にPDAの場合）などの詳細を記載する。使用するコントロールとは，データを一時的に格納するための非表示コントロールも含む。XMLを設定ファイルとして使用する場合は，設定項目も定義する。

＊7　人月（にんげつ）
人月とは，開発現場での一人のスタッフの1カ月の労働時間や，労働単価を表す単位。システム・ハウスでは，人月単位で見積もりを提出することが多い。例えば「システムエンジニア2人月＋プログラマ3人月の工期につき概算見積はいくら」という表現をする。

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/