Web制作会社の業務は，HTML系の制作だと一般的には思われています。しかし，現場の感覚から言えば，それは正解ではない気がします。お客様であるクライアントとの折衝が，実は多くの時間と労力を必要としている部分に思えるからです。もちろん，開発に専念するメンバーがいるのは常ですが，交渉の結果に一番影響を受けるのも彼らです。クライアントとの仕様の交渉などは，Web開発の根幹と言っても過言ではないでしょう。今回は，その交渉に焦点を当てます。

クライアントとの交渉

　下の絵は，もう三年ほど前に描いたものです。クライアントに振り回される，「Web屋」の悲哀を風刺したつもりですが，問題なことに，未だにこの絵を見せると笑いがとれます。多かれ少なかれ，似たような経験があるということです。この仕様を詰める段階での，振り回されるプロセスは，ここ数年あまり改善すらされていないと言っても良いのでしょう。

　ただし，この絵ではクライアントに理不尽な理由で振り回す役をやってもらっていますが，エンドユーザーを対象にした時点で，様々な個所で選択肢が増えてしまい，意思決定者であるクライアントが何を根拠に定めて行けばわからなくなった結果，仕様が揺れるということも頻繁に起こるケースであることには，注意をする必要があります。

仕様変更多発(朝令暮改)型

　Webが，社内のような専門家集団や特定の行動パターンを持った人たちを対象にしていた「システム開発」から，いわゆる「一般の人」を対象にし始めてから，この種の仕様変更という問題は，ずっと大きく深く存在しています。そのため，大きなプロジェクトでは，仕様設計フェーズと開発フェーズを分離した契約にしたり，次フェーズに行く際には有権限者のハンコを貰うなどの方法まで採られている状況です。

　しかし，本来的に「ユーザビリティ」や「使い勝手」を重視するならば，試作を重ねるようなトライ＆エラー方式で開発を進めるのがマッチしていて，ウォーターフォール方式はなじまないと思っている方が多いように思われます。そこで，重視されるのが，「交渉能力」です。

　契約やルールによって縛るのではなく，合意のうえできちんと前に進んでいくという理想的な形です。それは，開発の要となる「落としどころ」を模索して，クライアントも，開発陣も，そこに無理なく追い込んでいく「力」と呼んでもよいかもしれません。

交渉力：ファシリテーション

　うまく交渉を進めるということには，幾つかの構成要素があるように思います。大きくは四つ：「Webテクノロジー知識」，「Webトレンド知識」，「コミュニケーション能力」，そして「落とし所牽引力(仮)」だと，私は思っています。最初の二つは，信頼を得るための必須スキル。コミュニケーション能力は，正しく伝え，正しく聞けるかという双方向の能力。最後は，きちんとあるべきゴールに着地させる能力です。

交渉力(私見)

Webテクノロジー知識：30%？
Webサイトを構築するために最低限必要な知識です。クライアントやユーザーのニーズを実装するための最適解を提案できるだけの懐の深さも必要です。大規模なプロジェクトでは，少し未来の技術トレンドも押さえておく必要があります。何事も，できあがった瞬間から陳腐化は始まるので，できあがった時点の読みを深めておく必要はあります。
もう一つ注意すべき点は，「技術」に対する過信です。多くの一般的ユーザーは「Java」だからとか，「Flash」だから使うようなことはしない，ということを技術者は忘れがちです。最近では多くの方が言いますが，エンドユーザーは，そのアプリケーションが何でできているかはどうでも良いのです。技術は実装の決め手にはなりますが，利用/活用の決め手にはなりません。
Webトレンド知識：30%？
技術的に可能か不可能かという知識だけを持っていても，よき実装者とは言えません。マニュアルやスペックにどう記載されていようとも，実際に様々なブラウザでどう表示されるのか，動くのかを確かめておく必要があります。そして，実際にはどのように活用されているのか，どこに使われているのか，どういった留意点があるのかなどの情報が身に付いていると，言動に重みがつきます。こうした情報を得るために，様々なサイトを常にウォッチする必要があります。有名なシステムインテグレータ(SIer)が歴史に残るサイトを構築できないのは，このスキル育成が不足しているためではないかと思っています。小さなWeb屋が見ているサイト量に比べれば，明らかに劣っているから，実務ノウハウが不足してしまうのです。
コミュニケーション能力：30%？
Webというパソコン等を通じて世界とつながっている人たちには，得てして人付き合いが苦手な方がいます。しかし，クライアントという人間を前にして，「仕様の合意」を得るためには，それでは困ります。技術も，トレンドも，実績情報も，それを相手に伝えて初めて意味があります。
そして，Web開発を職業としている者の多くは，非常にたくさんのクライアントさんと出会うことを余儀なくされます。一つのコミュニケーション・パターンがいつでも通用するという職場ではないのが普通でしょう。相手の会社の風土も，そのクライアント自身の人となりも，毎回異なり，同じプロジェクトはない(毎回新分野へのチャレンジ)と思っていたほうが無難な状況なのです。
そして，伝えること以上に難しいのが，「聞く」ことです。通常，クライアント側はWeb技術にそう密に接してはいません。ですので，そうした技術用語にも慣れていません。日常業務の延長線上で，自分たちの言葉とその会社独自の方法で，やりたいことを伝えてきます。それを，自分たちの開発チームの中で共有できるように翻訳する必要があります。それも正しく。それは，Webが高度な機能を持てば持つほど，高いスキルといえるものです。そして，それを学ぶカリキュラムは，その必要度に比べると育っていません。
落とし所牽引力(仮)：10%～？
要件を聞けて，言えて，知識があっても，交渉が難航することが多々あります。典型的な例では，真っ正直なエンジニアがこの任を負った時です。何事にも正しさを求めて議論モードになることは，時として，プロジェクトを危うくします。連続10時間クラスの会議を何度もしてきましたが，正しさを突き詰めて行って，泥沼に入ったことは何度もあります。殆どの場合には，クライアントが決定をする，最終選択をするのが通常ですが，そこに至る道を用意してあげることが，Webのプロの責任なんだと，何度となく思わされています。
結論を出しやすい仕掛けを準備する，当て馬を用意する，等など様々な方法があります。半ば，「はったり」と呼べなくもないことも必要になったりします。ただ，いつも思うのは，姑息に思えるような手段を使ったとしても，実際に開発に入った段階で自分たちが楽になるように謀(はか)ることはまずなくて，品質を高めるためにそちらの選択肢に向かわせている，という点です。クライアントが何かを選択する際に，Web屋はそれが実際に使われるシーンを思い浮かべることができます。そこから逆算して行動しているのです。
そして，面白いことにこの能力は，技術スキルやトレンド情報をある程度は，代替してくれることもあります。まさに「はったり」の領域に入るのかもしれませんが，技術知識が足りなくても，ある程度の話術でカヴァーできるものなのです。