コミュニケーションは難しい。
伝えたつもりが伝わっていなかったり、誤解されたりしていることは日常茶飯事だ。

この問題を解決するためにインターネットの通信方法を見習うことにした。

会話も情報通信なんだからプロトコルを決めよう

プロトコルとは、コンピュータ同士の通信をする際の手順や規格である¹。
情報通信はプロトコルがないと成り立たない。

ヒト同士が口から発した空気振動を時間断絶的に解釈して意図を伝え合う行為²、即ち「会話」も、情報通信の一種と言えよう。
では、会話においてもプロトコルを適切に定めるべきなのではないか。

プロトコルってなんだ

コンピュータは電子の動きで情報を制御している。いわゆる「0と1の世界」というやつだ。³

しかし、無秩序に電子を行き来させてもそれはただ電流が発生しているだけになってしまう。
流れる電子くんたちを解釈可能な情報として扱うためには、電子の流し方とその解釈の仕方にある程度のルールを設けなければならない。
そのルールをプロトコルと呼ぶ。
例えば、「データはすべて0と1だけの数字で扱い、それぞれの0, 1を電気の流れ方で表現しよう」も立派なプロトコルである。

インターネット回線が跋扈し電波が飛び交う現代⁴においては、至る所でコンピュータ同士の通信が行われている。そしてそれぞれの通信で様々なプロトコルが定められているわけだ。

この章ではその中でも、インターネット通信における「トランスポート層」という場所で用いられる二つのプロトコルを紹介する。
かなり搔い摘んだ説明になることは自覚しているので、どうかそのマサカリ⁵は懐に収めてほしい。

TCP(Transmission Control Protocol)

TCPは、相手と接続を確立してから通信を行うプロトコルである⁶。
TCPでは送信する側と受信する側がお互いを確認し合ってから通信を始めるので、信頼性が高い。

具体的に何をやっているかというと、

1. 通信開始側(以下A)が受信側(以下B)に通信OKか確認
2. BがAに返事、BがAに通信OKか確認
3. AがBに返事
4. データのやり取り
5. 通信終了側(以下A')がもう片方(以下B')に終了OKか確認
6. B'がA'に返事、B'がA'に終了OKか確認
7. A'がB'に返事
8. おわり

1~3までが通信開始の手続き、5~7までが通信終了の手続きである。これだけ入念に接続を確認する⁷ので、そりゃあ信頼性は高い。
また、受信側の能力に応じて送信側は一度に送るデータ量を調節することも可能である。しかも、受信側が正しく受信できたか確認する機能も有していて、もしデータが途中で紛失したらきちんと再送までしてくれる徹底ぶりである。

UDP(User Datagram Protocol)

UDPは、TCPと比べるとシンプルなプロトコルであり、その分高速だが信頼性は低い⁶。

TCPのように接続の確認などせずに、ひたすらデータを送るだけである。
もちろん破損データの再送もしない。
データ受信側は、データが破損していることは分かるが、そのデータを廃棄するしかない。

会話におけるプロトコルとは

冒頭でも定義を示したが、「通信プロトコル」は主にコンピュータ同士の通信において使われる言葉だ。

しかし、情報のやり取りが行われる場においては、どのような手段だろうとプロトコルの概念を適用できるのではないか。
例えば原始的な通信手段である狼煙においても、「特定の日時に」「特定の場所で」「特定の色の煙を」立てる、と送信側と受信側で共有していれば、プロトコルとして解釈することができる。

しかし、会話においては、使用言語が同じであるとすればその内容自体には工夫の余地がない⁸。
ではどこにインターネット的な通信手法を取り入れるべきか。
始め方と伝える量だ。

大事な話をするとき

相手に確実に伝わってほしいことを口頭で伝えるのならば、TCPのやり方が模範となり得る。

始め方

TCPと同様、相手が確実に話を聞ける状態になるまで待つべきである。

「いま大丈夫ですか？」「いいよ、話すの？」「はい、話します」
この1.5往復の会話で接続が確立された。

また、TCP接続上で行われる通信のプロトコルの一つにHTTPというものがある⁹。
HTTPでは、GETやPOSTなどのリクエストメソッド¹⁰（この通信で何をしたいのか）を通信の頭につける。
会話においても同様に、冒頭で要求概要を開示するべきである。

「相談なんですけど～」
「やってほしいことがあるんですけど～」
「これは愚痴なんですけど～」

聞く側は最初に概要を知ることで、聞くときの頭の使い方を変えることができる。
相談なら、解決法を考えながら聞く。
お願いなら、自分の時間のどこにタスクを挟み込むかを考える。
愚痴なら、話半分に聞いて適度な相槌を打つ。

伝える量

相手が消化できる程度の情報量で話すべきである。
あまりにも早口でまくし立てると、相手が受信するまでの間でデータが破損してしまって効率が悪い。

また、TCPでは、受信側はデータを受け取ったら「これだけのデータを受け取りました」と信号を送る。十分にデータが届いていなければ、受信側はいったんデータを破棄し、送信側は再送するという仕組みだ。

会話においても、話を聞いたら「私はあなたの話をこのように解釈しました」と返事をしてあげよう。
もしデータが正しく相手に届いていないと判断したら、何度でも再送する。大事なことは伝わるまで何度でも言う価値がある。
コンピュータにできるのだから、人間にもできるだろう¹¹。

大事じゃない話をするとき

なんでもかんでも上記のように丁寧に話していると疲れる。
破損しても構わない会話は適当に済まそう。

UDPは、ビデオ通話における映像や音のように、多少抜け落ちても問題がないデータを通信するときのプロトコルだ。
雰囲気だけ伝わればいい雑談は、相手の反応なんて気にせずにひたすら喋ろう。
伝わらなくても、相手は聞き流すだけだ。

おわりに

あまりにも自分の意図を他者に伝えるのが難しすぎて本記事を書き始めた。

正しく伝わっているか、正しく伝えられているかを考えながらコミュニケーションをとるのはとても疲れる。
ある程度納得のいく方法論が共有されていればもう少し会話もしやすいのではないか。
本記事は、そんな手法の一提案として受け取っていただければと思う次第である。

まあ、本当に大事な話は口頭ではなく文字媒体で残すべきなのだが。

1. プロトコル | IT用語辞典 | 大塚商会 ↩

2. ヒトが空気振動を時間断絶的に解釈し得る表現を「音声」と呼ぶのに対し、光粒子の振動を平面空間断絶的に解釈し得る表現を「絵」または「文字」と呼ぶ。 ↩

3. RINGOMUSUMEは関係ない。 ↩

4. いま目の前を飛んでいるであろう通信電波の量を考えると、アルミホイルを頭に巻きたくなる気持ちが少しだけわかる。 ↩

5. インターネットにいるエンジニアはすぐ「マサカリ」とか「銀の弾丸」とか物騒な物ばかり取り出すので良くない。 ↩

6. 国民のための情報セキュリティサイト（総務省) ↩ ↩²

7. このやり方は3回のやりとりで接続を確立するので、「スリーウェイハンドシェイク」と呼ぶ。 ↩

8. 語彙力が明らかに異なる場合等には工夫の余地はあるか。 ↩

9. アドレスバーの最初についてる"http"とかのそれである。 ↩

10. GETならファイルが欲しい、POSTならデータを投稿したいなど。 ↩

11. この論は詭弁である。コンピュータにできて人間にできないことなど山ほどある。 ↩