エンジニアの「コミュ力」の正体は「構造化能力」である——なぜ"書けないこと"は"話せない"のか
こんにちは。
株式会社ココナラ 技術戦略室に所属している デミオ です。
こちらは株式会社ココナラ 2/2 Advent Calendar 2025 10日目の記事です。
導入：あなたは「パースエラー」の発生源になっていないか？
前回の記事（Day 5）では、エンジニアに必要な読解力を 「カオスな情報を脳内で構造化し、デコード（解読）する力」 と定義しました。
「なんとなく分かった気がする」という曖昧な状態（パースエラー）の発生を検知し、情報を正確にインプットする技術について解説しました。
しかし、通信は一方通行ではありません。
読み手として「構造化（デコード）」することの重要性を理解したとしても、あなた自身が書き手として送信するパケットが、相手の脳内で「パースエラー」を引き起こしているようでは、エンジニアとしての通信品質は低いままです。
今回は、情報の受信（デコード）から、逆方向のプロセスである 「送信（エンコード）」 へと視点を反転させます。
「複雑な仕様なので、ドキュメントより口頭で説明したい」
「チャットだと 細かいニュアンスが伝わらない ので、通話で話したい」
もしあなたがそう思っているなら、少し危険かもしれません。
エンジニアリングの観点、特に 論理構造（ロジック）の伝達においては、「書けないことは、話せない」のが原則 だからです。
本記事では、多くのエンジニアが陥りがちな「話せているつもり」の正体を暴き、「私のコードは構文エラーを含んでいますが、あなたの優秀な脳内コンパイラで補完して実行してください」 という依存から脱却するための、プロフェッショナルの通信プロトコルについて解説します。
1. 「話すのが得意」な人の正体：処理のオフロード
よく「文章化するより話した方が早い」と言う人がいます。確かにあなたの時間は節約できますが、その「伝わった感」はどこから来ているのでしょうか？
実は多くの場合、 あなたの「発信力（エンコード能力）」が高いのではなく、相手の「受信力（デコード能力）」が高いだけ というケースがあります。
聞き手という名の「優秀なコンパイラ」
会話（同期通信）では、あなたの説明が多少構造破綻していても、優秀な聞き手が脳内で補完（コンパイル）し、バグを修正してくれます。具体的な「進捗報告」のシーンで比較してみましょう。
【Before：構造化されていない（コンパイルエラーな）報告】
「あのー、決済機能の件ですが、ライブラリのバージョンが古くて、なんか動かなくて。色々試したんですけどエラーが出るんで、インフラチームに聞こうか迷ってて、ちょっと遅れそうです」
（聞き手の脳内負荷：事実と推測が混ざっている...結局「遅れる」のが結論か？ 原因はライブラリ？ アクションは何？）
【After：構造化された（コンパイル済みの）報告】
「決済機能の実装について、2日の遅れ（結論） が発生しそうです。
原因（Fact） はライブラリのバージョン不整合です。
対策（Action） として、インフラチームへバージョンアップを依頼中です。承認され次第、実装を再開します」
Beforeの例では、聞き手が脳内で情報を整理するコストを払っています。
この会話が成立したとき、知的負荷を負ったのはあなたではなく聞き手です。あなたは構造化のコスト（CPU負荷）を相手に オフロード（処理の転嫁） したに過ぎません。
「書けないこと」は「話せない」
一方、テキストコミュニケーション（非同期通信）やドキュメントでは、相手によるリアルタイムな補完は期待できません。
論理構造が破綻したコードがコンパイルエラーになるのと同じく、構造化されていない文章は「意味不明」として弾かれます。
もちろん、声のトーンや場の空気を読む「対人スキル」が高い人はいます。
しかし、「時間をかけて推敲できるテキスト」でさえ、論理を構造化できない人がいます。そのような人が、「瞬発力が求められる会話」で論理的な説明を完遂できる道理はありません。
あなたが「話せた」と感じているなら、それは論理が通ったのではなく、雰囲気や勢いで「なんとなく納得させた」だけ かもしれません。
以下の図が示すように、構造化されていない思考は、聞き手の脳内で「コンパイルエラー」を引き起こし、コミュニケーションの不全を招きます。
2. 「だと思う」はパケットロスである——推測への依存を絶つ
前回の記事では、「『〜だと思う』という感覚はパースエラー（理解不足）の危険信号なので、メタ認知を働かせよう」と説きました。
これは 受信側（自分） の話です。
しかし、 送信側（相手への伝達） に回ったとき、この論理を甘えに使ってはいけません。
「相手が賢いから、きっと行間を読んで補完してくれるだろう」という期待は、エンジニアリングにおいて「暗黙的な依存（Implicit Dependency）」と呼ばれるアンチパターン だからです。
相手に try-catch を書かせるな
- 「たぶん伝わった と思う 」
- 「仕様はこれで合っている と思う 」
この「だと思う（Assumption）」が含まれた言葉を発した瞬間、あなたは例外処理（エラーハンドリング）の責任を相手に押し付けています。相手はあなたの曖昧な言葉を受け取るたびに、脳内で try-catch ブロックを展開し、「この『思う』は事実なのか願望なのか？」を検証しなければなりません。
プロフェッショナルの通信プロトコルにおいて、不確実性は排除されるか、あるいは 明示的にカプセル化 されなければなりません。
TCPハンドシェイクとしての対話
ここで意識すべきは、信頼性の高い通信を行う TCPの3-Wayハンドシェイク です。
一方的に情報を投げつける（UDP的アプローチ）のではなく、相手との間で「認識の同期（SYN）」と「到達確認（ACK）」が取れるまでを1セットのトランザクションとして扱います。
-
悪い例（確認なしの一方的送信・UDP的）:
「この仕様で進めます」（相手の反応を待たずに実装し、後で「そこ認識違います」と言われて手戻りする） -
良い例（合意の形成・TCP接続）:
「この仕様で進めますが、懸念点Cについては未検証です（不確実性の明示）。ここだけ認識合わせさせてください（SYN/ACKの要求）」
「無知」をバウンダリとして定義する
全てを完璧に把握することは不可能です。重要なのは、知ったかぶりをして曖昧なパケットを送ることではなく、 「確実に合意できている範囲」と「未知の範囲（リスク）」の境界線（バウンダリ）を明確に宣言すること です。
前回記事の読解力が「推測して構造化する力」だとすれば、今回の発信力とは 「相手に一切推測させない力」 です。この 「認識の解像度の明示」 こそが、手戻りを防ぐ唯一の方法です。
以下の図のように、相手との間で「SYN/ACK」のプロセスを経ることで、初めて信頼性の高い対話が成立します。
3. 「コンテキスト」という名の環境変数——SSoTの徹底
ここまでは「情報をどう構造化するか」という送信側の技術を話しましたが、通信においてもう一つ重要なのが 「受信側の環境設定（コンテキスト）」 です。
どれほど完璧なコード（文章）を書いても、実行環境（相手）に必要なライブラリや環境変数が設定されていなければ、エラーになります。これが「話が通じない」の正体です。
相手の「スコープ」を特定する
エンジニアは変数のスコープ（有効範囲）には敏感ですが、コミュニケーションのスコープには無頓着なことがよくあります。
伝える相手が、どのレイヤーのコンテキストを持っているかを見極めることも、構造化能力の一部です。
-
対 個人 (Local Scope):
その人とだけ共有している一時的な文脈。
→ 「昨日の件だけど」で通じる。 -
対 チーム (Module Scope):
チーム内で暗黙知化されている開発フローや用語。
→ 「いつものデプロイ手順で」で通じるが、新メンバーには通じない。 -
対 組織 (Global Scope):
全社的な目標や、他部署には通じない専門用語。
→ 経営層や他部署に「リファクタリングが必要です」と言っても、その重要性（コンテキスト）は伝わらない。
「伝わらない」と嘆く前に、 あなたは相手のスコープで定義されていない変数（自分だけの文脈）を参照しようとしていませんか？
相手が持っていないコンテキストは、明示的に 「環境変数の設定（インプット）」 をしてから話す必要があります。
文化人類学者のエドワード・T・ホールは、共有された前提に依存する伝達様式を 「ハイコンテキスト」 と呼びました。しかし、異なる背景を持つメンバーが集まるエンジニアリングにおいては、前提を明示する 「ローコンテキスト」 な通信（依存性の排除）が求められます。
以下の図は、コミュニケーションにおけるスコープの不一致がどのように発生するかを表しています。
「言わなくてもわかる」を許すな——SSoTの徹底
しかし、会話のたびに 手動で環境設定（コンテキストの説明）を行う のは非効率です。
話すたびにゼロからコンテキストを説明するのは、コードで言えば「同じ初期化処理をあちこちにコピペしている」のと同じであり、メンテナンス性の低い 「冗長なコード（Duplication）」 そのものです。
そこで重要になるのが、 「共有コンテキスト（暗黙知）の管理」 です。これを解決するのは、「もっと話そう」という個人のコミュ力やコミュニケーション量ではなく、 組織的な仕組み作り（構造化） です。
個人の記憶やチャットログに依存せず、「情報がどこにあるか」を一意に定める仕組み が必要です。
Single Source of Truth（信頼できる唯一の情報源）の原則
何より重要なのは、コミュニケーションにおいて SSoT (Single Source of Truth) の原則を徹底することです。
「チャットのログ」「口頭での伝達」「古いWiki」。情報が散在し、どれが最新かわからない状態（データの不整合）は、分散システムにおけるバグそのものです。
私たちが頭を捻るべきは、もっと流暢に話す方法ではなく、 「どこを見れば正解があるか（ポインタ）」を一つに定める仕組み を作ることです。
-
コンテキストの永続化:
「チームに浸透している空気」を言語化し、SSoTとなる場所（Wiki等）に書き出すこと。 -
アクセシビリティの確保:
それが「誰でも、いつでも、URL一つで」参照可能な状態になっていること。
「ドキュメントを書く時間がない」と嘆く前に、チャットのログをWikiに転記しましょう。
その手間を惜しむことは、 「チーム全員が毎回車輪の再発明をするコスト」 を無視していることと同義です。
4. 「対面」という高帯域（ブロードバンド）の正体——帯域幅とコストの理論
ここまで「書くこと（テキスト）」による構造化の重要性を説いてきましたが、テキストは万能ではありません。
テキストは論理を伝えるのに最適ですが、「感情やニュアンス」まで含めた情報の総量（スループット）には限界があります。 そのため、複雑な状況においては、「対面（オフライン）」という高コストな回線 をあえて選択すべき局面が存在します。
なぜなら、オフラインという通信環境には、私たちのエラーを救ってくれる 圧倒的な「帯域幅（Bandwidth）」 があるからです。
コミュニケーションの帯域幅比較
経営学における 「メディア・リッチネス理論 (Daft & Lengel, 1986)」 でも指摘されている通り、不確実性が高いタスクほど、情報量の多い（リッチな）メディアが適しています。
- テキスト: 言語情報のみ（低帯域）。構造化ミスが致命傷になる。
- 対面: 言語 ＋ 表情 ＋ 声のトーン ＋ 身振り ＋ ホワイトボード（超広帯域）。
対面コミュニケーションでは、言語化（構造化）に失敗しても、「困った顔」や「身振り」といった非言語情報（メタデータ）が大量に送信されるため、相手がエラー訂正しやすくなります。
つまり、オフラインは 「構造化能力が不足していても、なんとかなってしまう優しい環境（補助輪付き）」 なのです。
しかし、「とりあえず集まろう」という安易な選択は危険です。
それは、本来ロジック（構造化）で解決すべきパフォーマンス問題を、ハイスペックなサーバー（全員の同期時間）を投入して無理やり解決するようなもの。まさに 「力技（Brute Force）」 に他なりません。
思考の整理をサボるために、会社のコスト（人件費）を浪費し、チームの生産性を犠牲にして「解決した気」になっていないか？ 私たちは常に自問する必要があります。
「構造化」を武器に、「高帯域」を戦略的に投下する
重要なのは、テキストで培った「構造化能力」があって初めて、対面の「高帯域」を真に活かせるということです。
思考が構造化されていない状態で対面を選ぶのは、広帯域回線を使って「ノイズ」を大量送信しているようなものです。
普段はテキストでコストを抑えつつ論理を「プリコンパイル（構造化）」し、複雑な仕様決定やトラブルシューティングなど、ここぞという場面で対面の表現力を戦略的に投下する。
これこそが、コストと品質を両立させる、プロフェッショナルな通信スタイルです。
以下の図は、各コミュニケーション手段の帯域幅（Bandwidth）とコストの関係性を示しています。
5. 明日からできる「構造化」トレーニング (Action Plan)
概念を理解したところで、明日から実践できる具体的なアクションを紹介します。
Level 1: 送信時の「プリコンパイル」習慣（個人レベル）
Slackなどのチャットツールを送信する前に、以下のチェックを挟むだけで「構造化」の訓練になります。
- 箇条書きファースト: 文章でダラダラ書かず、まず情報を箇条書きにする。
- 事実と意見の分離: 「〜だと思います」ではなく、「事実はAです。私の推測はBです」と分ける。
- スコープ確認: 「この単語（変数）、相手に通じるか？」を一瞬だけ自問する。
Level 2: 「非同期」で粘る訓練（対人レベル）
「ちょっとZoomいいですか？」と言う前に、3分だけ立ち止まってみてください。
- 3分ルール: 3分かけてもテキストで説明できないか試みる。
- 図解の活用: 言葉で詰まるなら、手書きのメモを写真に撮って貼る方が、会議を開くより低コストかもしれない。
Level 3: DRY原則の適用（組織レベル）
プログラミングの原則である Don't Repeat Yourself (DRY) を、コミュニケーションにも応用しましょう。
- 同じ説明を2回したらリファクタリング: 同じ質問を2回されたら、それはドキュメント化の合図です。
- 1秒で回答する: 3回目は「ここに書いてあります（URL）」と1秒で終わらせるために、今の数分を投資してWikiを書きましょう。
まとめ：言葉をデザインし、環境を整備せよ
- 送信スキル: 思考を構造化し、曖昧さを排除する（TCPハンドシェイク）。
- 環境認識: 相手のスコープ（コンテキスト）を見極め、不足していれば注入する。
- 環境整備: SSoTを徹底し、全員で「正解の置き場所」をメンテナンスする。
「コミュ力」とは、単に流暢に話すことではありません。
情報を論理的なブロックとして扱い、相手の実行環境（コンテキスト）に合わせてデプロイするエンジニアリング技術 です。
明日からは、「この説明で相手はビルドエラーを起こさないか？」と想像力を働かせてみてください。その思考の積み重ねが、あなたを信頼されるエンジニアへと変えていきます。
明日はゆーたさんによる「2025年の技術広報振り返りと2026年に向けての意気込み！」です。
ココナラでは積極的にエンジニアを採用しています。
言葉（コード）の可読性にこだわり、チーム全体の「通信品質」を高めていける方。
心理的安全性の高い「高帯域」なチームを一緒に作りませんか？
採用情報はこちら。
カジュアル面談希望の方はこちら。
Discussion