各国から優秀な人材が集まるグローバル企業では、コミュニケーションの“常識”が日本人の感覚とズレることも多々ある。米マイクロソフトの現役エンジニア・牛尾剛さんが一流エンジニアたちとのチームで学んだコミュニケーションの極意について解説します。

※本稿は牛尾氏のベストセラー『世界一流エンジニアの思考法』から一部抜粋したものです。

◆◆◆

「たくさん情報があっても消化できないだろう？」

　アメリカで発見したのが、対クライアントでも社内でのやりとりでも「脳の負荷を減らす」端的なコミュニケーションが喜ばれるという事実だった。

　とくにエンジニアの人には「情報が少ない」ほうが好まれる。たくさん情報があっても消化できないだろう？　という感覚。それはプレゼンテーションや会議に限らず、日常業務のコミュニケーションでもそうだ。

　最初、私はそのカルチャーがまったくわからずに右往左往した。日本ではコンサルタントとしてプレゼンは上位評価を受けていたし、話でお客さんを惹きつけるのも得意だったから、コミュニケーションスキルに自信をもっていた。ところが、アメリカに移住すると、これが死ぬほど通用しなかった。最初は英語力の問題かと思ったが、そうではない。

　どうやら私の話は盛りだくさん過ぎて、「わかりにくい」ようなのだ。

　日本では「情報が多い」と喜んでもらえるので、もちろんわかりやすく整理したうえで、相手が知りたそうな情報は全部盛り込んでいた。例えば聴衆を前に技術プレゼンをするときにも、初心者も上級者も「来てよかったなー」と思えるよう、ドキュメントからサンプルアプリケーションまで用意して、しっかり「お得感」を感じてもらえるようにしていた。総じて、日本で評価の高いプレゼンテーションでスライド枚数の少ないものはまずない。

たくさん書いて送ると無視されて……

　同僚とのコミュニケーション一つとっても劇的な違いがあった。

　例えばCI（継続的インテグレーション）のパイプラインが突然エラーで落ちて原因がわからないとする。日本だったら、「こんなエラーメッセージが出て、バージョンがどれで、自分はこれとこれを試して、結果がこうなった。これこれをやると落とし穴にハマるから避けてね。ちなみに、パイプラインのコードはこのPull Request で追加したものです」とすべての情報を整理して送ってあげると喜ばれた。

　しかしアメリカで似たようなことをすると、メッセージを送っても無視されるのだ。メンターのクリスに相談してみたところこんなことを言われた。

「みんな忙しいだけ。たくさん書いてあると読むの大変じゃない？　もっと単純なのでいいよ」

　私が絶句して、例えば「これをやったらハマる」落とし穴の情報を伝えなくてもいいのかと聞くと、

「要らないよ。さっきの例だと、このエラーメッセージが出てるけど、なんか知ってる？　ぐらいでOK。付加的な情報は聞かれたときでいいよ」

　つまり、日本では喜ばれた情報がむしろ余分な情報になっていたわけだ。　

最初から全部説明せず「情報量を減らす」

　思い返せば、インターナショナルチームの人たちの会話は、具体的にはこんな感じだ。

「CIシステムでこんなエラーメッセージが出て困ってるけど、なんか知ってる？」

「ああ、これ前にもあった。この設定、今どうしてる？」

　このやり取りでことがすめば、以上。もし終わらなかったら、

「調査が必要だな。このパラメータどうなってる？」

「こうしてるよ。よかったら、Pull Request のURL送るけど」

「いいね、見てみるわ」

「ちなみに、これやるとバグ踏むから、気をつけてね」

「ありがとう ！」

　といった感じだ。つまり、最初から全部説明せず、「情報量を減らす」コミュニケーションの仕方がすごく重要だったのだ。

　それを知ってからは、会話の中で情報を盛り込み過ぎないよう十分気を使うようになった。

「その場で吸収できることを最大化」する文化

　何かの技術を伝えるにあたって、パワーポイントで説明する場合でも、スライドの枚数を極限まで絞って、「これだけはわかって欲しい」と思う一点だけを説明し、質問が来たら追加説明するスタイルに変えた。これは良し悪しというよりは伝え方の文化なのだが、どちらが脳にとって本質的に楽かを考えると、慣れるとアメリカンスタイルのほうがはるかにストレスフリーだ。

　彼らの背景にあるのは、「その場で吸収できることを最大化したい」というスタンスだ。複雑なものを一気に提供されてもその場で理解しきれないので、単純にリアルタイムに理解できる適切な情報量が好まれる。

　インターナショナルチームでは、必要以上に脳に負荷をかけない伝え方がスタンダードになっている。

　ただし、プレゼンテーション等に関して、日本人特有の仕事の習慣が有利に働く側面もある。

　それは「準備」の力だ。先述してきたように会議でもチームへのプレゼンでも、アメリカ人はほぼ「準備」しない。その代わり何が来ても対応できるように、普段から反射神経を鍛えている節がある。その姿勢は見習いたいが、第二言語の英語である以上、非ネイティブが同じ土俵で勝負してもやはり戦闘力不足は否めない。

理解してもらうことに丁寧に時間をかける

　実は日本で鍛えられた丁寧な「準備」と「改善」の精神は、プレゼンテーションでは意外な強みを発揮する。

　ある日、最高に頭のいいメンバーたちを前に、技術的な説明をしたことがあった。難易度の高いところから順に、すべてのパターンやプラクティス、リポジトリ（プログラムの保管場所）の構造を知っている前提で話したが、今ひとつ反応がよくない。

　途中でふと、「まさか、みんなよくわかってない？」と気づいた。そこで学んだことは、ものすごく賢い人たちでも技術の中身は即座に理解できるわけではないということだった。

　だから2回目に説明するときはよく準備して、情報を最小にし、「簡単なこと」をしっかり説明するようにした。つまり、理解してもらうことに丁寧に時間をかける。

　すると、ここからが彼らは違った。情報量をコントロールして、筋道立てて基礎的なことから説明すると、一瞬で理解して、鋭い質問がバンバン飛んできたのだ。

　こうしたタイプの〈本質的な理解をうながす〉高度にコントロールされた最小のプレゼンテーションは、おそらくはアメリカ式の「アドリブ」でやるのは難しい。非ネイティブならなおさらだ。

　私はプレゼンテーションにさらに改善を重ね、アーキテクチャの説明に、パワーポイントで3分くらいの動画にまとめたものをつくってシェアするようにした。大変好評で、出席者たちからは「これは他のチームメンバーも見るべきだよ」と嬉しいコメントをたくさんもらった。

スライドを読み上げる説明は好まれない

　このようなパワーポイントのつくり方に関しても日米で好みの違いがある。日本人は図や概念図のようなビジュアルを好むが、アメリカ人は大きめで少ない文字が好み。ただし、難しい概念の場合、アニメーションにしてあげると、視点誘導をしやすいので、日米ともに喜ばれる。米国の場合、スライドに書いてあることを読み上げて同じ説明するのは好まれず、必然的にたくさん口頭で説明することになる。

　日本のほうはあとで見てわかるように情報がしっかりのっているのが好まれる。

　私は「その場の思考の瞬発力」が不得手だ。日本人は持ち帰って考える癖があるので、瞬発で考えるのがあまり得意ではない。でもドリューというボスが言っていた。

「それでいいんだよ。もしあとでいいアイデアを思いついたら、そのときシェアしてくれたらいいから」と。それであとからメールしたりすると「いいアイデアだね」と喜ばれることがよくあった。

「準備」と「持ち帰り」が習い性になると生産性を落とすので、先におすすめした通りなるべくその場で解決するのが望ましいが、優先順位の高い案件を持ち帰ってしっかり練るのは決して悪いことではない。

　インターナショナルなチームは、多様な人種・国籍の人たちが集まるので、個々人は違うという認識が当たり前のように共有されている。その中で自分の強みとなるスタイルを磨くことが、アウトカムを出すうえで武器になるのだ。

相手が求めている情報への感度を研ぎ澄ます

「相手が本当に欲しい情報は何か？」―これを普段から意識しておくことが、生産性を抜本的に向上させる鍵となる。

　プリンシパルエンジニアのグレナは、Functions チームの中でもひときわ優秀さが際立つ若手だ。開発スピードは速くて正確、システムの隅々まで把握していて、なにか問い合わせをすると、いつも一発で完璧に的を射た回答が返ってくる。

　実際、自分が問題を解決する側になったときに、的確な回答をするのはなかなか難しい。相手がどういう環境なのかわからないし、ログを見ても様々なエラーが発生していて、どれが今回の問題にヒットしているのかもわからない。そんな複雑な状況下で、根本原因を突き止めるために、普通は何往復もメールやチャットをやり取りすることになるわけだが、彼女はいつもその反復が1回で、「正解」に至るのだ。

　メンターのクリスに「彼女はなぜあんなに優秀なんだろう？」と聞いたら、「彼女を参考にしてはいけないよ。だって、彼女はインターンの頃から抜きん出ていたから。ただし、彼女はいつもメモをとっているね」と言う。

　彼女がなぜ魔法のようにピタリと根本原因をつきとめられるのかは不明だが、この「メモをとる」習慣は真似できそうだ。彼女は、自分が学んだこと、試したことを整理してOne Note というクラウドで共有されるメモシステムに登録し、みんなにシェアしてくれている。

人に伝えることを前提としたメモ術

　私がメモをとるときは、つい「自分用の、自分がわかるため」の書き方をしがちだが、彼女のメモは、見る人が欲しい情報はこれだろうという形で整理されている。

 

　エンジニアは開発だけではなく、他の人からの問い合わせ対応、障害の調査などにもかなりの時間を割かざるを得ず、引き継ぎも定期的に発生するものだ。これらは意外に労力がかかる。

 

　だったら最初から、他の人が欲しい情報をわかりやすい形式で整理しておくのが合理的だ。便利なクエリ（命令文のコード）を説明のコメント付きで書いておき、コピペしたらすぐ渡せるようにしておいたり、参考になりやすいPull Request をすぐ引き出せるようにまとめておいたりする。前章で紹介したコーネルメソッドなども参考にしつつ、ケースバイケースでわかりやすい形式で、メモやノートをとる。

　このように、日頃から人に伝えることを前提とした準備をしておくと、なにか聞かれたさいの工数削減にも直結する。ソフトウェアエンジニアは、開発の効率化ばかり考えがちだが、こうした「自分が主体ではない」タスクの省力化をしていると、自分が好きな「開発」にもっと時間を使えるようになる。

　私自身、他の人にシェアできる形式を意識して文書を書いて、リンクひとつでシェアできるようにしている。そこは時間を惜しまずやるようにしているのも、必要に応じてそのリンクをシェアするだけで終了するからだ。