Kashi が画面に出すものは、 およそ 「ダッシュボード」 と呼ばれる類のものとは、 似ているようで似ていない。 数値はある。 グラフもある。 けれど、 そこに表示されているのは 「誰が何を言ったか」 ではない。 もっと前の段階 — 会話そのものが持っている 形、 — を、 拾い上げて並べているにすぎない。
これは技術的な制約ではなく、 設計上の選択である。 私たちはあえて、 内容を読み取らないようにしている。 もっと正確に言えば、 内容を製品の表面に出さないようにしている。 その理由を、 この章では順を追って書いていきたい。
「構造」 とは、 何を指しているのか
対話の構造、 という言葉は、 はじめて聞く人にはやや抽象的に響くかもしれない。 だから、 具体的にどんなものを指しているのか、 先に並べておく。
たとえば、 ある会議の 45 分間で、 8 人のメンバーが何回ずつ発言したか。 そのうち、 質問の形をとった発話が何回あって、 そのうち応答が返ってきたものが何回あったか。 ひとりが話したあと、 次の人が話し始めるまでに平均何秒あったか。 沈黙が 4 秒を超えた瞬間が、 会議のどこに集中していたか。 同じ話題が、 ひとつの会議の中で何回戻ってきて、 そのつど結論を伴っていたか、 伴っていなかったか。
これらはどれも、 何を話したか を読まずに測れる量である。 録音から書き起こした文字列を見るのではなく、 会話のリズム、 ターンの取り方、 質問と応答の対応関係 — つまり 形 だけを見ている。 内容を見ずに形を見る、 というのが、 私たちが 「構造」 と呼んでいるものの正体だ。
Fig.01 を見ていただきたい。 左側にあるのは、 ある会議の発話の生データである。 これは Kashi の中で 確かに通り過ぎる。 けれど、 製品としての画面上には出てこない。 右側の、 数本の指標と、 「EMERGING (兆候あり)」 という小さなラベルだけが、 画面に上がる。
左と右のあいだに引いた点線を、 私たちは内部的に 「膜 (membrane)」 と呼んでいる。 内容は膜の左で必要な分だけ処理され、 形に変換されたあと、 右の世界にだけ届けられる。 膜は意図的に 透けない。
なぜ、 内容を見せないのか
「対話の問題を早く見つけたいのなら、 内容も見たほうが情報量は多いはずだ」 という反論は当然ある。 実際、 私たちも初期にはそう考えた時期があった。 けれど、 ふたつの理由で、 そこには戻らないと決めた。
ひとつは、 倫理の問題だ。 マネージャーが部下の発言の全文を見られる製品は、 結果として、 部下が 「見られている」 と感じる職場をつくる。 これは私たちが解こうとしている問題 — 対話が静かに崩れていくこと — を、 むしろ加速させる方向に働く。 監視の感覚が立ち上がった瞬間、 部下は本音を話さなくなる。 本音を話さない会議に、 構造として救えるシグナルは残らない。
もうひとつは、 もっと現実的な理由で、 内容を見せても、 マネージャーが 「次に何をすればいいか」 はわからないからだ。 「山田さんが先週の会議で 「忙しい」 と 3 回言いました」 という情報は、 ふつうの人事担当者にとっては扱いに困るデータでしかない。 一方で、 「営業チームで、 質問→応答率が 3 週連続で下がっている」 という形の情報は、 行動につながる。 内容は判断材料にならず、 構造は判断材料になる、 という非対称が、 そこにはある。
顕微鏡で覗き込むのではなく、 体温計を当てる。 Kashi は前者ではなく、 後者であろうとしている。
誰が、 どこまで見えるのか
構造だけを見せる、 と言っても、 その構造を 「誰に」 「どの粒度で」 見せるかは、 また別の設計判断になる。 ここでも私たちは、 「見せる量」 を最小に寄せている。
Fig.02 は、 役割ごとに何が画面に届くかを示した図だ。 個人 (member) は、 自分自身の対話のリズムだけを見られる。 マネージャー (manager) は、 自チームの集約された傾向を見る — けれど個人ごとの内訳は見ない。 人事 (HR) は、 全社の構造的なシグナルを見る — けれど、 どのチームの、 どの会議で、 という解像度では見ない。 経営 (CxO) はさらに上の、 組織全体の風向きだけを見る。
これは Kashi の設計のなかでも、 もっとも頻繁に議論された部分のひとつだ。 「もう少しだけ細かく見せたほうが、 マネージャーは助かるのではないか」 という意見は、 顧客側からも、 私たちの内部からも、 繰り返し上がる。 そのつど、 私たちは戻る。 一段細かく見せた瞬間、 個人が特定されはじめる。 個人が特定されはじめた瞬間、 これは別の製品になる。 — 私たちが作りたかったのは、 その別の製品ではない。
確からしさを、 そのままの粒度で渡す
もうひとつ、 Kashi が頑なに守っている設計がある。 それは、 シグナルの 「確からしさ」 を、 強い言葉に置き換えずに、 そのままの粒度で渡す、 ということだ。
多くの分析ツールは、 結果をひとつのスコアや、 ひとつの色 (赤・黄・緑) に丸め込む。 ユーザーにとってわかりやすいから、 という理由で。 けれど、 対話のように、 同じパターンでも何通りも読める現象を、 ひとつの色に丸めるのは危ない。 「赤」 が出たから誰かが辞めそうだ、 という単純化は、 製品が 判断者の代わりに判断する ことを意味する。 私たちはそれを引き受けない。
Kashi は代わりに、 シグナルを 段階 で表現する。 「INSUFFICIENT」 はデータが足りない、 「WEAK」 は微弱な傾向、 「EMERGING」 は兆候が立ち上がってきている、 「STABLE」 は安定して観測されている。 — どの段階にも、 色だけでなく必ず言葉のラベルがついている (色覚への配慮として、 そして、 色を超えて意味を残すために)。
そして肝心なのは、 これらは 結論ではなく、 始まりの言葉 として渡される、 ということだ。 「EMERGING が出ている」 という事実は、 マネージャーに 「対話してみるきっかけ」 を渡すだけで、 「この人を評価対象から外せ」 という指示にはならない。 結論は人間が出す。 Kashi はそこに立ち入らない。
見せないものについて、 もう一度
ここまで書いてきたのは、 ほとんど 「何を見せるか」 ではなく 「何を見せないか」 の話だった。 製品の中身を語るときに、 普通は機能の一覧、 画面のスクリーンショット、 統合先のサービスのロゴ — そういうものが並ぶ。 私たちが代わりにここに書いておきたいのは、 Kashi が 絶対にやらないこと のリストである。
Kashi がしないこと
個人ごとの発話内容を、 マネージャーや人事の画面に表示することはしない。 集約された数値のみを渡す。
退職予測スコアを出すことはしない。 「この人は辞める」 と製品が宣言する状況は、 本人にも組織にも、 利益にならない。
評価査定のための材料として、 シグナルを切り出して渡すことはしない。 Kashi の出力は、 評価制度のなかでは使われない設計になっている。
アラートを赤や警告音で煽ることはしない。 静かな段階表示と、 文字のラベルだけを渡す。
これらは将来の機能要望でも増設しない約束として、 内部の permanent-ui-principles という文書に書きつけてある。
結局、 ユーザーの画面に何が出ているのか
ここまで読んでくださった方には、 当然のように疑問が残ると思う — 「では結局、 画面に映るのはどんなものなのか」 と。 言葉では言い尽くせないので、 第 4 章のあと、 関心を持っていただけるなら、 実際に動く画面を見ていただきたい (※ 現在は demo Inc. の仮想データで構成しています)。
ただ、 ひとつだけ書いておきたいのは、 Kashi の画面は、 思っているよりずっと 静かだ ということだ。 数値は少ない。 色は薄い。 文字は短い。 — そこに余白を残しているのは、 私たちが見えていないことの方が、 まだまだ多いからだ。 製品が大声で何かを宣言してしまうと、 ユーザー側が考える余白を奪ってしまう。 だから、 静かなままにしている。
対話の構造を見る、 というのは、 結局のところ、 組織の 体温 を測ることに近い。 体温計は熱を出さないし、 治療もしない。 ただ、 熱があるかどうかを、 そっと教える。 Kashi がしていることは、 ほとんどそれだけだ。 — そして私たちは、 それで十分だと信じている。