コードは書けるのに、なぜ伝わらない？──中堅エンジニアが今すぐ変えるべき言葉の使い方

技術力には自信がある。コードも書ける。でも、なぜか「伝わっていない」と感じる場面が増えてきた──。

中堅エンジニアになると、純粋に手を動かすだけでは済まなくなります。上司への報告、ステークホルダーへの説明、後輩とのやり取り。「言い方ひとつ」で仕事の進み方が大きく変わる局面が増えていきます。

この記事では、エンジニアが日常的に直面する3つのシーン──Slack、報告・説明、部下との雑談──に絞って、今日から変えられる具体的な言い方を紹介します。

この記事で得られること：
・Slackで「伝わる」メッセージの構造がわかる
・上司・ステークホルダーに刺さる報告の型がわかる
・部下との雑談を「仕事の質」につなげる考え方が身につく

テキストコミュニケーションは、相手の表情も声のトーンも届きません。それだけに、言葉の選び方・構造が品質をそのまま決めます。よくある3つのパターンを見てみましょう。

📍 パターン1：「対応しました」だけで終わる報告

「対応しました」は受け手にとって「何が？どこまで？次は？」の疑問が残ります。
完了事項・影響範囲・次のアクションの3点をセットにするだけで、確認コストがゼロになります。

📍 パターン2：長すぎる質問文

質問は「状況・試したこと・知りたいこと」の3点構成にするだけで、相手の回答コストが激減します。相手の時間を奪わない質問力は、信頼の積み上げにも直結します。

📍 パターン3：曖昧な依頼・確認

依頼は「何を・いつまでに・どこを」が明示されていないと、受けた側が判断できません。相手が動けるだけの情報を依頼文に込める意識を持ちましょう。

まとめポイント：
・報告は「完了・影響・次のアクション」の3点セット
・質問は「状況・試したこと・知りたいこと」の構造化
・依頼は「何を・いつまでに・どこを」を明示する

技術的な正確さと、非技術者への説明のしやすさは別物です。上司や事業部門の担当者に話すときに陥りがちなパターンを見てみましょう。

📍 パターン4：技術用語が先に来る説明

非技術者に伝えるときは、「ユーザーにとって何が起きているか」→「なぜか」→「どうなるか」の順番で話すと一気に伝わりやすくなります。技術詳細は聞かれたら補足する形で十分です。

📍 パターン5：「問題があります」だけで終わる報告

問題の報告には必ず「影響範囲・現在の対応状況・次のアクションと時間軸」をセットにしましょう。上司が「何を判断すればいいか」がわかる報告が、信頼を作ります。

📍 パターン6：「やっています」だけの進捗報告

「やっています」は相手に何も判断させません。進捗・見通し・懸念点・対応策の4点を含めると、管理側が「介入すべきかどうか」を判断できるようになります。

まとめポイント：
→ 技術用語より「ユーザーへの影響」から話し始める
→ 問題報告は「影響範囲・対応状況・次の報告時間」をセット
→ 進捗報告は「進捗・見通し・懸念点・対応策」の4点構成

「雑談は業務外のこと」と思っていませんか？実は中堅エンジニアにとって、部下や後輩との雑談はチームの生産性に直結する重要な仕事です。

【なぜ雑談が大切なのか】

【雑談を「つくる」3つの習慣】

雑談が得意でないエンジニアも多いと思います。才能の話ではなく、小さな習慣の積み重ねで十分です。

技術の話から入る
「最近どんなもの触ってる？」「あのライブラリ使ってみた？」
エンジニア同士なら技術の話が自然な入り口になります。
仕事と近い話題から始めることで、雑談のハードルが下がります。
Slackの雑談チャンネルに顔を出す
random や #times-xxx のような雑談チャンネルに、週に数回でもリアクションを送るだけで存在感が変わります。中堅エンジニアが絵文字を押してくれるだけで、若手は「見てもらえてる」と感じます。
短い声かけを習慣にする
「最近どう？」「昨日のリリース、お疲れ」1on1の場を用意しなくても、日常の短い一言が関係の土台になります。まず一日一回、誰かに声をかけることから始めてみましょう。

まとめポイント：
・雑談はチームの問題を早期発見するセンサーでもある
・技術の話を入り口にすると自然に始められる
・Slackのリアクションや短い声かけで十分、まず小さく始める

技術力は変えるのに時間がかかりますが、言い方・伝え方は今日から変えられます。

・Slack：報告・質問・依頼は「情報を構造化」して相手のコストを下げる
・報告・説明：技術詳細より「影響と見通し」を先に伝える
・雑談：小さなやり取りがチームの心理的安全性と問題発見速度を上げる

中堅エンジニアになると、自分の技術力だけでなく「チームを動かす力」が求められるようになります。コミュニケーションの改善は、その第一歩です。

今日から一つだけ試してみてください。最初は「報告のときに影響範囲を添える」だけでも構いません。小さな変化が、少しずつ周囲の反応を変えていきます。

伝わる言葉を使えるエンジニアが、チームを動かせるエンジニアになる。