デザイナー主導型プロジェクトでは，デザイナー出身のプロジェクト・リーダーの営業センスが問われる。デザイナーであれ，プログラマであれ，誰しも信頼できるリーダーの元で働きたいと願うだろう。いわゆる「Everything OK」型のリーダーと，優柔不断型のリーダーの元で働きたいと思う人は，いないはずだ。

こんなリーダーは願い下げ

　「Everything OK」タイプのリーダーには，営業センスというものがない。営業センスのなさを自覚していながら成り行き上リーダーにならざるをえなかった人と，単に人の上に立って目立つのが好きな人がいる。前者は気の毒だが，後者は自分では営業センスがあると思っているから厄介だ。

　顧客からの要望に対し，実現可能性も難易度も工期も分からないまま，お客様の言うことだからと，何でもホイホイと引き受けてしまうのである。初顔合わせの時点から，実装可能性を考えず，顧客の求めそうな処理を先回りして成り行きの提案をする。ラフデザインを見た顧客が次々と要求する機能に対し，予算も工期も忘れて顧客と同じスタンスで「ぜひやりましょう！」と盛り上がる。

　実現可能性が低い機能についても，「できます」と即答する。検証の必要な機能も二つ返事で引き受け，プログラマが後に退けなくなる状況を作ってしまう。顧客への印象は良いが，プロジェクトの中は大騒動になる。

　優柔不断なリーダーは，何事においても，自分で即決しない。

　顧客からの要望に対し，HTMLでは実現できない（あるいはDreamweaverで実現できそうにない）と思えば，決して「YES」と言わない。顧客の要求すべてに対して即答を避け，「技術の者に尋ねてみますので」と言葉を濁す。「で，結局，できるのかね？ できないのかね？」と顧客は苛立つ。

　技術の知識が不十分と思われ「デザイナーに話してもらちが明かない，次回から技術者を同伴してくれ」と言われかねない。しかし，プログラマやコア・デザイナーを同伴することはできない。実現可能性について，顧客の目前で相談する状況になるからだ。このようなリーダーの迷惑は，プロジェクトの外部にも及ぶ。「だからデザイナーはダメなんだ」という意識を顧客に植え付けかねない。

　1から10までリーダーがメンバーにお伺いを立てると，プロジェクト内の力関係も崩れてしまう。リーダーの自信のなさがプログラマに伝わると，どうなるか。最終工程を担うはずのプログラマが力を持ち，デザインを軽視し始める。デザイナー主導型プロジェクトの意味が薄れていく。

　デザイナーのリーダーは，プログラマの天下にさせることだけは，阻まなければならない。

YESとNOの駆け引きを制す，優秀なリーダー

　それにひきかえ，成功するプロジェクトのリーダーは，顧客の希望に対する実現可能性について，YESとNOを使い分ける駆け引きに長けている。

　初顔合わせでは，冷静に顧客の要求を引き出すことに務め，その場で軽はずみな提案を行わない。提案ひとつにも技術的な裏付けが必要だと知っているので，ヒアリング内容を自分の中で消化するまで，企画を焦らない。

　ヒアリングして要求仕様をまとめたら，企画書と画面遷移図の作成，色彩プランの策定，ラフデザインと進め，その後の機能を確定する段階でも，安請け合いをしない。顧客は，ラフデザインを示されるとイメージが明確になり，実装してほしい機能を次々と語り始める。しかし優秀なリーダーは，予算や工期の面から実現可能性が無きに等しい場合は，「NO」をはっきりと口にする。その際，顧客の気分を害さないように気配りし，技術面の裏付けについて基本的な説明も行う。

　実現可能性が低い機能については，必ず実装する機能と，できるだけ実装に尽力するオプションの機能に明確な線引きをし，現在は難しくても将来的な実装可能性は匂わせて顧客の希望をつなぐ。過去に開発経験がなく検証の必要な機能については，検証結果の返事の期限をその場で決めて伝える。返答期限を決めておけば，顧客も安心できる。実現可能性が高い機能については，多少の困難は予測されても，メンバーを鼓舞して押し通す。

　リーダーと顧客間の問題は，医師対患者の関係に置き換えてみれば，よくわかる。医師に質問をぶつけたとき，すべてに対して「検査してみなければ何もわかりません」と言われたら，患者は検査結果を聞くまで不安でたまらない。逆に，患者が検査をしてもらいたいと思っていても，簡単な問診だけで即，病名を自信ありげに告げる医者は信頼していいのかどうか微妙な気持ちになってしまう。

　優秀なリーダーは，患者に信頼される医師に似ている。即答と検討と断りを適切に使い分ける。実装の可否が不透明な場合はコア・デザイナーを質問責めにして，顧客への有効な断り方や説得方法も考える。「YES」と「NO」のアブナイ顧客との駆け引きを，余裕を持って制することのできるリーダーの存在が，プロジェクトの成否を大きく左右する。

適材適所のメンバー配置

　リーダーの重要な仕事のひとつに，メンバーの配置がある。デザイナー主導型のメンバーのポジションは下記の通りだ。

【表1】デザイナー主導型のメンバーのポジション

　リーダーはサッカーのチームの監督に似ている。プロジェクトの成功のためのフォーメーションを考えなければならない。点取り屋をディフェンダーにしたり，独創的なリベロに対して，好機でも自分の判断では前に出るなという指示をしたら，チームとしてはうまく機能しない。例えば筆者の相方は，性格的にもフォワードのタイプである。目立つ位置に置けば，どんどん前に出てシュートを放つが，ディフェンスに配置しようものなら，試合開始後5分でレッドカード退場である。

　リーダーには，メンバーの適性を見極め，もっともうまく機能するポジションを与える眼力が求められる。

　まず，リーダー自身には，芸術系ベースの文系人間が適している。芸術系だからといっても暗い顔をして一作品に注力するタイプではなく，お洒落で流行に敏感で，衣食住すべてにセンスがよく，生きることを楽しめる人が向いている。フットワークも軽くなければならない。

　筆者の経験に照らし合わせてみると，優秀なリーダーには，現場を重視する姿勢がある。実践主義で，手も足も口も動かす，バランス感覚のある人が多い。技術書やWebからの情報を得々と語る「耳学問」ではなく，実際に開発ツールを触ったり，コードを書いてみたりする。プログラムが手に負えなければ，HTMLやCSSからでも始めようとする。コードを書いて表示してみるうちに，理論と実践との間の隔たりを実感するようになるからか，機能の実現可能性について顧客に問われたとき，はずすことは少ない。

　そうはいっても，プログラミングの経験がなければ，時には無理な注文を引き受けてしまう。だが，実務者に歩み寄る姿勢を持つリーダーなら，多少無理な開発を進めても，メンバーは力を貸してくれる。光ケーブルの行き着く先には，パソコンではなく，それを使う人間がいる。そこには「ここはひとつ，リーダーのために頑張ってみるか」という感情の問題があるのだ。

　また，コンテンツ・デザイナーのチーフには，個性的でクリエーティブなデザイナー集団をまとめられる，控えめで人格円満な人が向いている。事務処理能力も必要だ。制作者全員のスケジュールやファイルや資料の管理がきっちりできなければならない。オンライン・コラボレーションの場合は，24時間常にメールあるいはケータイで連絡が付く，責任感の強い人でなければならない。

　コア・デザイナーには，芸術系ベースの理系人間が適している。デザイナーと技術者間の通訳であり，イメージと論理の人間切り替え器の役割を果たすからだ。例えば，コンテンツ・デザイナーとビジュアル・デザインについて話し合っている最中に，プログラマから「原因特定不可能なバグ発生，対応策を至急検討してほしい」といった連絡が入る。画像処理ソフトを使う手をおいて開発ツールを起動し，プログラムを見なければならない。解決すれば，再び画像の検討に戻る。

　デザイナー主導型プロジェクトでは，デザイナーの視点から，プログラマを説得する立場になることが多い。そのため，人間好きでエネルギーにあふれた説得力を持つタイプか，プログラマ以上に論理的な人が向いているだろう。

　断っておくが，このような原稿を書いているからといって，筆者にプロジェクト・リーダーの資質があるわけではない。筆者がリーダーとして顧客から直接受注しようものなら，実現可能性をパーセンテージで正直に話し，あの機能もこの機能もと乗り気になっている顧客の気分をたちまち撃沈させてしまう。

　筆者から見れば，最も習得が難しくセンスが要求されるのは，デザインでもプログラミングでもなく，顧客との窓口，つまりリーダーが行う営業や折衝の仕事だと思う。このように，プロジェクトのメンバーが活躍しやすい采配も，プロジェクトの成否にかかわる大きなテーマなのである。


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/