第39回　Web開発者との付き合い方　～Web屋の一分（いちぶん）

　前回は，コミュニケーション・コストについて触れましたが，今回はもう少しWebサイト・デザインに絞って話をしてみたいと思います。

意見集約という「小リーダー」の役目

　前回の復習になりますが，何か大きな事柄を決めようようとするとき，あまりに民主的に行うと，意見を集約するのに膨大な時間がかかります。私は，Web開発にとって「時間」が一番大切だと思っているので，結論を出すまでのプロセスを効率化することは至上命令です。

　様々な方法があるかもしれませんが，基本的には，機動性の良いグループ単位で意見を集約し，代表者会議の場で即決できることが鍵になるように思えます。小グループの小リーダーたちの機動力と，権限を持っているという体制，これに勝るものはないでしょう。

　そして，意見集約の効率化という側面だけでなく，クライアントの担当者が時間までに難しい結論を決めてきてくれたり，決をとる場で「責任は俺が取るから」とすべてを一身に背負ってくれるような発言をしてくれたとき，開発への意欲も鼓舞されます。難しい開発の苦労を，苦労と思わせない力や潤滑油みたいなものさえ生まれます。

Web開発者の役目

　前述のような結論に至るプロセスを「Webサイト開発」に当てはめる前に，一般的に「誤解」されていることを書いておきましょう。クライアントはときおり，Webサイト開発者を「HTMLが書ける集団」と考えることがあります。

　Webサイトの「仕様書」を渡しさえすれば，HTMLの塊である「Webサイト」が納品される，そんな自動販売機のような技術集団だと思われている方にもお会いしたことがあります。

　確かに，成果物として「HTML一式」を納品することは多いのですが，作業の中心は，少なくともここ数年で大きく変わってきています。HTMLを記述したり，サイトのグラフィックデザインをするプロセスよりも，「何を作ればよいのか」を絞り込むプロセスに大きく時間をかける場合が増えてきているのです。

　Web開発業界の中には，「Webデザイナー」ではなく，「HTMLコーダー」という職種が生まれています。コード（プログラムなど）を書く人，という意味ですが，大前提は何を書けばよいかという仕様書が渡されるということです。指示さえあればきちんと作れる，と言っても良いかもしれません。細かな技法の部分で，「デザイン」をしているとは言えますが，全体としては「設計（デザイン）」をしているとはみなされません。逆に「Webデザイナー」と呼ばれる職種については，「仕様書」を書く，何を作ればよいかを明確にする人，設計を行う人，という認識が広まってきています。

Web開発者の任務

　では，「Web開発者」の仕事は，どんなことなのでしょう。小グループに分かれて結論をすばやく導くためには，どんな役回りをそれぞれが担えばよいのでしょうか。

　私自身は，Web開発者の任務を，（大きく構えて言えば）クライアントの投資を，コミュニケーションの部分で最大化することだととらえています。したがって，そのサイトでそのクライアントが何をなすべきか決めるのを支援することが，Web開発者の最重要課題だと思っています。

　そう考えたうえで，Web開発者はどういった小グループの小リーダーであるべきかというと，「エンドユーザー」の代表として参加すべきだと思います。そして同時に，Web技術の専門家としての顔も持ちます。Web開発者を議論の場に入れることは，基本的には「対象ユーザー」を参加させている状況に近づけることを意味します。いえ，意味しなければなりません。

　何万人といるユーザーの中からアピールしたい「対象ユーザー」を絞り込み，その人たちにリーチ（届く）できる手段を洗練させていくプロセスが，Webサイトの仕様書を作成することです。Web開発者は，クライアントの事情を離れて何が面白いかを意見し，何がつまらないかも明確に伝えます。

　現実的には，ユーザーの代表として意見を言うだけでなく，技術的な観点から最適なソリューションを提案したり，クライアント内部では調整しきれない事柄の調停所のような役目も果たしたりするすことが多くなって来ています。この辺りの品質が，プロのWeb開発者と，そうでない者との差になりつつあります。

　HTMLコーディングなどの技術力は，ツールの進化によって低価格化の波に揉まれています。こうした淘汰の波の中で，Web開発者たちはどこまでクライアントの立場になれるのか，どこまでエンドユーザーの立場に立てるのかという観点でも差別化しようとしているのです。

　こうした気持ちで参加している「Web開発者」に対して，どのような扱い方が一番効率が良いのでしょうか。ここが，Web開発のコミュニケーション・コストの考え方の分かれ道です。時間は無制限にあるわけではありません，他の人ができることを，彼らにやらせるのは得策ではありません。彼らにしかできない部分で，専門力を発揮してもらうべきです。

Web開発者とのコミュニケーション

　もう少し具体的に見てみます。Web開発者は，クライアントとの間で，次のようなコミュニケーションを持つことになります。

クライアントから「やりたいこと」を聞く

クライアント側で想定している構想や夢などは，得てして技術的な根拠を伴わないことが多いように思います。けれど，ここへの思い入れの大きさが，そのプロジェクトの原動力になることも事実なので，一概にどんな形が理想形だとは言いがたいものがあります。ここでどれだけ正直ベースで想いを引き出せるかも，最終到達地点での大きな差になることが大きいように思います。

クライアントの「やりたいこと」を整理する

　目的と手段とがチグハグな場合もありえます。派手に動きのあるWebサイトを作りたいと言われても，その目的や得られる事柄を考えると，渋めのWebサイトのほうが効果がありそうだとか，クライアントには出鼻をくじかれるような結果になることもあります。この整理の仕方が，開発者の品質に直結するともいえます。

クライアントに「やるべきこと」「やってはいけないこと」を伝える

やるべきこと：

対象ユーザーに好まれること，時代的なトレンドに即していること，対象ユーザーに受け入れてもらえること，好ましい少し未来を感じさせること，などなど。

やってはいけないこと：

Webサイトの作り手側の満足感が前面に出てしまうもの，セキュリティも含めて時代的に許されないこと（時代と共にその拘束力は変わってきています），対象ユーザーなどには不向きな表現（説明文やコメントにしても適切な言い回しがあります），などなど。

クライアントと「やれること」を詰める

予算も含めたうえで，「やりたいこと」と「やるべきこと」の接点の中から，実際に実装する部分を導き出します。せっかく作ったサイトが無数の他のサイトの中に埋もれてしまうのは致命的なことで，ある程度目立つような予算配分も必要になります。とはいえ，継続しなければ意味がないので，無理なく運用できるという観点での「落としどころ」を探すという観点も必要です。

　最終的にはプログラミングするのに必要な「仕様書」を作成するために，上記のようなやり取りが行われながらWeb開発は進んでいきます。すべてのWeb開発者に共通しているとまでは言えないかもしれませんが，本人たちが意識しているかどうかも含めて，多かれ少なかれこうしたコミュニケーションは発生していると思います。

　こうしたプロセスをわかったうえでWeb開発者と何をどう話せばよいのか，どのような事前準備をすれば効率がよく，密度の濃いWebサイト開発ができるのか，今一度考えていただければ，もう一歩深みに入り込んだWebサイトの開発が可能になるように思います。そして，そうした深いコミュニケーションの下に制作されたサイトこそが，対象ユーザーとの豊かな「交流」を生み出す，Webサイトとなるように思えます。

（追伸）
今回のお話は，ずいぶん前に書いた「Web開発の今後（デジクリ版 / Ridual版）」への回答になっている部分があります。よろしければ，こちらもご参照ください。

三井 英樹（みつい ひでき） 1963年大阪生まれ。日本DEC，日本総合研究所，野村総合研究所，などを経て，現在ビジネス・アーキテクツ所属。Webサイト構築の現場に必要な技術的人的問題点の解決と，エンジニアとデザイナの共存補完関係がテーマ。開発者の品格がサイトに現れると信じ精進中。 WebサイトをXMLで視覚化する「Ridual」や，RIAコンソーシアム，日刊デジタルクリエイターズ等で活動中。Webサイトとして，深く大きくかかわったのは，Visaモール（Phase1）とJAL（Flash版：簡単窓口モード/クイックモード）など。