リモートワークにおける非同期コミュニケーションを取り入れる方法

非同期（async）を始める方法

GitLab は、オールリモートが仕事の未来であると信じています。リモートワークを取り入れる第一歩は、非同期（async）ワークフローとコミュニケーションを理解し、かつ 非同期をあなたのために機能させる方法を理解することです。

非同期ワークとは何か？

私たちは Preston W. による Remote blog の説明が大好きです。

「非同期ワークはシンプルなコンセプトです：手持ちのものでできる限りのことをし、すべてを文書化し、プロジェクトのオーナーシップを次の人に渡し、別の何かに取り組み始めます。」

非同期ワークの人気は高まっています。従業員と雇用者の両方にとって大きなメリットがあるからです。

非同期ワークの 6 つの主要なメリット

1. 非同期ワークは自律性、権限委譲、主体性を提供する

非同期の会社では、チームメンバーは自分のスケジュールに合わせてプロジェクトを前進させる主体性が与えられます。GitLab では活動ではなくインパクトを測定します。これは、人々が最も適した時に成果を出す自由があることを意味します。

誰かが毎月新しいタイムゾーンに旅行しているか、美しい午後を家族と過ごすことを選択した場合、それはその人の権利です。

自分自身のマネージャーになれる人々にこのような自律性を提供することが、驚くべきロイヤルティ、定着率、仕事の質につながることは当然のことです。

このアプローチをさらに最適化するには、「フレキシブル休暇ポリシー」の追加を検討してください。これはチームメンバーが仕事を離れるために許可を求める必要がないことを意味します。

オールリモートの環境では、チームメンバーは自分が最も充実する場所で生き、働くことが可能になります。共同オフィス勤務の会社でも、フロアや部署を超えてチームメンバーがいる場合、特に複数のタイムゾーンが関係する場合、非同期での運営が必要になってきています。

この GitLab Unfiltered ビデオでは、Veamly の創業者兼 CEO である Emna G. が、GitLab の Darren M. と、デフォルトとしての非同期がストレス、不安、メンタルヘルス、全体的なウェルビーイングに与える影響について話しています。

非同期で働くことは、より効率的でストレスが少なく、スケールしやすいです。

2. 非同期ワークは効率を高め、生産性を向上させる

非同期で働くことは非常に効率的です。なぜなら、チームの全員が常に行動をデフォルトとすることができるからです。

「仕事が取り組める準備ができていない、タスクが計画されていない、意思決定者がオンラインでない、などの時間が多々あります。そのような時、成功するチームは実行します。たとえ後でリファクタリングや適応が必要になるとしても、彼らは『待つ』時間を無駄にしません。」

3. 非同期ワークはよりインクルーシブ

非同期ワークの最大のメリットの 1 つは、タイムゾーンの壁を完全に取り除くことです。

「GitLab では、60 か国以上にわたって人々が分散しているため、ほぼすべてのタイムゾーンがカバーされています。しかし、それはチームの誰かが大きく異なるタイムゾーンにいる可能性が高いことも意味します。実際、あなたが仕事をしている間中、彼らは眠っているかもしれません。」— Darren M.、GitLab の Head of Remote

ビジネスは、すべてのタイムゾーンで、永続的に 24 時間行われています。コミュニケーションを 1 つのタイムゾーンの所定の時間に押し込もうとすることは機能不全です。

65 か国以上にチームメンバーを持つ 100%リモートの会社として、非同期で働くことはタイムゾーンの壁を取り除き、GitLab がよりグローバルにインクルーシブな組織となるもう一つの方法です。

4. 非同期ワークはストレスを軽減し、メンタルヘルスをサポートする

決められた勤務時間内にオンラインであり、利用可能であり、応答可能であることへの期待は、膨大なストレスをもたらします。さらに悪いことに、超接続された社会はこの概念を 1 日のあらゆる時間に染み込ませ、仕事と自己の間の境界を壊してしまっています。

非同期で働くことの認識されていないメリットは、緊張の軽減です。会社全体が、チームメンバーがいつでもどんな理由でもオフラインになる可能性があるという理解のもとで運営されている場合、問い合わせに即座に返信する期待はありません。

これにより、メンタルヘルスが優先される環境が生まれ、チームメンバーは境界を設けることができ、絶え間ない通知や批判から解放されます。

非同期コミュニケーションが 1 日中即時返信への社会的期待にどう影響するかを聞かれたとき、GitLab の Head of Remote である Darren M. は、theCUBE のホストであり SiliconANGLE Media のコンテンツ GM である Stuart Miniman とのインタビューで以下のように述べました。

リモートは、他の環境よりもメンタルヘルスと正気にとって優れています。なぜなら、非同期で働くことを強制するからです。

非同期のマインドセットにより、誰もが一歩引いて、自分たちがやっていることは他の誰もオンラインでないという前提でやっていると考えることができます。即座に返答しなければならないメッセージの無限の連鎖という負担が取り除かれます。

メンタルヘルスの観点から、会社全体が非同期を受け入れると、私たちは長時間の中断されない時間を必要とする深い作業を行うための余裕が少し増えます。

社会はそろそろ転換点に近づいており、人々は仕事をうまくこなしながら、さらに多くのメッセージ、メール、あるいは緊急に見える ping に耐えられなくなっています。私たちはそのカーブより少し先を行っているかもしれませんが、業界全体が非同期コミュニケーションを受け入れ、人々が雇用された仕事をするためのより多くの時間が与えられることを望んでいます。

5. 非同期ワークは思慮深さと意図性を促進する

同期コミュニケーションの核心的な問題は締め切りの認識です。労働日に任意の開始時刻と終了時刻があると、処理時間を犠牲にして、多くの場合その時間内に可能な限り多くのコミュニケーションをとる圧力があります。

Gumroad の創業者兼 CEO である Sahil Lavingia は、完全に非同期になることで彼の会社が実現した強力なメリットを共有しています。

彼らの X (Twitter) スレッドより：

すべてのコミュニケーションが思慮深い。何も緊急ではない（サイトがダウンしている場合を除いて）ため、コメントは注意深い処理の後に行われ、リアルタイムには行われません。ドラマがありません。

誰もが常に事実上「ブロックされている」ため、全員が前もって計画します。また、誰もが 1 時間、1 日、または 1 週間消えても、会社の足を引っ張っているとは感じません。私でさえも！

人々は生活の周りに仕事を構築します。逆ではありません。これは新しい親にとって特に素晴らしいですが、幸福と生産性を最大化するために日々の計画を立てることができ、全員が恩恵を受けます。

これが可能なのは、すべてが文書化されているからです。全員が異なるテキストベースのメディアを通じて話し合うため、好奇心があれば（または必要に応じて引き継ぐ）人々が何にでも覗き込むことが容易です。また、会議もなく、すべての数値が公開されているため、職場の FOMOもありません。

私たちが出荷するソフトウェアは十分にテストされており、信じられないほど安定しています。同時にオンラインになって「デプロイ」することはないからです。ほとんど火消しはなく、Gumroad の技術的負債も毎週少しずつ減らしています！

全体的に、ストレスがとても少ない環境です。私たちの多くは Slack すらインストールしていません。それでも、これまで出荷した中で最高のソフトウェアを出荷しており、これまで以上に速く成長しています。不思議な話です！

6. 非同期ワークは知識のギャップを埋める

非同期の会社はローコンテキストカルチャーを実装すべきです。これは、コミュニケーションが正確で直接的であることを意味します。チームメンバーは、コミュニケーションについてどのような質問が寄せられるかを予測し、可能な限り多くのコンテキストを提供します。受信者が眠っていると仮定することで、あるいはまだ会社に入社していないかもしれないと考えることで、この追加コンテキストが曖昧さを減らし、誤解の可能性を低下させます。

これは非効率に感じるかもしれません。メッセージの作成に時間がかかる可能性があるためです。しかし、長期的なメリットは驚くべきものです。GitLab では、何年にもわたる意思決定の記録があります。例えば、この速度よりも可用性を優先する例は、コンテキストで溢れています。これにより、新入社員が過去のアーカイブを調べることで、特定の決定に影響を与えたコンテキストを自己学習することができます。

同期組織はしばしば一連のミーティングで意思決定を行い、途中でほとんど何も文書化しないため、途中からプロセスに入ってくる人は常にファクトファインディングミッションに時間を費やすことになります。さらに、重要な意思決定が行われた後に雇用された人は、入社前に変更されたものの文脈を理解できず、会社の効率を蝕む大きな知識のギャップが生まれます。

MailChimp のプリンシパルエンジニアである Coda Hale は、Work is Work という組織設計に関する包括的な記事でこれをよく説明しています。

ミーティングやステータス更新の大きな障害の原因の 1 つは、組織のリーダーが誰が何をやっているかを把握したいという欲求です。この状況認識は確かに重要ですが、ミーティングを開催したり、Slack でメッセージを送ったり、廊下で人を捕まえたりしてそれを維持しようとすることは、組織の生産性に対する重大なシステム的な重荷となります。

組織がスケールするにつれて開発状況を把握するためのより良いモデルは、グループが通常の業務のカデンスの一部としてステータスアップデートを公開することです。リーダーはこれらのアップデートを非同期で読み、必要に応じて追加の同期的な会話を開始して質問したり、フィードバックを提供したりすることができます。

同期ミーティングは複雑な問題に関する低遅延のコラボレーションのために予約されるべきです。同様に、コラボレーションは同期ミーティングのために予約されるべきです。— Coda Hale

会社がスケールするにつれて、人々が入退社します。非同期コミュニケーションを活用することで、組織はこれらの自然なサイクルを通じて知識を保持することができます。

例えば、GitLab の価値観ページの Git blame 履歴は、誰が何を変更したか、その理由のコンテキストを完全にリストしています。この洞察は非常に価値があります。一部のコントリビューターはもはや GitLab に在籍していないためです。情報を求める人は、他の誰かを煩わせたり、他の誰かが起きてオンラインになるのを待ったりすることなく、非同期で情報を見つけることができます。

非同期コミュニケーションのガイド

スケジュールとカレンダーは、私たちを同期的に運営するよう条件付けしています。つまり、2 人以上が同じ場所（物理的にまたは仮想的に）に同時にいることです。

しかし、私たちは今、非同期（async）コミュニケーションが利害関係者が同期的に物理的または仮想的に存在することなくプロジェクトを前進させることを可能にする世界に生きています。非同期コミュニケーションは、人々がどのように（そしていつ）働きコミュニケーションをとるかを最適化します。

非同期コミュニケーションはどのように機能するか？

根本的に、非同期コミュニケーションはシンプルです。私たちはメッセージを送ったり、ボイスメールを残したり、ビデオを録画したりする際に常にそれを行っています。非同期でコミュニケーションするということは、メッセージの受信者と送信者が同じ場所に同時にいる可能性が低いことを意味するだけです。

しかし、非同期コミュニケーションをうまく行うには、かなりの意図性が必要です。非同期メッセージを作成する際には、以下のような質問を考慮する必要があります：

• このメッセージに最も適した形式（書面、音声、ビデオ…）を使っているか？
• このメッセージを受け取る人は必要なすべてのコンテキストを持っているか？
• 混乱が生じないように明確にコミュニケーションしているか？
• 言語のトーンと、このメッセージがどのように受け取られるかを考慮しているか？
• 会話やプロジェクトが前進できるよう、必要なリソースや次のステップを提供しているか？
• このコミュニケーションは後で参照するために見つけられる方法で文書化されているか？

この水準の思慮深さによって、明確で、完全で、親切に伝えられ、生産的な結果をもたらすコミュニケーションが生まれることが多いです。

これはまた、非同期でのコミュニケーションにはより多くの時間と計画が必要であり、特定のツールが必要なことも意味します。非同期コミュニケーションに関しては、学ぶことと同じくらい、学びほぐすことも必要です。

時間と戦略への投資は価値があります：非同期で上手にコミュニケーションすることで、効率が大幅に向上し、強いコラボレーションとチームワークをサポートします。

強力なドキュメントなしに非同期コミュニケーションはできない

非同期コミュニケーションにとって強力なドキュメントの重要性は本当に強調しすぎることができません。どれほど意図的なコミュニケーションをしても、常に何かが欠けたり、誤解されたり、前進するために必要なものがあります。誰かがフォローアップの質問をした場合、返答まで何時間も何日も待つ必要があるかもしれません。あるいは、会社のハンドブックで答えを調べることができます。

GitLab はすべてのコミュニケーションにハンドブックファーストのアプローチをとっています。私たちの目標は、ハンドブックが常に最新の状態であり、チームを大幅に効率化する強力なリソースであることを確保することです。GitLab ハンドブックは印刷すると 2000 ページ以上になり、私たちの働き方を知りたい訪問者は誰でも読むことができます。

この水準の透明性を選ばない場合でも、組織内での透明な情報共有が非同期ワークにとって重要であることに注意してください。チームメンバー全員が、チームメイトがオンラインで利用可能かどうかに関わらず、いつでも自分の仕事を行うことができるよう権限を持つべきです。

リモートコラボレーションに GitLab を使う

GitLab のチーム全員が、すべての仕事について非同期でコラボレーションするために GitLab を使用しています。GitLab は、同じ場所にいる人々でも複数のタイムゾーンに分散した人々でも、より良く一緒に働けるよう設計されたコラボレーションツールです。

元々、GitLab はソフトウェア開発者がコードを書くことや、それをソフトウェアアプリケーションにパッケージ化することについてコラボレーションできるようにしていました。今日、GitLab はあらゆる種類の会社や役割の世界中の人々が使用する幅広い機能を持っています。

GitLab のリモートチームソリューションページでさらに詳しく学ぶことができます。

非同期コミュニケーションを同期コミュニケーションの代わりにいつ使うか

GitLab は非同期コミュニケーションへのバイアスを持っていますが、最大の効率を達成するためには同期と非同期の戦略的なバランスが有用です。非同期で働くことそれ自体が目標ではありません。むしろ、配慮を持って実行可能なときに議論やプロジェクトを非同期で前進させることを選ぶことが、同期的な瞬間のためのより多くのスペースを生み出します。

高い能力の非同期ワークは、適切な瞬間に一部の同期的な議論を許可し、含んでいます。非同期は GitLab にとって非常に強力ですが、絶対的なものではありません。特に私たちの価値観を犠牲にする場合はそうです。

なぜ口頭および書面で伝えるのか？書くだけでよいのでは？

GitLab では、仕事関連のミーティングをスケジュールする場合（例：コーヒーチャットではない）、アジェンダを用意することが必要です。アジェンダ項目を追加する場合、そのアジェンダ項目を声に出して述べ、あなたまたは他の誰かが返答のメモを取っていることを確認することが期待されます。書くことでインテントが効果的に伝わる場合、そのトピックについては完全に非同期で進めることを検討してください。

自分または他の人に二重の作業を作成している場合、つまりハンドブックファーストで働くために書き留める必要があるものを文書化するだけのためにミーティングを開催する場合、ミーティングを開催せず、代わりに非同期で作業することがより効率的である可能性が高いです。

ミーティングを検討する際は、効率の GitLab 価値観を確認し、他者の時間を尊重することに関するミーティングガイドラインに従ってください。仕事関連のミーティングを装ったコーヒーチャットをスケジュールしないでください。

非同期ワークフローの実装方法

「異なる会話には異なるコミュニケーションモードが必要か？」と問う

非同期マインドセットを取り入れる最も簡単な方法は、この質問をすることです：「チームの誰も（または会社全体が）眠っている今、どのようにしてこのメッセージを伝え、この作業を提示し、このプロジェクトを前進させるか？」

これにより、ショートカットを取ろうとする誘惑や、単に情報を集めるためのミーティングを開催しようとする誘惑がなくなります（結局、すべてのミーティングは具体的な提案のレビューであるべきであり、非同期で可能な場合より効率的な結果につながる場合にのみ開催されるべきです）。

イテレーションに集中する

GitLab でイテレーション 👣を実践するには、意図と努力が必要です。受け入れるのが最も難しい価値観とよく言われます。多数の進行中のプロジェクトに対してイテレーションすることは、非同期コミュニケーションへのバイアスを確保するための理想的な強制機能です。

他の人の貢献を待ってスタックしている単一プロジェクトにのみ取り組んでいる場合、非同期ワークは税負担が大きく非効率に感じることがあります。ブロックを解消されるのを待つ間に他のタスクに取り組めるよう作業をスケジュールすることで、このダウンタイムを減らすことができます。

5 つの進行中のプロジェクトがあると仮定しましょう。1 つについてイテレーティブな進捗を遂げ、GitLab のエピック、Issue、またはマージリクエスト内で必要な入力またはアクションを求める人またはチームにタグ付けし、待っている間に別の進行中プロジェクトに切り替えることがずっと容易になります。割り当てられたタスクを循環させ、引き継ぐ前にそれぞれについてイテレーティブな改善を行うとします。その場合、特定のプロジェクトに対する即時の返答をあまり気にせずに、はるかに多くのプロジェクトの最小限の価値ある変更を生み出すことができます。

非同期は複数のプロジェクトを管理する際にうまく機能しますが、規律と文脈を切り替えて区分けする能力が必要です。

GitLab の共同創業者 Sid とラーニング＆ディベロップメントチームが、非同期コミュニケーションへのバイアスとイテレーション価値観の重要性についてより多くのコンテキストを提供しています。

私たちが非同期に本当に優れている理由があります。それは物事をより小さくするからです。イテレーションを通じて、大勢の人と調整する必要がありません。イテレーションを通じてより小さなステップをとることで、より速く出荷できます。これを可能にする唯一の方法は非同期コミュニケーションです。— Sid Sijbrandij、GitLab 共同創業者

完璧ではなく進捗を目指す

GitLab では、すべてがドラフトモードであり、変更される可能性があります。非同期ワークフローは、完璧よりも進捗のカルチャーを育てるとより採用しやすくなります。利用可能なリソースで最善を尽くしてプロジェクトを前進させ、ブロックされた時点に達した場合は、双方向のドアを通じて現在持っているものを出荷しようとしてください。

これにより、同僚はあなたが向かっている方向を確認でき、多少の進捗は全くないよりも良いため、即座の返答への圧力が軽減されます。

漸進的な改善を祝う

非同期ワークフローは、漸進的な改善が大規模な立ち上げと同等、あるいはそれ以上に称えられるカルチャーを必要とします。リーダーシップが未完成または磨かれていない作業を非難した場合、ワーカーは非同期で作業することを躊躇するでしょう。代わりに、コンセンサスのために作業を遅らせます。コンセンサスは気持ち良いですが、非効率、進捗、イノベーションを容易にマスクすることができます。

正確にドキュメント化する

非同期でコミュニケーションするアートをマスターするには前提条件があります：ドキュメントです。根本的に、非同期コミュニケーションはドキュメントです。受信者が同時に利用可能でなくても——眠っていても——メッセージまたは一連のメッセージを届けることです。

組織に標準化された文書化の方法がない場合は、まずそれを確立してください。

適切なツールを使う

非同期コミュニケーションは、コミュニケーションをどこにどのように入力するかについて会社全体で一致している場合に最もうまく機能します。リーダーはツールを慎重に選択し、できるだけ少ないチャンネルにコミュニケーションを向けることを目指すべきです。

大規模組織における一般的な不満——リモートのステージに関わらず——は、コミュニケーションの混乱的な分散です。プロジェクトは頻繁に、メール、チャット、テキストメッセージ、記録されていないミーティング、デザインツール、Google ドキュメントなどに散らばってしまいます。プロジェクトの進捗を伝えるための単一のシステムを選ぶのが最善です。

GitLab（会社）では、その目的地は GitLab（製品）です。ミーティング中に行われるサイド会話は文書化され、有用な要素がコンテキスト化されて関連する GitLab の Issue やマージリクエストに移行されます。Slack やメールで行われるサイド会話も同様です。関連する部分は GitLab（製品）に移行されます。これは進行中の作業の唯一の信頼できる情報源です。

GitLab のエピック、Issue、またはマージリクエストにない場合、それは存在しません。このメンタリティは非同期コミュニケーションのメリットを享受するために不可欠です。

以下は非同期コラボレーションを促進する実証済みのアプリとクラウドツールです：

• Google Drive
• Dropbox Spaces
• Qatalog
• Yac
• Friday HQ
• GitLab
• Tettra
• Slab
• Twist

タイムゾーンバイアスを最小化する

リーダーは 1 つのタイムゾーン、または 1 つのタイムゾーン群（例：北米をカバーするタイムゾーン）へのバイアスを排除するよう努めるべきです。会社全体のミーティングについては、より多様なタイムゾーンに対応するためにローテーションすることを検討してください。また、後でも見られるよう録画することも検討してください。

ライブラーニングセッションを開催する場合、例えば、世界中の人々が自分のスケジュールに合うものに参加できるよう、複数のインスタンスを開催してください。

会社が 1 つのタイムゾーン（多くの場合、会社のエグゼクティブの多くが住んでいるゾーン）に過度に引きずられると、非同期ワークフローが真剣に受け止められていないことを会社全体に示すことになります。

非同期ワーカーのためのベストプラクティス

精神的なスペースを作る

リモートワークのより困難な側面の 1 つは、仕事を離れた後、すべての精神的なタブを閉じることです——ウェブブラウザのアナロジーを使うならば。リモートでは非線形の労働日に対応できるため、1 つの作業セッションがどこで終わり、別のセッションがどこで始まるかを合理化するのが難しくなります。「時間だから」以外の理由や言い訳がないことが多いのです。献身的なリモートワーカーは、この感覚から切り離すことに苦労し、自分のウェルビーイングを後回しにして「あと 1 返信だけ」というトラップに陥ることがあります。

チャットスタイルのコミュニケーションツールは、主にインフォーマルなコミュニケーションのために使用すべきです。以前の組織で Slack が常時稼働している緊急性の中心として機能していた場合、タスクを達成するためのコアな部分としての Slack への依存を断ち切るには、意識的な努力と強化が必要になります。

以下は、リーダーや個人のコントリビューターが即時メッセージと同期性へのバイアスに飲み込まれないようにするための推奨される強制機能です。目標は、優先順位付けの力を自分自身の手に取り戻すことです。これは自分自身のマネージャーとして効果的であるために重要です。

毎日/毎週すべてのメッセージをクリアする

人間は絶え間なく大量の新しいデータを受け取り続けるように設計されていません。多くの人にとって、Slack の新しいメッセージ（プライベートと公開）の毎日または毎週のダイジェストを読んで理解するだけでフルタイムの仕事になってしまいます。何が重要で何がそうでないかを絞り込む個人的なアプローチは役割や機能によって異なりますが、各作業日または週の終わりにすべてのメッセージをクリアすることで精神的な負荷を減らすことができます。

Slack ではこれを すべてのメッセージを既読にする と呼んでおり、Shift + Esc を同時に押すことで簡単に切り替えられます。

作業の好みを伝える

自分の働き方を明確にする基本的な README を作成してください。理想的には、GitLab の Issue ボード、タグ付けシステム、または会社全体で理解・使用できる To-Do リストから作業することです。その後、README へのリンクを Slack プロフィールに投稿して、他の人に参照を案内することができます。非同期を同期よりも意図的に選ぶ方法を他の人に示すことは、非同期コミュニケーションへのバイアスという運営原則を強化するために不可欠です。

これは別のリモートファーストの強制機能の延長です：常にリンクで回答する。

非同期作業日のコミュニケーション

GitLab は非同期ワークと非線形の労働日を幅広く支持していますが、通常の勤務時間外（例：旅行前後、旅行中の作業、週末の作業など）に作業していて、それをチームメンバーに伝えたい場合があります。このような状況では、チームメンバーは Workday に休暇として入力するのではなく、集中時間 のカレンダーイベントを追加し、Slack のステータスを変更してください。

電話から Slack を削除する

リモートワーカーには、仕事と生活の間の仕切りとなる多くの物理的な関所がありません。仕事と生活が同じ建物で行われ、仕事用の機器が常に手の届くところにある場合、未読の Slack メッセージに悩まされることを防ぐことは非常に難しいです。

スマートフォンから Slack を意図的に削除することは、仕事から離れる時間が重要であることを強化する素晴らしい方法です。スマートフォンの依存性に関する数々の研究があります。このアプローチが有益かどうかまだわからない場合でも、試してみてください。双方向のドアです。

キャパシティについて透明にする

共同勤務の環境では、誰かが怒りを示したり、大声でため息をついたり、邪魔されないようにノイズキャンセリングヘッドフォンを意図的に着けたりすることで、文脈の手がかりを拾うことができます。リモートの環境では、集中した作業が必要なことを人々に知らせることはそれほど簡単ではありません。

したがって、チームに対してキャパシティに関する情報を Slack のステータスでブロードキャストすることを活用することが重要です。キャパシティに達しているか、集中時間中であることを示すためにステータスを手動で調整することは安全に行えるべきです。これにより、他の人もできることを強化しつつ、Slack と同期的な会話がデフォルトであるべきでないことを思い出させます。

非同期がよりインクルーシブであることを人々に思い出させる

GitLab のセルフサービスとセルフラーニングへのアプローチはオンボーディング中に強化されますが、継続的な強化が必要な場合があります。組織図上の役職に関わらず、誰かが非同期コミュニケーションへのバイアスを発揮しているかどうかを尋ねることは許容されます。

すべての GitLab チームメンバーが何かがインクルーシブかどうかを素早く問うことを望んでいるのと同様に、非同期コミュニケーションが GitLab にとってよりインクルーシブになる別の方法であることを覚えておくことが重要です。

学ぶことと同じくらい学びほぐすことがあります。

正確な用語と識別子を使う

人々を参照する際に正確な名前を使うことが重要です。そのためには、GitLab の Issue/マージリクエスト、Google ドキュメント、および Slack で @ 記号を使って誰に言及しているかを明確にしてください。これにより、誰かの名前を誤って綴ったり、間違った人物に言及したりすることを防ぎます。

例：

• 綴りが難しい名前。例：Hubert Wolfeschlegelsteinhausenbergerdorff
• 複数の人物に言及する可能性がある名前。例：Tatiana という名前の GitLab チームメンバーは複数います。

非同期ミーティングの管理方法

GitLab では非同期コミュニケーションへのバイアスがあります。ミーティングの参加者として、スケジューリングする場合も招待された場合も、仕事関連のすべてのミーティングを疑問視してください。

1. ミーティングをスケジュールしたいという欲求につながった、達成しようとしている結果は何か？
2. 希望する結果をより小さなタスクに分解できるか？
3. 希望する結果をドッグフーディングして GitLab Issue またはマージリクエストを使って達成または進められるか？
4. コンセンサスを集めようとしているか？（もしそうなら、これは非同期で行うことができます。）
5. コンセンサスが集められた後、反応すべき提案があって意思決定しようとしているか？（もしそうなら、非同期で合意できない場合はミーティングが許容されるかもしれませんが、結果はハンドブックに文書化される必要があります。結果が最終的に文書化される場合、同期ミーティングの効率に疑問が生じます。）

同期で始めるべき時

キックオフミーティングがラポール、信頼の構築、そしてグループへの共有コンテキストの素早い提供に有用であることが明らかな場合、プロジェクトを同期的に開始することを検討してください。この最初のエンゲージメントは、将来のタッチポイントが主に非同期になれるよう、作業の基盤を確立するために使用すべきです。

同期キックオフで始めることは、以下の場合に意味があるかもしれません。（Dropbox がそのリモートコミュニケーションガイドでこれをよく表現してくれていることに感謝します。）

1. セールスエンゲージメント
2. 外部関係者との初めてのミーティング
3. 以前に一緒に作業したことのない GitLab チームメンバーとの初めてのミーティング
4. 片方向のドアの決定（例：ステークスが高く、決定を覆すのが難しい場合）
5. 複雑な初期化（例：企業の物語の定義、スコープの大幅な見直しなど）
6. 感情的に繊細なトピック（例：個人的な問題、キャリアパス/昇進、困難なフィードバックなどの議論）
7. 直属の部下のサポートとブロック解消（例：定期的な 1:1）
8. お祝いとレトロスペクティブ（グループで勝利を祝うのは気持ち良いですし、軽量なレトロスペクティブは将来のスプリントのキックオフポイントとして機能できます）

非同期で始めるべき時

「ちょっとビデオ通話しよう」と提案することは取るに足らないことのように感じるかもしれませんが、生産性に悪影響を与える可能性があります。一般的に、以下の項目についてはミーティングを避けるのが最善です。

1. ステータスアップデート
2. FYI と プロセスドキュメント
3. ミーティングについてのミーティング

非常に複雑なシナリオで非同期を最初に始める例として：ビジョンステートメント：gitlab.tv（Vision Statement: gitlab.tv）を参照してください。このシナリオでは、プロジェクトは非同期で始まりました。開始者は、チームメンバーがフィードバックを提供できるほど十分なコンテキストを提供するために、一連の複雑な仮定と例を伝える必要があったためです。

1. 大量の情報があるため、エピックの作成者は上部に一連の ハイライト を追加しました。これは他者の時間を尊重することの表れです。
2. 作成者はフィードバックの時間を区切り、非同期の入力を受け付ける特定の時間枠を提供しました。
3. 作成者は、非同期フィードバックと提案について意思決定するために、集中した同期ミーティングが後続することをグループに透明に通知しました。

非同期から同期に切り替えるべき時

2 人の間でのバックアンドフォースの非同期会話が小さな声明の多さで非常にゆっくり進んでいる場合、素早い同期的な議論が素早い小さな解決につながることがあります。一般的に、2 人が全く同じトピックで 3 回以上バックアンドフォースする場合——かつそれをより小さな非同期フレンドリーな決定に分割することが非現実的な場合——同期に一時的に切り替えるか、Yac や Loom などのより豊かなコミュニケーション媒体を活用することが理にかなっています。

これらのツールは、音声とビデオを媒体として使用することで、生のテキスト転送と比較してより深いつながりが可能になる場合がありますが、メッセージは非同期に伝えることができます。

同期通話への切り替えの後、結果について他の人に通知するための書面サマリーを作成すべきです。理想的には関連する GitLab のエピック、Issue、またはマージリクエストで共有してください。

非同期ミーティングのベストプラクティス

この GitLab Unfiltered のビデオでは、2 人の GitLab の同僚が、旅行しながら多くのタイムゾーンにわたってチームを非同期で管理することから学んだ教訓について話しています。

ポジティブな面に集中する

非同期で働くことで、チームはより少ないミーティングで済みます。最初は、「任意のミーティング」という概念は、同期コミュニケーションに慣れた人には不条理に思えるかもしれません。真実は、あなたはミーティングに貢献するために参加するか、そうでないかのどちらかです。

非同期の素晴らしい点は、チームメンバーが眠っている間に行われるミーティングに貢献できることです。

ミーティングへの参加は任意になります。すべての招待状に添付されるべきアジェンダと Google ドキュメントに各チームメンバーがアクセスできる場合です。これにより、世界中の誰もが事前に非同期で質問/入力を提供し、後で文書化された結果を確認できます。

ミーティングを開催した人は、結果をコンテキスト化し、関連するスニペットを関連する GitLab の Issue やマージリクエストに移行する責任があります。

主催者は、チームメンバーが検索できるよう、ミーティング後のドキュメントを通じて会社全体に結果を通知する責任があります。これは大きな責任であり、ミーティングの数を制限し、ミーティングが本当に必要かどうかのフィルターとして機能します。

非同期ワークによる改善を追跡する KPI ターゲットを設定する

チームのニーズはその目標と同様にユニークであり、非同期コミュニケーションの経験は異なります。しかし、チームリーダーとマネージャーは以下のうち 1 つ以上に基づいて KPI ターゲットを設定できます：

1. 同期ミーティングに費やす時間の割合削減
2. GitLab Issue/エピック/マージリクエストの使用率の割合増加
3. ミーティング時間対 GitLab コントリビューションの改善された比率
4. ダイバーシティ、インクルージョン＆ビロンギング項目で ‘非同期コミュニケーションへのバイアス’ を引用する 360 度フィードバックの増加

非同期 1:1 ミーティングの方法

非同期 1:1 ミーティングは、マネージャーと直属部下のコミュニケーションスキルを広げる優れた方法です。対面またはウォーキング 1:1 は有益ですが、書面テキストを使って 1:1 アジェンダ項目を非同期でカバーできることは、全体的なリモートコンピテンシーを向上させます。

非同期 1:1 を実施するには：

1. 次の 1:1 を非同期で行いたいと相手方に伝え、フォーマットの相互理解を確保します。
2. 非同期 1:1 の週中、継続中のアジェンダドキュメントにコメントするために作業週全体を公正なゲームと見なします。FYI または FYA コマンドで相手方にタグ付けし、書面またはビデオコンテキストを埋め込んで提供します。彼らのフィードバックや入力がリアルタイムには行われないことを理解してください。
3. 元の 1:1 カレンダーブロックをスケジュールに残すことを検討してください。そのブロックの前にアジェンダドキュメントを確認できない場合、これによりアジェンダ項目への返答や新しい項目の追加のための専用集中時間が確保されます。
4. 非同期 1:1 の週中に対応できなかったアジェンダ項目については、次のインスタンスに移して対面またはウォーキングを再開してください。

ミーティングのレトロスペクティブ

既存および今後のミーティングについては、アジェンダの上部または下部にこの質問を追加して答えを文書化してください：このミーティングは非同期で処理できたか、もしそうであればどのように？

非同期ワークフローを通じて何が可能かについての追加の認識を生むために、これらの学習を公開チャンネルで共有することを検討してください。最近の数週間に参加またはスケジュールしたミーティングについて振り返る時間をとってください。どれが時間の有効な使用で、どれが非同期で処理できたか？

多くのタスクは同期および非同期で処理できます。目標は、常に実行可能な場合は非同期を選択し、1 日のより多くの集中時間を生み出すことです。これはまた、仕事の関係を強化する同期的なつながりのためにチームメンバーがより多くのエネルギーを持つ可能性が高くなります。インフォーマルなコミュニケーションはオールリモートの環境で不可欠です。非同期ワークへのバイアスを徹底することで、コーヒーチャットやチームトリビアなどのインフォーマルなコミュニケーションのための同期的なチームボンディングのためのスペースが増えます。私たちは仕事関連のミーティングやビデオ通話に対して有限の許容量を持っています。可能な限り、同期的な瞬間はインフォーマルなコミュニケーションのために保存するのが最善です。

非同期コミュニケーションの限界と課題

非同期コミュニケーションには限界があります。GitLab でプロジェクトは非同期で前進しますが、プロジェクトの一部が同期で処理されるのが最善の場合もあります。

効率の評価

原則として、GitLab のチームメンバーが 3 回バックアンドフォースする場合、同期ビデオ通話に切り替えます（そして結果を文書化します）。

クライアント向けの役割

特定の役割は他よりも非同期コミュニケーションに対して寛容です。クライアント向けの役割は、例えば、特定の時間帯のカバレッジに関する特定の要件があるかもしれません。単一障害点がないことを確保することで、非同期組織内のチームが自己組織化し、誰が特定の時間帯をカバーするかを決定できるようにすることで、これらの需要の上に非同期ワークを重ねることは可能です。

タイムゾーン

非同期でコミュニケーションすることは、タイムゾーンにまたがってチームメンバーが分散している痛みを軽減する優れた方法ですが、小さなチームとしてこれを管理することは特に困難です。例えば、主に北米に拠点を置く小規模チームは、タイムゾーンの差からシンガポールから参加した最初のチームメンバーとのコミュニケーションに苦労するかもしれません。

しかし、チームがスケールし、間のタイムゾーンにさらにカバレッジが追加されると、世界が回るにつれて作業を引き渡すことが容易になります。多くの意味で、タイムゾーンの管理はスケールとともに容易になります。チーム間のデルタが減少するためです。

外部候補者の面接

GitLab のすべての面接プロセスには何らかの形の同期コミュニケーションが含まれます。一部のチームは面接プロセス中に非同期の慣行を活用していますが、これはすべての面接プロセスで標準的なアプローチではありません。

会社外での非同期ワーク

チーム内で非同期ワークを確立していても、会社外の人と作業する際に非同期の慣行を奨励することは困難または不快に感じることがあります。

すべての組織はそれぞれの規範を持っていますが、情報提供と教育を通じて丁寧に現状に挑戦することができます。外部の関係者と非同期で作業するためのアプローチを以下に示します：

1. 同期で始める： プロジェクトやパートナーシップのキックオフのために同期通話を行ってください。その通話中に、今後のプロジェクトに一部の非同期ワークを組み込みたいことを伝えてください。この通話を関係とラポールを構築するために使用すると、非同期ワークがより効率的になります。
2. 期待を設定し、行動でモデルを示す： どのように非同期で一緒に作業するか（どのツールを使用するか、何を文書化するか、どのくらいの頻度で）を事前に議論してください。将来の同期のためのカデンスに合意することで、全員が何を期待するかがわかります。プロジェクトやパートナーシップを通じてこの行動をモデルにしてください。
3. 非同期ドキュメントを共有する： ハンドブックページまたは非同期に関するドキュメントを外部で作業している人々に送ってください。これにより、この方法で作業することに慣れていない人は、ページを参照して他の人と共有することができます。

一部の組織は非同期で作業することに開放的でない場合があるため、特にクライアント向けの役割では柔軟性を持つことが重要です。しかし、より多くの会社が非同期へのバイアスを持っていたら、どれほどの時間が節約できるか想像してみてください？

GitLab での非同期

非同期コミュニケーションは、ビジネスがますますリモートになる世界において重要な差別化要因です。GitLab は非同期コミュニケーションをより明確に定義し、運用化しようとしています。

時間の経過とともに、GitLab という会社はその非同期カルチャーをイテレーションしてきました：

1. イテレーション 1：GitLab は小規模チームとして共有された観察された行動を通じて主に非同期で運営していました
2. イテレーション 2：プレイブックを構築し始め、同期と非同期がいつ適切かを定義しました
3. イテレーション 3：ベストプラクティスと意図的な運営を定義しました。

これにより以下が実現すると信じています：

1. GitLab がリモートワークにおけるリーダーシップを維持するのに役立つ。
2. コミュニケーションモードの曖昧さを減らし、ハンドブックファーストを強化する。
3. GitLab チームメンバーの日常生活に柔軟性の追加を可能にする。
4. グローバルリモートワークの長期的ビジョンをサポートする。

GitLab チームでの非同期統合の例

このページにマージリクエストを作成して、非同期統合の例をさらに追加することを歓迎します。

非同期で構造化されるべきコアな行動/コミュニケーション

1. ホワイトボードを通じてコラボレーションやブレインストーミングを求める場合は、GitLab が Google ドキュメントをリモートホワイトボードとして使用する方法を研究してください。
2. 提案と思考のスターターは書き留められるべきです。そうすることで、広いグループが非同期でフィードバックとコンセンサスを素早く集めることができます。
3. 別のチームメンバーからの助けやフィードバックを求める場合は、適切なコンテキストとともに GitLab のエピック、Issue、またはマージリクエストにリクエストを文書化する意欲がなければなりません。

非同期に代わってミーティングを断る方法

ミーティングはラポールを構築し、プロジェクトを前進させるのに有用です。しかし、非常にコストがかかりフローを中断させます。ミーティングをスケジュールする前に二度考え、ミーティングの招待を丁寧に疑問視することは共同の責任です。

ミーティングよりも非同期ワークフローを提案することは不快に感じることがあります。すべての GitLab チームメンバーが、これが真に意味することを認識するよう確保したいと思います：仕事をよりインクルーシブな方法で前進させるための誠実な試みであり、個人的な侮辱ではありません。存在する必要がないかもしれないミーティングに招待された場合、丁重に断って GitLab チームメンバーをこのハンドブックセクションに誘導することは問題ありません。

以下は、Dropbox が組み立てた優れたリモートコミュニケーションガイドから借りたいくつかのサンプルの断り文句です。

1. 「お招きいただきありがとうございます！考えと進捗が文書化されるよう、代わりに GitLab Issue またはマージリクエストを使用して解決できないか検討いただけますか？」
2. 「最近たくさんのミーティングに参加していますが、スケジュールについてより規律正しくしようとしています。まずミーティングなしで解決できないか試してみませんか？」
3. 「喜んでフィードバックをお伝えします！ミーティングをスケジュールする前に、GitLab Issue/マージリクエストまたは共有ドキュメントで確認させていただけますか？」

チームがあなたが参加できないミーティングを進めることを決定した場合は、代理人を割り当てて代表してもらい、添付されるべきカレンダーの招待に添付されたアジェンダにフィードバック/質問を事前に提供することを検討してください。

ベストプラクティス、ガイドライン、非同期の機能セット

非同期ワークは、理解と配慮を強調し、一律のアプローチを規定するのではなく、さまざまなコミュニケーションアプローチをサポートし合理化する機能セットです。

チームは非同期ワークフローの機能を完全に理解し、GitLab（製品）が非同期コミュニケーションをどのように促進するか、そして非同期の方法で既存のツール（例：Google ドキュメント）を活用する方法を理解するためにセルフサービスのメンタリティ、唯一の信頼できる情報源（SSoT）を受け入れるべきです。

GitLab チームメンバーはミーティングに疑問を呈し、非同期の代替案（例：GitLab エピック、Issue、またはマージリクエストでの議論）を提案して、ミーティングのトピックをカバーすることができます。

1. 非同期パイロットを実施してください。これは 1 週間の週次ミーティングの半分を非同期で参加し、同期出席と非同期出席の違いについてレトロスペクティブを行うことを意味するかもしれません。
2. 非線形の労働日パイロットを実施してください。生産性のピーク時間、介護時間に合わせてスケジュールを変更することを検討するか、厳格に同期的な組織ではサポートされない代替勤務スケジュールで実験してください。
3. 特定の作業について、最大の効率とイテレーションの可能性のために同期と非同期のエンゲージメントの混合を最適化するよう努めてください。
4. チームメンバーは異なる学習とコミュニケーションスタイルの好み（例：ニューロダイバーシティ）を持っており、音声による議論が書面よりも大幅に効果的です。思慮深くタイミングを計った同期的な議論により、誰もが貢献できます。
5. すべてのミーティングは具体的な提案のレビューであるべきか、将来の一連の非同期イベントを触媒するためのものであるべきです。そして、非同期で可能な場合より効率的な結果につながる場合にのみ開催されるべきです。
6. プロジェクトやマイルストーンの開始時の初期チームビルディングシンクは、その後の一連の高効率な非同期イベントを解き放つことができます。これらの初期シンクを意図的に構造化して、ラポールと信頼を構築することに注意してください。グループを共有スペースに集める目的は明確であるべきです：チームメンバーが主に非同期に切り替えるために必要なコンテキストを備えることです。これらの意図的に構造化されたキックオフ通話でさえも、すべてのタイムゾーンにインクルーシブでない場合があることに注意してください。したがって、GitLab のミーティングガイドラインに従うことが重要です。カレンダーの招待に Google ドキュメントのアジェンダを添付し、全関係者が対面で参加できない場合にテキストで貢献することを奨励し、将来の視聴のためにセッション全体を録画してください。
7. 特定の書面によるアクションまたはフィードバックを具体的に要求している場合、かつ実行に必要な提案とコンテキストを提供している場合にのみ、@ ハンドルを使用してください。
8. GitLab のエピック、Issue、またはマージリクエストが 1000 語以上の場合、効率的な重要ポイントの吸収のために Issue/マージリクエストの上部にサマリーが必要です。
9. アイデアを同期的にブレインストーミングまたはインキュベーションすることを全面的に否定すべきではありませんが、チームメンバーは知識の劣化を防ぎ、同期ブレインストーミングセッションに参加した人々よりも広いグループからのフィードバックをインクルーシブにするために、できるだけ早くテイクアウェイを文書化することを心がけるべきです。GitLab ソングブックで将来の栄光のために新しいジングルのアイデアの閃きを発見した 2 人の作詞家を考えてみてください。彼らはアイデアのエッセンスを捉えるために音声メモを録音し、それをより広く共有して曲をリファインし、イテレーションするかもしれません。同様のアプローチは、GitLab マージリクエストまたは Issue にアイデアの閃きを文書化し、追加フィードバックのために関連する Slack チャンネルで共有することで取ることができます。

非同期アンケートデータ

GitLab チームメンバーは、2020-09-02 に公開 #company-fyi Slack チャンネルで投票され、2020-10-02 まで投票が行われました。チームメンバーの約 20%が投票に回答し、回答と回答の割合は以下の通りです。

チームメンバーへの質問：仕事関連（例：インフォーマルなコミュニケーションではない）の議論について、非同期よりも同期コミュニケーションを選ぶ理由は何ですか？

• GitLab の「非同期コミュニケーションへのバイアス」という運営原則を知らなかった - 1%
• 書面よりも口頭コミュニケーションを好む - 3%
• 内容が機密だと思う - 10%
• チームの別のメンバーが同期ミーティングのテイクアウェイを文書化できる - 1%
• 非同期コミュニケーションで他の人の注意を引くのが難しいと感じる - 12%
• ラポールを構築し、将来の非同期会話を触媒するのに役立つ - 38%
• 自分の役割で非同期に頼るためのツール、サポート、またはトレーニングがないと感じる - 0%
• 非同期コミュニケーションを成功させるための設定の方が、ミーティングをスケジュール/実施するよりも時間がかかる - 6%
• 非同期で作業する場合、ブレインストーミングや情報収集が難しいと感じる - 19%
• その他 - 10%

主な学び

回答は解釈の余地がありますが、データは GitLab リーダーがチームのダイナミクスをより良く理解し、解決策をイテレーションするために使用できる重要な洞察を提供します。

1. わずか 1%が非同期コミュニケーションに関連する運営原則を知らなかったと答えましたが、リーダーはすべての運営原則が認識され、よく理解されていると仮定すべきではありません。1:1 ミーティングと日常のワークフローで価値観を強化し議論してください。
2. GitLab はデフォルトで公開です。何かが機密であると思う場合は、コミュニケーションハンドブックの非公開セクションで確認してください。
3. 非同期の手段で誰かの注意を引くのが難しい場合は、同期エンゲージメントを活用して期待のギャップについて話し合うことを検討してください。GitLab は作業が行われる場所について明確にしていますが、一部のチームメンバーはGitLab の To-Do リストまたはスコープラベルのみから作業し、優先順位付けへのアプローチが異なります（例としてブランドとデジタルデザインのイテレーションプロセスハンドブックを参照）。家族と友人を最優先にするために返答の遅れが生じる可能性があるため、ポジティブな意図を仮定してください。
4. 回答者の大多数は、ラポールを構築し将来の非同期会話を触媒するために同期エンゲージメントを活用することを示しました。容易に行われるからではなく、将来の効率とコヒージョンを生み出すためにミーティングを開催することは、ポジティブな結果です。
5. GitLab チームメンバーが非同期ワークフローに頼るためのツール、サポート、トレーニングがあると感じていることは励みになります。しかし、リーダーは GitLab がパイロットして表面化できる新しいツールと慣行に注意を払い、公開 #values Slack チャンネルでこれらを共有するべきです。イテレーションは非同期コミュニケーションへの私たちのアプローチにも適用されます。

GitLab の専門家が同期と非同期をいつ使うかについてアドバイス

1. 「インシデントや締め切りなどの緊急事態が発生した場合に、他の人を助けるために同期ミーティングを使用します。」
2. 「特定の問題を解決するために非同期の説明やバックアンドフォースよりもライブダイアログが速い場合のトラブルシューティングに主に同期を使用します。」
3. 「非同期の選択肢を使い果たした場合、または非同期が成果につながっていない場合に同期を使用します。」
4. 「チームとのクリエイティブなアイデア/提案を生み出すために同期ミーティングを使用します。これは非同期では行うのが難しいです。」
5. 「Zoom での 10 分は、数時間にわたる 100 の Slack 返信や、タグ付けされたチームメンバーからの GitLab Issue スレッド返信を 10 日間待つよりも効率的です。」
6. 「仕事関連の正式なコミュニケーションについては、非同期を好み（フォーマットが自分で選べる場合は非同期を選択します）。同期は関係構築（コーヒーチャット、グループソーシャルチャット）に優れています。」
7. 「チームメンバーがまだ一度も会ったことがない場合（例：コーヒー/ソーシャル/チーム通話）に、最初の人間的なつながりを確立するために同期を楽しみます。」
8. 「時間的に非常に敏感なものがある場合は、関係者全員との同期ミーティングを選んでより迅速な議論をします。」
9. 「私は非同期コミュニケーションをリードし、非同期が失敗した場合は同期会話に戻る傾向があります。時間的に敏感なトピックが効率的に対処されない場合や、参加者が矛盾したり互いに話し合っている場合に非同期コミュニケーションが失敗していると見なします。このような状況では、集中して会話を強制するために同期会話を呼びかけ、会話が事実上解消された後は非同期に戻ります。」
10. 「非同期はコードにリンクされた詳細な技術的会話に非常にうまく機能します。時々、何かを概念化するために数回読む必要があり、非同期はこれに最適です。非同期はコードレビューにも優れています。大きなピクチャーの議論には非同期とライブ/ビデオ通話の組み合わせが有用ですが、透明性のために関連する GitLab Issue に結果を文書化すべきです。Google ドキュメントを使用することもありますが、GitLab の方が優れた記録であり、検索やコメントが容易です。」
11. 「ほとんどの場合は非同期を好みますが、デザインプロセスの初期段階では問題を理解してチームと一緒にブレインストーミングするために同期時間が必要なことも認識しています。その後、全員がコミュニケーションに effort を入れる限り、非同期が同期と同じくらい効率的であることがわかります。潜在的な誤解とバックアンドフォースの必要性を最小化するために、追加の詳細を含め、書き方に特に注意を払うことが重要です。」
12. 「ほとんどのコミュニケーションを非同期で処理しますが、時々の同期ミーティングがプロダクトチーム全体の方向性を合わせるのに役立つことがわかりました。私たちの同期セッションは、ユーザーリサーチの結果を議論したり、デザインをレビューしたり、実装について議論したりするために全員を集めます。このまれなミーティングは全員の方向性を合わせ、チームの非同期構造がより円滑に流れるのに役立ちます。」
13. 「ほとんどの場合、デフォルトでは非同期コミュニケーションを使用します。一般的に、特定の意思決定につながったステップをたどり、理由を再考するのが容易です。稀に特定の観点を共有することが難しいことがあります。1 つの事項について数回バックアンドフォースした後、問題の根本に到達するために短いチャットを好みます。そして結果を文書化します。同期を非同期より好むもう 1 つの例外は、重要な意思決定を行う前の最後のブレインストーミングです。非同期コミュニケーションでは、いくつかの事項が些細に見えすぎて尋ねられないことがありますが、最終的には重要である場合があります。そのような場合、最終的な締めくくりのステップとして同期ブレインストーミングを行った後、レトロスペクティブや AMA セッションが有用かもしれません。」
14. 「私は非常に技術的な概念に取り組んでいます。非同期コミュニケーション（特に書面）でこれらを理解することは時間がかかり困難です。機能の技術的な詳細と目的を説明し、その場で質問に答えることができる技術的な同僚とミーティングする方が効率的です。技術的な詳細をよく理解した後は、非同期で作業することが快適になります。」
15. 「非同期コミュニケーション中には、誰かの返答を待ちながら多くのコンテキスト切り替えが発生します。素早く前進できるようにするために同期コミュニケーションを行う必要がある場合があります。」

GitLab は世界最大のオールリモート企業の 1 つです。私たちは地球上のどこにも会社所有のオフィスがなく、100%リモートです。65 か国以上にチームメンバーがいます。

GitLab の製品が優れているかどうかを尋ねることが妥当であるように、私たちはリモートワークの分野における専門知識について透明であることを望んでいます。

学びを共有する

GitLab はオールリモートが仕事の未来であり、リモート企業はそれを取り入れている他の組織のために道を示す共同の責任があると信じています。あなたまたはあなたの会社にこのページに貢献するより広い世界に役立つ経験がある場合は、マージリクエストを作成してこのページへのコントリビューションを追加することを検討してください。

オールリモートのメインページに戻る。

ページのソースコードを見る - ページの編集 - please contribute.