チャットの中に、小さなアプリを置く
私たちは社内のコミュニケーション基盤に Element を使っています。その Element には「ウィジェット」という、あまり知られていない機能があります。チャットの画面のなかに Web の画面を組み込み、会話と地続きの小さなアプリとして動かせる仕組みです。日報の運用を題材に、この機能で何ができるのかを図で追いかけてみます。
チャットは「会話する場所」だけではない
私たちは社内のチャットに Element を使っています。Element は Matrix というオープンな規格にもとづいたチャットツールで、大きな特徴は自分たちのサーバーで動かせることです。やり取りされる情報が自社の管理下に留まるため、業務の中身に踏み込んだ使い方をしやすい、という判断でこれを選んでいます。
使い込むうちに気づいたのは、チャットツールに求めているものが「会話」だけではない、ということでした。日々の業務では、チャットと別のシステムのあいだを行ったり来たりする時間が意外と多くあります。別のタブで作業をして、チャットに戻って報告する。そのたびに、少しずつ手間と転記ミスが積み上がります。
会話の隣に、そのまま使える小さな道具が置けたら。
それを実現するのが「ウィジェット」です。
ウィジェットとは何か
ウィジェットは、チャットルームの中に Web ページを組み込む機能です。Element の画面は大きく「ルームの一覧」「会話のタイムライン」「右側のパネル」に分かれていますが、このうち右側のパネルに、任意の Web 画面を表示できます。
図 1 ウィジェットは、会話のタイムラインの隣にあるパネルに表示される。会話から目を離さずに触れる位置にある、というのがこの機能の出発点。
ここまでなら「チャットの横に Web ページを貼れる」だけの話です。実際、社内ポータルや監視画面をそのまま貼るだけでも十分に役立ちます。ただ、ウィジェットにはもう一段があります。組み込んだ画面とチャットのあいだで、データをやり取りできるのです。
図 2 ウィジェットは2階建て。ページを貼るだけの1階と、チャットとデータをやり取りする2階がある。後者に踏み込むと、表示のための機能が業務のための道具に変わる。
「誰として」動くのか
チャットに書き込める仕組みと聞くと、勝手に動いてしまわないかが気になります。ここがウィジェットのよくできているところで、ウィジェットはそれを開いている本人の権限で動きます。しかも、できることを事前に本人へ申告し、承認を得なければ何もできません。
図 3 ウィジェットは権限を自分で決められない。利用者の承認を経て、しかも本人の名前で動く。この2点が、あとで説明する「ボット」との決定的な違いになる。
この「本人として動く」という性質は、地味に見えて重要です。誰が書いたのかがそのまま記録に残るので、報告や承認のように発言の主が意味を持つ場面で使えます。
ボットとは役割が違う
チャットの自動化と聞いて多くの人が思い浮かべるのは「ボット」でしょう。ウィジェットとボットは競合するものではなく、担当する場所が違います。
図 4 同じルームに投稿していても、投稿の主体と動くタイミングが違う。人がいなくても動くべきものはボット、人の操作を伴うものはウィジェット、という線引きになる。
どんな場面で効くのか
私たちが検証のなかで手応えを感じたのは、次のような場面でした。共通しているのは、チャットと別のシステムを往復していた作業が、会話の場に集約されることです。
監視画面の共有
サービスの状態を映したダッシュボードを、関係者が集まるルームに常設する。異変の話をしながら同じ画面を見られる。
手順書・ポータルの参照
社内ポータルやよくある質問を貼っておく。「あの手順どこでしたっけ」を会話の中で解決できる。
障害対応の進行共有
「対応開始」「復旧」をボタンで押すと、そのまま経過がタイムラインに残る。あとから時系列を追いやすい。
投票・見積もり
優先度や工数をその場で選び、集計結果だけをチャットに流す。打ち合わせが会議室の外へ出ていかない。
定型の報告フォーム
日報や作業報告のように、書式が決まっているものを入力欄に置き換える。書き方の揺れがなくなる。
たまった投稿の集計
ルームに流れた投稿そのものを数え、状況を可視化する。別で台帳を作らなくてよい。
日報の書式がそろわない、という悩み
実際に私たちが手をつけたのは、日報でした。終業後に決まった書式で日報を投稿してもらう運用をしていたのですが、人によって書き方が揃わないという問題が続いていました。項目が抜ける、時間の書き方が違う、そもそも書式が古い。書く側が悪いというより、「テンプレートを見ながら手で書く」という方法に無理があったのだと思います。
そこで、日報の入力フォームをウィジェットとして日報用のルームに置いてみました。フォームを埋めて送信すると、いつも同じ形に整えられた日報が、本人の名前で投稿されます。
図 5 書式を「守ってもらう」のではなく、フォームを通すことで崩れた日報を作れなくする。入力を助けることが、そのまま品質の担保になる。
気をつけたこと
既存の手書きの日報と見た目が変わらない形で投稿されるようにしました。スマートフォンなど、ウィジェットを使えない環境から手で書く人がいても、タイムライン上で不揃いにならないためです。新しい仕組みを入れるときに、それを使えない人の側が困らないようにする、という考え方です。
投稿がそろうと、数えられるようになる
書式がそろうと、次の景色が見えてきます。日報の投稿そのものを数えれば、誰がいつ提出したかが分かるのです。そこで、同じルームにもう一つ、集計用のウィジェットを置いてみました。
こちらは投稿する機能を持たない、読むだけのウィジェットです。ルームに流れた日報を読み取り、メンバー別・日付別の提出状況を一覧にします。新しくデータベースを用意する必要はありません。集計のもとになるのは、チャットに残っている投稿そのものだからです。
図 6 集計のもとになるのは、チャットに残っている投稿そのもの。別の台帳を作らないので、日報を書く手間はそのままで、状況だけが見えるようになる。
数字の扱いについて
この手の集計は、数え方の前提を隠さないことが何より大事だと考えています。私たちのウィジェットは、集計に使った件数と対象期間を画面に必ず表示し、データが足りないときは「足りない」と警告を出すようにしました。休暇や祝日は差し引いていないため、あくまで参考値である旨も画面に書いてあります。もっともらしい数字が独り歩きするほうが、数字が出ないことより危ういからです。
できること、できないこと
便利な一方で、ウィジェットには向き不向きがはっきりあります。検証を通して分かった線引きをまとめておきます。
| 向いていること | 向いていないこと |
|---|---|
| 人が操作する画面を、会話の隣に置くこと | 人がいないときに動くこと。開いていなければ何も起きない |
| 書式の決まった入力を、崩れないように助けること | 定期実行や常時監視。これはボットの仕事 |
| 操作の結果を、本人の名前でチャットに残すこと | 利用者が権限を拒否した場合の動作。強制はできない |
| ルームにたまった投稿をその場で集計して見せること | 誰でも勝手に設置すること。ルームの管理権限が要る |
| 外部の画面をそのまま貼って共有すること |
言い換えると、人の操作を伴うものはウィジェット、人がいなくても動くべきものはボット。この境界線さえ押さえておけば、どちらを選ぶかで迷うことはあまりありません。
ウィジェットは、どこで動いているのか
「チャットに機能を足す」と聞くと、チャットサーバに何かを組み込む姿を思い浮かべるかもしれません。実際、私たちも設計を始めるまではそう思っていました。ところが調べてみると、まったく違いました。
チャットサーバが持っているのは、
URL の文字列、たった1行だけです。
ウィジェットの実体は、ごく普通の Web ページです。チャットサーバはそれを取りに行きませんし、実行もしません。「このルームには、このアドレスの画面が貼ってある」というメモを預かっているだけです。ページを取りに行くのは、利用者のブラウザのほうです。
図 7 ウィジェットはチャットサーバを直接呼ばない。投稿は必ず隣のチャット画面を経由する。だからこそ、利用者の承認を求められるし、本人名義の記録になる。
この構造には、運用上の大きな利点があります。ウィジェットを増やしても、チャットサーバの構成は何ひとつ変わりません。プラグインの追加も、再起動も要りませんでした。チャットは業務の生命線なので、機能を足すたびにそこへ手を入れる構成だったら、私たちは導入に踏み切れなかったと思います。
「器」と「中身」を分ける
もうひとつ、実運用に向けて考えていることがあります。
ウィジェットの中身は、使う部署やチームによって変わります。日報のフォームひとつ取っても、項目は組織ごとに違うはずです。一方で「どこに置き、どう配信し、どんな条件で埋め込みを許すか」という部分は、どこでも同じです。そこで、この2つを分けて管理する構成を検討しています。
図 8 基盤は「器」だけを持ち、中身が何であるかを知らない。この分け方だと、現場が自分たちのペースで更新でき、しかも失敗の影響がチャット本体に届かない。
この分け方には、思わぬ副産物がありました。中身が壊れていても、チャットは止まりません。 配信の設定は基盤側で固定されているので、ウィジェットのファイルに問題があっても、単にその画面が表示されないだけで済みます。チャット本体には波及しません。現場に更新の権限を渡していくうえで、この性質は重要だと考えています。
まだこれからの部分
ここまで書いた構成は、検証環境で確かめたところまでです。実際の運用環境へ展開するにあたっては、配信経路の権限をどう設計するか、誰がウィジェットの中身を変更できるようにするかなど、決めるべきことが残っています。ウィジェットは利用者本人の権限で動く画面なので、そこを預かる責任の設計は慎重にやるつもりです。
道具を、会話のある場所へ
ウィジェットが面白いのは、新しい機能を足しているというより、すでにある業務を、人が集まっている場所へ引き寄せている点だと思います。日報の例でいえば、やっていること自体は前と同じです。変わったのは、書式を人の記憶に頼らなくてよくなったことと、たまった投稿がそのまま集計のもとになったことでした。
紹介した2つのウィジェットは、まだ検証段階のものです。実際の運用に載せるにあたっては、権限の設計や、集計の対象範囲など、詰めるべきことが残っています。それでも、チャットを「会話する場所」から「仕事をする場所」へ広げていく方向には、まだ手をつけていない余地がかなりありそうだ、というのが今の実感です。
コメント