「よくわからない」と言われてしまう人の特徴とは

多くはエンジニアにありがちではあるが、他の職種の方にも当てはまるのではないだろうか。
私自身も過去のエンジニア・PM経験でよく「わからない…」と言われてしまったことがある説明や報告・相談の特徴として

主題、言いたいことがわからない
同じ意味の言葉を複数の単語で言い換える
「これ」「それ」「その」など指示語で物事を省略する
質問されていることと違うことを答える
複雑さ、しんどさの情報を強調しがち
資料を見せながら説明しているのに話している内容と資料が紐づかない
自分しか知らないルールを作る（そのルールは説明しない）
結論に至ったプロセス、理由を順を追って説明しない
説明する相手が自分の知識レベルと同じかそれ以上であることを前提としている
なぜか謝る　もしくは　謝らない
「わからない」と言えない、「わかりました（わかってない）」

このあたりが挙げられる。

・主題、言いたいことがわからない

結構な時間をかけて散々説明をしたあとに相手から「で、結局なにがいいたいの？（なにがききたいの？）何をしてほしいの？」という無情な言葉をうけたことがある人はまずここから。
説明の主題、最も伝えなければいけないことが全く伝わっていない。

主題は「これから何について説明するのか」
言いたいことは「結論は何か」、「何をしてほしいか」
ということである。

まず主題。例えば
「本日はMM月DD日に発生したトラブルについての報告と再発防止策について説明いたします」とか
「◯◯システム開発において発生している課題の説明と対応方針を決定したいです」だとか
説明を始める前、あるいは会議のタイトルとして主題を相手にハッキリ伝えること。

次に言いたいこと。
説明において結論は何なのか、それが事象・トラブルや経緯の説明であればその説明によって相手に何を判断して欲しいか、何を決めてほしいかを明確にしておかないと相手はどういうつもりで説明を聞かなければならないのかがわからないため「で、なにがいいたいの？」状態になってしまう。

まず説明を始める前に主題と併せて結論（結果）や言いたいこと・して欲しいことの要点をヘッドラインとして出して相手が聞く準備ができてから詳細な説明を始める、という話し方や資料の作り方にしておくと無情な言葉を浴びせられることは少なくなるのではないだろうか。

・同じ意味の言葉を複数の単語で言い換える

「この～～一連をA」と定義し説明したと思ったら、なぜかその「A」を次の場面では「B」や「A’」といった全く違う単語もしくは定義した単語とよく似た別の言い回しで説明にさも当たり前のように再登場させる。
聞いている側としてはその「B」や「A'」がイコール「A」のことなのか、全くあたらしい別のものを指しているのか判断できない。
そのため説明を続けている相手に対し
「ちょっとすいません、その『B』というのは何ですか？さっき出てきた『A』とは別のものなんでしょうか？」
という質問をせざるをえない。
一度定義した「A」ならば「A」で統一して説明をするように気をつけよう。

・「これ」「それ」「その」など指示語で物事を省略する

事象が発生した原因などを説明するときにシステム構成図やソースコードなんかをつかって「原因はこれだと思うんですけど」や「それがこっちのこれに影響して…」なんて説明、こちらもよくやりがち。

説明を聞いている人は「これ」が何のことを言っているのか把握できないし、
IDEのソースコード画面を共有しながら長々と喋られても画面上のどこのどのソースの話をしているかわからない。
全く同じソースコードを説明している人物と同じレベルで開発している人ならば
「ああー、この◯◯Service内のこのメソッドが△△のところにも使われてるから影響が出てくるんだな」
など具体的な実装と起きている事象の予想をつけながら補完することが可能かもしれないが説明する相手はPMや上司など自分と同レベルかそれ以上の開発者では無いことも多い。
「どこの」「なにが」「どういう事象によって」「どうなって」発生したかを明確に説明すべきだ。
そもそもソースコードは見せてこなくていい。

・質問されていることと違うことを答える

質問者の求めている答えは「YESかNOか」だけだったりするのに
「それについてはまだ検証しているところなんですけど～～～と、～～～があって…～～」
と質問に対し説明が始まる。
自分では質問に答えているつもりでも聞いている側はもう長々と始まった説明はもはや聞いていない。
まず「YES」か「NO」を答える。答えに条件があるならばその後に説明を補足する。

また、「〇〇が起きた理由はなんですか？」という質問に対して
「～～～について調べたんですけど詰まってしまって△△というエラーが解消しなくて～」
と理由ではなく過程や今陥っている状況を答えてしまっている、などもありがち。
理由を聞かれているので、その理由がはっきりしない場合でも
「完全に再現・特定は出来ていないのですが、ログとソースコードを確認した上で理由として予想できるのは～～～でーーーーが発生したことであると考えています」
のように前提条件を説明した上で答えられる範囲で答えると伝わりやすい。

・複雑さ、しんどさの情報を強調しがち

ここまでの項目の例で挙げているように
「詰まってしまって△△というエラーが解消しなくて～」
のように自身が困っている事象であったりしんどいことをまず言いたがる傾向にある。

また、システム構成の説明など俯瞰的な説明が求められている場でも
「APIの認証は◯◯を使っていて連携は△△情報と✕✕情報を…」と詳細なロジックであったり「ここの作りは〇〇というサービスを使っていて～～～がーーーーで難しいんですが△△を使うことにより…」
と複雑な中身の説明に入ってきてしまう。

エンジニアの視点で言えば時間をかけて考えている部分はたしかに困っていることであったり複雑なロジックでなんとかこのしんどさを伝えたい気持ちがあるかもしれないが、
詳細の説明をしても相手は
「何の話をしているんだろう？なんか難しいし…」
と聞く気がなくなってしまう。

説明するトピック、説明する相手によって伝えなければいけない本質は何かをまず理解し、例えば「システムの全体構成」を説明するのであれば構成する要素と関係性を過度な専門用語を使わずに簡潔に伝えることに集中すべきだ。

・資料を見せながら説明しているのに話している内容と資料が紐づかない

資料をPPTで作成して写しながら説明する場も多々あるが、写しているページのヘッドライン、トピックまでは一致しているものの喋っている内容が資料上のどこにも書いていないことがよくある。

聞いている側はまず視覚に入ってくる画面の文字を読み始めて説明を聞くが話している内容が全く資料に書かれていないと「何の話…？」と混乱し話している内容が頭に入ってこない。
仮に説明がわかりやすい言葉を用いていても伝わらないので損でしかない。

説明内容をすべて資料に書く必要は無いが、
ページ上のメッセージに概要を書き、口頭で補足説明をする
のように目で見えている情報と話している内容をリンクさせる。

・自分しか知らないルールを作る（そのルールは説明しない）

例えばある物事に対してメリット・デメリット表を作成するとする。
その時にメリット・デメリットを判断するための要素が行ないし列の項目として設定してあるが
「メリデメ表の通り、Aの方がいいと思います」
と表をパッと見せて説明を終わらせてしまうと聞いている側は、その要素がどのような基準で定義されたのかを説明されていないので「なんで？」となり正しく判断ができない。

自分では「表にこれだけ明確に書いてあるからわかるじゃないか」と思っているかもしれないが相手はその表を作っている最中にピッタリ横にいて一緒に項目を考えていたわけではないのでなぜその要素なのか、どういうルールで作ったのかはわからない。
「Aの方がいい」と言っているのが何故なのかは自分しかわかっていないのに世の理のように言われても説明されている側は「？」しか浮かばない。
まず要素の定義と優先度を説明してから表の中身を比較していくことを心がけたい。

物事を説明する場合、
・主題
・前提
・要素、要素の定義
・事象
・理由
・結論
などで組み立てて一貫性を持って説明しないと繋がりが行方不明になってしまう。
ルールが存在するならそのルールがどんなものかがわかっていないと前提・要素・理由・結論にどのように作用してそうなったのかが見えない。
相手はルールも何も知らない相手であることを念頭に置いて説明しよう。

・結論に至ったプロセス、理由を順を追って説明しない

自分しか知らないルールの項目と繋がるが、つまり途中過程の過度な省略や、理由・考え方を順を追って説明しないため理由・根拠不明の主張だけが続いてしまう。
聞いている側は主張だけ聞いても確からしさは正しくジャッジは出来ず、説明の声が頭を通り抜けるのみとなる。

途中過程をダラダラと1から10まで話す必要はないが、
結論に至るまでのプロセスがどのようなものだったのか、何を根拠としてその結論になるのかを明確にする必要がある。
ここでどこがしんどかったとか、どこで躓いたとか、「複雑さ、しんどさの情報を強調」はせず事実のみを伝えることが大事。

・説明する相手が自分の知識レベルと同じかそれ以上であることを前提としている

ここまでの項目で共通するのが何故か相手は自分と同じかそれ以上の知識レベルを持っている、もしくは自分の作業・思考内容を共有・理解していることを前提として考えてしまっていること。
そんなわけはない。

基本的に相手は経緯を何も知らないし、開発者でもエンジニアでもない、専門知識は通じない、という前提で考えた方がいい。

その前提であれば無用な言い換え、過度な省略、専門用語・専門知識を多用して伝わるはずがないのは明白ではないだろうか。

・なぜか謝るもしくは　謝らない

矛盾している表現ではあるがピントの合っていない謝罪文句を羅列する必要はない。
説明に間違いがあったり、矛盾が発生している場合に「間違いでした、すみません」と謝ることは必要なことであり、謝らないのは良くない。

例えば、説明していることに関して相手から「どのようなプロセスで結論に行き着いたのか？」という質問に自分が答えられなかった場合（あんまりプロセスなく考えていた等）、
「申し訳ございません、説明の書き方が十分ではなかったです」
と謝っているとする。
聞いている相手側はこの謝罪に「そもそも考えてなかったのだから書き方の問題ではないのでは？」と謝っている箇所にピントが合っていないことにモヤモヤを感じる。

指摘されている間違いを理解せずとりあえず謝るのは得策ではない。
間違いを正しく認めていないという点では謝らないのと同義。

・「わからない」と言えない、「わかりました（わかってない）」

こちらもピントが合っていないという点では謝罪の項目と似ている。
指摘された内容や質問に対しとりあえずなんとなく答えてしまい、「わかっていない」ことを煙に巻こうとしても相手からしたら「ああ、わかってないな」とバレていることが大半。
その場で「わかりました」と元気よく返事をしても次回修正された内容がやっぱり相手の思ったものと違い何度も手戻りが発生するなんてことが容易に想像できる。
それならば素直に「わかりません」と言ったほうが良い。

とはいえ「わかりません」一辺倒では何の努力も改善もしようとしていないただのだめな人なので、わからないのがどこなのかをハッキリさせたい。

例えば「仰っている指摘は◯◯を△△すべきということで理解合っていますか？」とか
「手順はわかっているんですけど、その手順が何故必要なのかはわかっていませんでした」とか
自分がどこまでわかっているのか、この時点で指摘されていること・トピックとのピントが合っているかを確認することが必要。
この時点でピントが合っていなければ、
「〇〇を△△すべき、ということではなくて～～～をーーーーの前提で考え直してほしいんだよね」
など軌道修正が可能で、何度もやり取りや手戻りをする無駄な工数を抑えられる。

まとめ

いかがだろうか。
全てではないにしても思い当たることがあったのではないだろうか。
自分がわかっているつもり、ちゃんとわかりやすく説明しているつもりでも相手は全然ついてこれていなかったり、聞く気がなくなってしまっていることがかなりの場面である。

説明を始める前に話す相手が誰なのかを再確認したり資料に変な言い換えや説明されていないルールがないか再チェックして少しでも気をつけると
話し始めから「え、どういうこと？よくわからないんだけど…」と言われることがだんだんと減っていくと思うのでぜひ実践してみてほしい。