日程調整に関するコミュニケーション

「会議の日程調整」というタスクのペインポイントについて興味深い分析

僕なりの整理

• 会議の参加者に対してコミュニケーションを取りたいケースがある
  • 例
    • 予定の変更
    • アジェンダの共有
    • 議事録の共有
• カレンダーツールとコミュニケーションツールが統合されていない時に苦痛が起きる
  • 例: カレンダーがGoogle Calendar、コミュニケーションがSlack
  • カレンダーツール側で、会議の参加者を確認する
  • コミュニケーションツール側でその参加者が全員入ったグループチャットを作成する
    • Slackの場合、複数名の相手を指定してDMすることで無名のコミュニケーショングループが作成できる
      • 既にあるのかどうかを確認する手段がない
      • 名づけのコストなく作れるのはよい所だが、数が増えると名前がなければ識別できなくなる
        • 名前を付けたところで人間による検索のコストが掛かるのは同じ
      • カレンダー上での個人IDとSlack上での個人IDが一致しない場合、人間による変換コストがかかる
  • グループチャット上でコミュニケーションした結果をカレンダーツール側に人間が書き戻す必要がある。
• カレンダーツールとコミュニケーションツールが統合されている場合
  • 例: サイボウズGaroon
    • カレンダーツールに会議の予定を登録する→掲示板的なものできる→コミュニケーションはそこでやる
    • 予定登録の段階で予定名でコミュニケーショングループが作成される、と言える
    • もちろんデメリットもある
      • イベントごとに掲示板が分かれるので同じメンバーで繰り返し会議を行う場合に、それぞれの議論が違う掲示板に分かれる
      • 前のイベント(とその掲示板)にパーマリンクがあるので、そのリンクを新しいイベントの掲示板に張る運用で回避

備考

• 話者の投稿を読んだ後、空き時間を探すことがペインポイントだと誤解する人が2人出たのが興味深い

  • 機能がある状態を経験してからない状態に移動した場合にはペインに気づきやすいが、元からない状態の人には気づきにくい

• カレンダーツールがコミュニケーション機能を持っていないのが問題の根なのでコメント欄を付けるよいのでは案

  • 全てのページにコミュニケーション機能を付けようとした LUNARR が思い出される
    • 抽象度の高すぎるサービスは学習コストが高い

• 通知がメールではない方法で送られて欲しい案

  • 人によって都合のいい通知フロントエンドが異なるのでAPIの標準化が起こるべきかなぁ

#グループウェア