優秀なエンジニアがリーダーになってつまずく、説明力の壁

「ExcelのAA列の〇〇ですが」

システム開発の現場で、こんな説明から話が始まることがあります。

説明者本人は、そのExcelが何のデータで、AA列が何を意味していて、なぜそこが論点なのかも、頭の中ではつながっている。

でも、聞いている側は違います。

（AA列？ 何の話？）
（これって何のデータだっけ？）
（この表って、どんな目的なんだろう？）

いろいろ頭の中で「？」の疑問が出てしまい、話についていけない場合があります。そうして感じることは、

「話がわかりにくい」

です。

細部を見る技術者、エッセンスだけ欲しい聞き手

技術者は、普段、細部を見ます。
システムエンジニアだと、こんな感じです。

・ログや設定を見る
・差分をチェックする
・データの不整合や異常値を探す

これは、現場ではとても大切な力です。
細かい条件の違いを見落とさずに膨大なデータから原因につながる手がかりを見つけること。これは技術者として、とても重要な能力です。

しかし、説明を受ける側、特にお客様、経営層、非エンジニアが求めているものは、細部ではなく、

「要するに何？」

です。

・何が起きているのか
・どれくらい問題なのか
・業務にどんな影響があるのか
・判断すべきことは何か
・選択肢は何か
・おすすめの対応は何か

のようなエッセンスを求めています。

問題を見つける力と、問題を伝える力は別物

ここは技術者がリーダーになる時につまずきやすいところだと思います。
問題を見つける力と、問題を相手に伝える力は別物です。

問題を見つける時は、細部を確認します。
ログからエラー文を確認し、それがどこで起きているのかを深掘りしたり、Excelのどのパラメータが間違っているのかを探します。

一方で、説明する時は、細部から一段上がらなければなりません。

・細かいログを見た結果、何が分かったのか。
・Excelの一覧を見た結果、どこに問題があるのか。
・その問題は、業務上どういう意味を持つのか。
・何を判断してもらいたいのか。

つまり、問題解決は「詳細を読み解く力」で、
説明は「詳細から抽象化する力」です。
方向が逆です。

ここを意識しないと、詳細を調べる力がある人ほど、その詳細をそのまま見せてしまいます。

本人としては、正確に説明しているつもりです。
根拠も出している。
データも見せている。
嘘もついていない。

でも、聞いている側からすると、
「で、何を見ればいいの？」
「何が問題なの？」
「私は何を判断すればいいの？」
となってしまう。

問題を調べるときと、相手に説明するときでは、情報をたどる方向が逆であることを意識しないと、せっかく一生懸命説明しても「話が分かりにくい」という残念な結果になってしまいます。

リーダーになると急に変わる評価軸

システムエンジニアとしてメンバーの立場にいる時は、「詳細を読み解く力」や「細部から原因を見つける力」がある人が評価されます。

「これがバグの原因だ」
と突き止められることが強みです。

しかし、リーダーになると評価軸が変わります。

・相手に合わせて説明できるか。
・要点を抽出できるか。
・判断しやすい形に変換できるか。
・技術的な話を、業務や経営の言葉に置き換えられるか。
・お客様や非エンジニアに、納得してもらえるように話せるか。

こういう力が求められます。

ここに気づかないと、技術者として優秀だった人ほど、リーダーになってから苦戦します。

本人からすると、
「ちゃんと調べているのに」
「根拠も出しているのに」
「細かく説明しているのに」
「なぜ伝わらないのか」
となります。

Excelの中にいる説明者、表の外にいる聞き手

既に答えがわかっている説明者は、Excelの中にいます。しかし、聞き手はまだExcelの外にいます。

そのため、
まずは背景や経緯、
次に、なぜこのExcelを使って説明するのか、
このExcelはどういうデータで、どのような構造になっているのか、
今回、見るべきポイントはどこなのか
を説明します。

順番が大事です。

でないと、目的や行き方もわからないまま、いきなり
「ここに来て」
と呼ばれているような状態になります。

技術者同士なら通じる説明が、お客様には通じない

技術者同士であれば、詳細から入っても通じることがあります。
前提知識が近いからです。

「ここでエラーが出ています」
「この設定値が違います」
「この条件だと分岐が変わります」
「この列が不整合になっています」
という詳細内容でも、相手もついてこられるかもしれません。

全部見せることは、相手に編集作業を渡している

詳細なExcelをそのまま見せることは、一見すると誠実に見えます。

隠していない。
全部見せている。
根拠も出している。

しかし、説明としては不親切になることがあります。なぜなら、どこが重要かを相手に探させているからです。

詳細データは必要です。
ただし、説明の主役ではなく、根拠資料として後ろに置きます。

まず要約を説明し、必要に応じて詳細へ進み、質問されたら根拠を示す。この順番の方が、相手は理解しやすくなります。

私が説明するときに意識している5つの順番

お客様や経営層へ説明するとき、私は次の順番を意識しています。

1. 結論：何が起きているのか

2. 影響：業務、費用、品質、納期にどんな影響があるのか

3. 判断事項：相手に何を決めてもらいたいのか

4. 選択肢と推奨案：どんな対応があり、どれをおすすめするのか

5. 根拠：その判断に至ったログ、データ、設計資料

詳細なExcelやログから説明を始めるのではなく、まず相手が全体像と論点を理解できる状態をつくります。そのうえで、必要に応じて詳細へ降りていきます。

技術者が調査するときは、詳細から結論へ進みます。

しかし、相手に説明するときは、結論から詳細へ進みます。調査した順番と、説明する順番は同じではありません。

リーダーとして求められる能力

リーダーやPMに近い立場になると、
メンバー向けには、技術的な詳細まで説明し、
お客様向けには、業務影響と判断ポイントに変換し、
経営層向けには、リスク、費用、納期、意思決定事項に絞る。

このような聞き手に応じた見せ方が求められます。

技術的には優秀だけど、この部分ができずに損をしている人は多いかもしれません。この評価軸の変化に気づけるかどうかで、リーダーになった後の評価は大きく変わると思います。

私も、最初からうまく説明できたわけではありません。

今でも、話す相手をイメージし、説明の順番を整理して事前に練習しても、十分に伝えきれないことがあります。

説明力は、一度型を覚えれば完成するものではありません。相手の反応を見て、伝え方を振り返り、地道に改善を重ねていくしかないと考えています。

最後に

技術者にとって、詳細を見る力は大事です。
ただし、問題を見つける力と、問題を伝える力は別物です。

特にお客様や経営層、非エンジニアに説明する場合は、詳細をそのまま出すのではなく、「要するにどういうことか」まで引き上げる必要があります。

リーダーになると、説明する機会が増え、評価軸が急に変わります。
ここに気づけると、リーダーとしての評価は一段変わると思います。
技術力があるのに、説明で損をしている人は多い。

だからこそ、「詳細を読み解く力」だけでなく「詳細から抽象化する力」を磨く。そこに、優秀なエンジニアがリーダーとして一段上に行くための、大きな伸びしろがあるのではないでしょうか。

関連記事
今回の記事に興味を持たれた方は、下記もおすすめです。