ドキュメントで済むはずだった会議（そして、会議にすべきだったドキュメント）

「このミーティングはメールで済んだはずだ」というのは、誰もが経験したことのある状況を表しているため、ジョークとして定着しました。それは、一方向の情報伝達のために存在し、参加者が一人の発言をただ受動的に聞き、議論や討論、意思決定が実際には一切行われないミーティングに席を置いている状況のことです。

このジョークがなくならないのは、問題が解決していないからです。チームの規模が大きくなるにつれてミーティングは増殖し、その大半は双方向のやり取りではなく情報提供にとどまり、どの調整活動に同期的な時間が必要で、どれが必要でないかを判断するための体系的なフレームワークを誰も持っていません。

ここに、そのためのフレームワークがあります。

テスト

カレンダーにある定期的なミーティングそれぞれについて、1つの質問を投げかけてみてください。「このミーティングは主に情報を伝達するためのものか、それとも相互作用を通じて新しい何かを生み出すためのものか？」

ミーティングが主に一方向の情報伝達である場合（1人のメンバーや1つのチームがステータス、背景、決定事項、アップデートなどを、主に聞く側に回っている他のメンバーに共有するケース）、それはドキュメントにするべきです。GitHubやSlackからステータスを取り込む自動更新されるwiki、選択の背景にある論理的根拠を記録する意思決定レコード、プレゼンするのではなく文章で書き出すプロジェクトアップデートなどがこれに該当します。ドキュメントにすることで、情報はより広い範囲（参加者だけでなく全員）に届き、長く残り（検索可能で、忘れられない）、より少ない時間で済みます（読む方が参加するよりも速いためです）。

ミーティングが主に相互作用を通じて新しい何かを生み出すものである場合（ブレインストーミング、創造的な問題解決、対立の解消、リアルタイムの議論を必要とする意思決定、関係構築など）、それはミーティングのまま残すべきです。これらの活動には、リアルタイムなやり取りによる双方向の対話、非言語的な手がかり、そして勢いが必要です。ドキュメントでこれらを再現することはできません。

フレームワークの適用

スタンドアップ（朝会） → ドキュメント。 標準的なスタンドアップ（昨日やったこと、今日やること、障害になっていること）は情報伝達です。各自がステータスを共有するだけで、誰もそれを深く議論しません。この情報は、全員が閲覧でき、プロジェクトの活動から継続的に更新されるステータスドキュメントで提供する方が適しています。

スプリントレビュー → ドキュメント。 何がリリースされ、なぜそうなったのかのプレゼンテーションです。参加者は時折質問を挟むことはあっても、基本的には聞いています。マージされたPRから生成された変更履歴（チェンジログ）を使えば、時間をかけることなく同じ情報を提供できます。

アーキテクチャの議論 → ミーティング。 複数のメンバーがトレードオフを議論し、選択肢を評価し、お互いの制約や論理的根拠を理解した上で意思決定を下すプロセスです。これには同期的な相互作用が必要です。ただし、将来のミーティングで再構成する必要がないよう、決定事項は直後にドキュメント化されるべきです。

全体会議（All-hands）のアップデート → ドキュメント ＋ 任意のQ&A。 アップデート自体（会社の進捗、戦略、アナウンスなど）は情報伝達であり、文書化が可能です。デリケートなテーマや複雑なテーマを扱うQ&Aは、同期的な相互作用から恩恵を受けます。これらを切り離し、情報はドキュメントのアップデートで、議論が必要な質問については短いライブセッションで行いましょう。

オンボーディングのウォークスルー → ドキュメント ＋ ペアリング。 事実に基づいた内容（システムアーキテクチャ、チームの規約、ツールのセットアップなど）は情報伝達であり、ドキュメント化されるべきです。関係構築や判断に基づくガイダンスは、メンターと同調する時間を持つことで効果を発揮します。この2つを切り離すことで、メンターの時間は人間にしか提供できないことに使えるようになります。

レトロスペクティブ（振り返り） → ミーティング。 何がうまくいき、何がうまくいかなかったかを振り返るには、率直でリアルタイムの議論が必要です。このミーティングは実施すべきです。レトロからのアクションや洞察は、次回のレトロで活用できるようにドキュメントに記録しておく必要があります。

チーム間シンク → 条件付き。 シンクがチーム間でステータスを共有するためのものであれば、ドキュメントにします。優先順位の交渉、依存関係の解決、共同作業の計画を目的とする場合は、ミーティングにします。多くのチーム間シンクは後者のように見えて、実際には前者の機能を果たしています。

ミーティングにすべきだったドキュメント

このフレームワークは双方向に機能します。現在ドキュメントや非同期チャネルで処理されているいくつかの事柄は、同期的に処理した方がうまくいきます。

対立の解消。 Slackのスレッドで繰り広げられる意見の相違は、解決に向かうどころかエスカレートしがちです。なぜなら、書面でのコミュニケーションには、人々が共通の基盤を見つけるのに役立つニュアンスやトーン、リアルタイムの柔軟な対応が欠けているからです。解決に至らないままやり取りが3、4回以上往復した場合は、同期型の会話に移行してください。

デリケートなフィードバック。 誰かの仕事やパフォーマンスに対して実質的なフィードバックを与える場合は、対面（またはビデオ通話）で行う方が適しています。相手が質問でき、相手の反応を読み取ることができ、リアルタイムでやり取りを調整できるからです。

リスクの高い複雑な意思決定。 決定が重大な結果をもたらし、参加者が実質的に異なる見解を持っている場合、リアルタイムの議論は非同期のコメントスレッドよりも優れた成果を生み出します。双方向のやり取りにより、連続するテキストのやり取りでは難しかった、お互いの論理的根拠に対する理解が深まるためです。

関係構築。 ドキュメントを通じて信頼を築くことはできません。フォーマルなもの（1on1、チームイベント）であれ、インフォーマルなもの（コーヒーチャット、雑談）であれ、同期的な時間は、いかなるドキュメントでも代替できない仕事の人間的な側面に不可欠です。

定着させるために

このフレームワークが持続的な変化をもたらすのは、ドキュメントのインフラがそれを支えている場合のみです。ミーティングをドキュメントに置き換える手法が機能するのは、そのドキュメントが最新で、見つけやすく、信頼されている場合だけです。ドキュメントが数週間で古くなってしまうと、人々はミーティングを復活させるでしょう。ミーティングは時間を浪費するとはいえ、少なくとも最新の情報を提供してくれるからです。

自動更新されるドキュメントは、手動でのメンテナンスなしで最新状態が維持されるため、ミーティングからドキュメントへの移行を持続可能にするインフラとなります。置き換えられたドキュメントが正確でアクセス可能なままであるため、ミーティングが復活することはありません。

よくある質問

メンバーがドキュメントを読まない場合はどうすればよいですか？ ドキュメントが最新で、検索可能であり、適切なチャネルにプッシュされていれば、一般的に導入率は高くなります。読む方が参加するよりも速いためです。導入率が低い場合は、ドキュメントが古くなっているか、見つけにくい状態になっていないかを確認してください。これらは導入が進まない最も一般的な2つの原因です。

どのように移行を進めればよいですか？ すべてを一度にキャンセルするのではなく、一度に1つのミーティングずつ置き換えていきましょう。まずは最も明らかに情報伝達を目的としているミーティング（通常は週次のステータスアップデート）から始め、それをドキュメントに置き換えて、2週間後に評価します。チームがより少ない時間で同じ情報を得られているようであれば、次のミーティングを置き換えます。

ミーティングの社交的な側面が失われませんか？ 社交的な機能と情報伝達の機能を切り離してください。情報伝達のためのミーティングを社交の代役として使うのではなく、その目的のために特化した社交の時間を設けるようにします。

関連情報： ミーティングを減らす方法、ミーティングが増殖する理由、調整コスト、仕事のための仕事。 関連ページ： 自動更新ドキュメント、決定ログ。