Posted on

クライアントフェイシング ~ ITエンジニアのコミュニケーションに違和感 ~

常に下から接する人、一方的に説明する人、辛さばかりをアピールする人、日常ではあまり見かけない人達がシステム開発の現場では多くいます。業界特有なのかITエンジニアにありがちなのかは分かりませんが、とても不思議です。
クライアントフェイシングとは、外資コンサルで使われる言葉で、クライアントと対峙する行動を示します。簡単に言えばクライアントとのコミュニケーションですが、システム開発の現場で見かけるクライアントフェイシングは、違和感の宝庫です。

会話をしようよ

「この機能について説明します」「何々と考えています」「このように進める想定です」・・・沈黙。
「でっ?」というユーザーの心の声が聞こえてきます。
なぜITエンジニアの多くが、クライアントに対して一方的な”説明”をするのか不思議でしかたありません。誰かから教えられたのか、伝統芸能のように脈々と受け継がれてきたのか。
知りたいことを説明してくれるなら嬉しいけれど、知りたいと思っていないことを長々と説明されたら迷惑なだけです。クライアントの心が知りたい状態になっているか、そこを理解していないとコミュニケーションは出来ません。雑談から入ったり、導入で気になることを言ってフックしたり、いきなり問い掛けから入ることだって相手の状態によっては有効です。考えてきたことを伝えたい気持ちは分かりますが、ビジネスにおいては何を伝えるかよりも何を引き出すかが大切です。
馬鹿の一つ覚えのように常に一方的な”説明”ではなく、双方向で”会話”をすること、もっと言ってしまえばクライアントに多く話してもらう方が良いコミュニケーションです。

会社員エンジニアが昇進するために必要なことは技術力よりも他にあり、そのひとつが会話だと思っています。説明が上手な人は、いわゆる作業者エンジニアで昇進できずに停滞しがちです。管理職へ昇格するエンジニアは、会話することができ、クライアントから言葉を引き出すコミュニケーションができる人です。

3つのトークルール

プライベートでは当たり前に会話が出来るエンジニアが、仕事でクライアントと話すとなった瞬間に説明一辺倒になってしまうのは残念で仕方ありません。分かりやすい説明ができる、端的に回答を言えることも必要なコミュニケーション能力ですが、いくら説明がうまくても会話ができなければ発展はありません。
プロジェクトで現場のエンジニアに伝えている会話のコツは選択肢・論拠・短くの3つです。


①選択肢
唐突に北海道の話を始めたら、何の話?ってなるのは当然です。友達を旅行に誘いたいなら、海と山のどっちが好きか、暖かい所と寒い所のどっちが、車か電車か飛行機か、肉と魚なら、などいろいろ聞いていって目的地を絞り込んでいくのが普通の会話です。
会話と説明の決定的な違いは、選択肢があるかです。


②論拠
クライアントだろうが、マネジメントだろうが、コミュニケーションの仕方はプライベートと何ら変わりません。
日常会話と違うのは丁寧に語ることだけで、ビジネスにおける丁寧とは論拠を言うことです。「量が多いので」「過去にこういう難しさを経験しているので」など、なぜそのように考えたのかの論拠が、説得力あるいは突っ込みどころとなって双方向のコミュニケーションを発展させてくれます。


③短く
説明ができる人と会話ができる人は違います。説明ができる人は、一歩間違えると話が長くなってしまいます。「それと」「ちなみに」「ただし」のような接続詞の連投は、お坊さんのお経のように心に染み渡る以前に理解できずに眠くなります。

クライアントは神様

お客様は神様ですと誰が言ったか知りませんが、そんなことはありません。理不尽な対応をとる客が神様であるはずはないし、ビジネスとしてどう稼ぐか決めるのは客ではありません。
システム開発の現場では、右に倣えの如く皆一様にクライアントが上位でベンダーが下位の関係性でコミュニケーションをしています。クライアントにも「どうなっているんだ?」と常に上から目線の人もいますが、その発言の背景も考えずに「ごめんなさい、頑張ります、なんとかします」という、下から接することが絶対的なルールと勝手に思い込んでいる開発ベンダーのエンジニアも多いです。
発注者と受注者の関係からこのパワーバランスになるのも理解は出来ますが、システム開発においてはクライアントが出来ないことを代わりにやってあげてるとも言えるので、対等あるいは協力関係というのが正しい理解です。
「この案件から手を引きます」という切り札を開発ベンダーは持っていても良いのです。この切り札をチラつかせるのはギャンブル同様にテクニックが必要ですが、いざベンダーに手を引かれて困るのはクライアントということを頭にいれておいて損はありません。
パフォーマンスをそれなりに出しているベンダーであれば、クライアントも良好な関係性を維持しようと考えるはずですし、駄目なベンダーであれば、もっとドライなやり方でとっくに変えられているはずです。神様扱いを貫き通したところで結果がよくなることはなく、次の契約があるかは成果次第です。

ベストを尽くす

「絶対に治します」とは口が裂けても言ってはいけない設定で、患者の親族と医者がせめぎ合うシーンを医療ドラマで良く見ます。
絶対がないのはシステム開発も同じです。極論言ってしまえば、あらゆる技術に絶対はないと思います。相当なコストと期間をかけて安全に配慮した設計とテストを繰り返したとしても、自動車でもリコールは起こっています。
窮地に陥った患者の親族と同じように、クライアントが絶対と言って欲しい気持ちは理解できますが、無理なことを「わかりました!」と言ってはいけません。絶対はないのですから、冷静になって「絶対はありません」「可能性はこれくらいです」「ベストを尽くします」と言ってあげましょう。そしてその言葉通りベストを尽くした行動をとることが大切なのであって、結果はあくまでも結果です。

時に演出も大事

実際に経験したことがない人にとって、システム開発の大変さを理解するのは難しいと思います。何が大変なのか、なぜこんなにもお金がかかるのか、この理解のギャップは埋めようがありません。クライアントのユーザー部門が理解できないのは当然ですが、IT部門にも理解の無い人がたまにいます。このような人達に大変さを説明したところで絶対にわかってもらえませんが、大変なことと認識してもらうことは出来ます。
早朝にメールを送る、寝ぐせスタイリングで打合せに参加する、ピラミッドのようにリポDの空き瓶を机に並べておく、このようなくだらない行動や状況を見せることも大変さを認識してもらうためには有効です。金曜日の19時にユーザーとの会議が終わる際「開発メンバーは、この後も少し残ってください。今週末の作業について話したいので」と、あえてユーザーの前で言うのも効果的です。何が大変かはわからないものの、週末作業になるくらいやってくれていることはユーザーに伝わります。システム開発の現場では、辛そうにしている人が多く、それを見て「大丈夫?」とクライアントから言われることもありますが、「大丈夫?」と言われるよりも「頑張ってるね!」と言われるほうが励みになります。
嘘の演出は駄目ですが、事実であれば隠す必要もなく、伝えるのであれば辛さではなく頑張りにするべきです。会話だけがクライアントとのコミュニケーションではありません。

まとめ

若い時は、クライアントとの関係性について考えることなく、ただひたすら仕事に向き合っていました。経験を積み責任あるポジションになってきた時、クライアントが出来ないことをやっているのに、なぜ文句ばかり言われなければいけないのかと不条理に感じはじめ、いつしか「じゃーこの契約が終わったら次工程の契約はやめましょうか」と平気で言えるようになってしまいました。
ただ、このように言う相手は理不尽なクライアント担当者だけで、そのような人たちは大抵ビジネスを理解していないビジネス赤ちゃんです。上司の評価を一番気にしているビジネス赤ちゃんは、上司へ報告しないといけない状況を作りだされると、とたんにビビッてしまいます。高圧的にくるビジネス赤ちゃんには、対等な立場で本当の気持ちを言ってしまいましょう。実際にこの発言によってプロジェクトが止まることはないし、止まるようなら、それは現場の知らぬところで止める動きが進んでいたということです。

長丁場となるシステム開発においては、相手の気持ちや感情を探りながら進めていくより、正直に伝えて、お互いでどうするかを考える方が良い関係性だと思っています。

出典:柴田秀夫@ARAKADO※転載は筆者承諾済