2009年1月29日

「顧客対応」掟と極意153

ITエンジニア必携!顧客対応の掟と極意153  本園 明史 やりたいコトは
膨張する

今のプロジェクト、景気好くポシャってますか?
それとも、デスマーチってますか?

真面目な人ほど、
遅々として進まない案件に関して、
キーっ! となってることでしょう。

本書は、プロジェクトマネジメントに関して、
マニュアルや体系化された方法論から一歩踏み込み、
相手の心理的状態を想像し、「人間模様」に焦点をあて
サンプル事例別に解説している。著者は本園明史さん。

"議事録"は自分とプロジェクトを守ってくれない。
と知っているなら読む必要は無いかもしれないし、
人ごとだと、笑いながら楽しく通読しているだけじゃ、
明日は我が身かもしれない。

ワンマン社長や、わがままクライアントに振り回されている
お疲れの方々にもオススメ。

歴戦のプロマネにとっては、2,280円は高い。
うなずける事例があるものの、
具体的な解決策は出てこないからだ。

だが、経験豊富な者にとって、プロジェクト毎によって異なる状況に、
どうやら普遍的な解など、存在しなさそうだ・・・
ということにも気づいてしまっている。

頻繁に出てくる"システム"という単語は、
それぞれの職種で頻度の高い単語に置き換えられるので、
過去のプロジェクトや、現在進行中の案件に対して、該当する例を発見し
大変なのは自分だけじゃないんだ、という一体感を味わって慰めよう。

逆に、初めてプロマネに就任する人にとっては安い価格だ。
トラブルが発生する前に、モメ事の種類を把握することができるのだから。

どのプロジェクトでも、モメそうな箇所。

  1. 事実認識の誤り
  2. プロセスや手段の相違
  3. 目的レベルでの衝突
  4. 価値観や信念レベルでの衝突

上記のポイントを分析して、
自分と顧客がどの位置で騒いでいるのか把握する。

後で喧嘩にならないように、事前に釘をさしておく
ということを重視しつつ、まとめ。

  1. キーパーソンを探す
  2. やらないコトを決める
  3. なめられない
  4. 覚悟して怒る
  5. ステークホルダーごとの要求を知り、システムの目的に合わせて精査する
  6. 言葉の齟齬を放置しない
  7. 正論で相手のプライドを傷つけない
  8. リクエストは受けるのではなく、検討する
  9. 過剰なサービスを提供しない
  10. "このやり方が正しい"という錯覚に浸らない

ミーティングや、顧客のプロファイリングで活用できそうな小技。

  1. 突っ込まれた部分を切り出して会議化
  2. ラベリングの共有化
  3. 会議での議題の順番を意図的に入れ換える

教訓。

P.67
ベンダのマネジャーはジェット機のパイロットのようなものです。
その飛行機のオーナーがどれほど強く要求したからといって
素人の指示に従ってはいけませんし、
素人に操縦桿を握らせてはいけないのです。

P.79
ワンマンに説得が通じることはまずないと考えていた方がよいでしょう。
正論を言っているのだから一生懸命に説得すれば何とかなるはずだ
と考えるのは甘いと言わざるを得ません。

残念ながらワンマンは
人から説得されることはありません
手は一つです。
事実だけを告げて、あとは自らの判断で
「こちらの思う方」に向かうように仕向けるしかありません。

P.82
ベンダに対して感謝の気持ちも「借り」の感覚も持っていません。

             (~中略~)

 「すみません」「すみません」と常に申し訳なさそうに
しているのですが、

             (~中略~)

最初のうちはベンダも頑張ります。
しかし、頑張れば頑張るほど
顧客は甘えるようになります。

             (~中略~)

顧客第一主義は重要です。
それでも難しい顧客はいます。中にはこちらが
赤字覚悟で提供したサービスにも
まったく満足しない顧客もいます。

要求は膨らむものであり、
ある意味これは仕方のない面もありますが
限度もあります

P.102
顧客の組織文化は実に多様です。
システムに対する考え方も多様です。

したがって「システムとはこうであるべきだ」
「システム開発はこうであるべきだ」
という思い込みを持って顧客に対応すると、
仮にその思い込みが一般的に常識と呼ばれるものであっても、
思わぬ抵抗にあってびっくりすることがあります。

こうした状況こそ、顧客を理解するチャンスです。
常識を顧客に押しつけたり
説得しようとするのは後になってからもできることです。

まずは常識との乖離が
どのような理由で生じているのかを明確にしましょう。

P.155
理屈はわかってもらえたはずなのですが、
最後のYESを言ってくれません
そしてその理由も言ってくれません。

"やりたいこと"の制御

P.134
要件は一般的に「この機能は○○することができる」
というような書き方で表されますが、それと同時に
「○○が達成できれば機能要件が満たされたものとする」
というような機能の要件定義の終了条件
を明確にしておくのです。

警戒心を緩めない。

P.163
顧客は「聞いた」かもしれないが、
「理解した」か「納得したか」はわからない。

             (~中略~)

相手は意味を理解しただけなのか、
それともきちんと内容に納得したのかを、確認するくらいの
用心深さは欲しいものです。

P.187
そもそも見積りというものは、求められている要件、納期、品質レベル
をベースに計算されたものです。
それが交渉によって上下の変動が可能ということであれば、
インプットとなった要件や納期や品質は何だったのか、
ということになります。

交渉によって値引きに応じることは、
自らの見積りの信頼度を否定する行為
と言えるでしょう。

合理性や、正論を、相手の触れて欲しくない部分に突き刺さない。

P.221
どれほど不合理なものであっても、
顧客には顧客にとっての合理性がある。

本編には出てこないが、
インテルの共同創業者、アンディ・グローブ(アンドルー・グローヴ)の言葉は
我々を励ましてくれる。

Only the Paranoid Survive
病的なまでの心配性だけが生き残る

コメントする


画像の中に見える文字を入力してください。