連載
» 2013年03月27日 00時00分 公開

顧客が本当に欲しかった、「技術力以外」のものITエンジニアの市場価値を高める「営業力」(7)(2/2 ページ)

[森川滋之,ITブレークスルー]
前のページへ 1|2       

顧客から「情報提供がない」と言われてしまう理由

 まずは「1.相手の課題は何か?」についてです。

 私がかつて、顧客満足度調査の集計をする部門にいたときのことです。顧客満足度調査は事業部ごとに集計しており、どの事業部の調査にも共通する、3つの不満要因がありました。

 それは、「1.価格が高い」「2.提案がない」「3.情報提供がない」でした。1と2については、また別の機会に検討することにしましょう。今回取り上げる問題は3です。

 「3.情報提供がない」について営業に聞くと、顧客には新製品情報やセミナーの案内など、機会があるたびに情報を提供しているとのこと。それなのに顧客からは「情報提供がない」と言われ、理由が分からないとのことでした。

 私も当時は、その理由が分かりませんでした。その後、ユーザー企業のITコンサルタントをしたり、IT導入成功事例の取材を重ねたりして、だんだん分かってきました。

 答えは単純でした。顧客の課題を聞かずに、自分たちが提供したい情報だけを伝えていたからです。ワンクッション置けばよかったのです。まず顧客の課題を聞く機会を作り、その後に情報提供をすればいい。

情報提供とは、相手の知りたい内容を語ること

 多数の導入事例を取材していて分かったのは、評価の高い営業や顧客担当SEの多くが「顧客の課題を聞いてから情報提供」を心掛けているということでした。

 案件を受注するきっかけは、偶然に見えることが多いのです。顧客からすると、解決策を探していたら、たまたま○○社の営業がやってきたという印象です。しかし、偶然ばかりで仕事を取っているということはあり得ません。それなりの仕掛けをして、顧客のアンテナに引っ掛かる努力をしているというのが本当のところです。

 誰かの紹介がきっかけかもしれません。たまたま展示会で名刺交換をしたということもあります。Webサイトを充実させるという手もあります。営業力のある会社は、一つだけでなく、あらゆる手段で情報提供の機会を用意しています。紹介されやすい仕掛けをしたり、定期的に大量の資料を送ったりして、自社に連絡が来る確率を高めるためのありとあらゆる工夫をしています。

 そして、機会を捉えてからの行動が違うのです。

 私がユーザー企業のITコンサルタントをしていたとき、ITエンジニアに多い2つのタイプに気が付きました(業界内部にいるときにはなかなか見えなかったことです)。知っていることであればいつまでも語っているタイプと、ひたすらこちらの課題を聞き出そうとするタイプです。営業力のある会社のITエンジニアに、後者のタイプが多かったことは言うまでもありません。

 せっかく受注の機会を捉え、顧客を訪問しても、自分の知っていることばかりを語ってしまっては台無しです。顧客の知りたいことを語らなければ、受注には結び付きにくいでしょう。

 自分が知っていることを語ることが情報提供だと勘違いしている人が本当に多いのです。そうではなく、相手が知りたいことを語るのが情報提供なのです(図2)。

図2 情報提供とは、「自分が知っていることを語る」のではなく「相手が知りたいことを語る」こと 図2 情報提供とは、「自分が知っていることを語る」のではなく「相手が知りたいことを語る」こと

自分が知らなくても、顧客の心は捉えられる

 「情報提供」=「相手の知りたい内容を語ること」の事例として、私自身の経験談があります。

 有名な家電メーカーA社がデータウェアハウスを構築するという案件がありました。今から15年以上前のことです。

 A社には開発部隊がありましたが、ずっと汎用機のシステムをCOBOLで開発してきました。この案件では、UNIXサーバ上でOracleを使って開発を行うことが決定していました。「ついては、UNIXとOracleのプロをプロジェクトに参画させてほしい」との要望が、私のいた会社に来たのです。最終的な目的は、A社のITエンジニアへのスキルトランスファーでした。

 当時私がいた会社では、Oracleのプロはアサインできたのですが、UNIXのプロはアサインできませんでした。そこで、私に話が回ってきたのです。

 私は、UNIXベースのシステム開発プロジェクトでリーダーを務めた経験がありました。しかし、技術的な部分はメンバーに任せていたので、UNIX自体にはあまり詳しくなかったのです。

 A社は、ある意味社運を賭けたプロジェクトなので、実現可能性の事前ミーティングを兼ねて面接したいと言っているとのこと。天下のA社です。厳しいやりとりが予想されます。私は青くなって断りました。

 しかし、部長はどうしても行ってくれと言う。A社との取引は、部長のかねての夢であったからです。それで私も折れて、面接を兼ねた事前ミーティングに参加しました。

 UNIXに関して根掘り葉掘り聞かれることを覚悟して行きました。でも考えたら、そもそも根掘り葉掘り聞くだけの力があれば、UNIXのプロが欲しいなどとは言わないわけです。ミーティングは、A社が実現したいことの詳しい説明があった上で、「これはUNIXで可能なのか」という質問に終始しました。

 実現可能性であれば、過去のプロジェクトから類推して判断できます。A社の質問に答え、理由も含めて解説したところ、「ぜひプロジェクトに参画してくれ」ということになったのです。

 UNIXのプロという触れ込みで出向いた私は、ボロが出ないように、技術的なことはあまり話さないようにしていました。これがもし詳しければ、どうでもいいことを長々と語っていたかもしれません。UNIXのプロだということを証明するために。

 しかし、長々と語れるほど詳しくなかったため、顧客の課題を聞くことに集中できました。その上で、顧客の知りたいことに答えることができました。

 本当に偶然でした。知らなかったので、聞くことに集中した。とにかく理解しようと必死で質問した。顧客も自分たちの課題が明確だったので、それについて私に尋ねた。私は自分の経験から回答することができた。今思えば、理想の展開です。

 「自分が知らなかった」ことが幸いし、顧客の心を捉えることができた事例です。

顧客には、技術力とは別の判断基準がある

 この話には、オチがあります。

 案件は、A社に常駐して対応する、いわゆるプロフェッショナルサービスでした。本当はUNIXの素人である私は、シェルスクリプト入門とかvi入門とか、UNIXのプロが持参するにはちょっと恥ずかしい本を持ち込む必要がありました。今ならネットで調べてごまかすという手もありますが、当時はインターネットもまだ普及し始めたころで、技術情報は今ほど充実していませんでした。

 そんな本が机の上に並んでいたら、嫌でも素人だということが分かってしまいます。そこで、A社の担当者に正直に打ち明けました。「UNIXのプロということでのお引き合いですが、実は技術的に詳しいわけではないのです」と。

 すると、担当者はこう言ったのです。「それは、事前ミーティングでなんとなく分かりました。でも、われわれが求めているのは技術者ではなく、一緒にプロジェクトを遂行してくれるパートナーなので、その意味では全く問題ないと思いました。こちらの課題にきちっと耳を傾けてくれる人なら、必ずやり遂げてくれるはずです」

 課題に耳を傾けるITエンジニアが少ないことを示す逸話だと思います。「課題に耳を傾けているかどうかは、適切に質問できているかどうかで判断する」ということも、この後教えてもらいました。

 これにはショックを受けました。私は、ITエンジニアは技術を知っていてナンボと思っていたので、それなりに勉強してきました。逆に、技術的に詳しくないのであれば、その仕事は断るべきだと思っていました。

 ところが顧客には、技術力とは異なる判断基準があったのです。

 判断基準は、顧客のそのときどきの課題に基づいて変わります。なので、それをきちっと聞き出さないといけない。私の事例では偶然聞き出せたわけですが、意識して聞き出されば当然もっといいわけです。

 三大質問方針(1.相手の課題は何か? 2.相手の知識レベルはどのぐらいか? 3.相手の興味・関心はどこにあるのか?)について全部お話しするつもりでしたが、1番目の話が長くなりました。

 残り2つについては、次回以降お話しします。

筆者紹介

ITブレークスルー代表

森川滋之

1963年生まれ。1987年、東洋情報システム(現TIS)に入社。同社に17年半勤務した後、システム営業を経験。2005年独立し、ユーザー企業側のITコンサルタントを歴任。現在はIT企業を中心にプロモーションのための文章を執筆するかたわら、自分の価値を高める「自分軸」の発見支援にも従事している。

著書は『SEのための価値ある「仕事の設計」学』、『奇跡の営業所』など。日経SYSTEMSなどIT系雑誌への寄稿多数。

ライターとしてのサイト

自分軸発見支援のサイト



前のページへ 1|2       

Copyright © ITmedia, Inc. All Rights Reserved.

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。