組織の「パケットドロップ」を防げ。コミュニケーションを最適化する5つの設計原則
数十人、数百人が参加する会議で流れる、自分に関係のない情報。
チーム会議の中で突如始まる個人戦（そしてなかなか終わらない）。
私たちは、日々どれだけの量の情報を聞き流しているのでしょうか。
朝から晩まで埋め尽くされた会議、際限なく飛んでくるメールやチャットの中で、どれだけ「パケットドロップ（聞き流し）」が発生しているのでしょうか。
誰もが暇ではありません。自分に関係ない話は聞き流すしかなく、時間や心のリソースが浪費されていきます。
これらの内部コミュニケーションのトラフィック問題が、組織全体のスループットを著しく下げているのに違いはありません。
1. 「ネットワーク設計」に学ぶコミュニケーションのトラフィック最適化
こうした組織内コミュニケーションのトラフィック問題をシステム開発における「ネットワーク設計」の考え方を用いて最適化できないか考えてみます。
1.1. セグメンテーション
セグメンテーション
ネットワークを物理的、または論理的な小さな単位に分割すること。不要なブロードキャストパケットの到達範囲を限定し、通信効率の向上とセキュリティの強化を図る。
乱暴にまとめると、「適切に部屋を区切る」ということです。
コミュニケーションにおいては、「会議参加者の最小化」を指します。これは真っ先に取り組むべきところだと思います。
定例の会議体は特に重要です。今一度参加者を確認し、本当に必要な参加者を選別します。ここで不参加になった人は別に不名誉なことではありません。無駄な会議から解放されたと喜ぶところです。また、個別の会議でも注意してください。上司を常に参加させる習慣があったり、通例で声をかける範囲が決まっていたりする場合は今一度見直してみてください。
1.2. データ圧縮と重複排除
データ圧縮と重複排除
データの冗長な部分を取り除き、転送サイズを小さくすること（圧縮）。また、同一のデータブロックを検知し、二度目以降は送信を省くこと（重複排除）。限られた帯域とストレージを有効活用するための技術。
「何でもかんでも会議で話さない」ということです。これが実は私が2番目に強調したい点です。1.1.の「セグメンテーション」とこれをやるだけでだいぶ改善するはずです。
問題視している「冗長なデータ」や「重複」の具体的な事例としては、以下のようなものです。
冗長なデータ
考えがまとまっておらず、その場で相談あるいは迷走してしまう。
不必要な説明、不必要な資料、不必要な情報。
重複
同じ議題、同じ情報のやりとり。
会議をするまでに議題を明確化しておきましょう。自分自身の主張も話せるように整理しておきましょう。全員の時間を奪うことになります。
重複の方は実際のコミュニケーションであまりない思います（年取って物忘れが激しくなって、同じ人に同じことを話してしまう…というケースは否定できませんが…😓）。
1.3. QoS（Quality of Service／優先制御）
QoS（Quality of Service／優先制御）
データの種類や用途に応じて、通信の優先順位をつける技術。リアルタイム性が求められる通信（音声や動画など）に帯域を優先的に割り当て、遅延やパケットロスによる品質低下を防ぐ。
一言で言うと「優先度をつける」ことです。
会議自体に優先度をつけることももちろん有効ですし、同じ会議内でも提示する情報に優先度をつけることも有効です。
例えば、同じ会議で共有する情報でも、「これは重要だからしっかり聞いてほしい」という情報と「」これは参考レベル」という情報をラベリングして伝えるのです。聴衆が自分でラベリングする手間も避けますし、聴衆が誤った優先度付けをしてしまったりするのも防止できます。
1.4. エッジコンピューティング
エッジコンピューティング
データを中央のサーバーに送るのではなく、データの発生場所に近い端末や拠点のサーバーで処理すること。通信の往復時間を短縮して低遅延を実現し、基幹回線の負荷を大幅に軽減する。
これは組織内の決裁ルールにも依存しますが、上司の決裁が必要のない判断事項はなるべく自分たちで処理するということです。
上司の性格によっては、後で「聞いていない」と怒る人もいるので、事前にすり合わせは必須です。もし合わないようなら、これはやらない方が得策です。ただ、上司の決裁を早められるように、判断材料を簡潔に伝えたり、「私はこれでいきたいです。よろしいでしょうか？」とこちらの判断や希望を伝えることは有効です。
（このあたりは以下の記事に書いているのでよろしければご参考ください）
1.5. プロトコルの最適化
プロトコルの最適化
通信の手順（プロトコル）を調整し、データのやり取りに伴う「付随的な通信（オーバーヘッド）」を最小化すること。確認応答（ハンドシェイク）の回数を減らすなど、データ転送の純粋な効率を向上させる。
一番大きいのは「会議自体をやめること」です。会議という形式をやめて、例えばチャットの連絡だけで済ますというのは有効です。
そこまでいかずとも、「議題をやめること」も有効です。定例会議の議題であればその議題の準備に時間を費やしている人が必ずいるはずです。それを削減できるのは大きいです。
もっと小さいところでは、チャットで「理解した」ことを「👍（イイネ）」マークのリアクションで済ますルールを作るのも有効です。いちいち「承知しました」のコメントがつくのも鬱陶しいし、何も反応がなくて伝わったのかわからない状態も不安です。
2. トラフィック最適化したらどうするか。
2.1. 余裕が生まれる
余計なトラフィックを削減できれば、余裕が生まれます。
時間的余裕、精神的余裕。
これは、以下の記事で私が主張する人が主体性を持って行動するための条件のうちのひとつであり、もっとも獲得が難しい「余裕」を手にすることができます。
余談ですが、余裕を得られたことはなるべく公にしない方がいいです。得た余裕分、新しい仕事が振ってきますから。
2.2. 「イミテイティブ」に押しやられた「クリエイティブ」を救い出す
私は仕事を次の2つに分類しています（詳しくは以下の記事参照）。
「イミテイティブ」（模倣的）
「今」を作る仕事。
計画した成果を上げる。成功を再現する。
「クリエイティブ」（創造的）
「未来」を作る仕事。
新しい価値を生み出す。未来に向かう。
日常的な会議の多くは「イミテイティブ」な仕事です。特に定例会議なんかはまさに「イミテイティブ」です。
通常、企業は今を生きることに必死ですから、この「イミテイティブ」な仕事が多くなります。そして「クリエイティブ」にチャレンジする余裕を得られないことが多いです。
トラフィック最適化によって得た「余裕」は「クリエイティブ」に使いたいものです。
3. おわりに
今日は組織内コミュニケーションの非効率をネットワーク設計上の「トラフィック問題」と捉え、ネットワーク設計の考え方をもとにした整理を考えてみました。
私の職場も「トラフィック問題」が溢れているので、少しずつ解決していきたいところです。
ここまでお読みいただき、ありがとうございます。
