「顧客対応」の現場では、理屈では割切れない様々な事象が発生する場所でもあり、苦手に感じている方もいるでしょう。しかし、システムを顧客のために作っている以上、この「顧客対応」はITエンジニアが成長するうえで避けて通れない道でもあります。本連載では、新人プロマネ弁田君が顧客対応に挑戦するストーリーをみながら実際の現場でよく症例を紹介し、その対応について解説していきます。第1回では、みなさんも1度は体験するであろう、デモ当日から止まらなくなった顧客の要求に対する対応の掟と極意を解説していきましょう。
日記：デモ当日になってあれもこれも！
……システム開発も設計、製造と作業が進んでくると、機能の一部が目に見えるようになってきます。すると顧客も興味津々のようで、一部でもいいから実際に動くところを見てみたいと言ってきました。設計書は見せていたので「設計書と同じですよ」と言っても、やはり実物の動きを見てみたいようです。弁田君は若干の不安を抱きつつも、快く承諾して日程を調整しました。
さてデモの当日です。実際の動きを顧客に確認してもらいました。ところがと言うべきか、案の定と言うべきか、動きを見た顧客はすぐにあれこれと要望や疑問を口にし始めました。先ほどまでのにこやかな顔はどこへやらです。弁田君も苦い顔をしています。
確かに今回のプロジェクトでは顧客の時間を押さえるのに一苦労でした。要求定義にも必要最低限の時間しか割けていないという現実があります。とてもではありませんが、要求定義に自信があるとは言えない状態でした。それでも、前に確認したときは「いらない」と言っていた機能が、デモでは「この機能が足りない」と言われたときにはカチンときてしまいましたが。
顧客はすっかり気分を害していました。即、スコープ調整のための会議が開催されることになりました。要求定義で100パーセントの努力をしなかったかもしれない、という負い目を心の中に持っている弁田君は、できるだけ譲歩して、できるだけのことは誠実に対応しようと考えていました。しかし顧客からの要求はそんな弁田君の想像をはるかに超える大きなものでした。
最初に合意したスコープから考えるとグレーゾーンどころか真っ黒な部分までもが当然のごとく要求の中に含まれています。顧客は「スコープの合意」が何を意味するのかさえ理解していないようです。念押しの確認だったものが、少しも念押しの役目を果たしていませんでした。
こちらが難色を示すと、「それでは業務がまわらない」「そんなことは常識だ」の連発です。「やるんですか、やらないんですか」と強く迫られると、つい引き受けてしまう弁田君でした。しかし抑えに抑えて何とか最低限の仕様で勘弁してもらったつもりでも、その仕様を自社チームに持って帰ると、今度は開発メンバーからの反発です。
そのうちに「うちのリーダーは単なる顧客のメッセンジャーかよ」といった陰口までもが聞こえてくるようになりました。…
この記事は参考になりましたか？
- 現場の「困った」を解決する！顧客対応の掟と極意連載記事一覧
-
- 顧客を怒らせてしまった場合の対応の掟
- 顧客との話がいつまでも平行線の場合の対処法
- 顧客から要求を迫られた時に知っておくべき対応の掟
- この記事の著者
-
本園 明史（モトゾノ トシフミ）
1967年福岡県生まれ。法政大学経済学部卒業後、三菱電機東部コンピュータシステム株式会社に入社。契約エンジニア、ソフトハウスを経て、現在はウルシステムズ株式会社に勤務。
ビジネスとITのギャップを埋めるべく、発注側・ユーザ側の立場から、システム化計画立案、RFP作成・ベンダ選定支援、ベンダ管理、プロジェク...※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です
この記事は参考になりましたか？
この記事をシェア
