リモートチームのための非同期意思決定：会議なしで決定する

サンフランシスコは8:00、ベルリンは17:00、シンガポールは23:00で、8人が1つの決定を下すために通話をしています。シンガポールのエンジニアが最も関連性の高いコンテキストを持ち、残された注意が最も少ないです。オフィスで effortless に感じられた会議 — すでに部屋にいる全員、背後にホワイトボード — は、このチームが行う最も高価なものになり、最も必要とされる決定を下す人が最も多くの費用を負担しています。

共にいるチームは、部屋が空いているのでその場で決定します。分散チームにはその部屋がなく、そうでないふりをすると、すべての重要な決定がスケジュールの問題になり、その中に公平性の問題が生じます：誰かがいつも朝食前や夕食後に参加し、疲れていて半分しか参加していません。

リモートチームにとっての正直な質問は「どうすればより良い意思決定会議を運営できるか？」ではなく、「どの決定が会議で行うべきか？」です。その大部分に対する答えは「なし」です — 書面で、定義された期間内に行う方が良いのです。そうすれば、タイムゾーンの問題は関係なくなります。これが非同期意思決定であり、分散チームにとっては回避策ではありません。それがより良いデフォルトです。ここにその理由、5ステップのプレイブック、そして設計すべき失敗モードがあります。

リモートチームが非同期の意思決定を必要とする理由

3つの要因が分散チームを非同期での決定に向かわせており、それぞれがリモートワークの制約を利点に変えています。

これらのことは「決して会わない」という意味ではありません。会議が反射的なものではなくなるということです。非同期は決定が行われる場所であり、同期の時間は執筆が本当にできないことのために取っておかれます。この再構築は、健全な共同意思決定の背後にあるものと同じです — 目標はグループが所有する良い決定であり、出席者が多い会議ではありません。（そして、それには存在のよく知られた証明があります：1,500人以上のチームメンバーが65か国以上にわたる完全リモート企業のGitLabは、まさにこのパターンのハンドブックファースト版で運営されています — 書き留め、書面で決定し、誰もが見つけられる場所に記録します。）

非同期意思決定プレイブック

非同期の決定は「会議だが遅い」だけのときに失敗します。形に従うと成功します。ここに機能するものがあります — 5つのステップがあり、それぞれが非同期が間違う特定の方法を防ぎます。

それを静かに壊す落とし穴

ほとんどの失敗した非同期の決定は、同じ数少ない方法で失敗します。それらを特定すれば、それに対抗する設計ができます。

非同期はすべてを遅くするだけではないのですか？

決定によれば、しばしばそうです — そして証拠について正直であることは重要です。コンピュータを介したグループ意思決定の古典的なメタ分析（Baltesら、2002年）では、書面でのコミュニケーションを通じて作業するグループは対面グループよりも意思決定に長い時間がかかり、プロセスに対する満足度も低いことが多いとされています。数日間の書面でのやり取りは、30分の電話の遅延に勝ることはほとんどありません。

しかし、分散チームにとっては、意思決定ごとのレイテンシーは適切な単位ではありません。30分で1つの質問を解決するためのコールは、8人にとって同期したスロットを必要とします — 1人は午前6時、もう1人は午後11時 — さらに、どちら側でもコンテキストスイッチが発生し、記録は残りません。非同期スレッドは、各人に自分の作業日内で15分の集中した時間を費やさせ、他のすべてのスレッドと並行して実行され、書面での決定に至ります。あなたは、すべての意思決定に対するスループットのために、単一の意思決定のスピードを少し犠牲にしているのです — そして、入力の質のために：ライブミーティングの最も早口の話者が決して余地を残さない、考慮された証拠に基づく議論です。したがって、正直な分け方は「常に非同期」ではなく、以下の表です — そして、本当に緊急なコールの場合、ミーティングは依然として適切なツールであり、議事録が取られるべきです。

同期 vs 非同期: どの決定がどこに行くか

非同期はデフォルトであり、ルールではありません。スキルは、どの決定をライブで維持するかを知ることです。簡単なテスト：決定が主に考慮された入力と記録を必要とする場合は、非同期を選択します；主にリアルタイムの人間のつながりや新しい選択肢を必要とする場合は、同期を選択します。（知っておく価値のある研究のニュアンス：BrucksとLevavは、2022年にNatureで、ビデオ通話が創造的なアイデアの生成を抑制することを示しましたが、選択肢の間で選択することには悪影響を及ぼさないことを示しました。選択肢を発明する仕事であれば、部屋に入るか電話をかけてください；選択と記録を行う仕事であれば、書くことが役立ちます。）

両方の列が共有していることに注意してください：決定はどちらにしても記録されます。記録のないライブ決定は、非同期のものと同じ失敗モードを持っています — それは消えてしまいます。トランスクリプトと実際の記録の違いを知りたい場合、それは会議の議事録と決定ログの間のギャップです：一方は言われたことをキャプチャし、もう一方は何が決定され、なぜそうなったのかをキャプチャします。（そして、同期のものをスケジュールする前に、これはメールで済んだかもしれないの四つの質問テストを通過させてください — 多くはそれを乗り越えられません。）

Argumentreeは非同期の意思決定をどのようにサポートするか

手動でプレイブックを実行することができ、規律と共有ドキュメントを使用します。Argumentreeはツールに形を組み込むため、ファシリテーターがスレッドを監視しなくても構造が維持されます。人々は自分の作業時間内に自分の主張を事前に提出するため、貢献は同時にオンラインであることに依存しません — タイムゾーンの制約は単に適用されなくなります。

その貢献は、特定の主張に関連付けられた構造化された賛否の議論として到着し、単なるコメントの流れではありません。これにより、数時間後に追いついたチームメイトは、返信の壁をスクロールする代わりに、議論の実際の状態を一目で把握できます。そして、ウィンドウが閉じると、議論は決定記録になります：結果、賛成と反対の理由、そして誰が何を主張したかの完全な記録です。この記録が、良い非同期の議論を持続可能な組織の記憶に変えます。これにより、分散チームは一度決定し、後で参照することができ、四半期後に同じ質問を再度議論することがなくなります。今週、あなたのチームが実際の決定にこのプレイブックを試す準備ができているなら、無料トライアルを開始し、ツールで最初のものを実行できます。

書面で決定し、目的を持って会う

オープニングのシンガポールのエンジニアは、より良い会議の時間を必要としているわけではありません — そんな時間は存在しません。彼らが必要としているのは、決定が彼らのもとに届くことです：彼らが午前9時に読むことができる書面による提案、彼らだけが持つ主張を追加するための構造化された場所、入力が締め切られる時間を知らせるウィンドウ、そしてその質問が再浮上したときに指摘できる記録です。プレイブックのすべてのステップは、その必要性を一般化したものに過ぎません。

非同期意思決定はリモートワークの慰めの賞ではありません。構造 — 提案、ウィンドウ、決定者、議論、記録 — を持って行われるそれは、置き換える会議室よりも実際に優れたプロセスです：より考慮された入力、より多くの声、そしてスレッドを超えて生き続ける記憶。これに苦しむチームは、あまりにも多くの非同期を行っているのではなく、構造なしで非同期を行っています。構造を修正すれば、チームページのタイムゾーンマップは制約ではなく、あなたの決定が記録される理由になります。