PR

 今回から,これからコラボレーションを始めようとするデザイナーやエンジニアが直面するであろう諸々の問題を取り上げていく。まずは,コラボレーション開始当初に,乗り越えなければならないハードルについて取り上げよう。

 コラボレーションを開始した当初の段階では,プロジェクト内の問題ではなく,むしろ,窓口担当者と顧客あるいは顧客を取り囲む第三者―――技術進化の中で,技術習得や切磋琢磨をあきらめた人たち―――との問題が生じる。プロジェクト・リーダー自身はもちろん,多忙なリーダーのピンチヒッターとして折衝に出向いたメンバーに,分野,職種,居住地域,性別,年齢等による作業能力の評価,といったハードルが立ちふさがることがある。

問題1:職種や肩書きを気にする人たちがいる

 顧客の中には,職種や肩書きを必要以上に気にする人たちがいる。最初に取り込んだ職種データから,人となりや能力を決めつけるのである。職種の間に境界線を引き,「デザイナー」の名刺を差し出すと技術に無知だと決め付け,逆に「エンジニア」の名刺を差し出すとビジュアル・デザイン軽視の発言に及ぶ。筆者が,デザイナーとしてではなくXMLエンジニアとして顧客と接しているとき,世間話の中で,ビジュアル・デザイン軽視の発言に共感をもとめられて答えに窮することがある。

 こういったタイプの顧客と初めて会う場合は,「Webプロデューサ」「Webディレクター」「システムデザイナー」などの,具体的な作業をイメージさせない肩書きの名刺を渡してみるのも一つの方法だ。自信を喪失しかねない発言を聞くこともあるから,二人一組で動いたり,新人の場合は,開発に無関係な部署の人であっても,年配者に同伴してもらうとよいだろう。人格円満な雰囲気を持つ年配者なら,その場にいるだけで糊しろの役割を果たすことがあり,状況のリカバリーや精神面のフォローアップができるからだ。

 顧客がどのような発言をしようと,その価値観に縛られる必要はない。成果を出せるのであれば,デザイナーがプログラムを書いてもかまわないし,プログラマがデザインを担当してもかまわない。それ以前に,デザイナー主導型プロジェクトでは,デザイナーといえど任意のプログラミングに要する時間を予測できなければ,作業積算方式での見積もりなどできない。プログラマもCSSをわかっていなければ,表現と連動する処理の実装は難しい。

 「この職種だからこうあるべき」という外部からの制約に縛られず,クロスオーバーな姿勢で,軽やかに,ITの波を乗りこなしていこう。

問題2:地方在住というだけで色眼鏡で見られる

 本稿の読者には,東京在住者だけでなく,地方で頑張っているデザイナーやエンジニアもいるだろう。

 地方在住者は,ハンディキャップを背負っている。顧客やその周りにいる同じ地方在住者たちから,「地方にいて,都会から仕事を受注できるわけがない」「地方の人間が,東京で通用する仕事を出来るはずがない」といった後ろ向きな発言にさらされる,というハンデである。

 顧客の大半が東京にあり,頻繁な面談が必要なら,プロジェクト・リーダーは東京にいるほうが便利だ。ネットワーク管理者も,データセンターの近辺にいるほうがよい。だが,制作や開発の実務担当者が東京在住である必然性はない。

 地方のエンジニアは,「展示会やセミナーが開催されないのだから,新しい情報が入手できないだろう。地方では時代遅れの仕事しか出来ない」などと言われて,納得しないことだ。たしかに,展示会でベンダの社員や同業者と会って交流したり,その場の中に身を置くことには大きな意義がある。しかし,新しい情報は展示会やセミナーからしか得られないわけではない。 W3Cや,ベンダーの提供するベータ版を徹底的に活用すればよい。さらに,いくら展示会で情報を得ても,実践しなければ何の意味もない。

 デザイナーの場合は,エンジニアより深刻である。「東京のデザイナー」という言葉自体が,地方では一種のブランドだからだ。同じデザインでも,担当者の居住地域によって評価が大きく異なる風潮がある。しかし,これに屈しないことだ。筆者の経験では,プロジェクト内の担当作業は,予算とスケジュールの兼ね合いや使用技術,制作テーマの得手不得手で決まるのであって,居住地域で決まるわけではない。

 デザイナーであろうとエンジニアであろうと,情報の洪水にのまれないほうが自分を見失わずに済む。展示会や商談やネット上の情報は,すでに誰かが考えて発信したものである。新しい情報は,誰も発信していないのだから,自分で考えて生み出すしかない。考える作業は,居住地域に左右されない。

 その昔,スクラップブックにデザインやイラストをとじて,企画会社の門を叩く「売り込み」という手法があった。地方で実力が正当に評価されないと感じたら,ラフデザインを作ったり,プロトタイプを開発してから売り込めばいい。やる気さえあれば,海外に売り込むことだって可能なのではないだろうか。

 また,Webの世界では,データの質と量が重要だ。東京の情報は東京在住者しか持ち得ないように,地方の情報は地方の者しか持ち得ない。発信者を特定できず内容の真偽を確認できないネットだからこそ,情報の高いクオリティが求められる。作為的ではない,足でかせいだ「事実」を持っていることは,その地域に住む者,それぞれの強みなのである。

 居住地域によって,作業能力やその結果が決まる時代は,インターネットが地方に普及し始めた10年前に,とっくに終わっている。

問題3:性別や年齢で正当に評価されない場合がある

 顧客の中には「デザイナー=技術に疎い」だけでなく,「女性=技術に疎い」「若い,あるいは若く見え過ぎる=経験が浅く能力が低い」と思い込んでいる人もいる。Webアプリケーションのビジュアル・デザインと異なり,性別や年齢は,服装や物腰といった本人の努力だけではカバーできない。ステレオタイプの思い込みを持つ顧客相手では,たとえ実績があったとしても,実力が正当に評価されず,初回打ち合わせに支障をきたすことがある。

 顧客からの評価を獲得するうえで最も不利なのは,若い女性デザイナーだ。これが「技術者」の名刺を持つ,スーツでキメた年配の男性であれば,それだけで人間性も能力も評価される(場合が多い)。筆者が技術講演に出向いたときでさえ,「ご主人(フリープログラマの相方)にパソコンを習って,この仕事を始められたのですか?」と,全く根拠のない質問を受けたことが一度や二度ではない。

 IT業界には若い人が多いから,デザイナーに限らず,エンジニアでも顧客のほうが年上で,「若造」扱いされることもあるだろう。その場合は,性別や外見に対する相手の反応や態度を,営業方針の判断材料にするとよい。性別や外見で判断せず,「Webアプリケーションの成功」という目標だけに的を絞って打ち合わせのできる顧客なら,長く付き合うことができる。

 また,オンラインで仕事を進め,面識のない状態で相手に「デキル人」という印象を与えた後で,面識を持つという方法もある。

 なお,若いプロジェクト・リーダーが打ち合わせに臨む場合は,面談の回数が度を越さないように注意しなければならない。自分の意志を反映させたい顧客は,顔合わせを好み,議事録や仕様書の内容を軽視しがちだ。求めに応じて足しげく通ううち,いつのまにか無理な要求を押し通されてしまう恐れがあるからだ。

 デザイナーやエンジニアは,以上のようなハードルが立ちはだかっても,決して落ち込む必要はない。落ち込んで顧客の発言を鵜呑みにしたら,その時点で自分自身の成長を止めてしまう。インターネットの可能性に,自ら制限を設けてはならない。

 ハードルを置いていく人もいれば,自ら歩み寄ってきてくれる顧客もいる。筆者の経験からいえば,その比率は1対4だ。プロジェクトの成功に必要なのは,両者を見分けて,できるだけ後者と付き合うことである。また,前者と付き合わざるをえない場合は,ハードルを跳ぶ練習をするのではなく,跳ばずにさっさと横に退けてしまうことだ。開発者は常に,ゴールだけを見て走ればよいのである。

 無我夢中でゴールを目指して走り続けていると,ふと,肩の荷をおろしたような状況が訪れるものである。足を止めて,ふと周りを見渡してみると,メンバー全員がお互いを思いやって邁進できるようなプロジェクトに参加し,良い顧客,良い取引先に囲まれている自分に気づくのだ。

本稿で述べたことは,複数のコラボレーターたちとの筆者の実務経験や,第三者の立場で見聞きした内容,同業者たちから受けた相談に基づくものである。必ずしも,すべてのデザイナーやエンジニアに当てはまるわけではないことをお断りしておく。


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/