サイボウズ社内でのブロードリスニング活用事例

企業全体のチームワーク向上のための企業文化（Culture）の理解と共有を目的として、100人のマネージャーが参加するワークショップが行われた

ワークショップの目的: 社員が自らの言葉で語り、共有・理解を深めることで、組織全体の共通認識を育成する。

ワークショップの内容

個人ワーク: 5つの企業文化を体現する「行動」について、まず個人で書き出す

抽象的な議論ではなく具体的な行動にフォーカスすることで地に足のついた議論にするため

グループワーク: 5人ずつ20個のグループに分け議論をする

5つの企業文化それぞれに分けて5つのレポートを作成する

15時にデータが来て17時にレポートが返るタイトなスケジュール

出力されたクラスタの例

技術的な話

データソースとしてkintoneを選んだことについて

対象企業がサイボウズであって、社員全員kintoneのアカウントを持っているという要因のウェイトが大きい

当初100人が個人ワークで同時並列的に書き出し、それを速やかにCSVにして分析するという要件だと思っていたので、kintoneがいいなとなった

最終的に「20チームの議事録」を分析する形になったので同時並列性への対処ははあんまり必要なかった

kintoneを使えば20件を束ねる作業を僕がする必要なくCSV書き出しをするだけで済むのはメリット

今後100人同時並列書き出しワークショップをやりたい人のために書いておくと、kintoneが使えない状況ならGoogle Spreadsheetでやると思う、これもCSV書き出しができるから

CSV書き出しの文字コード

日本語環境だとExcelなどの非Webアプリケーションとの互換性を考えてShift-JISになっていることが多い

Talk to the CityやOpenAIの側はUTF-8だと想定しているので下記のようなエラーになる

UnicodeDecodeError: 'utf-8' codec can't decode byte 0x91 in position 31: invalid start byte

kintoneならここでUTF-8での出力を選べる

https://gyazo.com/c296965df13bc3999e4f434a64752e91

Google Spreadsheetにも同様の機能があるはず

なおUTF-8で書き出すと今度はExcelがShift-JISだと想定してて文字化けになったりする、この問題は"BOM付きUTF-8"にすることで解決できるが、たぶんTTTCが「BOMがついてること」を想定していない実装になってるのでエラーになりそう。

今回のケースでは、書き出したCSVを直接TTTCに食わせるのではなく、前処理を行うPythonスクリプトを自作してたのでそこの部分で吸収した

code:py

with open(filename + ".csv", "r", encoding="utf_8_sig") as csvfile:

reader = csv.reader(csvfile)

next(reader) # skip one line

for row in reader:

...

事前テストの重要性

LLMで仮想の議事録を生成して事前に実験した

事前の実験の通りに行かなかったところもいくつもあったが、当日対処することが減らせてよかったと思う

上記の文字コードの話もその一つ、事前に試したことで先に気づいて対処できた

Azure OpenAI Service

TTTCがOpenAIのAPIを直接叩く想定になっている

Azure OpenAI Serviceに切り替えるのに割と手間取った

こういうの非エンジニアが「切り替えるだけだから簡単でしょ」とか思いそうだけど、無償でやっていい作業感ではないので、受託でやるならAPI切り替えは別料金で+50万取った方がいいw

この修正差分はうまいこと共有したい

並列実行

5レポートの作成を並列実行した

レポート5枚でも時間は5倍にならない(並列実行できるから)

Extructionを5つ並列実行してRate limitで一つ死んだ

今回のケースでは再実行でOKだった

残りの処理は問題なし

visualizationのところが同時に実行されると確実に死ぬようだ

これも死んだものだけ再実行すればいいだけ

この程度の規模であればエラーにならなければ5〜6分で完了する。

実際データが来てから5件のレポートのver.1を作ってシェアするまで30分だった(その後問題が発覚したが)

事前テストで発覚した問題

clusteringに発生するエラー

ValueError: empty vocabulary; perhaps the documents only contain stop words

解決に割と悩まされた

議事録のフォーマットの問題

事前テストで発覚しなかった問題

事前テストでLLMが生成した議事録はこのようなものだった

山田：それでは、企業文化を体現する行動についてディスカッションを始めましょう。「理想への共感」がテーマですね。まず、皆さんがどのように理想を共有しているか、ご意見を伺いたいです。

森：法務部としては、企業全体の法的リスクを最小限に抑えることが理想です。そのためには、部全体が一丸となって高い倫理基準を守ることが重要です。これを実現するために、定期的な内部トレーニングやワークショップを開催しています。

小林：クリエイティブ部でも共感できる理想を作ることが大切です。特に、クリエイティブなアイデアを生み出すためには、成功へのビジョンを全員で共有することが不可欠です。今年のキャンペーンでは「独創性の追求」という共通のテーマを掲げて行動しました。

重要な特徴として「一人の一塊の発言が一行になっている」

実際の議事録は各グループごとに異なる書記が異なるフォーマットで記録した

例:

code::

森：法務部としては、企業全体の法的リスクを最小限に抑える

ことが理想です。そのためには、部全体が一丸となって高

い倫理基準を守ることが重要です。これを実現するために

定期的な内部トレーニングやワークショップを開催してい

ます。

こういう単語途中での改行とか見た目のための全角空白文字が入れられるとデータサイエンス的には困る〜〜ということは事前に説明しておくべきだった

「一人の一塊の発言が一行になっている」という特徴を仮定して行ごとに刻んで処理するプロセスにしていたためとても困る

実際のタイムラインとしては15:10にデータが来て、見た目に不信感を感じつつも一旦5レポートを作り終わったのが15:40

その後不信感の原因を究明して15:42に上記の文中改行と全角空白インデントに気づいた

この種のフォーマットを一人一行形式にクレンジングするコードを開発するのが正攻法

その場合レポート生成の再実行に30分掛かるとして、48分で開発と前処理を終わらせないといけない

手動で気合いで直すのも検討

開発する目線で検討したが、インデントの入り方もまちまちなので、結局これも実装するならif文で実装するよりLLMで実装したほうがいい

であるなら時間がない中で新規開発をするよりは抽出部分のLLMに任せる方がいいと判断し、「議事録全体を一つの投稿」とみなしてレポート作成することにした

それで一応時間内にまともな見た目にはなった、ただし

各点の「原文表示」で議事録全体が出るようになってしまう

抽出された意見の点は格段に減ったと思う

離れ小島ができるのは、そもそも元データに変なものが入ってるか、うまく抽出できなかったとかにLLMが変なものを生成しているから

おかしな出力が出た場合にはプロンプトを修正するイテレーションを何度か回す必要がある

前処理の必要性

今回の議事録フォーマットの問題もそうだけども、標準的なTTTCのワークフローに適したデータが来るとは限らないので、前処理プロセスを挟むことを想定しておいた方が良いかもしれない

これができるとベター

ここでの議論を取り込んで第二弾の可視化をやるなどが考えられる

台湾のvTaiwanでも可視化と議論を何回か繰り返している

基本的には顔の見えないX/Twitterでの放言より、社内での議論の方が暴言のフィルタリングなどの面倒がなくて楽

ただしもちろん、同じ組織内の人が同じものを見てフィルターバブル化するリスクはある