顧客との信頼関係を得るには顧客の不安を解消しなければならない

ソフトウェア開発プロジェクトが失敗した、お金を払わずに裁判になった、という悲しい話をたまに耳にするが、その際に決まって言われるのは「顧客との信頼関係が損なわれていなかったら、裁判にはならなかっただろう」というような内容である。

受託のソフトウェア開発プロジェクトにおいて、どうやったら信頼関係が損なわれないか、ということが問題である。顧客も開発側も、わざわざ信頼関係が損なわれるようなことはしないだろう。

わざとやったのではなくて、なんとなく不信感が募り、いつのまにか敵対関係になり、最終的に喧嘩別れして、かかった分の作業コストを払え払わないという話になるのである。

プログラマは、とかく技術的な側面に目が行きがちだが、技術的に難しいかどうかは、顧客側から見るとあんまり関係ない。逆にプログラマから見るとどうでもいいことにこだわったりする。

顧客側には、業務的にその機能は必須だとか、以前作ってもらったシステムではその機能がなくて大変な騒ぎになったとかいう理由で、まずその機能が実装されるのかどうかで頭がいっぱいになってしまう人もいる。

その時に、まず全体を決めてからその後でその機能について議論しましょうと言っても、全体よりその機能の方がその人にとっては大事なので、全体の議論をしていても上の空で集中力が散漫になっているかもしれない。

開発方法論に沿ってないことはできないとか、後で不要になるかもしれないからまず全体を決めないからでないと判断できない、という理由は当然のようにあるが、不要になれば捨てればいいだけの話で、まずは顧客の気になっている部分についてちゃんと議論して、顧客側の不安感を解消しなければ、実質次へ進めないのである。

開発側から見ると、全体から細部を構築して、理路整然とした感じで、顧客と仕様を詰めたいという希望があると思うが、顧客の誰もが似たような脳みその構造を持っているわけではないので、ほとんどの場合、開発側の土俵でいっしょに話をするのは難しいのである。

開発側が顧客は何にもわかってないと思うのであれば、顧客側も開発屋は何もわかってないと思っていることだろう。早い話が、顧客に合わせて話をしないと意味がなくて、顧客がわからないことにOKを求めても、後でもめるだけなので、顧客がわかる評価基準を決める必要があるのである。

ソフトウェアが作れるからソフトウェア開発の仕事をするのでなくて、顧客が満足できるような仕事が出来るからこそソフトウェア開発の仕事をする、というスタイルで望めば、たぶんもめることはないだろうし、納期が遅れてもただで働けとは言われないだろうと思いますよ。たぶん。