39
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

技術力だけでは選ばれない。未経験エンジニアが現場で差をつける「対話の技術」5選

39
Last updated at Posted at 2026-06-17

はじめまして。株式会社PRUMでエンジニアをしているひとみです。

日々、プログラミング学習や実務の中で、つまずきやすいポイントや、
仕事で起きやすい"ズレ"について整理して発信しています。
誰かの助けになれば幸いです。

伝わらないのは話し方の問題じゃなかった。相手を「見る」ことで変わる要件定義の話

image.png

はじめに

「ちゃんと説明したのに、なぜか伝わらなかった」

エンジニアとして働き始めた頃、こんな経験が何度かありました。

仕様の説明を丁寧にしたつもりなのに、後から「イメージと違う」と
言われる。要件定義の打ち合わせで合意を取ったはずなのに、納品後に
そんなつもりじゃなかった」と言われる。

そのたびに「もっとうまく説明できればよかった」と思っていました。
でも実は、問題は説明の上手さではありませんでした。
相手を見ていなかっただけだったんです。

「同じ説明」がなぜ人によって届いたり届かなかったりするのか

ある日、二人のクライアントに同じ資料を使って説明したことがあります。

Aさんには画面の完成イメージを見せながら「こういう感じで動きます」と説明したら、
すぐに「 わかりました、進めましょう 」となりました。

でも次のBさんには同じ資料を使って同じ説明をしたのに、
なぜこの構成にしたんですか? 」と聞き返されて、
会話が噛み合わなくなってしまいました。

最初は「 Bさんは難しい人だ 」と感じました。でも違ったんです。

Aさんは目で見てイメージを掴む人

Bさんは論理と理由で納得する人

だったというだけでした。
人によって「情報の受け取り方」が違います。見た目やビジュアルで理解する人、
言葉の論理で理解する人、実際に触って体で感じる人。同じ内容を伝えても、
届け方を合わせないと「伝わった感覚」は生まれません。

現場でよく見る4つのタイプ

image.png

相手の言動を少し観察するだけで、大きく4つのパターンが見えてきます。
自分やクライアントがどのタイプかを意識するだけで、
要件定義の場の進め方がかなり変わってきます。

結論を先に欲しい人

「で、スケジュールは間に合うの?」

と最初に聞いてくる経営者や決裁者に多いタイプです。
長い説明は不要で、結論・原因・選択肢を短く整理して
伝えることが喜ばれます。

私は以前、このタイプの方に対して丁寧に経緯から説明し
始めて、途中で「 結論は? 」と遮られたことがあります。
最初に「2日遅れています。原因は○○で、対応策は2つあります」
と切り出すようにする方が好まれます。

ビジョンで動く人

「このシステムが完成したら業務が一気に変わりますね!」

という一言で目を輝かせるタイプです。
プロダクトオーナーや事業担当者によく見られます。
細かい仕様の話を先に詰めようとすると、一気に熱が
冷めてしまいます。まずビジョンを共有して気持ちを
乗せてから、詳細の話に入る方が好まれます。

安心感が決め手の人

「今の業務が急に変わったりしませんよね?」

と確認してくるタイプです。変化に慎重で、本音を言い出せない
ことが多い。「 何か気になることがあれば遠慮なく教えてください 」と
先に言える関係を作ることが大切です。

後からの大どんでん返しを防ぐには、本音を丁寧に引き出す方が好まれます。

データで確認する人

「その根拠は何ですか?」

とすぐ聞いてくる、エンジニアやQA担当者に多いタイプです。
たぶん大丈夫です 」は絶対に通用しません。「 ログを確認して
本日17時までにご報告します
」という誠実さが信頼に変わります。

認識ズレを防ぐ「オウム返し」の使い方

タイプを把握したうえで、もう一つ意識してほしいことがあります。
それは「相手の言葉を繰り返して確認する」習慣です。

クライアント:「毎朝、全店舗のデータを手作業でまとめているんですが、
       本当にしんどくて……」
私:「毎朝の手作業でのまとめ、それは本当に大変ですよね」

これだけで
この人は自分の話をちゃんと聞いてくれている
という安心感が生まれます。さらに進めると、

私:「つまり、自動化して転記ミスをゼロにすることが一番のゴールということでよいですか?」
クライアント:「まさにそれです!」

こうやって確認することで、認識のズレが起きる前に合意を取ることができます。「言った・言わない」のトラブルは、この小さな繰り返しと確認で多くが防げます。新人の頃の私には、この「繰り返して確認する」という発想がまったくありませんでした。自分が理解したかどうかだけ気にして、相手が納得しているかを確かめていなかったんです。

まとめ

image.png

私は以前、

「もっと説明が上手くなれば伝わる」

と思っていました。でも実際には、
説明の仕方よりも先に考えるべきことがありました。
それは、

相手が何を大切にしていて、どうやって情報を受け取る人なのか

を知ろうとすることです。
もちろん伝える力を磨くことも大切ですが、
その前に、

この人はどんな人なんだろう?

と相手に関心を持つこと。
相手を知ろうとする姿勢が大切なのかもしれません。

まず、自分はどのタイプかなって考えると、面白いかもしれないですね!


PRUMのエンジニアの95%以上は未経験からの採用です。
もし弊社にご興味あれば下記のサイト記事を覗いてみてください。

未経験からエンジニアになるための転職ロードマップ

39
4
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
39
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?