伝える力がなければ優れたエンジニアにはなれない
というタイトルにしてみましたが、そもそも集団活動のすべてにおいて優れた結果は出せないですよね。エンジニアに限った話ではありませんでした(:3_ヽ)_
まぁそれはともかく、エンジニアも優れることはできませんので同じ同じ。
残念ながら一部の個人で成立するクリエイター…伝統工芸の職人などを除き、現代はどんな職業であっても技術が高いだけでは生き残っていけない時代です。とにかくどんなビジネスをするにしても必ず誰かと連携しないとならないからです。
第二次産業までであれば「作る」「売る」さえできればなんとかなる職業もあるかもしれませんが、第三次産業ではそれも叶いません。とにかくビジネスのあちこちに協働や共有、共感が必要になってしまうからです。
私が在籍している業界も、いわゆるＳＩ事業を生業とするＩＴ企業です。
ＳＩ（System Integration）とは
システムを組み上げるために本来お客さまが実施するべき
さまざまな業務のすべてまたは一部を代わりに請け負い、統合することで
大きな付加価値を提供するサービス
のことを言います。
ＳＩ事業を担っているというのであれば、自らの携わっている仕事は「モノづくり」をすることが目的なのではなく、「お客さまの代わりにお客さまの仕事を請け負うサービス」を行うことが目的であって、モノ作りはあくまでそのサービス業務のなかの一部に存在する実現手段の１つと考えるべきなのです。
お客さまの業務を、お客さまの代わりに、お客さまの立場になって請け負う
わけですから、当然自社目線や自分目線ではなく常にお客様の立場に立った『お客さま目線』『相手目線』でなくてはなりません。それができないのであればSIer失格と言ってもいいでしょう。
【余談】
これはSIerに開発業務を委託するお客さま側の立場になられる方へのアドバイスですが…SIerが要件定義、基本設計あるいはシステムテストのテストシナリオなどでお客さまに合意形成を図ることがあると思います。もちろんお客さまの業務における課題解決を行うためにも重要なポイントですので、お客さま自身が「要求仕様通りであるか」「問題がないか」を確認するのは当然の責務だと思います。
ですがもしもそうして確認し、承認・合意した後に問題が発生した場合、次のような事例でSIerがお客さまに責任を押し付けてくるようなことがあった場合は気を付けてください。間違いなくそのSIerは『お客さま目線』『相手目線』というＳＩ事業にとって最重要となるコアコンピタンスを満たしていないことがわかります。つまり、今後も信用してＩＴ投資を委託できる企業ではない可能性があるということです。特に、SIer側の管理職層までが出張ってきて同じようなことをいうようであれば、それは企業姿勢として元々そういう組織だったということです。個人の問題ではなく、そういう判断を下す人を要職に据えることを是とした組織であるということです。
（事例）
シナリオテストにおいてお客さまが確認／合意できるのは「業務シナリオ」のケースパターンのみである。そのケースの結果としてシステムがどのような挙動をするかについて、そのテスト仕様はSIerが当初の要求仕様をもとに明らかにし、保証しなくてはならない。このなかで、お客さまの領分を超えて自らが保証しなければならないシステム挙動に対し「お客さまが合意されたので」という理由でお客さま側に責任を押し付け、あまつさえ請求までしようとする。
このようなSIerであれば、その場をどうするかはともかく、以降は二度と委託しないほうがいいかもしれません。
さて、少し脱線してしまいましたが、エンジニアとしてはもともと持ち合わせている高い技術力に「伝える力」が加われば、間違いなく開発業務のパフォーマンスは大きく改善されます。
そもそも１つのスキルをそれなりにつぶしが利く状態にまで昇華させるのは至難です。特にＩＴ業界の進歩はすさまじく、１～２年放置しているとあっという間についていけなくなることもしばしばです。にもかかわらず１点集中型で「限られた技術」だけを追い求めようとする人は後を絶ちません。
先述の通り、ＳＩ事業において「技術」とはビジネスを成立させるための要素のごく一部でしかありません。単純な技術以外にもサービス業務のなかには要求されるスキルはたくさんあります。
「技術修得」は、
ビジネス成功のための必須条件ではあっても、
十分条件にはなりえない
ということを改めて知っておきましょう。それだけで満足しているとビジネスは成立しないのです。
「エンジニアは技術が本業だから、話が下手でも大丈夫」
もしかしたら、こんなふうに考えていませんか。
でも、これからの時代、技術力だけでエンジニアは生きていけるのでしょうか。
すでに何年も前から言われていることです。
二昔前であれば、エンジニアは技術が高ければそれだけでよかったかもしれません。製造業のような表舞台に立つことのないエンジニアであれば、それでも成立するでしょう。
しかし、ＳＩ事業を担う以上は技術の高さや価値を適切に伝えることができなければ生き残っていけない時代です。
情報を論理的に正しく話しても、伝わらないということはよくある話です。
「伝える」ではなく「伝わる」でなくてはならないのです。
たとえ話の筋をきちんと組み立てたとしても、高圧的で気まずい会話になってしまい相手を怒らせては元も子もありません。「弁が立つ」ことと「伝わる」か否かはまったく別物です。
口先だけの弁が立っても、相手の反感を煽っていては正しく情報が伝わることなく、偏見や歪曲したものの見方をされることもしばしばです。よくて論破できる程度です。そこで自満足できたところで、より関係性にヒビを入れることが精いっぱいではないでしょうか。
エンジニアリングだけできていれば仕事が成立すると思っている人の話し方は、常に自分の中にある『正しい意見』を認めてもらうための会話をしようとします。それも自分が『正しい』と思い込んでいる論理を持ち出しているにすぎません。相手にとっても正しいわけではないのですから。
そのため会話は相手との戦いであり、会話は最初から対立しています。
だから変にプライドが助長され、相手との公的な会話において「勝った」「負けた」の心理が働きやすくなります。そしてそのせいで会話相手の精神に必要以上に軋轢を生むことが多くなります。
所詮、エンジニアの持つ主観的な話し方は正しいことを「正しい」と言っているだけで、お客さまのビジネス課題を解決しようとしているわけではありません。
それは、
「技術というものには答えが１つなのだから、他に伝え方はない」
という考えに基づいているのでしょう。
ゆえに相手を攻撃して傷つけ、不満を持たせているという自覚がありません。「正しいのだから相手が納得するべきで、そうでないなら相手が悪い」という発想になってしまっています。決して悪意があるわけではないからこそ、無意識のうちに周囲にとって害となるケースが多くなるのです。
もちろん、そのような答えが唯一解（真理）であるはずもなく、実際にはところ変われば回答も変わるようなケースは決して少なくありません。
これでは、コミュニケーションの本質
「正確に情報が伝わる」
「正確な情報を共有する」
に反する結果になるのも当然です。
適切な伝え方をしているとは到底いえないでしょう。
会話というものはその内容を通じて相手を信頼し、本音を話せる状態になると考えがちです。
しかし、最初に相手を信頼して本音を話せる状態になってから会話の内容を伝えるということもできます。その鍵となる手法が"ラポール"です。
ラポールとはフランス語で「かけ橋」という意味があり、臨床心理学では「信頼関係」と言う意味合いで用いられる言葉です。カウンセリングでは、セラピストとクライアントの相互信頼が重要になってきます。
本音で話す状態を作り出すラポールは、日常生活においても活かすことができそうです。
そもそも、会話は仲がいい状態でスタートしようとすることが重要です。
私のようにトラブルプロジェクトの解決ばかりで、初めて会ったお客さまはいつも怒髪天の状態からスタートするのはごく稀です。１からビジネス（プロジェクト）を開始するのであれば仲がいい状態を構築してすすめるべきです。
本題に入る前に意見が対立しない話題を意図的に作り出し、あなたと私は「同じ」であると伝えることは30秒もあれば十分です。「同じ」を見つけて口に出し、心を許して話してもらうラポールを築く。説明を始めるのはそれからです。
実際、私がソフトウェア開発においてトラブルが発生しているプロジェクトの解決にあたる際に、お客さまのところで孤軍奮闘するような際にも必ず取り入れています。
たとえば、私は（私が起こすわけではありませんが）トラブルが起きた時、そのトラブルの解決のためにお客さまのところへ初めて訪問する際、まず絶対にそのトラブルそのものに対して
謝罪しません
（別に悪びれないというわけではなく）
それをお客さまが望んでいないからです。
炎上中のプロジェクトにおいて、その解決のために参画してきた人間に対してお客さまが心底求めているのは『早期解決』です。一分一秒でも早く問題を解決し、元々契約にて取り決めていた期日までに仕上げる、あるいは遅延被害を最小限に食い止めることが求められています。
「申し訳ありません」
「すいませんでした」
たった数言ですが、そんな１銭の価値もない妄言を吐いている暇があったらその時間分、解決に注力した方がお客さまのためになりませんか？
安易に謝罪する人は自己保身意識が強く、無意識に贖罪を求めているにすぎません。
「謝ったらお客さまは留飲を下げてくれるのか？」
「土下座したら、問題は解決するのか？」
答えは"No"です。
最短で解決する以外にお客さまは何も望んでいません。
もちろんそれで留飲を下げてくれて物事が解決するのであればいくらでも謝罪しますし、仮にそうならなかったとしてもお客さまが無駄な時間を費やして「謝罪しろ」といえば謝罪します。しかし、いつもお客さまは口をそろえて
「で、どうするのか説明を聞こうか」
と言ったことを求めます。そう、このトラブル状況をどう打破するつもりなのかを聞いているのです。決して謝罪を聞きたいわけではありません。
でも、なぜか謝る人は後を絶ちませんし、謝ったところで何一つ進展しません。
すべてが解決した後に迷惑をおかけしたことを謝罪するのであればまだしも、何一つ解決していないうちから謝る行為に走る人というのは「謝ったら多少なりとも許してくれるかもしれない」という自己都合を前面に押し出しているにすぎません。SIerとしては風上にもおけない行為ですよね。これはそもそも"ラポール"を理解できていないからに他なりません。
ラポールを構築するための順番は
① ⇒ ② ⇒ ③
ぺーシング⇒ラポール⇒リーディングという順番で行います。
コミュニケーションを繰り返す時に注意しべきは、ペーシング80%・リーディング20%を意識すること、それだけです。ペーシングとは、「ペースを合わせること」「同調すること」…つまり相手目線になることです。リーディングとは、読むことではなく「リードする」…つまり導くことです。
コミュニケーションをとる時間のほとんどがペーシングです。他にも、
相手の行動や表情など、同じ動作をすることで仲間意識や親近感を与える
相手の話をオウムのように繰り返すことで理解してくれているという安心感を生み出す
ことなどもペーシング以外の方法として信頼関係を築くために有効です。
そして信頼関係が構築されたかどうかは相手のある行動から読み取れます。
それは
「任される」
ということです。
上司から、お客さまから、様々な関わりのなかで「まかせたよ」「頼んだよ」と言われること。そのために権限を委譲されたり、「何かあったら何でも言ってくれ」と協力姿勢を整えてくれたりすることです。
トラブルの解決であれば、進め方や対策案を説明したうえで
「じゃあそれでお願い」
と言われることです。信頼関係が出来ているということは相手のことをよくわかっているということであり、細かい説明はしなくても安心できるということに他なりません。
簡単に言うとこの「おまかせ」の状態が信頼関係が出来ているということになるわけです。逆に、この「おまかせ」ではない状態が信頼関係はまだ無いという状態だと考えればいいでしょう。
もちろん信頼され「おまかせ」された以上は、その信頼や期待に応えられなければその反動は大きくなります。そう、リバウンドです。その信頼や期待に応えられないのであれば、これからの時代はエンジニアであり続けるのはどんどん難しくなっていくのかもしれません。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。