【ポエム】コミュニケーション技術・人間プロトコルメモ

人間プロトコルメモ

なぜこれを書いているか

人間同士のコミュニケーションには仕様書がない。本音と建前が混ざり、言葉・態度・空気・関係性が同時に流れてくるので、どこが何のレイヤーなのか見えにくい。

ネットワークならOSI参照モデルがあって、どの層で何が起きているか切り分けられる。人間関係にはそれがない。だから「今どこで失敗したのか」を切り分けられないまま、全部を自分のせいだと感じてしまう。

そこを整理しておきたかった。

OSI参照モデル
ネットワーク通信を7つの層に分けて考える国際規格。物理層からアプリケーション層まで積み上がっていて、障害が起きたときにどの層の問題かを切り分けられる。「ケーブルが抜けている」のか「アプリの設定ミス」なのかを区別するための道具。

人間プロトコル(仮)

自分なりに層を分けてみるとこうなる。

層	名前	中身	観測できるか
L1	通信	メッセージが届く、会話が成立する	できる
L2	応答	返信が来る、リアクションが付く、既読になる	できる
L3	言語	実際に発した言葉	できる
L4	関係	初対面か、友人か、上司か、家族か	推測できる
L5	感情	嬉しい、怒っている、困っている	推測しかできない
L6	社会	建前、礼儀、空気	推測しかできない
L7	本音	本人ですら整理できていないこともある	観測不可能

L4から上には仕様が存在しない。しかも厄介なのは、本人すらL7を正確に説明できるとは限らないこと。サーバー側にも仕様書がない状態でリバースエンジニアリングしようとしている。

自分の癖

L7を解析しようとしてしまう。

例えば「ありがとうございます。」という一文だけでも、こうなる。

本当に感謝している
社交辞令
怒っているけど隠している
会話を終わらせたい
とりあえず打っただけ

延々と可能性を並べてしまう。でも受け手はそこまで分析していないことが多い。相手は「ありがとう」と打っただけで、意味を込めていないケースがかなりある。

こちらが7層まで解析している間、相手はL3で終わっている。存在しないデータを解析しようとしている状態になる。

人間は確率で動いている

多くの人は「たぶんこういう意味だろう」くらいで会話している。100%の確信は持っていない。

AIも同じ構造をしていて、「絶対これが正解」ではなく「この返答が最も確率が高い」を選び続けている。

人間の会話
「たぶん怒ってないだろう」 → 行動 → 反応を見る → 更新

自分がやっていること
「99%怒ってない。でも1%は?」 → 行動できない

確率で動くのが普通で、確信を求める方が例外だった。

自分の問題

「仮説が外れたらどうする?」が常に頭の中で動いている。99%歓迎されていると分かっていても、残り1%を無視できない。

ただ、ここで混ざっているものがある。

混同していたもの	実際
仮説が外れる	頻繁に起きる。普通のこと
致命傷になる	ほとんど起きない

仮説が外れることと、致命傷になることは別だった。この2つを同じものとして扱っていたから、1%が怖かった。

人間関係はTCPに近い。パケットが落ちる前提で作られている。

誤解する → 説明する → 修正する

この流れ自体が異常事態ではなく、プロトコルに最初から組み込まれている正常動作だ。

TCPとUDPの違い
TCPは届いたか確認しながら送る方式。届かなければ再送する。UDPは投げっぱなしで確認しない。動画配信のように多少落ちても構わない用途で使う。

人間関係はTCPに近い。届いていなければもう一度言えばいいし、間違って伝わったら訂正できる。一発勝負のUDPではない。

実際にあった例

1. イベント参加の連絡をもらう
2. 返事を忘れる
3. 相手が推測する →「参加しないのかな?」
4. 「確認を失念していました」と伝える
5. 相手が納得 →「参加ありがとうございます」

相手の最初の推測は外れていた。でも追加情報によって修正された。これがエラーではなく正常なプロトコルだった。

誤解が発生した時点では何も壊れていない。修正されなかった場合にだけ問題になる。

誤解をゼロにしようとしない

目標を書き換える。

前	後
誤解されない人になる	誤解が起きても修正できる人になる

前者は達成不可能だった。相手の解釈は自分の管理外にあるので、どれだけ丁寧に書いても外れるときは外れる。達成不可能な目標を持っていたから、常に失敗している状態だった。

後者なら達成できる。修正の手段を持っているかどうかは自分側の話だから。

責任範囲の切り分け

ここが一番はっきりさせたかった部分。

自分の責任	相手の責任・制御不能
必要な情報を伝える	どう解釈するか
誠実に説明する	どう感じるか
誤解に気づいたら修正する	修正を受け入れるか

通信で言うとこうなる。

自分の責任 : パケットを送る、ACKを受け取る
相手の責任 : どう解釈するか、どう感じるか

送信は制御できるが、受信側の処理は制御できない。当たり前だが、ここを混ぜていた。

ACK (Acknowledgement)
「受け取ったよ」という確認応答。人間関係だと返信・リアクション・既読あたりがこれにあたる。

ACKが来たことは「届いた」ことの証明であって、「意図通りに解釈された」ことの証明ではない。L1〜L3の確認であって、L5〜L7の確認ではない。ここを区別しておくと、既読だけで安心も不安もしなくて済む。

事実と推測を分ける

これは書き方を変えるだけで効いた。

悪い例
「上司は怒っている」

良い例
事実 : 上司は「ここ違うよ」と言った
推測 : 自分は怒っているように感じた

同じ出来事でも、書き方によって確定情報になったり仮説になったりする。前者だと反証できないが、後者なら後から更新できる。

自分の頭の中で起きていたのは、推測をいつのまにか事実として保存してしまうことだった。一度事実として保存されると、それを前提に次の推測が積み上がる。

誤解されやすい原因は一つではない

「誤解されやすい」を一括りにすると対処できない。分解するとこうなる。

原因	対処
説明不足	空白を埋める。自分側で対処可能
相手との相性	どうにもならない。頻度を下げるくらい
自分の思い込み	事実と推測を分ける
相手が受け取る気がない	対処範囲外

全部を同じ「自分の欠陥」として処理すると、直せる部分まで見えなくなる。

情報量の偏り

自分の傾向として、普段は説明不足で、気になり始めると今度は説明し過ぎる。

通常時 : 情報が足りない
不安時 : 情報が多すぎる

どちらも「適切な量」から外れている

説明し過ぎも問題になる。情報量が多いと、相手はそこから意図を読もうとする。「なんでこんなに丁寧に説明してくるんだろう」という新しい推測を発生させてしまう。

対処としては、誤解を生みそうな空白を一つだけ埋める。全部説明する必要はない。

悪い : 全部説明する / 何も説明しない
良い : 一番誤解されそうな箇所を一つだけ埋める

観測できるものを信用する

制御工学的に考えると、内部状態は観測できないので、出力を見るしかない。

信用してよいもの(観測値)	信用し過ぎないもの(推測値)
返信が来る	本当は怒っているかもしれない
会話が続く	実は嫌われているかもしれない
誘われる	あの絵文字には別の意味があるかもしれない
リアクションが付く	気を遣わせているかもしれない

右列は全部データではなく生成した仮説。自分で作ったものを、外から来た情報のように扱ってしまうのが問題だった。

フィードバック制御
内部状態が分からないシステムを、出力を見ながら少しずつ調整して目標に近づける制御方式。エアコンが室温を測りながら出力を変えるのがこれ。

人間関係はこれに近い。相手の内部状態(L5〜L7)は観測できないので、返信・態度・継続といった出力を見て調整する。内部状態を完全に把握してから動こうとすると、永遠に動けない。

一番重要だったこと

誤解を防ごうとし続けるのではなく
誤解が起きたときに必要な情報を追加して修正できる状態を維持する

そして修正に応じない相手まで自分の責任だと思わない。

「誤解を解ける」と「必ず解ける」は違う
世の中には、話を聞かない人、一度決めつけたら変えない人、説明する前に離れる人もいる。

送信側がどれだけ正しくパケットを送っても、受信側が破棄する設定になっていれば届かない。そこまで自分の責任にすると終わりがない。再送は無限にできるが、無限に再送する義務はない。

補足として整理したこと

人間関係は状態推定ゲームではない
→ フィードバック制御に近い

人間関係は正解を当てるゲームではない
→ 十分に確からしい仮説で行動し、新情報が来たら更新するゲーム

「正解してから動く」ではなく「動いてから修正する」。順番が逆だった。

まとめ

全部覚えようとしない。原則だけ持っておく。

原則	中身
誤解はゼロにならない	目標にすると達成不可能な状態が続く
観測できるのはL3まで	L4以上は全部こちらが作った仮説
必要な情報だけ伝える	空白を一つ埋める。全部説明すると別の推測を生む
事実と推測を分ける	推測を事実として保存しない
相手の行動を見る	内部状態ではなく出力で判断する
仮説が外れる ≠ 致命傷	再送・修正が前提のプロトコル
責任範囲は送信まで	解釈と感情は制御対象外
修正できる関係を目指す	誤解されない人ではなく、直せる人
修正に応じない相手	そこまでは責任範囲外

結局、やっていたのは仕様書のないプロトコルを完全解析しようとする作業だった。相手側にも仕様書はないので、原理的に不可能なことをやろうとしていた。

やるべきなのは解析ではなく、外れた前提で再送できる構造を持っておくことだった。