正論だけではすまないから交渉力が求められる

どんなソフトウェアでも、「あと、これがあれば完璧なのになぁ」と思う事は多いと思う。「なんでこんな簡単な機能がないんだろう」とか「これが出来ればすごく楽なのに」と考えるのは日常茶飯事である。

落ち着いて考えると、そのソフトウェアをあなたは利用しているのである。利用している上で、よりよい機能を欲しがっている。もし直接開発している人に連絡が取れるのであれば、それを伝えるだろう。

それは利用者から開発者へのフィードバックであり、開発者がそれはいい提案であると思えば、次のリリースでその機能は実装される。開発者側に実装する機能の選択権があればの話だが。

問題は、受託開発の場合、出来上がる前のソフトウェアでも、顧客は上の話と同じ思考パターンで開発者に要求を出してくるということだ。当然、仕様書には書いていないことについてもである。

開発者側には、ここで交渉力が問われるのである。仕様書に書いてないからやりません、契約範囲外です、とずばっと言いたいところなのだが、その機能がないと確かに不便なので使いにいくというのも事実、ということが往々にしてあるからだ。

わかっているだけに開発側も作りたいが、納期が伸びる、予算が増える。顧客と交渉しても納期が伸びたり、予算が増えたりするかしないかは交渉次第だ。ここでよくあるのは次の仕事に金額を上乗せするから、今回はこのまま機能だけ追加してくれというパターンだ。

また、次の仕事も予定が詰まっているので、仕様書にないからやらないといっても今回の開発分のお金はもらえるだろうが、顧客の心情を悪くすると次回はないかもしれない。あの会社はちょっとした顧客の頼みを聞いてくれない冷たい会社だと、ネガティブな口コミ情報が流れるかもしれない。

最初にちゃんと要求分析しないからダメだ、とかよく言われるのだけれども、やはり顧客は実物に触るまで感覚的に理解できないため、あらかた出来上がってからいろいろ要求が出るのは当然なのだと思う。

要はその時に、どう顧客を納得させて次に繋げるか、という大人の対応が交渉力であり、交渉力に劣ると、どれだけ素晴らしい技術力があっても顧客に不満が残る。

最後は交渉力でカバーすると言うと、技術屋的にはすごい嫌悪感を持つ人がいるが、他人に納得してもらってなんぼである。ダメなソフトウェアを騙して買ってもらうということではなくて、一生懸命作ったいいソフトウェアを納得して使ってもらうために必要なのである。

何も説明しなくても解る人には解るとか言ってたら、より粗悪なソフトウェアに交渉力だけで負けてしまう事もあるのだ。だからプログラマは交渉力を磨いて、いいものが駆逐されないように頑張らないといけない。

喋りだけが達者で中身が何も無い人よりも、喋りも中身もある人の方がいいに決まっている。喋りが達者じゃなくても中身があればいいと思っているプログラマは、少し方針を転換して、喋り（漫才ネタではなくてここでは交渉力）のスキルがあればより自分も相手も幸せに出来るかもと思って頂ければ幸いである。