- Teeting
- Teeting の構成要素
- Teetingツール比較
- TAFA の実現
- Teeting のカバー
- おわりに
- 更新履歴
- 参考文献
Teeting
Text + Meeting = Teeting
はじめに
このページでは Teeting の整備を目指す。
具体的には Teeting という概念、方法論、仕組み、ツールなどについてまとめ上げていく。Teeting の必要性やメリデメについても取り上げる。
Teetingとは
Teeting とはテキストのみで行う会議を指す。テキスト会議、筆談会議などと呼んでも良いだろう。
Teeting はチャットや Wiki とは異なるものである。コミュニケーションにおける「3つの拘束」 で言えば、「場所」「時間」「話題」のうち「時間」のみが拘束されたコミュニケーション形態だと言える。
Teeting を定義すると、次のようになる――制限時間の間、参加者全員が、「n個の議題が書かれているエリア」を自由に編集することで議論を行うという会議形態。つまり どの場所から参加してもいいし、どの話題に書き込んでも構わないが、会議時間だけは守れ(そして時間内に結論を出すよう立ち回れ) というものだ。
FAQ
Q: なぜわざわざテキストで会議するのですか?対面で会議すれば良いのではないですか?
Ans: 対面会議はコストがかかりすぎるから
- 対面会議は場所、時間、話題のすべてを拘束する
- 従来はこれしかやり方がなかったので頼らざるを得なかった
- 今は技術も方法論もあるので、このやり方から脱することができる
- 拘束を緩めることができる
Q: 拘束を緩める必要はあるのですか?
Ans: ある
- 時代は VUCA であり、多様性と包摂が求められている
- 色んな人に考慮できるようにならなければならない
- そのためには Slack(余裕)と MBMP を確保する必要がある
- MBMP …… My Base and My Pace。自分のベース(やり方)とペース(取り組み方)。
- Slack と MBMP を確保する方法は色々あるが、それらとは無縁な「対面会議の横行」にメスを入れるのは有効
Q: 顔を突き合わせてコミュニケーションを積むことが大事なのではないですか?
Ans: そのとおり、だが……
- コミュニケーションを積むのは、それ専用の時間を確保して行えば良い
- ここでは「雑談タイム」を紹介する
- しかし現状は会議のついでに行われてしまっている
- これは問題である
- コミュニケーションを積む行為に効率や生産性は無い
- たとえば家族や友人との団らんにはそれらを求めない
- 一方で会議にはある
- 両者が混ざっていると、前者に引きずられて後者も「効率や生産性どうこうの話ではなあるまい」なんてことになる
- コミュニケーションを積む行為に効率や生産性は無い
- 後者の会議にメスを入れるために、前者を切り離す必要がある
- 切り離した上で、個別に取り組めば良い
- Teeting は、後者(メスを入れる方)に関する取り組みである
- 前者(コミュニケーションを積む)を扱ったものではない
Q: なぜわざわざ Teeting をするのですか?完全に非同期で済ませれば良いのではないですか?
Ans: 非同期だけで過ごせるならそうするに越したことはない、だが……
- 非同期だけで過ごすことは難しい
- たとえば以下があると難しくなる
- 短納期かつ一人では進められない仕事
- 締切を持った(多数の)タスク
- いつ何にどれだけ取り組むかを自律的に制御できないメンバー
- 管理されずに成果を出せないメンバー
- つまりは組織や仕事の状況次第、メンバーの資質次第で困難になる
Q: Teeting が向いてない仕事もあるのではないですか?
Ans: それはそのとおりである
本文書は Teeting という「新たな手段」を提供するものであり、あらゆる仕事に対して向いていると主張しているわけではない。しかし、対面会議は現時点で唯一の手段として扱われがちである。何でもかんでも対面会議で押し通すのは適切ではない。
そういう意味で、Teeting は「対面会議だけが唯一ではない」というカウンターとも言えよう。
Teeting の意義
拘束についてはコミュニケーションにおける「3つの拘束」も参照。
拘束のゆるい打ち合わせ手段を提供できる
- 会議は拘束が強い
- 場所、時間、話題のすべてを拘束する
- リモートでも時間と話題を拘束する
- teeting は時間だけを拘束する
- 場所と話題は拘束しない
密度の高い議論を実現する
- そもそも従来の会議にはターン制コミュニケーション(話題の拘束)の限界がある
- 同時に一人しか発言できない
- 同時に一つの話題しか扱えない
- ゆえに 発言する要領を持つ者のみが、数多く存在する話題のうちのごく一部だけを議論することしか できない
- 全員が言いたいだけ言う、10個の話題すべてを検討する、3000文字の表現を要する主張を伝えるといったことができない
- Teetingだと突破できる
記録を残せる
というより残る (最初から残すやり方なので)。
非同期だと際限がないところに、有限時間を設ける
- 非同期で働くだけだと「しまり」がない
- 迅速な意思決定が行われず、だらだらしがち
- 個人で抱え込みがち
- そして後々になって問題が発生する
- かといって拘束の強い会議はやりたくない
- Teeting であれば、時間こそ拘束されるものの、両者を取れる
非同期派と同期派の折衷案として、両者がどちらも歩み寄れる
- 同期派は拘束の強さなどお構いなしに、対面口頭で話したい・話すべき
- 非同期派は逆に対面口頭などなくてもいいから、拘束を緩くしたい&緩くても回せるようにしたい・すべき
- どちらかに寄せると、他方がしんどい
- 両者のバランスを取れるのが Teeting
- 時間を拘束することで同期派に歩み寄る
- 話題を拘束しないことで非同期派に歩み寄る
Teeting の構成要素
Teeting において欠かせない要素を 3x3 で整理した。
全体像は次のとおり。
- 手段
- ワークスペース
- ツール
- ダイナミック・プロトコル
- 考え方
- トピック指向
- 箇条書き指向
- 同時編集
- 流れ・進め方
- TAFA
- PRIDS
- 参加者と意思決定者
ワークスペース
一つの Teeting を行う場所。n のページ(1-議題 1-ページ)が用意された場所と考えて良い。参加者は全員、ここに集まって各自が自由に立ち回る。
ワークスペースは以下から構成される。
- ロビー
- 参加者全員が通る動線(ホーム)
- 参加者一覧、議題一覧、意思決定者エリアなどを含む
- 議題ページ
- 1つの議題は1つのページで扱う
- 議題Aに関するネタは、ページAに書く
- ゴールレイヤー
- この Teeting で目指すゴール(目標)
- 以下三つのカテゴリに各議題を放り込む
- Layer1: Check。報告、連絡、情報共有、指示など「各自が確認すればいいもの」
- Layer2: Should。「この会議中に決定しきらなくてもいいが重視してもほしいもの」
- Layer3: Must。「この会議中に決めてしまいたいもの」
ツール
Teeting には専用のツールが必要である。たとえばワークスペースやトピック指向や同時編集をサポートしたツールでなくてはならない。
ダイナミック・プロトコル
ダイナミック・プロトコルとは筆者造語であるが、プロトコル(ある場におけるルールや振る舞い)を動的に決めて・変えて、それに従うことを指す。
Teeting には、従来の対面口頭にあった「非言語コミュニケーションの解像度」と「声を掛けるだけで伝えられる即時性」がない。しかも話題の拘束もなく、過ごし方は自由である。そんな会議において収拾をつけるためには、収拾をつけるための何らかのプロトコルを定義し、皆がそれに従って動くしかない。別の言い方をすれば、「プロトコルによって制御された自由行動」が求められる。
ここでいうプロトコルとは、細かいものである。下記のトピック指向や箇条書き指向といった粒度ではなく、もっと細かい。たとえば「このページでは最上部に投票エリアを設けて、各自賛成か反対かを一行で記す」「このページでは自分の意見を5行以内でぶら下げる」などである。このような細かいプロトコルを適宜定義し、また修正し、全員がそれに従うこと――それがダイナミック・プロトコルである。
Teeting は「書いて残す(というより残る)」からこそ、プロトコルが重要である。要求されるのは右記である――「皆が過ごしやすいプロトコル」を各自考えること、それを言語化して共有すること、誰かのプロトコルに従うこと、微修正を行い提案すること、このような動的変更を必要に応じて自然に行うこと。
トピック指向
話題AはページAで扱おうという考え方。Aに関するネタはページAに書く、というルールをストイックに守ると言っても良い。これにより各話題は各ページ内に存在することになり、言及・俯瞰・連携などがスムーズに行えるようになる。
また、話題Aに直接関係しない話題Bや話題Cを、ページAとは別のページに逃がす(ページBやページCをつくり、ページAからはリンクだけ張る)ことも容易い。これにより、ページAの中が散らかりにくくなり、しかしBやCについてもちゃんと残すことができる。
トピック指向を担保するためには、専用のツールが必要。ただのチャットやファイルで行うのは不可能に等しい。
箇条書き指向
Teeting では主に箇条書きを用いる。
箇条書きには以下のメリットがある。
- 情報を端的に記述できる
- 階層構造を記述できる
- 他者が意見をぶら下げるのが容易である
- 編集が容易である
- エディターの機能により並べ替えが行える
Teeting は n 人が同時に編集を行うものであり、また n 人全員に読んでもらう情報を書くものでもある。チャットのように、ただ文章を書き連ねるだけだと非常に読みづらく扱いづらい。箇条書きを使えば、かなりの部分を解決できる。
ただし箇条書きは通常の文章と比べて行間が失われがち(接続詞が無く前後の関係がわかりづらいなど)なため、端折りすぎには注意が必要。
同時編集
Teeting では参加者 n 人が同時に編集を行う。たとえば議題Aについて書くページAに、XさんYさんZさんがいて、三人とも思い思いに書き足している――といった光景は日常茶飯事である。
TAFA
TAFA(Timekeeping And FAcilitation) とはタイムキーパーとファシリテーションの意であるが、Teeting ではツールの力で(半)自動化する。
タイムキーパーについては、アジェンダプログラミングを行う。これは「いつ何をしてほしいか」を記述しておき、そのとおりにシステムにリマインドさせるというもの。たとえば「7分で各議題を読む」「30分で議論」「10分でサマリーまとめ」と記述して作動させると、システムが「もう3分で議論フェーズが終わります」「そろそろサマリーまとめに移ってください」などと教えてくれる。
ファシリテーションについては、意思決定者が行う。意思決定者は「参加者全員が見えている場所で」「参加者全員 or n人に」メンションを送ることができる。全員に見せるのは公平性と透明性のためである。
PRIDS
Teeting の流れは典型的には PRIDS に従う。
- Put(並べる)
- 元ネタを置くフェーズ
- 議題、議題の詳細説明や情報源、持論、質問 etc
- Read(読む)
- 並べられたネタ(議題とそこに並べられた記述)を読み込むフェーズ
- 事前に読み込んだ方が議論が捗るため推奨
- 頭を温める(ウォーミングアップ)の効果もある
- Insert(混ぜる)
- 議題ページに自分の意見を差し込むフェーズ
- コメント、返信、やり取り etc
- Decide(決める)
- 決定事項を決めるフェーズ
- 意思決定が必要であり、意思決定者が行う
- 多数決を取ったり誰かに委譲したりしても良い
- この議題はこうします、と意思決定者が書く
- Summarize(まとめる)
- ここまでの内容を、あとで参照・活用しやすくするためにまとめる
- まとめる際は「サマリーエリア」を別途つくって、そっちにまとめる
- ここまで書かれてきた内容はいじらない
- あくまでもサマリーエリアはワークスペース中につくる
- この場で正式な文章をつくる、といった意味ではない
Teeting は Read から行われる。つまり Put――並べるフェーズは事前に済ませておく。これはもっと言えば、Teeting で使うネタは各自が事前に準備しておくことを意味する。 説明は「読んでわかるもの」として準備しておく。会議中に改めて説明するなどといったことはしない。会議は議論と決定であり、プレゼンテーションではないからだ。読んでわかるものとして準備できなくてはならない。
Teeting は必ずしも Read から行う必要はない。極端な話、Teeting が始まるまでの間に Decide まで決まってしまうこともある。その気になれば Teeting を一度も開催せずに仕事を回すことも不可能ではない。
役割(参加者と意思決定者)
参加者と意思決定者に分かれる。
参加者は Teeting の間、ワークスペース上を自由にうろつく。どの議題に書き込んでいいし、何なら書き込まなくてもいい(あけすけに言えばサボっても良い)。もちろんサボりすぎると議論が成立しないため、成立する程度にパフォーマンスを出しているなら、という前提はつく。
意思決定者は Teeting の場を眺め、必要に応じてコントロールする立場である。たとえば議論が進んだ議題に対して「こうします」と決定を下したり、議論が進んでいない状況を鑑みて「議論Aはこの会議で決めてしまいたいので皆さんご意見お願いします」とフォローしたりする。また、ワークスペースをつくる(特に議題を決める)のも意思決定者であることが多い。
Teetingツール比較
Teeting ツールは以下を備える必要がある。
- トピック指向で使える
- 同時編集できる
Teeting 専用のツールは 2021/10/28 現在、まだ存在しないが、上記を備えたツールを Teeting 用途で使うことは可能である。そこで、本節では上記を備えたツールのいくつかを Teeting 目線で紹介する。
※なお TAFA について取り上げない。次節で取り上げる。
Scrapbox
- ★★★ ワークスペースのつくりかた
- 単にページを一つつくればいい
- 表示位置を気にする必要はない
- ★★★ 議題ページのつくりかた
- 単に
[議題A]
と書き、リンク先を拡充させればいい
- 単に
- ★★★ 同時編集とトピック指向のやりやすさ
- 同期速度が早い(ほぼリアルタイム)
- ページの作成・移動もシームレスに行える
- ★★☆ 表明
- 行ごとの更新者は記録されない
- ページごとに「誰が更新に加わったか」は記録される
- icon記法で表明できる(改ざん可能)
- ★★★ エディタの書きやすさ
- 非常に洗練されている
- Scrapbox記法
- Half-WYSIWYG
- ショートカットキーや機能のカスタマイズ
- 非常に洗練されている
- ★★☆ プレゼンス
- 参加者のカーソル位置が表示される
- どのページにいるかまではわからない
2021/10/28 現在、最も優れた Teeting ツールだと考える。
コンセプトも機能も先進的であるため、慣れは必要。説明してわかるものではないので、とりあえず使ってもらうことで慣れてもらうしかない。もし使ってもらえない場合、そのような人や組織では Teeting はできないと考えた方が良い。Teeting は書いてやり取りするため、これくらい当たり前に馴染めなければ話にならない。とはいえ、難しくはない。たとえば大学生や高校生でも問題無く使うことができる。スマホを扱えるリテラシーがあれば適応できる。
表明が少し弱いが、仕事は性善説で進むのが普通なので問題はない。バックアップや履歴は記録されているため、いざとなれば調査や復旧もできる。
OneNote
- ★★☆ ワークスペースのつくりかた
- 単にページを一つつくればいい
- 表示位置は気にする必要がある
- どのセクションに置くか
- ページ一覧の上に置くか、下に置くか etc
- ★★☆ 議題ページのつくりかた
- 議題ページをつくり、サブページとしてワークスペースページにぶら下げればよい
- いくつか考慮要素がある
- ワークスペースからリンクするかどうか
- サブページの並び順
- ★☆☆ 同時編集とトピック指向のやりやすさ
- 同期速度がスムーズではなくn秒以上のラグはざらにある
- ページの作成・移動はシームレスではない
- キーボードで完結できない
- ページ追加はデフォルトでは末尾(スクロールバーの一番下)に行われる
- リンクを繋ぐ際に、いちいちダイアログを開く必要がある
- ★★☆ 表明
- 行ごとの更新者は記録される
- icon記法はない
- ★☆☆ エディタの書きやすさ
- WYSIWYG
- 二次元でテキストエリアが可変
- 配置場所やサイズを気にするコストがかかる
- 人によってばらけたりする
- ブラウザだけで読み書きできない
- OneNote アプリを使う必要がある
- ★☆☆ プレゼンス
- 参加者のカーソル位置は表示されない
- どのページにいるかもわからない
エディタの書きづらさや同期の遅さ、ページ間のシームレスネスなど Scrapbox と比べると使いづらさが目立つが、Teeting ツールとしては十分活用できる。
Scrapboxほど独特ではないが、Outlook アプリでメールを処理する程度のリテラシーは必要であろう。これも実際に使ってもらって慣れてもらうのが早い。一番の障壁は「アプリを使って当たり前に利用できるようになるまで」。
Box Notes
- ★☆☆ ワークスペースのつくりかた
- .boxnotes ファイルを一つつくればよい
- 配置場所(ディレクトリ)を気にする必要がある
- ★☆☆ 議題ページのつくりかた
- 案1: ワークスペース内に書く
- o 手軽
- x ページ内が混雑する
- x 下部で編集している人が、上部での行追加・削除の影響を受ける(文章全体が上下する)
- 案2: 新たな .boxnotes ファイルをつくる
- o ワークスペースが混雑しない
- x ファイルをつくる手間
- x ファイルへのリンクの手間
- そもそもboxnotesファイル間リンクがサポートされていない
- permalinkをいちいち貼り付ける必要がある
- 案1: ワークスペース内に書く
- ★☆☆ 同時編集とトピック指向のやりやすさ
- 同期速度がスムーズでほぼリアルタイム
- ページの作成・移動はシームレスではない
- キーボードで完結できない
- そもそも単位が重たい(ファイル)
- リンクという発想がない
- ★☆☆ 表明
- 行ごとの更新者は記録されない
- icon記法はない
- ★★☆ エディタの書きやすさ
- WYSIWYG
- ★☆☆ プレゼンス
- ファイル単位で「今誰が開いているか」はわかる
- 参加者のカーソル位置は表示される
- どのページにいるかもわからない
OneNote と同様、Scrapbox ほど使いやすくは断じてないが、Teeting ツールとして活用できる程度のポテンシャルはある。
OneNote より優れているのは、画面がシンプルでわかりやすいこととと、閲覧者とカーソル位置の表示による「一緒にいる感」の充足である。
ネックなのは「ファイル」という概念を引きずっていることだ。 .boxnotes ファイルを誰がいつどこにどう置くかを考え実行せなばならない。整備できる者が裏で上手くやり、参加者には細かい管理を意識させないことが重要であろう。逆を言えば、整備できる者がいなければ、Box Notes による Teeting はおそらく成功しない。
まとめ
Teeting を行うなら、基本的に Scrapbox 一択である。この場合、Scrapbox に一刻も早く慣れてもらうことが肝心である。
OneNote や Box Notes など、他のコラボレーションエディタでも行えないことはない。しかし参加者が快適に行えるようにするためには相応の整備(ページやファイルをどう配備するか)と教育が必要である。特に整備が肝であり、整備できる者がいること、そして参加者達が整備結果に従って動けることが重要となる。
TAFA の実現
Teeting において TAFA(Timekeeping And FAcilitation) が重要であることは既に述べた。本節ではその実現方法を述べる。
既存の手段でタイムキープを実現
タイムキープとは、参加者がどの議題にどの順番でどれだけ時間かけて取り組むかを定義し、それに従うよう働きかけることを指す。
タイムキープはアジェンダプログラミングによって行う。
アジェンダプログラミングとは、アジェンダ(議題と費やす時間の組)を並べることで「このとおりに」「この時間配分で行う」旨を論理的に記述することをいう。何らかの規則で記述し、それをプログラムが読み取り書かれたとおりにアナウンスする。こうすることで、Teeting 参加者はタイムキープの手間から解放される。いわば事前に時間割を書いておけば、そのとおりにプログラムがタイムキープをしてくれるわけである。参加者はプログラムが言うこと(リマインドしてくること)に従えば良い。
アジェンダプログラミングの実現案
- スケジューラ案
- アジェンダを記述したスケジュール設定を用意する
- 参加者全員がこれを自分のスケジューラに import する
- googleカレンダーでできる?
- Slack リマインダー案
- Slack のリマインダー機能
- 参加者全員にリマインドできる
- リマインド用 Slack command を駆使してプログラミングすればよい
- Scrapbox UserScript案
- 以下のような UserScript をつくり、全員に使ってもらう
- 指定ページに書かれたアジェンダを読み込み、その経過を表示する
- どのページを読み込むかは設定として記載できるようにする
- ある Teeting A を行うときは、こうする
- 1: Aのアジェンダを記述する
- 2: UserScript 側で、1を読み込むよう修正する
- 以下のような UserScript をつくり、全員に使ってもらう
既存の手段でファシリテーションを実現する
ファシリテーションとは、意思決定者による参加者への働きかけを指す。
ファシリテーションにはアクティブとパッシブがある。アクティブは参加者に割り込んででも働きかける形式を指し、パッシブは意思決定者の意向を記述しておき参加者は各自のタイミングで見るという形式を指す。アクティブは強く働きかけられるが、拘束や監視が強い。パッシブは逆に拘束や監視は無いが、働きかけの効果は弱い(気づかれない、無視されるなど)
アクティブファシリテーションは割り込みによって行う。割り込みとして知られる手段は通知と通話である。通知としてはチャットにおけるメンションや、クライアントアプリにおける通知などが知られている。通話については、単に音声やビデオで常時接続しておき(必要に応じて)呼び出すだけである。
パッシブファシリテーションは情報共有が行える手段なら何でも良い。しかし、参加者が自分のペースで気軽にチェックできるようにするために、なるべく軽くて読みやすい手段が良い。また、働きかけの内容が長すぎると読む気が失せるため、長くならないよう抑える機能も求められる(文字数制限など)。ファシリテーションはあくまで働きかけであって、議論ではない(議論は Teeting として行うべきである)。議論を発生させないことは MUST である。
実現案
- ファシリテーションツイート(passive)
- Twitter のような短文投稿サービスが使えるという前提
- ある teeting A におけるファシリテーションを発信するアカウントをつくる
- A 開始時は皆これを見る(ウィンドウ並べて常に見えるようにしておく)
- A の最中、意思決定者はこれにファシリテーション内容をつぶやく
- ファシリテーションチャンネル(passive or active)
- ある teeting A におけるファシリテーションを行うチャンネル
- A 開始時は皆これを見る(ウィンドウ並べて常に見えるようにしておく)
- A 終了後はアーカイブする
- メンションは使っても使わなくてもいい(使うとactive facilitationになる)
- ファシリテーションスレッド(active)
- ある teeting A におけるファシリテーションを行うスレッド
- A の最中は、意思決定者は全員 or n 人にメンションを撃つ
通話系はいったん考えない(Teetingの意味が薄まるのでやるべきではない(安易に音声やビデオに頼るべきではない))
TAFA ツールを新たに検討する
既存の手段では限界がある。TAFA 用のツールを新たに検討するのが望ましい。案を示す。
タイムキープ
独立したサービスとして使えると良い。
- 例:調整さん
- ブラウザだけで、関係者のみが利用できる
- タイムキープの進行もこのサービス内(ウィンドウ内)で行われる
- 利用者は、別ウィンドウとして小さく表示しておくだけで良い
- スマホ利用も想定するならアプリは必要だろう
アジェンダプログラミングの文法を考える必要がある。
例:
13:30
10 議題読み込み
10 議題 Layer1 対処
10 議題 Layer2 対処
20
議題 Layer3 対処
/次の突き詰め時はなるべく居合わせてほしいです
20 意思決定&Layer3突き詰め
10 サマリータイム
- この会議のスケジュールは以下のようになる
- 13:30 に始まる
- 14:00 に Layer2 対処まで終わる
- 14:00~14:20 は Layer3
- そして次の突き詰めで居合わせてほしい旨も伝えている
- この旨は 14:00 のタイミングでお知らせされる(ぶら下げている)
- 14:20 から突き詰め
- 14:40 からサマリー
- 14:50 終了
- 13:45 時点では以下が表示されるだろう
- 「Layer1対処フェーズ」
- 「あと5分でLayer2に移ります」
- 14:03 時点では以下が表示されるだろう
- 「Layer3対処フェーズ」
- 「次の突き詰め時はなるべく居合わせてほしいです」
アジェンダプログラミングの実装パターンを考える必要がある。
- 細かく書くか、ゆるく書くか
- 上記の例は前者寄りである
- 細かさはどの程度が正しいか?チーム次第か?
- メッセージ(
/
始まりのもの)の量はどうするか- 無制限にすると乱用されかねない
- 最大1つまで、2つまで、と制限した方が締まりが良さそう(本質に集中できる)ではある
- 休憩や拘束はどのように制御するか
- Teeting 自体は参加者を拘束しない
- が、PRIDS でいうところの Decide や Summarize フェーズ中は拘束が求められることが多い
- Decide(決定を下す)時は、その場に居合わせていないと不服を進言できない
- Summarize(議論の内容や結果をまとめる)時は、その場に居合わせていないと作業・補足ができない
- もう少しフレームワーク化できるのではないか?
- hints
- PRIDS
- Layer1,2,3
- 愚直に考えるなら、5x3 で以下15パターンであろう
- Layer1のP
- Layer2のP
- Layer3のP
- Layer1のR
- Layer2のR
- Layer3のR
- Layer1のI
- Layer2のI
- Layer3のI
- Layer1のD
- Layer2のD
- Layer3のD
- Layer1のS
- Layer2のS
- Layer3のS
- 実際はグルーピングできるはずだ
- たとえば Read フェーズは「Layer1,2,3まとめて行う」で良いだろう
- というより、アジェンダプログラミングでは「この15パターンのうち特に集中したいものだけをプログラミングする」が良い?
- hints
ファシリテーション
独立したサービスが良い。
- ファシリテーションはともすると意思決定者の暴走や彼らによる乱用に繋がる
- たとえば teeting で議論するべき内容を、長々と特定個人にクローズドで伝えるかもしれない
- たとえば意思決定者の割り込みや監視が多すぎて、teeting の良さ(参加者は拘束されず MBMP に取り組めること)が殺されるかもしれない
- 暴走や乱用を「ファシリテーションツール側で」防ぐことは MUST であろう
- 既存ツールではこの防御機構が十分ではない
防御機構として以下が必要である。
- クローズドでないこと
- 意思決定者のメッセージは必ず参加者全員に届くようにする(透明性・公平性のため)
- 長文を撃てないよう文字数制限をかけること
- Twitter の 140 文字でも問題ないと思える
- あるいはもっと進んで「自由記述させない」もアリ
- 自由記述させない場合は、たとえば以下のような選択肢を用意する
- please prioritize about Topic-X …… 「~~の議題をもっと重視してほしいです」
- i will start deciding …… 「これから決定を下していきます」
- i have decided Topic-X …… 「~~の議題について決定を下しました」
- i want @A to help about Topic-X 「@Aさん、~~の議論が煮詰まっているのですが見解もらえませんか?」
- ……
アクティブかパッシブかは参加者次第であろう。
- パッシブでもファシリテートが機能するならパッシブで良い
- パッシブで機能しない場合、アクティブにせざるをえない
Teeting のカバー
Teeting だけではまかなえないが、必要であろう諸々についてまとめておく。
以下について取り上げる。
- コミュニケーションスタッキングをカバーする「雑談タイム」
- 同期的なやり取りをカバーする「Hybrid Teeting」
- 日本人のハイコンテキスト問題にどう対処するか
- 「書かない」から「書いてもらう」にシフトするための、伝達指向性という考え方
- 文字入力ハードルを下げる話
雑談タイム
コミュニケーションスタッキングを Teeting で行うのは厳しいため、Teeting では扱わない。しかし、無くせるものでもないため、別の取り組みとしてカバーする必要がらう。それが雑談タイムである。
コミュニケーションスタッキングとは
コミュニケーションの機会を積むことで親密・友好・単純接触効果・お互いの把握などを高めることを コミュニケーションスタッキング(Communication Stacking) と呼ぶことにする。長いのでコミュスタと略す。
コミュスタが「混ざっている」という問題
コミュスタは仕事において重要とされているが、あらゆる会議において「ついでに」行われるのが現状である。そしてコミュスタ自体は効率や生産性とは無縁のものである(極端な話、家族との交流にそれらを求めようとはすまい)。
よって、会議そのものがその(無縁という)性質に引きずられ、非効率的で非生産的になってしまう。定例会議、全員参加、半強制的なビデオオン――思い当たる節はあろう。
問題に拍車をかけるのは、コミュスタの必然性を疑っていない勢力の存在である。彼らはそもそもコミュスタを削減するという発想をもたない。自分の信念として、あるいは人間の性質として、コミュスタの必然性を疑っていない。一方で、頭では会議効率化の必要性を理解している。しかし現実では、会議には「(削減対象になりえない)コミュスタ」が混ざっている。効率化するかしないかと言われたら、しないに倒すのだ。彼らにとって会議を削るとは、コミュスタを削ることに等しい。自覚的であれば、無自覚であれば、強烈な抵抗や忌避をもよおす行為である。
コミュスタを分離する
会議をより効率的・より生産的にするには、コミュスタを切り離す必要がある。つまり「会議を行うための時間」と「コミュスタを行うための時間」とに 分離 し、前者に後者を混ぜない。
そもそもコミュスタそのものは効率・生産性とは無縁の営みである。このような営みを CWEP(Communication Without Efficiency and Productivity) と呼ぶことにするが、要するに会議に CWEP を混ぜないようにするのである。
無論、人間である以上、CWEP そのものは必要であるが、それは CWEP 専用の時間を別途確保することで担える(※1)
※1 beforeコロナであれば、オフィスに全員が集まっておりアトランダムに雑談が発生していたため CWEP は行われていた。また飲み会や喫煙室での井戸端会議などもあった。withコロナではそれができないため、別の方法を考える必要がある。それが「CWEP専用の時間を設ける」という発想だ(※2)。
※2 beforeコロナだからといって全員が CWEP の恩恵を受けていたかというと、そうではない。人付き合いが苦手な者や下手な者だっている。かくいう筆者もその口で、よくチームでは「筆者以外の全員がランチに行っている」「会議に参加している」という状況が起こっていた。beforeコロナ時代の CWEP は、よくも悪くもある種の要領が求められる。withコロナになってからは、その要領がないものでも仕事がしやすくなった……と小話をしてしまったが、要するに before コロナ時代の CWEP が最適だったわけでもない。
雑談タイム(概念レベル)
CWEP 専用の時間として具体的に何を行えばよいか。アイデアはいくつも考えられる(というよりまだ誰も本格的に追求してはいないだろうからこれから考えていくことになる)が、筆者のアイデアを一つだけ挙げてみよう。
雑談タイム とは、雑談するためだけの時間である。
- 毎日10~30分、確保する
- 業務時間中に確保する
- 雑談タイム中は、仕事の話はしない
- 自然な流れで行うのは良い
- 命令や圧力の形で半ば強引に仕事の時間に変えるのはナシである
- 定時間前に行う
- 雑談タイム後、用がなければ帰宅できる
ポイントは「仕事の一環として」行うこと、しかし「仕事の話はしない」ことにあろう。一見すると矛盾しており、真面目な者は頭ごなしに否定しがちである。
既に見たように、コミュスタは人間である以上必要でありながら、「ついでに」行われるがゆえに効率と生産性が削がれていた。両方に切り込むには、コミュスタを分離し、コミュスタ用の時間を設けるのが理にかなっている。
雑談タイムのやり方
と、コンセプトについては述べたが、まだ具体的なやり方までは整備できていない。
たとえば以下について考える必要がある。
- 何人で行うか
- 誰と誰が喋るのか
- メンバーは毎回固定するのか、それともローテーションか、シャッフルか
- いつ、誰が、何について喋るのか
- 従来の CWEP の問題はどうするのか
- シャイが集まるとコミュニケーションが進みづらいこと
- 声の大きい者や権力を持つ者による「一方的な講釈の場と化する現象」
- 喋るのが苦手な者
- etc
以下、筆者が考えるヒントをいくつか述べる。
ヒント ~1on1~
まずは 1on1 である。
1on1 の起源は定かではないが、元々は「1on1 coaching session」として整備されたビジネスフレームワークであり、2017年頃にヤフーの取り組みにフォーカスが当たったことでブームが加速した印象がある。1on1 というと上司と部下間で定期的に行うミーティング、というニュアンスが強い。
しかし最近はそうでもなく、クロス1on1、いきなり1on1、斜め1on1、シャッフル1on1など、多様な広がりを見せている。共通しているのは、社内の色んな人との雑談機会を増やそうという意思であろう。1on1 に関するサービスも既にいくつも展開されている。
1on1は「コミュスタに特化した時間」と言えるだろう。今のところは「せっかくの貴重な時間なのだからビジネスやキャリアに役立てる」という意識が強いようだが、それ以外の目的――筆者が主張する「単にコミュスタを行うための時間」も含めて――も模索されるのではないか。
多様な 1on1 文化の広がりとともに、雑談タイムのヒントが開拓されていけば良いなと筆者は考えている。また、積極的にヒントとして活用して、筆者自らやり方を開拓したいとも思っている。
ヒント ~ゲーム~
それからもう一つが ゲーム である。
読者はスプラトゥーンをご存知だろうか。ポップなキャラクターがペンキ銃を撃ち合う、あのゲームである。エンジニア界隈ではずいぶんと人気なようで、Twitter で遊んでいる光景をよく見る。筆者は全くの無知であるが、あのようなゲームを通じてでもコミュスタは行えるのではないかと思っている。
そうでなくとも、たとえばボードゲームはゲームを楽しむためではなく他者と触れ合いたいがゆえに行われていたりする1。既に(ゲームというよりは「講師」によるワークショップだが)バヅクリ - テレワーク時代のチームビルディング のようなサービスも登場している。
要するに、ゲームはコミュスタを行うための手段として重宝するのではないかと筆者は考えている。なにしろ皆のやることが(ゲームという形で)決まっているため、当人同士で話題を考えたり空気を読んだりしなくても良い。システマチックに過ごせるのである。
ひょっとすると、未来のビジネスパーソンは1日30分、チームメンバーとゲームをして過ごしているかもしれない――そう考えるのは妄想だろうか。
Hybrid Teeting
Hybrid Teeting とは、以下を組み合わせた Teeting である。
- 口頭ベースの議論
- Teeting
参加者は基本的に Teeting を行うが、意思決定者は必要に応じてメンバーを捕まえて口頭ベースで議論できる。これを キャッチ という。キャッチされたメンバーは、意思決定者の要望に従い、議論を行う。必要ならさらにメンバーをキャッチしにいってもよい。
用が済んだメンバーはその場から離れて Teeting に戻る( リリース という)。リリースされたメンバーは、Teeting にて先ほどの議論をまとめる。
特徴
- 以下の両方を取れていること
- 手持ち無沙汰なメンバーが Teeting できること
- しかし、その場にはいるので、必要に応じてキャッチできること(口頭ベースの議論を開始しやすいこと)
コツ
- 意思決定者が賢く立ち回る必要がある
- なるべくメンバーの teeting を尊重すること
- キャッチはここぞで使う
- 大前提は 原則 teeting で回す・回せるようにする こと
- それだと間に合わない、それだとまどろっこしい場合にキャッチを使う
- 個人的な興味や寂しさでメンバーをキャッチしないこと
- メンバーは積極的にリリースしに行くこと
- 用が済んだのに居続けるのは不毛
- まとめたい、まとめるべきなのにいつまでもあーだこーだ言っているのももったいない
- たとえば
- 「もうリリースしていいですよね?」
- 「大筋は決まったと思うので、あとはteetingでやります」
- メンバーは積極的にキャッチされにいってもよい
- 今行われている口頭ベースの議論に対して、言いたいこともあるだろう
- そういうときは「ちょっといいですか」などと割り込んでもいい
- 今行われている口頭ベースの議論に対して、言いたいこともあるだろう
- キャッチ時に透明性を確保する必要がある
- TAFA のファシリテーションの項でも述べたが、意思決定者の独善や情報の不透明性をなくす必要がある
- キャッチは「参加者全員に見えている」か、あるいは「参加者がいつでも入れる」場所で行われなくてはならない
- この原則は守るべきである
- 守れないと「意思決定者と特定の参加者が内密に話し合う」世界になってしまう
- もちろんデリケートな話題は内密にせざるをえないが、それは teeting の外でやるべきことだ
やり方
場所を拘束かどうかで二種類に分かれる。
- 1: 場所を拘束する
- メンバーは会議室などに集まる
- つまり「話し合っているメンバー」と「黙々 Teeting しているメンバー」に分かれるような光景になる
- 2: 場所を拘束しない
- この場合、キャッチとその後の口頭ベース議論をどうやるかという問題がある
- 以下二つが必要
- A: 常設されたオンラインミーティングルーム
- B: Teeting 中のメンバーにメンションできるツール
- シームレスネスをいかに担保するかが重要
- たとえば A にしても、いちいち部屋番号とパスコードを打つのは面倒
- クリック一発で入れるくらいのシームレスが欲しい
会議中のプレゼンスをどうするか
そもそも Teeting は各自が自由に立ち回るものであり、拘束されることは前提としていない。議論さえ行えているならどう過ごそうが自由である。たとえば 1 時間の teeting のうち、30 分をサボっていても良い。
ところが Hybrid Teeting の場合はそうもいかない。意思決定者がAさんをキャッチしたい場合に、Aさんから何十分も応答がないと困る。どうすればよいか。
- Q: チャットツールのようにステータスを設ける?
- Ans: 良くない
- 以下の問題がある
- A ステータスを更新するのを忘れる
- B いちいちステータスを更新するのが面倒くさい
- C サボっているなど、だらけた過ごし方を可視化したくない
- 特に C が深刻で、たとえ「teeting 中はどう過ごしてもいい」と事前に周知していたとしても、人はサボっている者には不快感を感じる
- これをなくすためには、どう過ごしているかをブラックボックスにするしかない
- そういう意味では、 場所を拘束する hybrid teeting はそもそも望ましくない
- ただし、参加者全員が「過ごし方の自由」よりもチームの生産性を重視できる状態にあるならこの限りではない
- いわゆるアジャイルで心理的安全性の担保されたチームはこの境地に至っている
- 筆者はこれを「利他的な行動至上主義」と呼んでいる
現実的なのは、以下のように区別して使い分けることだろう。
- まず hybrid teeting を以下の二種類に分ける
- blackbox hybrid teeting …… メンバーの過ごし方を見せない
- whitebox hybrid teeting …… メンバーの過ごし方を見せる
- blackbox については、hybrid teeting は諦める or 現実的にキャッチできる範囲で行う
- たとえば意思決定者1人とメンバー1人の 1vs1 であれば、比較的キャッチしやすい
- whitebox については、参加者は常に意思決定者から声をかけられるという前提で望む
(おわりに) 安易に Hybrid Teeting をしないこと
そもそも Teeting は非同期に、しかし生産的に議論するための手段である。一方で、Hybrid Teeting はキャッチという形で同期的な意思疎通手段を(半ば強引に)確保している。
Teeting について話すと、よく「そんなことできるわけない」などといわれるが、そうではない。肝心なのは「できるようにする」ことだ。そのためにツール導入が必要ならするし、勉強や訓練が必要ならする。ダイナミック・プロトコルとして述べたように、相応のやり方に適応していく必要もある。対面口頭のやりやすさに溺れて思考停止していては、Teeting など成し得ない。
ここまで解説しておいて何だが、できれば Hybrid Teeting に頼らず、純粋な Teeting のみで成立する道を探っていただきたい。もちろん Hybrid Teeting の方が生産的でメンバーも満足しているというのならそれでも良いが、ともかく安易に Hybrid Teeting(キャッチという同期的な手段)に頼らないように、とは重ねて強調しておきたい。
ハイコンテキスト問題
日本人にのしかかるハイコンテキスト問題とは
Teeting では非言語コミュニケーションが使えないため、言葉で書くウェイトを重くせざるをえない。しかし、ハイコンテキストな文化ではこれは敬遠される2。世界屈指のハイコンテキスト文化である日本は特にそうだ。
たとえば、以下のように受け取られてしまうことが想定される。
「そこまで書かなくともわかっとるわ」
「そんなに丁寧に書いてるのは読み手を馬鹿にしてるからか?」
「あなたの心は鬼ですか?誰も信用していないのですか?」
二つの対処法
このような問題に対し、同書では以下二点の対処を挙げている。
- 相手の文化を知り、それに自分を合わせる
- どういう文化があるかを説明し、理解してもらい、お互いに歩み寄る・対処を入れる
- 多国籍チームなど複数の文化が混ざっている場合は、これにせざるをえない
- やり方は色々ある
- 全員が各文化を尊重して立ち回る
- 文化Aを持つメンバーn人に代表者1人を設け、チーム全体は代表者がやり取りする(代表者でラップする) etc
実質使える対処法は一つ
本文書ではいったん日本人または同等の文化が染み付いた者を想定する。
この場合、文化としてはハイコンテキストであり、全員がそうである。Teeting ではとにかく書く必要があるため、前者の「相手に合わせる」は使えない。よって後者の対処を使うしかない。
後者の対処として何をするか。具体的には、私達がハイコンテキストであること――詳しく書くことを敬遠する価値観があることを周知(自覚させる)した上で、しかし Teeting では書かねばならないことを強調する。要するに、多かれ少なかれ折れてもらうしかない。
無論、折れてもらうのはかんたんではない。同書でも、グローバルに活躍する優秀なビジネスパーソンでさえ苦戦している例は枚挙に暇がない。
いかにしてこのハードルを下げるかは重要であろう。筆者はまだ妙案を思いつかないが、ゲームのように「ルールや指示に従って動く」路線になるのではないかと考えている。たとえば teeting に慣れることも兼ねて teeting のチュートリアルやワークショップを行う、競技ディベートなど「率直に議論し合うことに特化した機会」をやってみることで慣れる、プログラム開発や創作などものづくりを共同で行う(厳密または詳細に言語化してすり合わせないとゴールにたどり着けない)。少なくとも、「teeting していればそのうち慣れるよ」では遠回りであろう。ゲームがそうであるように、初学者はセオリーに基づいて頭や手足を動かすのが効果的である。
伝達指向性の対処
伝達指向性とは
狙った相手にだけ届く度合いを伝達指向性と呼ぶことにする。
伝達指向性は以下から構成される。
- 閉鎖性 …… 今目の前にいるn人にしか届かない
- 揮発性 …… この発言は残らない(のでここにいるn人以外には届かない)
- 伝染性 …… この発言は漏らされない(のでここにいるn人以外には届かない)
人は伝達指向性を高くしたがる。一方で、書くコミュニケーションはこれが低くなりがちであるため、人は書くことに対して抵抗感を抱いてしまう。
伝達指向性に配慮する必要性
Teeting はまさに書くコミュニケーションであるため、伝達指向性に配慮しなければならない。配慮しなければ、参加者は「ストレスフルな状態で書く」という辛い状態になるか、あるいは書かないだろう。多いのは圧倒的に後者である。伝達指向性に配慮できなければ書いてもらえない、と言っても過言ではない。
どのように配慮するか
構成要素各々のレベルで配慮していけば良い。
閉鎖性に配慮するには、クローズド(関係者以外は閲覧できない)にすれば良い。重要なのは「新たなメンバーが追加される可能性」も参加者全員で議論し、認識を合わせておくことだ。一番最悪なのは、意思決定者が勝手に幹部を追加するといったケースである。次によろしくないのが、「将来的に幹部を追加するかもしれない」といった合意を取る(取らせる)ことである。どちらの場合も、幹部というデリケートな存在に見られる可能性を孕んでいる。これでは書きたいことも書きづらい。理想は「直接のチームメンバー以外は入れません」「新しいチームメンバーを入れる場合は事前に相談します」の二点を周知することだろう。
揮発性に配慮するのは、難しい。Teeting はそもそもサマリーと過程を残すものだからだ。一つアイデアを挙げるとすれば、「制限時間後に記述内容が消えるエリア」を設けて、Teeting 中はそこで雑談できるようにする、だろうか。このような時限消去は既に知られており、Twitter のフリート や Insragramのストーリーズ などが知られている。が、Teeting で使えるようなツールとしてはまだ世の中にないため、新規が必要であろう。
伝染性に配慮するには、二つの取り組みが必要であろう。まず一つは「勝手に引用・転載しない」「したい場合は(そのページに書き込んでいる)参加者全員の許可を取る」というルールの周知だ。そしてもう一つは、口が軽い者を追放することである。ここでいう口の軽さとは「軽率に引用・転載する」ことも含む。極端な例だが、Teeting のやり取りをコピペしたりスクショを取ったりして Public な場所(インターネットはないにしても社員全員が見える場所など)に平然と置くような者は論外である。そういう者がいれば、参加者は安心して書き込めない。厳しく対処することが必要である。
文字入力ハードルを突破するための「IRN」
Teeting では文字入力を行えることが前提となる。そもそも文字入力が苦手な者には行えないか、かなり苦しい。
Teeting をより一般的な手段とするためには、文字入力のハードルを下げねばならない。どうすればよいか。一案として 音声認識を発展させる が挙げられる。
IRN
IRN とは Input、voiceRecognition、Normalize の略である。音声入力、音声認識によるテキスト化、認識されたテキストの整形を意味する。
音声入力は(喋るという自然な営みであるため)入力ハードルは非常に低い。タイピングのようなスキルを学ぶ必要はない。しかし、これだけで十分かというとそうではなく、IRN すべてを満たさねばならない。
2021/11 現在の状況をまとめておこう。
- R はおおよそ足りている
- 既に音声入力で仕事している者も存在する
- スマート家電など商用化もされている
- I は足りない
- たとえばツイート投稿くらいにかんたんに音声や動画を投稿することは、まだできない
- 音声や動画が投稿できるだけでも不十分である
- テキストは必須であろう
- つまりはトランスクリプトである
- 無論、利用者にストレスを感じさせない程度に早く処理出来る必要がある
- N も足りない上に、方向性もまだ出ていない
おわりに
本文書では Teeting――Text Meeting について一通りまとめた。正否や質はさておき、議論や活用のたたき台となるものを一通り整備できたと考えている。
よりイメージを膨らませたい方は、(Teeting そのものの例は皆無に等しいが)Scrapbox のコミュニティを参考にすると良い。たとえば Nota TechConf ではイベント当日、数十人が同時に編集を行っておりその跡は今も残っている。井戸端 や hub、言語化コミュニティ『シナプス』 など「誰でも参加できて」「コミュニケーション用途で使われている」場所もあり、テキストでどのようにやり取りしているかの参考になるだろう。
Teeting に話に戻すが、当面の課題は「行動」であろう。本文書では具体的なやり方や事例を紹介していないが、理由は単純で、まだ無いからである。筆者としても(一人で行えるものではないから)ろくに手を動かせておらず、したがって本記事の内容も机上の域を出ていない。誰かを巻き込んで行動してみる必要がある。
しかし、ここまで見てきたとおり、Teeting はかんたんなものではない。対面口頭など同期的なやり取りを好む層にも、逆にフルリモートで非同期的に働く層にも、どちらにとっても Teeting は中途半端であり煩雑に見えるだろう。この文書を見て「やってみないか」と誘ったところで、一体誰が乗ってこようか。乗ってもらうためには説得するなり、(たとえばツールやサービスをつくる等して)訴求するなり、(自分が「率いる立場」になる等して)メンバーにやらせるなり、何かしら強い行動が求められる。
もしご興味を持たれた方がいらっしゃれば、ぜひコンタクトをお願いしたい。たとえば Scrabox で試してみたり遊んでみたりすれば双方ともに学びがあり、何より楽しいと考える。もちろん、読者の方で本文書の内容を自由に試してもらったり、何なら続きを整備・強化してもらっても構わない。何か進展があれば教えていただけると嬉しい。
更新履歴
- 2021/11/05 v0.0.1
- 初版
- 2021/10/17 開始