顧客の要求する不要と思われる機能を否定する方法とは？
請負でシステム開発をしていると、顧客が必要となる機能を取りまとめたりする作業が必要になります。えー？こんな機能いらないんじゃないですか？って思う機能を要求されたり、そんな実装方法をするの？？って事もあったりと色々です。
そんな時にどうやってお客を思い留まらせるか？私の経験での話を交えてしたいと思います。
目次 [hide]
顧客の要求をエンジニアとしてどう捉えるか？
顧客の要求をエンジニアとしてどう捉えるべきか？心構えと言う点でまず考えてみたいと思います。まずはその部分が異なると話が変わってしまいます。
顧客の要求は「飯のタネ」
顧客（依頼主）が要求する仕様、機能はぶっちゃけ「飯のタネ」とだと考えています。ここが大きく別れる考え方何じゃないかなぁと思うんです。
私も若い頃、20代の頃とかは顧客が途中でしてくる仕様変更は「面倒くさい」と思って極力請けない方向、思う留まらせる方向で話を進めようとしていました。なので、こちらの要求が通らずにやらざるを得なくなった時のモチベーションの下がり様といったら・・・でしたね。
我々エンジニアは価値を創造して顧客に提供するのが仕事です。顧客が要求する物を作るのが仕事です。その要求するものを作って開発する代わりに対価をもらう職業です。その大前提を踏まえた時に、顧客の要求する仕様、機能は対価をもらえる「飯のタネ」となる訳です。
「飯のタネ」と考えると交渉の観点が変わります
さて「飯のタネ」と考えた瞬間に交渉の観点が変わります。
「顧客の考え方を思い留まらせる」交渉から、「より良い価値にしつつ、どれだけ対価を貰うか」、この方向に観点が変わります。これにより、建設的な対話が顧客とできる様になるので、良いシステムが開発できるだけではなく、顧客との関係も良くなっていきます。
要求に対して対価って納得するのか？
いちいちの要望に対価とか追加とかって、顧客は納得するの？関係悪くなるんじゃない？と思っている人も多いと思います。
確かに自分の都合の良い方向で考える顧客が多いのも事実です。今ある見積もりでやって貰えると思う人も多いです。
大体は「費用が発生する」事を理解できていない顧客が多いです。なので、相手が「追加費用になるってわかっていていっている？」「これは追加にならないって知ってて言ってるんだろうな」という思い込みはやめて、確認しましょう。「追加費用です」といった瞬間に尻込みしたり、「そうなんですね」と理解を示します。エンドユーザーは特にそうです（悪用はダメですよ）。SIerからの依頼であったりユーザー系の情シスからの依頼の場合はそう甘くはないので、各ドキュメントはしっかりとしてFIXをしておく必要があります。
これだけで案外楽な交渉が可能です。
どういったプロセスで話を聞くべきなのか？
まず、顧客の要求する仕様をどういったプロセスで聞くべきなのか？どういった判断基準で聞くべきか？から考えたいと思います。
- まず聴く（肯定的に）
- 背景を確認する
- システム全体に照らしわせて要・不要の判断を行う
- コストと照らし合わせて要・不要の判断を行う
- 提案と正式費用の提示
ざっとこの様なプロセスでしょうか？では順番に説明していきます。
1.まず聴く（肯定的に）
まず聴きましょう。ここで重要なのは「肯定的」に聴く事です。なるべくやらない方向でとか「否定的」な意識を持っていると、この先に良い交渉はできません。
2.背景を確認する
一旦、要求を確認したら次はその要求が発生した背景を確認しましょう。工程が漏れていた？使い勝手？現行システムがそうだったから？政治力の強い人にプレッシャーをかけられたから？
要求ある所には必ずその理由があります。表面にある要求だけで判断するのは「御用聞き」になってしまいます。その背後関係までをしっかり洗い出してトータルで判断できる様になる必要があります。そこを抑えると、交渉が非常に論理的になるので必ず背景は確認しておきましょう。
3.システム全体に照らしわせて要・不要の判断を行う
ここから要・不要の判断になります。
聴いた機能、要望をシステム全体にはめ込んでみます。システムのコンセプトやポリシーに反しないか？他に代替できる等価な機能は存在しないのか？それで効率が上がるのか？
全体的な観点から判断が必要になります。当然伺っている背景も判断する必要があります。
不要となった場合に代替案がないのか？も重要な要素となります。
4.コストと照らし合わせて要・不要の判断を行う
次にコストと照らし合わせてみます。
何をどうやっても、どんなに機能を簡易的にしてみたとしても費用対効果が見込めない。そんな要望もあるでしょう。そうした時は正直に費用の話をしてしまうのも手です。
「それでもやる！」
そう言うのなら、それはそれ。全力で仕事をさせていただいて、きっちりと納めます。当然、変な条件は飲まない様に気をつけながらになりますが。
5.提案と正式費用の提示
最後は提案と正式費用を提示します。
100％顧客要求を実装できる事は難しい場合があります。その時でも代替案を必ず持って交渉をする様にしましょう。
ここまで結構コミュニケーションを密にとる必要があります。交渉ごとはコミュニケーションが大切です。書類やメールだけではなかなか難しい。チャットツールの様な話し言葉でコミュニケーションが取れる様なものであったり、音声でコミュニケーションが取れるもの、最も理想的なのはFace to Faceなんですが。密にコミュニケーションを取って交渉する事が大切です。
こんな声が聞こえてきそうです
さて、ここまで書いて、こんな声が聞こえてきそうなんでまとめておきます。
- ウォーターフォール型前提かよ
- PMがすでに請けちゃってどうにもならんのだけど？
本当にそうなんですか？
ウォーターフォール型前提かよ
そうとも言えません。アジャイルやインクリメンタル式であったとしても適用可能です。アジャイルの場合、準委任契約で進める事もあると思うので、仕様変更や追加といった概念はないのと、もともと変更を受け入れるポリシーがあるので、顧客の要望は肯定的に聴く必要があります。
なので、顧客要望を肯定的に聞き入れ、最も適した提案をし続ける必要があります。
PMがすでに請けちゃってどうにもならんのだけど？
顧客接点から遠いほど、プログラマーなど現場になるほど、この考えは難しいのか？さて、そんなPMは板挟みにしてやりましょう。プログラマーからすると、PMやリーダーは顧客（依頼主）とも言えます。
顧客と正しい交渉ができない無能なPMと言えども、ある意味では自分の依頼主であるとも言えます。まずは意見を正しく肯定的に聴きます。その上で理路整然と工数を言うのです。必要な工数を引き出します。無理なもの出来ると答える必要も筋合いもないのです。
ただ、PMが顧客と交渉しやすい代替案や知恵を授ける必要はあります。自分はPMと交渉しつつも、顧客とも交渉しているつもりでやりましょう。
その経験は将来確実に生きます。
まとめ
顧客との交渉というのはエンジニアにとって必要なスキルだと思います。交渉のシーンで一番多いのは機能に関する話をしてしている時です。その時の心構えを今回書いてみました。
以下にざっくりとまとめてみます。
- 顧客の要望は「飯のタネ」である
- 肯定的に聴き入れ、建設的な提案をする
- より良いシステムだけでなく、顧客との関係が良くなる
- 交渉をする事はその成功失敗に関わらず、大幅にスキルアップに繋がる
最後の交渉の成功・失敗は関係なく、交渉した事実だけでスキルアップに繋がるのは本当に事実です。エンジニアは本当に交渉が嫌いな人がおおい。すごい損をしています。交渉してどんどんスキルアップをするのと、交渉する事で顧客とどんどん関係が良好になると、どんどん良い仕事が入ってくる様になります。
これらが出来ないと誰も引き受けない美味しくない仕事をし続けるだけのエンジニアなってしまうので、皆さんも是非とも意識的に交渉スキルを磨いてください！
