オープン会議の仕組みのご紹介 #TimeTreeアドカレ

はじめに

これは株式会社TimeTree Advent Calendar 2024 の18日目の記事です。

昨日は情報システムチームの @koala_time による「Jamfを導入してから少し経っての感想」でした。

https://qiita.com/koala_time/items/47aa5e54afe7f3eb92af

Koala は会社のPodcastでも度々仕事に対する想いや考えを発信しています。聞き応えのある内容満載なのでもしよければご視聴ください。

---

こんにちは。株式会社TimeTreeで COSO (Chief Organizational System Officer) という、組織OSを作る仕事をやっている @lazy です。

今日は、TimeTreeで運用しているオープン会議カレンダーという仕組みについて紹介します。

オープン会議とは

背景と課題

TimeTreeでは 「だれもためらわない環境を -オープンコミュニケーション」 をバリューに掲げており、社内情報はできるだけオープンにするようにしています。

業務の予定を管理するためにGoogleカレンダーを利用していますが、最近まではグループカレンダーをほとんど活用せずに運用してきました。そのため、どこでどんな会議が行われているかはそれぞれのメンバーのカレンダーを見ないとわからず、横断的に知るのは難しい 状況でした。

また、組織が拡大したことにより業務範囲も細分化されるようになり、それによって情報共有面での課題も出てきました。例えば、議論経緯を背景含め正確に把握するには会議に参加するしか方法がない、その結果会議参加者が増えてその時間に縛られてしまう人が増えてしまう、などです。

オープン会議カレンダーはこれらの課題を解決するために検討した仕組みです。

解決方針

とはいっても、実態は「オープン会議」という名前のグループカレンダーをGoogleカレンダー上で用意したよ、というものです。

名前の通り、メンバーには「社内で情報をオープンにできる会議はこのカレンダーで予定を作成していきましょう」という定義でアナウンスしています。

こうすることによって大抵の定例会議は可視化ができるようになり、「どこでどんな会議が行われているか」は解決できるようになりました。

一方、情報共有面での課題についてはこれだけで解消されるわけではありません。会議の中身は結局参加しないとわからないためです。

解決策としては文字起こしや会議録画を活用する方向性があり、これには tl;dv のようなSaaS活用が思い付きますし、ほとんどの場合そちらを選択されるのではないかと思います。

ただ弊社では、いきなり全社員にライセンスを配って各自で設定するような状況を避けたかったり、カレンダーから録画にアクセスしやすくしたかったりなどで、まずはGoogle Meetの録画機能を活かした形でこれを解決するように志向 しました。

その結果、Googleカレンダー上で可視化されたオープン会議の予定から、そのまま録画を閲覧できるようなUXになっています。

実現に向けた課題と対応

このUXを実現する上で課題になるのが 「Google Meetでは、録画や文字起こしが予定のゲストにしかデフォルトで共有されない」 という仕様です。録画の所有者が自分で他の人に共有する設定をしてくれれば解決しますが、毎回毎回録画ができるたびに設定しなくてはなりません。
しかも、録画はすぐ共有設定できるのではなく、数十分後にアップロードされた録画ファイルを開いて共有設定する必要があります。会議が終わってしばらくしてからの作業となるため忘れやすいですし、会議参加者は共有設定しなくても困らないため、忘れず実施しようというモチベーションも生まれづらいです。

そこでこの部分を解決すべく 「録画ができたら自動で全社員に共有設定する」 という自動化を行っています。

また、共有設定したタイミングでSlackのパブリックチャンネルで通知しています。

実装について

Google Cloud の Cloud Functions 上で定期処理を実行することで実現しています。

実装時に注意が必要なポイントには以下のようなものが挙げられます。

1. Google Meetの録画ファイルはマイドライブに作成されるため通常の権限ではファイルにアクセスできない

Google Workspaceのドメイン全体の委任 が必要になります。

ドメイン全体の委任を使えば組織内の誰にも成り代われるため個別に認可を取る必要がない一方、一歩間違えば情報セキュリティや社内秩序を乱し得るため取り扱いには非常に注意が必要なものです。

TimeTreeではなるべくドメイン全体の委任を設定しないようにしていますが、設定する場合はGoogle Cloudのアラート機能でサービスアカウントの稼働量を監視するようにしています。

2. Cloud Functions でドメイン全体の委任の認証処理が失敗してしまう

以下のようなケースでうまく認証処理が成功しない事象にあたってしまいました。

• Cloud Functions 上で
• node.js の google-auth-library を用いて
• サービスアカウントキーファイル使わずに
• Application Default Credentials でドメイン全体の委任の認証処理を行う

参考Issue

サービスアカウントキーファイルを発行すれば問題なく認証でき解決はするのですが、Cloud Functions で動かしているのにわざわざキーファイルを発行することに納得がいかず、結果的にこちらのコメント のようにアクセストークンを用いた実装をすることでサービスアカウトキーファイルの発行を回避しています。

※Issueの中ではpythonライブラリでは問題ないというコメントがあるのですが、現時点で未確認です。

3. 誰のマイドライブに録画ファイルが作成されるのか特定が難しい

ドメイン全体の委任の機能により組織内のユーザーに成り代わる場合、あらかじめ特定のユーザーを指定した上でアクセストークンを取得する必要があります。

そのため誰のマイドライブにあるのか特定した上でアクセストークンを発行したいものですが、これをスマートに取得する方法が現状よくわかっていません。

どういうことかと言うと

• Google Calendar APIで予定の作成者は取得できますが、録画ファイルは予定作成者のマイドライブに作成されるわけではない
• 予定に紐づく Google Meet であっても別途 Google Meetの方に「主催者」の概念がある
  • Google Meetの主催者は現状APIで取得することはできない
  • 必ずしもGoogle Meetの主催者のマイドライブに保存されるわけでもない

といった具合です。

もともと予定作成者のマイドライブにアクセスする実装で運用を開始しましたが、上記によりうまく共有されない事象が観測されたため、現在は予定作成者の方にMeetの自動録画の設定をしてもらうように案内することで事象の抑制をしています。

実装の方でゲスト全員のマイドライブを片っ端から調べれば概ね抑制できそうですが、あまりスマートでなく対処療法になってしまうため悩ましいところです。

もし詳しい仕様をご存知の方がいらっしゃったら、コメントなどで教えてくださると助かります🙏

運用してどうなったか

いわゆる公式の定例がオープン会議になっていくことによって会議参加者が適正化されていく事を主に想定していましたが、それだけではなく 勉強会のような予定もオープン会議でやっていこうという動きが見られるようになりました。

また、共有された録画ファイルを用いてChatGPTにサマリーしてもらう取り組みも連鎖的に始まっています。

プロンプトの相性もありそうですが tl;dv で生成されるまとめと比較して精度が高い という意見も出ており、この部分の自動化についても今後改善していきたいと思います。