第38回　コミュニケーション・コストをいかに軽減するか

　Webサイトを開発する際，数字には表れない「コスト」がいくつか存在します。今回は，その中でも最もコントロールしづらい「コミュニケーション・コスト」について考えてみましょう。

コミュニケーションという関係性

　二人の人間が何か一つの事柄を一緒に成そうと思えば，様々なコミュニケーションが必要になります。それが，初対面であればなおさらです。Webサイトの構築行う際，二期目（バージョンアップ）や，組織的系列的なつながりがある場合を除いて，基本的には多くの「初対面」が発生します。Web業界が「継続的なパートナーシップ」という言葉を目標に掲げることの多さからも，そうした慣れ親しんだ間柄で開発が進むことがまれなことを示しているといえます。

　そうした比較的，初対面的に開始するプロジェクトは，お互いがお互いの力量や，物事の伝え方などを，推し量ろうとするところから始まると言えます。開発者は機械ではありません。仕様を渡せば，ポンと納品物が出てくるというわけにはいかないのです。指示を受ける側は，指示の仕方や構想自体の考え方・運用体制を理解しようとしますし，指示をする側も，どこまで実装してもらえるのか，どこまで細かな指示が必要なのかを見切ろうとします。互いに探りを入れ，判断し，徐々に信頼関係を構築していくものなのです。

　しかし，ここに膨大なエネルギーが費やされます。それは電話や，会議や，仕様書という形を取って，見えない「コスト」となって開発を圧迫します。しかも，Web開発者の多くには，出身分野などの共通点があまりありません。グラフィックデザイン出身者，DTP出身者，正統派プログラマなど，様々なタイプがいます。そうした共通の「よりどころ」的な部分がない状態で，信頼関係を築かなければならないのです。

　こうしたことを考えると，エンジニアとデザイナーの確執は，この時点で生まれていることも多いように思います。探りをいれたり判断したりするのは，時間と手間のかかるものです。ですから，最初からそうした苦労を省いてしまって，命令調の指示になり，お互いが理解しあうことなく，ただ黙々と仕様を実装化していくだけの作業になってしまうわけです。

　しかし，こうしたやり方は，昨今のトレンドから見れば逆行していると言わざるを得ません。様々なプロフェッショナルの知恵を集結しない限り，お客様を喜ばせるWebサイトを構築することができなくなっているからです。もはや，エンジニアだけの発想でも，デザイナーだけの発想でも不十分です。お客様はその上のサービスを探しています。そして，少しでも気に入らなければ，さっさと別サイトに飛んでいってしまうのです。

　したがって，信頼関係の構築を省くようなことはできません。お客様に訪問してもらえなければ，何のためのサイトなのか，何のための開発だったのか，何のための苦労だったのか，すべてわからなくなってしまうのですから――。しかも，Webの開発はどんどん短納期化しています。信頼関係の構築は，待ったなしという状況と認識すべきでしょう。

会議やチームというコミュニケーション

　二人だけでWebサイトの開発を行うということは実際には珍しいでしょう。現実には，プロジェクト・メンバーの数だけ信頼性構築のプロセスが必要になります。

　プロジェクトの最小構成は，クライアントと開発者の二者。規模が大きくなれば，クライアントの中に複数部署が含まれ，開発者側も協力会社などの形で複数社が入り混じることも少なくありません。そして，Web開発会社の人間が，その調整役を担うことが多くなります。さらに，同じ会社の部署間の調整も任されることがあります。短期間に信頼関係を築かなければならないという危機感を一番実感しているからかもしれません。

　この多数の入り組んだ関係の中で正常な関係性を探り出し，議事を進めるのは，当然ながら人数が多くなればなるほど困難になります。

　ずいぶん前になりますが，大手のSIerと仕事をした際，（先方は力の入れようを示すためだったのかもしれませんが）高めの肩書きの人が毎回たくさんやってくるということがありました。会議の時間は長くなるは，会議室を確保するのに苦労するは，それなりに気を使うは，正直言って何も良いことがありませんでした。議事を進めるためのエネルギーを，あまり発言をしない人たちに吸い取られていたようにさえ感じました。結局その後，参加者を絞ってもらうよう依頼しました。どうしても，その人たちの知恵が必要であるならば，参加者がリーダー役になって，社内でまとめて来てくれとお願いしたのです。

小さなリーダーの必要性

　そのような経験から，Webサイトの構築プロジェクトは，機動性に富んだいくつかの小グループに分け，その小グループの中はその小リーダーがまとめたうえで，小リーダーが集まって会議を開催したほうが効率がいいと私は思うようになりました。

　こうした考え方が顕著に現れるのが，メール系です。例えば会議のスケジュールを組むといった単純なことでさえ，関係者全員にメールして日程調整をするとなると，かなりの労力が必要です。多くのプロジェクト・リーダーやマネージャが，他にやることが山積みにもかかわらず，こうした作業に忙殺されることはよくあることです。日程調整をしたいだけなのに，連絡する人の多くから質問が寄せられ，それに答えているうちに話が発展したり道をそれたりしてしまうのです。

　しかし，小さなグループ単位で日程調整して数個の候補日に絞れるなら，明らかに日程確定までの時間は短くて済みます。民主主義の象徴のようなやり方で，全員を平等に扱うことは，時間効率という意味ではあまり良い方法ではないのでしょう。そして，いまやWeb開発において，「短工期（短納期）」は必須条件になっています。「時間」の重要性が大きくなっているのです。時間を一番大切にした，組織や体制といったものも必要となってきています。

　この，メールと同じ手法を会議にも当てはめてみましょう。平等に皆を扱った場合，会議は長時間化する傾向があると思います。きちんと統計を取ったわけではありませんが，個人的意見を皆が言ったところで，全体の方向性が定まることはまれだからです。個人の意見もあるでしょうが，何らかの小さなグループとしての意見をまとめておくことをお願いしておくと，会議の場ではスムースに話を進められます。

　そうした会議参加者の意識付けに失敗すると，何度言っても宿題をやってこなかったり，毎回初回にした概要説明から始めないと議論もできないクライアントや，クライアント（発注者）を前にして内輪もめや初めて聞くようなことを言い出す開発者が現れたりします。事前に小グループとしての活動があり，そのうえで召集されているのが「会議」であるという前提が崩れると，総合的なアウトプットにも悪影響が出ます。

小リーダーが任を果たさないならば

　こうした責任分担制を，毎回きちんと構築していくのは非常に難しいことです。自分の前にある課題にだけ集中するのではなく，プロジェクト全体の中で自分のタスクの占める位置や，担当者の位置付けを明確に意識する必要があるからです。

　「木」を見るよりも，「森」を見ることのほうがはるかに難しいのです。そのため，そこから逃げ出す者は多くいます。どこかで，サボる輩が出てしまうのが常です。もしそうなった場合，何が起こるのでしょうか。前述のように，会議全体の成果が下がることは当然ですが，全体会議の「長」の負担が増えるのです。全体を俯瞰（ふかん）していろいろと調整しなければならない立場の人間が，少し粒度の小さなレベル（小リーダーがまとめるレベルの仕事）の調整に苦労することになります。

　チーム編成にしても，会議にしても，それを仕切る人の力量が大きく問われます。それは「様々なレベルで」です。大リーダーも小リーダーも，それぞれの「森を見る視点」で自分の立ち位置をわきまえて調整をしなければなりません。どこかが崩れただけで，どこかに負荷集中が起こり，そこからプロジェクトにヒビが入ります。

　どこまでを小グループに任せ，その達成をどのようにチェックし，どのように記録するか。会議そのものも，いかに短時間に濃縮できるか，それがコミュニケーション・コストを下げるためには必要な検討事項です。そして，それらをきちんと「設計（デザイン）」するには，その参加者の特性を知っておく必要があります。ですから難しいのです。ですから，おざなりにされ，毎回行き当たりばったりで対処しようとしてしまうのでしょう。

まとめ

　プロジェクトの規模が大きくなるにつれ，関係する人間の数が増えることになり，潜在的に人と人との調整に苦労する状況が増えていきます。したがって，先取りしてその苦労を分散させる必要があります。Webサイト開発は，実はお客様とクライアントの間のコミュニケーションの活性化です。それなのに，プロジェクト内のコミュニケーションの活性化や効率化の準備が疎かにされるのは，本末転倒とさえ言えます。

　こうした，見えない「コスト」を見込んで開発を進めないと，結局のところ開発リーダーやプロジェクト・マネージャーの能力と努力が空回りし，能力を発揮しつくすこともできないまま，本当に良いものを創り出せない状況に陥ります。

　お客様が陥るだろう「迷子」を事前に見抜いて，そのようなことがないようなサイト構造を提案するように，会議の場や開発チーム体制を考えるときにも，自分たちが陥りそうな「落とし穴」を事前に埋めていけるような歩みを目指していきたいものです。

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