2017年10月22日日曜日

相手を説得するときにやってはいけない8つのこと

The 8 worst things you can do to try and convince somebody:

 今回はUXデザイナーのPaul Boag氏の記事を元に、デザイナーが顧客を納得させようとするときのアンチパターンを紹介したいと思います。実は、Boag氏が言われるアンチパターンは、自分たちソフトウェア開発者の場合もほとんどそのまま当てはまることに驚きました。

 自分の場合、電機メーカーに属する開発者ですが、SIの立場で顧客との打合せに出る場合もありますし、開発者の立場で自社内の事業部門の人との打合せに出ることもあります。どちらの場合も、お金の権限を持っているスポンサーは相手側ですから、自分が思う「こんな素晴らしいソリューション」を相手も「いいね、それ!」と言って賛同してもらう必要があるわけです。そうしないと、受注がもらえないとか、開発予算を取ってもらえないということになってしまうので、ある意味開発者も自分の考えを売り込む営業が必要なのです。というわけで、Boag氏の言われるアンチパターン8カ条はこんな感じです。

(1)相手を驚かせる
 誕生日のサプライズプレゼントなら喜んでもらえるでしょうが、人は仕事上で驚かされることは嫌いなものです。クライアントは、途中のプロセスを見せてもらえずに突然最終形が出てきて「どうですコレ、素晴らしいでしょう!」とやられても、戸惑うばかりなのです。そして、そんな戸惑いがマイナスのバイアスとなって、たとえいいものでも「こんなものダメだ!やり直し!」という理不尽に繋がってしまうのです。
 ところが、デザイナーも開発者も根は芸術家というかアーティストなので、苦労して悩んでいる姿をクライアントに見せたくない性質があります。昔、音楽プロデューサーの小室哲哉氏が、作曲を依頼されたときに、裏では徹夜作業で苦悩したにも関わらず、いかにもあっさりと作ったかのように、納期をずっと前倒してクライアントを驚かすのが好きだと言われていましたが、まさにソレです。芸術家やアーティスト系の職種の人って、コレやってしまいがちなんです。

(2)相手を排除する
 デザイナーも開発者もその道のプロですが、クライアントは素人です。しかし、クライアントもデザイナーや開発者と一緒に仕事している(つもりでいる)わけですから、出されたものを丸ごと受け入れることには抵抗があり、彼らなりの意見や提案をしてきます。つまり、デザイナーや開発者が途中プロセスをクライアントに見せてそこまでの成果の承認を取ろうとしても、クライアントはこのデザインはインパクトがないとか、この画面はなんだか使いづらそうとか、素人的な意見や提案を出してくるのです。
 それはいい意味でプロの盲点を突く意見や提案の場合もありますが、多くはプロから見ると取るに足らないものなので、ついついクライアントの意見をおざなりにしてしまいがちです。そうすると、クライアントは排除されていると感じ、必ず怒って不満を募らせます。結果的に、デザイナーや開発者が主導権を取るのを阻止しようとする強力な抵抗勢力となってしまいます。

(3)相手のアイデアを拒否する
 相手の出したアイデアが自分の視点からはナンセンスだと思える場合、却下するのが当然と思うかもしれませんが、無下に却下するのは考えものです。自分のアイデアがいつも却下されていると感じた人は必ず不満を募らせ、あなたが何かを達成しようとするとき強力に抵抗してくる可能性があります。たとえレベルの低いナンセンスな意見であっても、それなりに考慮に入れる "フリ" をすることはとても重要なのです。

(4)相手の意図を無視する
 皮肉なことに私たちは、最終ユーザーの気持ちを理解することには大きな労力を割く一方で、同僚や上司・クライアントを理解することにあまり力を入れません。スポンサーであるクライアントにはまだ注意を払うでしょうが、同僚や上司に関しては自分の味方だと思ってしまいがちです。ところが彼らの意図を無視し続けると、不満が溜まって敵側に寝返ってしまう場合があります。クライアント・同僚・上司などあらゆるステークホルダーが、どのくらいの不満を貯めているかを推し量り、爆発前に適宜彼らの意見を聞く姿勢を位せることはとても重要です。

(5)相手に実物を見せずに伝える
 人は合理的な決断をしているように装っていますが、実際のところほとんど感情で動いていると言って過言ではありません。そして、感情を動かすための最もいい方法の1つは、実物を見せることです。
 デザイナーの場合は途中のラフスケッチでそれに代えることができますが、開発者の場合は実物を準備できず仕様書などで確認しようとします。しかし、クライアントに対して文章で書かれた仕様書だけで承認を得て実物確認をさせないと、クライアントは最終形をイメージできないまま承認を与えた形になり、最終形に対し(1)と同様こんなはずじゃなかったという感情を抱きます。
 開発者はクライアントが承認した仕様書通りだと言い張り、クライアントはこんな最終形だと分かっていたら承認しなかったと言い張るでしょう。冷静に考えれば開発者の言い分の方が正しいのですが、不毛な争いを生む結果は互いに不幸なだけですので、できるだけモックアップやプロトタイプで実物をイメージしてもらう努力を怠ってはならないのです。

(6)相手の自由なフィードバックを求める
 正直なところ、クライアントや同僚・上司が自由にフィードバックをしだすと、上手くいかなくなることが多いです。というのも、彼らはデザイナーや開発者が本当に欲しいフィードバックとは全然違う、個人的で感情的な話題で腹を立てがちだからです。
 ですから、「どう思いますか?」というような漠然とした質問でフィードバックを求めてはいけないのです。自分の経験上、設計レビューなどでソフトウェアのアーキテクチャを説明して「どう思うか」といった曖昧な質問でフィードバックを求めたとき、技術的な意見を出せない人たちは「そもそもこんなの売れるんだっけ」とか、全然的外れな意見をさも得意げに出してきて辟易したことがあります。そうではなく、意見をもらうときはフィードバックの幅を狭めて「これはユーザーのニーズを満たすか」といった聞き方が重要なのです。

(7)相手に反論する
 誰かを説得しようとしているとき、いつの間にか議論になってしまうのは最も避けなければなりません。その会議に他の出席者もいて、一対一でない場合は特に気をつけなければならないのです。この手の対立は、最初は対象がはっきりしていても、徐々にその対象から離れ感情のぶつかり合いというかエゴとエゴのぶつかり合いになってしまいます。
 特に説得しようとする側よりも相手側が権限を持っている場合、いくら説得力があって論理的に正しい主張をしても、相手側は自分たちの権限に盾突いていると捉えてしまい、感情的に拒否反応を示すことになるのです。権限がある人は、相手の説得に100%丸め込まれたところを他の出席者の前で示すのは、感情的に嫌悪感があります。どんなに理不尽で感情的なことをしてでも、生意気な相手に一矢報いようとしてくることがあるのです。
 したがって、権限を持つ相手を説得しようとして反論が出た場合に、さらにそれにかぶせる反論を出してはならないのです。一旦相手の意見を受け止め、考える時間が必要だと言って相手を立てる心遣いが必要なのです。そして他の出席者がいない、相手が受け入れやすい状況で個別に再度説得をするのです。そうすると、あのときは他の出席者の手前簡単に受け入れることはできなかったがアイデアそのものは素晴らしなどと、態度を軟化してくれるケースも多いでしょう。

(8)一度に大きな要求をする
 私たちは同僚やクライアントに、仕事のやり方を変えたり仕事を依頼したりといった、相手にとって不快なことを要求しなければならないケースも多々あります。しかし、人間は負担が大きすぎると感じると、見て見ぬふりをして問題が存在しないかのように振る舞うことがあります。キャパシティに対して問題が大きすぎるとき、少しずつ解決しようとはせず、もう考えることすら拒絶してしまうのです。
 そこで、同僚やクライアントに大きな決断を下したり、重要な変更を一度に行うように求めることは避けなければならないのです。相手のキャパシティを見ながら、変更や決定をいくつかに分けて、より小さくより管理しやすい形にして時間をかけて提示するのです。

 Boag氏のアンチパターン8か条、デザイナーに向けて書かれたものですが、自分たちソフトウェア開発者にもそのまま当てはまることがよく分かります。全ての項目に共通しているのは、人間は決して理性的な判断を下すのではなく、感情的な生き物だということを忘れないようにせよということです。いかに説得力があって論理的に正しい結論を提案していても、感情的に嫌悪感を抱いている相手には決して納得してもらえません。どんな小さな揚げ足を取ってでもひっくり返そうとしてくるはずです。

 デザイナーやソフトウェア開発者のような専門職でアーティスト系の頭脳を持つ人たちは、人間の「感情」に対する注意が弱い傾向があり、結果的にクライアントや同僚・上司とうまくやるのが難しい人が多い気がします。人は論理や理性では動きません。人が動くのは感情によってだけ。だからこそ、クライアントや同僚・上司を説得しようとする場合、相手の「感情」にさえ注意し、相手が今どう考えているか好感を持ったか嫌悪感を持ったかをカウントしてコントロールすることさえできれば、承認をもらいたい成果物や提案の論理的正しさなどは二の次なのです。

0 件のコメント:

コメントを投稿