電子メールの主な利点の1つは、それが企業通信の標準であるため（ この技術の特定の短所にもかかわらず）、大企業でも通信の単純さと有効性です。
これまでのところ、主に通信に課せられている制限のために、他のツールに置き換えることはできませんでした-多くの場合、情報の過負荷に耐える必要なく、適切な人々へのアクセスに使用することはできません。 その結果、特定の従業員チームのフレームワーク内であらゆるコミュニケーション手段を使用できますが、会社全体は電子メールで完全に接続されています。
コーポレートコミュニケーションKato.imのメッセンジャーに取り組む際、対話者の到達可能性と情報ノイズ量の削減の問題に多くの注意を払いました。
Twitter vsノイズ
非常に「うるさい」ソーシャルネットワークのイメージにもかかわらず、Twitterには、無関係な情報につまずく可能性を減らす非常に思慮深く効果的なシステムがあります。 特定のユーザーおよびリストからのメッセージをサブスクライブするメカニズムにより、ユーザーは自分のフィードを作成してニーズを満たすことができます。ユーザーの1人が「うるさい」またはスパムを公開し始めた場合、彼から登録解除するのは非常に簡単です。 これにより、彼のツイートがテープから完全に削除されます。
同様のアプローチが加藤で導入されました-数千人の従業員を抱える大企業では、多数の部門、プロジェクト、内部チャット（加藤の用語では「チーム」と「部屋」）が存在する場合があります。 ユーザーはこのすべての情報を必要としないかもしれないので、私たちは彼に最も関連性のある議論に関する情報を受け取るために必要な部屋に「サブスクライブ」する機会を与えることにしました。
同時に、Twitterにはもう1つの素晴らしい要素があります。言及（言及）です。 目的のユーザーの注意を引くために、サブスクライブする必要はありません（または、このユーザーが対話者にサブスクライブする必要はありません）。 ツイートに彼のユーザー名（@ユーザー名）を記述するだけで、このツイートを見ることができます。
加藤では、特定の会話におけるユーザーの「存在」のモデルはありません。 適切な人の注意を引くために、あなたは単に彼に言及することができ（Twitterのように）、サブスクリプションレベルに関係なく、彼にはメッセージが表示されます。
加藤のアプローチは、個人と部屋の間に強固なつながりがないことを意味します-従業員が以前に参加したことのない部屋で言及された場合、彼はそれをすぐに開いて議論に入ることができます。
このアプローチは、他のメッセンジャーとは根本的に異なります。受信者が自分のいない部屋でメッセージを見るには、まず何らかの方法でメッセージを追加するか、このユーザーが自分でアクセスを要求する必要があります。
最終的に「すべての部屋のすべて」または人々が情報ノイズに悩まされないように問題を解決した後、必要な部屋に常に入室して出なければならない状況が発生するため、このようなスキームはうまくスケーリングしません。 さらに、人が部屋を出ると、新しいメッセージに応答できるように、対話者は部屋に彼を招待するように招待されます。
特定のグループへのこのような強制的なメンバーシップは、実際のコミュニケーションの構築方法とは関係ありません。サブスクリプションとメンションのメカニズムはより有機的で、はるかに効率的に機能します。
通信のスケーリング
インスタントメッセンジャーの使用時に発生する別の問題は、狭い「帯域幅」です。 通常、これらのツールでは、コンテキストを変更せずに多数のディスカッションに簡単に参加することはできません。通常、ユーザーは単位時間ごとに1つの会話（ルームまたはチーム）を処理し、コンテキストを切り替えて別のディスカッションに参加する必要があります。
ここでは、「バス」の概念との類推が適切です。人数が多いほど、バスの帯域幅が大きくなり、すべての会話を効果的に「ポンプ」できる唯一の方法になります。
コンテキストを部屋から部屋に切り替えるプロセスの「高コスト」により、作業中の通信でのチャットの使用はほとんど役に立たなくなります。 そのため、加藤では、多くの部屋とチームで簡単に作業できることを同時に認識しました。
このような機会を必要とするユーザーの簡単な例は、大企業のプロジェクトマネージャーです。 このサービスのスペシャリストは、開発者、テスター、デザイナーのさまざまなチームとのコミュニケーションを余儀なくされており、さまざまなトピックに関する会話を同時に行うことができます。 彼が常に会話を切り替えてこれに時間を費やす必要がある場合、これはコミュニケーションの質を劇的に低下させ、その結果、管理をします。
会社全体で1つの通信「バス」を使用することは非常に重要ですが、1つの組織内の異なるチームが使用するチャットプログラムの動物園がある場合、これは通信データの断片化のみに寄与し、情報交換のプロセスを遅くします。
さらに、企業では非常に多くの場合、自動的に生成された多数のメッセージ（コミットメッセージ、サーバーステータスアラート、オンラインストアでの新規購入に関するデータなど）を処理する必要があります。 通常、メッセンジャーでは、ユーザーはこれらのメッセージをチームのコミュニケーションのためにメインルームに送信するか（視認性を確保するため）、または別のルームを作成する必要があります（常時切り替えはあまり便利ではないため、誰も読むことはありません）。
Katoを使用すると、ユーザーは一度に多くの部屋にいて、そこで発生するすべてを見ることができるため、自動メッセージの問題は非常に簡単に解決されます。 人々が通信する部屋にこれらのメッセージを送信するのではなく、統合のために（または情報の種類-コード、財務、統計など）部屋の周りに作成することをお勧めします。 これにより、チームメンバーはノイズレベルを柔軟に調整できます。
放送通信
何千人、何万人もの従業員が勤務する大企業では、多くの人が個人的にお互いを知らないかもしれませんが、それにもかかわらず、彼らは互いにコミュニケーションをとるべきです。 たとえば、技術的な障害が発生した状況では、干渉している従業員はサポート部門に連絡する必要があります。
これを行うために、彼は特定のエンジニアの名前を知る必要はありません-通常、彼は単に
support@companyname.com
ような一般的なアドレスにメールを書くだけで、現時点で利用可能な専門家が彼の問題に対処し始めます。 加藤は、チーム全体と1人の「ブロードキャスト」通信の同様の可能性を実装します。
必要なユニットの従業員がメッセージに注意を払うために、このユニットを結合する部屋の名前を言及する必要があります（たとえば、すべて同じサポート）。 したがって、必要なユニットの誰かが関与するトピックのディスカッションがある場合、名前を知らなくても、プロファイルの専門家をチャットに「呼び出す」ことが非常に便利です。
このような部屋は、特定の範囲のタスクを担当するチームとそれに含まれる個人との間の一種のバッファーとして機能します。
チームメンバーは、緊急事態で他の従業員が呼び出す部屋への参照に誰がどのように応答するかについても同意する場合があります。 したがって、そのような状況が発生した場合、何らかの理由で部屋に言及しても責任のある従業員からの反応が生じない場合、チームの作業プロセスの組織の質の問題を提起することは理にかなっています。
検索の重要性
インスタントメッセンジャーの一般的な問題は、必要な情報の検索が非常に難しいことです。 さまざまな議論に参加する人は、メッセージ履歴で必要なデータやファイルを簡単かつ簡単に見つけることはできません。 代わりに、彼はまず目的のチャットを開き、次にctrl + fを使用して履歴を検索し、「勝利の終わり」にロードする必要があります。
加藤では、メールのようにすべてのチャットルームで一般的な検索を実装することでこの問題を解決しました。ユーザーは必要なキーワードを入力し、使用されたチャットルームを確認します。
今日は以上です。見てくれてありがとう。 今後の記事では、加藤アーキテクチャと、サードパーティのサービスとのメッセンジャー統合の構成について説明します。