発注の際のトラブル原因はクライアントではなくディレクターのほう

少し前ですが、「困ったクライアントのダメな発注4つの実例」という記事がありました。
クライアントがしてはダメな事みたいな書き方をしていました。
しかし、こういうトラブルの原因はディレクター側に問題がある場合がほとんどです。

ネタ元はこちらの記事。
マンガ「困ったクライアントのダメな発注4つの実例」 ~こんなクライアントはもうイヤだ! | Web担当者Forum

記事元はWeb担当者Forumなので、ウェブサイト製作者側ではなく、発注するほうの立場向けに書かれていますが、クライアントが悪いみたいな感じです。

バッドケースとして以下が挙げられています。

  1. 目的があいまいだったりころころ変わったりする
  2. 「やっぱりあれもこれも」あとから工数がどんどん増える
  3. スケジュールが決まっていなくて作業が伸び伸びに
  4. あとから値切られたあげく追加工数分の支払いを渋られる

実際こういう状況に陥ることは多々なのですが、これは別にクライアントが悪いわけではありません。

なぜならば、クライアントはウェブサイト制作のエキスパートではないということ。だからウェブでどんなことができるのか、頭の中で想い描いている事が現実的なのかということはさっぱりわからないわけです。

だからこそ、プロのウェブサイト制作会社があるわけで。バッドケースの問題はクライアントが解決することではなくてディレクター(クライアントと直接交渉する人)が解決すべき問題です。これらのケースに陥ることは当然のことで、打ち合わせで十分話し合って、見積の段階で全てクリアしておかなければなりません。

見積が受諾されるということは提示した値段で契約を結んだということになります。なので、見積が通った後に仕様の変更が起これば値段や納期の変更も必然的に起こってしまい、それこそがトラブルの原因です。見積時点での仕様を変更しない、変更する際は追加の料金が発生することは、見積を受諾してもらう際の最低条件です。(しかしこれがうまくいかなことも事実。)

トラブルになった場合、作るほうは納期に間に合わすために必死になっているのに相次ぐ仕様変更で今まで徹夜してやった分が無駄になってしまい、とても苦しい思いを経験した人は多いと思います。つまり、このようなバッドケースで一番被害を被るのはプログラマやデザイナーなど作り手なのです。そしてこの人たちにはクライアントと直接交渉する権限はないわけです。(ただし、案件の規模が小さくて開発者が仕様を説明できる機会を与えられる場合もあるとは思います。)

クライアントには納得してもらい仕様が変更しないようにもっていくトークテクニックがあることが、優秀なディレクターさんの素質のひとつではないかと思います。それが必然的に、開発者には快適な開発環境が用意され、よりよいものができあがり、クライアントも開発者も満足したWin-Win(というかBoth are satisfied?英語がわかりませんが・・・)の関係が築けるのではないでしょうか?

徹夜して作ったものほど最悪なものはないですからね><(テンション上がって手が止まらなくて気づいたら徹夜したというやつは、逆に最高のものができるのですがね・・・。)私は、徹夜が常識と思われているこの業界の常識を作ったのは、できないプロジェクトマネージャー(プロジェクトの最高責任者)だと思っています。8時間労働で十分にペイできる環境ができないものかな~と常々思っています。

投稿日:2008年2月 3日

トラックバック歓迎です。以下URLにて登録をお願いいたします。

このエントリーのトラックバックURL:

↓↓↓トラックバックしてくださった方々↓↓↓
※トラックバックされても管理人がスパムと判断したものは公開されません。

top