NISHIO Hirokazu[日本語][English]

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

2024-09-10にサイボウズでは社内ワークショップにブロードリスニングを活用した 安野さんの日テレでのブロードリスニング放送(日テレNEWS×2024衆院選×ブロードリスニング)で認知度があがり、SNS上で「ブロードリスニングは公共分野だけに限らず民間企業の中でも使えるのではないか」という議論がちらほらみられた。実際に民間企業の中で使った事例があるので紹介しよう

企業全体のチームワーク向上のための企業文化(Culture)の理解と共有を目的として、100人のマネージャーが参加するワークショップが行われた ワークショップの目的: 社員が自らの言葉で語り、共有・理解を深めることで、組織全体の共通認識を育成する。

ワークショップの内容

  • 個人ワーク: 5つの企業文化を体現する「行動」について、まず個人で書き出す
    • 抽象的な議論ではなく具体的な行動にフォーカスすることで地に足のついた議論にするため
  • グループワーク: 5人ずつ20個のグループに分け議論をする
    • 各グループには議論に参加しない書記がつき、議論の記録をkintoneに書く
  • その議事録をTalk to the Cityで可視化して懇親会でシェアする
    • 5つの企業文化それぞれに分けて5つのレポートを作成する
    • 15時にデータが来て17時にレポートが返るタイトなスケジュール

出力されたクラスタの例 imageimageimage imageimage

技術的な話

データソースとして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での出力を選べる
    • image
    • Google Spreadsheetにも同様の機能があるはず
  • なおUTF-8で書き出すと今度はExcelがShift-JISだと想定してて文字化けになったりする、この問題は"BOM付きUTF-8"にすることで解決できるが、たぶんTTTCが「BOMがついてること」を想定していない実装になってるのでエラーになりそう。
    • 今回のケースでは、書き出したCSVを直接TTTCに食わせるのではなく、前処理を行うPythonスクリプトを自作してたのでそこの部分で吸収した 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で一つ死んだ
    • 残りの処理は問題なし
    • visualizationのところが同時に実行されると確実に死ぬようだ
      • これも死んだものだけ再実行すればいいだけ
  • この程度の規模であればエラーにならなければ5〜6分で完了する。
    • 実際データが来てから5件のレポートのver.1を作ってシェアするまで30分だった(その後問題が発覚したが)

TTTC:empty vocabulary

  • 事前テストで発覚した問題
  • clusteringに発生するエラー
    • ValueError: empty vocabulary; perhaps the documents only contain stop words

    • 解決に割と悩まされた
  • 2024-10-29現在は日テレNEWS×2024衆院選×ブロードリスニングのバージョンのソースコードが公開されてるのでそれを使うのが解説が楽と思う

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

  • 事前テストで発覚しなかった問題
  • 事前テストでLLMが生成した議事録はこのようなものだった
    • 山田:それでは、企業文化を体現する行動についてディスカッションを始めましょう。「理想への共感」がテーマですね。まず、皆さんがどのように理想を共有しているか、ご意見を伺いたいです。

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

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

    • 重要な特徴として「一人の一塊の発言が一行になっている」
  • 実際の議事録は各グループごとに異なる書記が異なるフォーマットで記録した
    • 例: :
森:法務部としては、企業全体の法的リスクを最小限に抑える
  ことが理想です。そのためには、部全体が一丸となって高
  い倫理基準を守ることが重要です。これを実現するために
  定期的な内部トレーニングやワークショップを開催してい
  ます。
    - こういう単語途中での改行とか見た目のための全角空白文字が入れられるとデータサイエンス的には困る〜〜ということは事前に説明しておくべきだった
  • 「一人の一塊の発言が一行になっている」という特徴を仮定して行ごとに刻んで処理するプロセスにしていたためとても困る
    • 実際のタイムラインとしては15:10にデータが来て、見た目に不信感を感じつつも一旦5レポートを作り終わったのが15:40
    • その後不信感の原因を究明して15:42に上記の文中改行と全角空白インデントに気づいた
    • この種のフォーマットを一人一行形式にクレンジングするコードを開発するのが正攻法
      • その場合レポート生成の再実行に30分掛かるとして、48分で開発と前処理を終わらせないといけない
      • 手動で気合いで直すのも検討
      • 開発する目線で検討したが、インデントの入り方もまちまちなので、結局これも実装するならif文で実装するよりLLMで実装したほうがいい
        • であるなら時間がない中で新規開発をするよりは抽出部分のLLMに任せる方がいいと判断し、「議事録全体を一つの投稿」とみなしてレポート作成することにした
        • それで一応時間内にまともな見た目にはなった、ただし
          • 各点の「原文表示」で議事録全体が出るようになってしまう
          • 抽出された意見の点は格段に減ったと思う

TTTCの「離れ小島クラスタ」問題

  • 離れ小島ができるのは、そもそも元データに変なものが入ってるか、うまく抽出できなかったとかにLLMが変なものを生成しているから
  • おかしな出力が出た場合にはプロンプトを修正するイテレーションを何度か回す必要がある

前処理の必要性

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

良い議論ができる場を可視化の後につける

  • これができるとベター
  • ここでの議論を取り込んで第二弾の可視化をやるなどが考えられる
    • 台湾のvTaiwanでも可視化と議論を何回か繰り返している

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

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

(C)NISHIO Hirokazu / Converted from Markdown (ja)
Source: [GitHub] / [Scrapbox]