2009年02月03日

[書籍]ITエンジニア必携!顧客対応の掟と極意153

ITエンジニア必携!顧客対応の掟と極意153
著者:本園 明史

 システム開発における下流工程で(属人性を低くする可能性が高い)プログラミングやテストでこの手の本はそこそこあります。
 が、上流工程…特に要件定義における顧客対応にフォーカスした内容で珍しいかなと思います。

 事例紹介のように色々なシーンが描かれていて…そのほとんどが「あぁそういやあるなぁ、それ」というものです…それの対応例が書かれています。

 使い方としては人間相手なので「本に書いていたからこう!」と決めつけるのではなく、あくまで1つの案として、自分なりに都度状況に合わせて対応すれば役立つと思います。

***********************

◆目次
第1章 タイプ別顧客対応の基本
(顧客対応はタイプ別が基本タイプ別顧客対応のポイント ほか)
第2章 組織力学を考慮した顧客対応
(組織ゆえの宿命組織文化の違い ほか)
第3章 日々発生する顧客対応の実践
(日常の顧客への報告、提案、話し合い会議での心構え ほか)
第4章 主体的な顧客対応―プロジェクト推進と顧客満足度向上
(主体的にプロジェクトを推進する顧客と対等に接し、満足度を上げる)
付録 説得のテクニック

◆SEにありがちな「0」or「1」かでラベル付けはしない。
 「AだからB」なようによくある血液型性格診断のようにパターンを決めつけた対応はしないということです。

◆反対屋の質問やツッコミの癖を掴んでおくこと。
 反対屋だけでなく、想定質問は考えておくべきかなぁと。
 それが当たれば良いですし、当たらなくてもそこまで考察していれば答えに深みが出て、それは相手に伝わる(あ、よく考えているな)と思います。

◆一回の説明に納得してもらっても安心してはいけない。
 お客様はそのプロジェクト以外にも、兼務していることが多いと思います。
 そのせいもあってか、同じ説明でも、下手をすると違う結論に持って行かれそうになることもあります。
 しかも悪いことに、そうなる場合、前回(せっかく)検討した内容が漏れていて、誤った結論に辿り着くこともあります。
 その点ではポイントになりそうなところはその決定への経緯までも共有するのも手かと思います。

◆何かを依頼する場合に必ず付け加えるべき情報。
 困るのはプロジェクト関係者全員(決してベンダーだけでない)ということを分かってもらい、変に遠慮して「いつでも良いですよ〜」なんて言わないことです。
 私は「ベストはいつまでに、このレベルで。ベターは…そしてこれがクリアできないと…デメリットは…」と言うことが多いです。
#デメリットまで言うことは余程のことでないと言いませんが…。

◆顧客の意思決定プロセスを理解すること。
 常にボールが今どこにあって、どういう力学が働いてボールが動くのかをウォッチ、アンテナを張ることが大事です。
 これを見誤ると、後で決定事項(と思っていたもの)がひっくり返されたりします。

◆顧客はどこまで理解した上で意思決定しているのか。
 「お客様がそう言ったから…」なんて言っていると「御用聞きSE」なんて言われてしまいます。
 背景が分かれば、お客様が持っていない知識…例えばIT…をベースに(双方にとって)より良い提案ができることも多くあります。
 また、そういう提案をすることで信頼度も上がることがあります。

◆「やらないこと」と終了条件を明確にしておくこと。
 「やらないこと」スコープ外を認識することはとても大事です。
 得てしてお客様の暗黙の要件、仕様が含まれておらず「え?こんな機能がないの?当たり前じゃないの?」となります。
 ただし、ありがちな「…はできません」とネガティブな会話が連発するのは避けて、印象をコントロールする必要があるとは思います。

◆顧客は「聞いた」かもしれないが「理解した」か「納得したか」はわからない。
SE:「言ったと思いますが…」
お客様:「確かに聞いたけどね…(納得はしていないのよ)」

 面と向かって「分かりました?」なんて聞けないので、お客様から「こういうことよね」と聞いてくれたらラッキーですし、そうでなくても自分から切り口、見せ方を変えて確認を取るのが大事かなと。

◆議事録をあてにしないこと。
 議事録は最後の防護線…とは言うものの、議事録を引っ張りだしてお客様と議論しているようでは負け戦かなと思います。

◆正論で顧客を納得させようとしてはいけない。
 お客様と熱く議論になってしまうと、我を忘れてこうなりがちです。
 常に「プロジェクトの目標を達成するために…」を意識するようにしていく必要があると思います。

◆曖昧さを駆使してプロジェクトを進めていくこともある。
 アジャイル開発のように走りながら、作る、仕様を決めるが広まっているとは言え、まだまだ「これを決めないと進めない」(実際にその項目はそうでもない)と強固に主張し、プロジェクトが停滞することがあります。
 大事なのは曖昧にして良い点の見極めと、状態が「曖昧である」ことの共有ができれば良いと思います。

***********************

 顧客対応がない若手には、変な先入観を持ってしまうことかもしれませんが、ある程度の経験があり、次のもう1ステップを…と思うSEには良書かと思います。




posted by yohhatu at 00:16 | Comment(0) | TrackBack(0) | 書籍 | このブログの読者になる | 更新情報をチェックする
この記事へのコメント
コメントを書く
お名前:

メールアドレス:

ホームページアドレス:

コメント:


この記事へのトラックバック