第3回 気まずい雰囲気を醸し出す間違いだらけのヒアリング
顧客の要望を聞き、問題点を発見し、その解決策を提示する提案営業では、営業担当者のヒアリングの能力が成否を大きく左右する。しかし、その能力が不足している営業担当者が少なくない。今回は、ヒアリングをする際の注意点を紹介する。 システムの営業では、契約にこぎ着けるまでに時間と労力を費やさなければなりません。その一方で、ソリューションプロバイダの営業担当者はたくさんのお客様にアプローチするように求められています。時間とエネルギーが限られている中で、できるだけ受注の確率を高くする必要があります。 では、どうしたら成果に結び付く確率は高くなるのでしょうか。私が悩んだ末に達した結論は次のようなものです。「提案する内容は、お客様の事業を反映したものでなければならない。それから、お客様にも参加してもらい、力を合わせて課題や問題を抽出して解決策を考えていこう」。 提案書は営業担当者が書かなければなりませんが、
質問するからいけない～質問せずに質問攻めにするには？
■商談や開発の打ち合わせで重要になるのがヒアリング。上手なヒアリングのためには、質問力を高めなければいけません。質問力を高めるための具体的な方法論として、今回は相手が心地良く思う質問のやり方を紹介します。 ヒアリングとは「質問攻め」とも言える。 前回のお話のように医師の問診であれば、聞かれる側に目的があるので、少々ぞんざいな聞き方で質問攻めにされても問題はない。警察の尋問も基本的には同じだ。 しかし、商談などのヒアリングでは、聞き手はあくまで協力してもらう立場だ。質問攻めにして、こちらの聞きたいことを何でもしゃべってくれるとは限らない。 相手から情報を引き出すときに、必要なのは、聞かれる立場として心地良いかどうかと、答えることで報酬があるかどうかだ。 質問攻めにしながら、心地良いとは、質問攻めと思わせないことだ。すべての質問が、「～ですか？」という質問句だと、尋問のようで心地良くない。聞き
顧客の真の課題をつかむヒアリングと課題形成の技術
「顧客に課題を聞いても教えてくれない」「十分なヒアリングができないまま、提案するだけに陥っている」「ヒアリングで肝心なことを聞き漏らしてしまう」「顧客のリクエストに応えているのに、提案に魅力がないと言われてしまう」――。このような悩みを抱えた営業パーソンのために、現場で使える「ニーズ把握の道具」をご紹介しましょう。 ソリューション営業のプロセスでは、顧客とのリレーション構築の次は、「ニーズ把握」のプロセスです（図1）。顧客との十分なリレーションができていることが、ニーズ把握の前提になります。営業の現場では顧客との良好な関係ができていないということも少なくありませんが、顧客とのリレーションがある程度構築できているという前提で、話を進めることにします。 ニーズ把握にはヒアリングと課題形成 ニーズ把握プロセスで営業パーソンが担う中心的な役割は、ヒアリングと顧客の課題形成です。その役割を果たすため
上流工程の問題解決 見積もり編【前編】
見積もりは手法こそ整備されてきたものの，精度を上げるのが難しくなってきた。現場担当者が疑問に思う七つの問題を取り上げる。 問題＆解決 根拠なくして納得感は得られない 「こんな見積もりはのめない！」。味噌メーカー，マルコメの役員はあるシステム開発プロジェクトの会議の席上，決断を下した。販売/生産/財務など基幹システム再構築を発注していたベンダーとの契約を打ち切り，改めて他ベンダーを探すことになった。 プロジェクトは既に要件定義を終え，設計工程に入ろうとしていた。ここで最初に開発を発注していたベンダーが「最初の見積もりではできません」と，当初とはまるで違う再見積もりを通知してきたのである。 当初の見積もりと再見積もりの乖離幅は2倍以上。発注時に4社から相見積もりを取り，最も安価なベンダーに発注した経緯があるだけに，後になって2倍超ものコスト上積みなどとうてい受け入れがたいものだった。 現場の指
SEのための提案力強化講座【第4回】
今回は，ユーザー企業が納得する提案書の作り方を解説する。ITエンジニアが起こしがちな失敗事例を具体的に挙げつつ，顧客を論理的に最適解に導くデシジョン・テーブルの作成方法を伝授する。 提案書はITベンダーのビジネスの中で大きな意味を持つ。顧客が抱える問題や課題を事前に収集・分析し，自社の提供する商品・サービスに適合するかどうかをビジネスと技術の両面から検討，解決策を導き出す――これがITベンダー側の視座から見た提案活動の基本である。提案書は解決策を集大成したものであり，その内容は顧客の期待と興味を喚起するものでなければならない。 そうでなければ顧客の意思決定，つまり受注には結びつかない。これは顧客がITベンダーに提案を要請した場合でも，ITベンダーが積極的にアプローチして提案した場合でも同じである。 せっかく苦労して提案書を作っても，受注に結びつかなくては報われない。訴求力と魅力のある提案書
意図が伝わる設計書作成の心得【第4回】
「仕様書」は，設計者とプログラマをつなぐ重要なコミュニケーション・ツールだ。それゆえ，安易な書き方をすると問題を起こす。よく議論されるのは，「仕様書の内容はどこまで詳しく書くのが適当か？」という点だろう。過剰品質を避け，効率的に書きたいところだが，きちんと意図が伝わることが大前提である。二つの実例を通して，そのキー・ポイントを紹介する。 今回から，題材を「仕様書」に移して設計書作成の心得を紹介していこう。 前回までは，ユーザーからの要望聴取を基に作成する基本設計書を題材として，設計者とユーザーとのコミュニケーションを軸に展開してきた。これに対し，今回から取り上げる「仕様書」は，基本設計書を基にシステムを実装するプログラマやSEに対して，より具体的なシステムの詳細を伝える設計書である（図1）。 このような設計書は「詳細設計書」や「プログラム仕様書」など，様々な名前で呼ばれていることと思う。ま
第2回 Webプランニングをするためのチェックポイント
顧客候補の「ど真ん中」のタタキ台を提案するには，Web開設による達成目標や，開設目的を明確にしておく必要がある。初回面談のノッケから「外してしまう」と，顧客を振り向かせることは厳しくなってしまう。営業力で修復しようとすればするほど，すれ違うこともあるから，とにかく初期の段階で「外さない」ことが肝心だ。 達成目標や開設目的をおさえて，タタキ台を作成しよう 達成目標や，開設目的によって，最低限外してはならないチェックポイントは異なる。下記の表にリストアップしてみた。 例えば，顧客候補が新たな取引先確保や，公共の助成金申請等にあたって，プレゼンテーション用のWebサイトを一時的に開設することがある。プレゼンテーション用Webではインパクトが最重要だ。ところが，会社設立や事業所および営業所開設の告知のためのWebサイトでは，インパクトは誠実な姿勢を妨げるもので，むしろ邪魔になる。 情報伝達のための
意図が伝わる設計書作成の心得【第3回】
効率よく，ユーザーと必要十分な打ち合わせをしたつもりでも，基本設計書に大きな“抜け”が生じることがある。システムの目玉機能ばかりに目を奪われたり，設計者が補って考えるべきところで手を抜いたりするためだ。設計書の“抜け”がどうして生まれるのか，それを防ぐにはどうすればよいかを，よく起こりがちな二つの実例を通して考えてみたい。 いざ基本設計書をレビューしてみると，システムのある部分に関する重要事項がすっぽりと抜け落ちていた――。 このような話は，システム開発の現場でしばしば耳にするのではないだろうか。図1のように，システムの構築に欠かせない重要な事項が，なぜかユーザーからも設計者からも指摘されないことがあるのだ（あるいは指摘されながらも議論が不十分なことがある）。こうした状況で基本設計書を作成しても，その通りに作るとシステムは意図通りに動かない。 問題が表面化すると，基本設計書の“抜け”に対す
Part 2 失敗しないCMS導入ワークフロー：ヒアリング、プランニング | 成功するCMS導入の必須ノウハウ
失敗しないCMS導入ワークフロー 多数の導入経験で磨かれた手順と設計書 ページではなく“コンテンツ”を管理前置きはこのくらいにして、CMS導入に関する流れを説明しよう。スリーイントでは、CMS導入において以下のようなワークフローを使用している。これはCMS導入が“システム構築”という面を持つ一方で、システム系とはまったく関係ない“コンテンツ管理という”面を持っている非常に厄介な仕事だからだ。順序だててきちんと進めなければ、成功し得ないプロジェクトだといえるだろう。 CMSが単にウェブサイトを管理するものだと考えているならば、このプロセスは必要ないのかもしれない。なぜならば、現状のウェブサイトを管理しているのはウェブマスターであり、ウェブサイトについてはほぼすべてを熟知しているからだ。システムを構築するベンダーとウェブマスターとの間で設計をして構築すればいいだろう。しかし、これによって何が構
SEのための提案力強化講座【第2回】
提案で重要になるのは，まず顧客がなぜ提案を依頼しているのか，理由をきちんと押さえることだ。 提案を行う局面は2通りある。1つは提案者側からの働きかけ，つまり計画的かつ能動的に提案する場合。もう1つは，顧客からの働きかけによる受動的な提案の場合である（表1）。 顧客からの働きかけによる受動的な提案は，さらに依頼の理由が分かれる。 1つは，顧客がシステム導入を検討する中で，専門家の意見や判断を参考にしようとしているケース。例えば，見込み客としてはみなしていなかったユーザー企業から，「今，当社で次期システムのあり方について検討中ですが，専門企業である御社から提案していただけませんか」というような提案依頼が来た場合が相当する。 もう1つは，ユーザー企業である程度の検討は終わっているが，検討結果の検証のために提案を依頼されるケースである。 いかなる局面であっても，顧客の依頼の目的を明確にすることが，
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「うちの部下は自発的に仕事をしない」 この悩みに答える（後編）：NBonline(日経ビジネス オンライン)