はじめに
株式会社LITALICOでエンジニアをやっている@kazuisです。
LITALICOでは多くのエンジニアが開発を日々頑張っております。
障害者福祉を中心に事業所を運営している会社です。
エンジニアの人数も200人近く在籍しておりIT企業の一面もでてきました。
ネタ記事ですが、年末年始にご笑覧ください
リモートワークは困難さが多い
LITALICOのプロダクト開発を行う組織ではリモートワークができるルールになっており、多くのエンジニアがリモートワークを選択しています。プロダクトマネージャやサポートの面々もリモートワークで業務をしている事が多くネットワークを介してのコミュニケーションが多くなっています。
コロナ禍からはじまっているリモートワークですが、数年経過しネットワーク越しで、はじめて会う人も少なくない状況になっていると思います。
読んでくださっている方の会社でもリモートワークならではのコミュニケーションの失敗もあるのではないでしょうか？
- いきなり話しかけづらい
- 忙しいとか状況が分かりづらい
- ボタンの掛け違いがあったり
- 通信環境が良くなく会話がうまくできない
オンラインで仕事するときのようにちょっと雰囲気さぐるとかできなかったり、難しかったりしてミスコミュニケーションが起こりがちです。
世界中のコンピュータ同士が情報伝達している仕組みを参考に、よりよいコミュニケーションにしていきましょう。
はじめてのコミュニケーション
他部署の方や、コミュニケーションをとったことがない方にいきなり話しかけて仕事を進めるのは、なかなか難易度の高いコミュニケーションだと思います。
失敗しがちなのが、相談したいが分からず、この人かなっと思って話しかけても役割がちがったりとか
そういう事もあるでしょう。
そういうときは、自分より上の上司に相談して、他部署の方を紹介してもらいつつ役割などの説明を受けてコミュニケーションとったりします。
TCP/IPの世界でも同じです。
Qiitaのサービスにアクセスしたい！と思ってもいきなりアクセスはできないものです。
そういうときはDNS(Domain Name System)に問い合わせを行いIPアドレスを教えてもらいます。
トランスポート層のTCPから見ると、DNSはアプリケーション層で上位レイアになります。TCP/IPの世界でもいきなりコミュニケーションは取れないわけです。
現実の世界だと以下のイメージでしょうか
〜チャット〜
部下『営業ツールの追加機能の業務内容を知りたいのですが、誰に聴けばいいですか？』
上司『営業部の木村さんに業務内容を聞いてください』
TCP/IPの世界も、リモートワーク下のコミュニケーションも情報伝達ですから参考にできそうですね。
はじめての方とコミュニケーションとるときは上位者を仲介してコミュニケーション取るのが良さそうです。
これでTCP/IPでコミュニケーションをとるIPアドレス知る事ができました。
では実際にコミュニケーションを取っていきましょう。
リモートワークですから、メールやチャットでコミュニケーションが始まると思います。
そのときに、注意したい事としては一方的に相手の状態も確認せずに、メッセージを送ってはミスコミュニケーションを発生させてしまいます。
TCP/IPの世界はどうでしょう
参考にするのは3Way Handshakeです。
コミュニケーションのお手本みたいなシーケンスですね。
SYNはコネクション確立要求です。
サーバ側がACKを返してます。ACKは確認応答です。
要求を出して、確認応答をする。
これがセットです。
このシーケンスだとサーバ側は80番ポートでアプリケーションが稼働している状態で、80ポートに接続要求を送信しています。現実の世界だと、ポートに割あたっているアプリケーションは業務や役割と例える事ができそうです。
コネクションを確立する際に、お互いにポート番号(役割)を確認しコミュニケーションを開始する事ができます。
そのポートでやり取りするプロトコルが送信側、受信側で一致しているから正しいコミュニケーションができるのです。
〜チャット〜
部下『木村さん、はじめまして。部下といいます。機能追加の担当エンジニアです。』
木村『はじめまして。部下さん。営業事務をやってます。木村です。』
部下『追加機能の業務を教えてほしいのですが、よろしいですか？』
木村『業務で使う手順書を説明しますね』
部下『よろしくお願いします。』
この場合、担当エンジニアと営業事務という役割を確認しあい。会話をする内容、業務手順書の理解(プロトコル)を決めています。リモートワークであるから、こそインターネット越しには伝わらない情報も多いですので役割とプロトコルをお互いに確認し合いながら、コミュニケーションをはじめると良いと思います。思い込みでコミュニケーションを始めると「HTTP 400 Bad Request」が返ってくるかもしれません（涙）
役割の確認と、コミュニケーションするときのプロトコルをお互いに話そう
コミュニケーションは当たり前はない、接続するたびに確認が必要ということをTCPは教えてくれています。
応答がない！そんなとき
リモートワークでネットワーク越しに仕事をしていると、仕事をしている姿が見えたりはしないので忙しそうだなとかテンパってるなぁとか非言語コミュニケーションで伝わる情報が圧倒的に少なくなります。
メッセージしても応答がないとかで不安になることも多いのではないでしょうか？
そんなときに学びたいのがTCPの再送タイムアウトの決定の仕組みです。
通信はネットワーク環境によって『揺らぎ』が大きい場合と小さい場合があります。
TCPは高性能な通信を実現するために、ネットワークの混雑の変化を記録し、送信タイムアウト時間を適切にする仕組みがあります。パケットを送信し、ACKが帰ってくるまでの時間、ラウンドトリップ時間(RTT:round trip time)を記録します。RTTの変化によって、再送タイムアウト時間（RTO:retransmission timeout）を計算して決定するのです。
細かい話はRFC6298を見てもらうとして、、、
ここで重要なのはコミュニケーションで応答がないときは、必ず発生します。
リマインドするときはRTTを計測すると高品質なコミュニケーションができるという事です。
コミュニケーションの状況は常に変わります。
メッセージを送って、その応答がどれぐらいの応答時間が計測しSRTT（滑らかな往復時間）を計算する必要があるのです。1時間おきにリマインドするのが適切なのか？ 翌日でいいのかリマインドのタイミングは送信者側だけで決めてはいけません。
相手のメッセージの応答時間からリマインドするタイミングを決めて優しいコミュニケーションをしよう
これもまた、ミスコミュニケーションを減らし、円滑なコミュニケーションを行う手法の１つだとTCPは教えてくれています。多すぎるメッセージは輻輳を発生させてしまいます。
リモートワークファースト
オフラインのコミュニケーションの方が優れている事も多いと思いますが、リモートワーク前提で働き方を良くしていくリモートワークファーストで頑張っていきたい！
TCPは最小限のルールでノードとノードでコミュニケーションを取ることができるプロトコルです。情報量が少ないままコミュニケーションとると失敗しがちになるリモートワーク下で参考にできる事は多いような気持ちになりました。
リモートワーク時代の働き方にはルールが必要、それは最小限なルールであるのが望ましい
リモートワークを推進してく上でTCP/IPというインターネットのルールをお手本にしてみるのはどうでしょうか？
おわりに
ノードとノードをつなげるプロトコルとしての技術を知っているはずなのに、コミュニケーションは難しいものだなと思いいます。TCPの触りだけで参考になる事たくさんあります。通信プロトコルは、コミュニケーション技術の塊とみると楽しくRFCも読んだりできるのではないでしょうか
好きなRFCは3271です。