はじめに：非同期コミュニケーションの増大と組織課題

リモートワークやハイブリッドワークに関係なく、オフィスワークであってもSlack・メール・Notion・Teams など、非同期コミュニケーションに頼る機会が格段に増えている。実際に、オフィスにいたとしても非同期のテキストコミュケーションが多い。
だが、こうした非同期の便利さと引き換えに、いくつかの課題が顕在化するようになった。まず挙げられるのは、メッセージの往復回数の増加だ。オフィスで雑談まじりに「これどうなってる？」と聞けば一瞬で解決したかもしれない問題が、Slack のメッセージを投げても相手が離席していてすぐには返事が来ない――それだけならまだしも、投げかけが曖昧だったり、目的が十分に説明されていなかったりすると、数時間後に「それは何のデータが欲しいんですか？」と追加質問が返り、さらに数時間後にようやく詳細を伝え、やがてまた別の質問が……という具合に、ちょっとした意思決定に何日もかかってしまうケースが生まれる。
また背景や文脈の共有不足が起こりやすいことも大きな問題だ。非同期の文章だけでは「なぜこの数字が必要なのか」「この議題の重要度はどれほどか」などが十分に伝わらないまま作業が進みがちである。最終的に「そこまで緻密な分析は要らなかったんだが……」とか「実は開発そのものが白紙化したのでデータ抽出しなくてよくなった」という事態に陥り、無駄な工数が発生してしまう。
そして、これらが積み重なると組織全体の意思決定リードタイムが大幅に遅れ、内外から「結局、いつになったら結論が出るのか」と不満が生まれたり、優先度の高いプロジェクトが停滞してしまったりする。
こうした非同期下のコミュニケーション問題は、実はコミュニケーションの“型”を少し意識するだけで大きく改善できる。本稿では「B‑H‑D フレーム（Background–Hypothesis–Decision）」による“仮説先出し”手法を紹介し、その効果を具体例を交えて考える。

B‑H‑D フレームとは何か

紹介する B‑H‑D フレームの要点は以下の三つである。

1. Background（背景）
   なぜこの問いを投げかけるのか、どんな文脈・経緯があるのか。まずは「依頼がどこから来て、どこへ向かっているのか」を明示する。

2. Hypothesis（仮説）
   送信者の考えや狙い、あるいは「こういう結果であれば A、そうでなければ B」といった想定を先に書く。「これを確認したい理由はきっと●●だからだ」「こういう数値が出れば▲▲が導ける」等を提示する。

3. Decision（意思決定）
   相手（読み手）に何をしてほしいのか。データの抽出だけでなく、それが 30% を超えれば新機能に Go したいのか、3日以内に回答してほしいのか――そうした「結果をどう扱うか」「いつまでに意思決定したいか」を明確にする。

この三つが先に提示されていれば、受け手は最初の段階で「ああ、そういうことを考えているのか。だったらこういう指標も必要かもしれないな」「締め切りは 3 日後だからこの形で進めよう」と段取りを整理できる。結果的に、無駄な追加質問を減らし、往復を最小化し、意思決定を加速できる。

非同期コミュニケーションにおける B‑H‑D の効用

1. 往復回数の削減

先ほど述べたように、最初のメッセージで「背景」「仮説」「意思決定条件」が整理されていると、いわゆる「ping-pong」のようなやり取りがグッと減る。

• 「そもそも何が必要なんだっけ？」

• 「それを知ってどうするの？」

• 「そこまで細かい数字が必要なら、最初から言ってくれればいいのに」

こうした追加問い合わせが発生しにくくなるため、集計や作業のやり直しが減る。

2. 意思決定のスピードアップ

「Decision」の部分で 「どの基準を超えたらどうする」 が明確になると、データや情報がそろった瞬間に判断ができる。

• 経営層の承認を得る場合でも、「なぜその判断が必要なのか」がすぐにわかるので、上司側も即座に判断しやすい。

• 読み手が判断保留する理由が取り除かれるため、結果的に意思決定リードタイムが縮まる。

3. 後追い参照が容易になる

非同期コミュニケーションはログとして残りやすいという特性がある反面、情報が散逸しがちでもある。しかし B‑H‑D フレームで書かれたメッセージは「あとから読んでも何の話かが一目でわかる」ため、後日ほかのメンバーがスレッドやメールを見返したときに役立つ。
ドキュメント検索で引っかかった場合でも、冒頭に重要な情報がまとまっているので理解が早い。

成功・失敗ケース：Slack でのやり取り例

以下は B‑H‑D の有無で何が変わるかを示す、Slack 上での典型的やり取り例である。

1. 失敗例（生産性の低いやり取り）

[09:15]  PdM佐藤:
機能Aと機能Bの利用率ってどれくらい？ ざっくり教えて！

[09:17]  Analyst田中:
了解です！ 期間はどれぐらいで取ればいいですか？

[09:20]  PdM佐藤:
うーん、1か月くらいかな…？

[10:50]  Analyst田中:
データ出ました！A: 62,410, B: 57,180 です。

[11:05]  PdM佐藤:
ありがとう。でもピーク時の値と全体に占める割合も欲しいんだけど……できるかな？

[11:07]  Analyst田中:
わかりました…再度集計します。

このように、背景（何が目的か）や仮説（どこまで数値が出ればどう判断するか）が最初に示されていないため、あとから「やっぱりこれも」「これ足りない」などの追加要求が出まくり、何度も SQL や集計をやり直すハメになる。

2. 成功例（仮説先出し＋意思決定条件つき）

[09:15]  PdM佐藤:
機能AとBの利用状況を教えてください。
- 背景（B）: 新機能Cのリリース判断をしたい。AとBが広く使われているならUI流用を考えている
- 仮説（H）: 直近30日平均でA+Bが全体DAUの30%を超えていれば、流用する価値が高い
- 意思決定（D）: 30%を上回っていれば今週中にCの仕様策定にGo。データは本日18時までに欲しい

このメッセージなら、受け手のアナリスト田中は 「全体DAUに占める割合」「重複調整後のA+B」 など、最初から必要な指標をまとめて計算できる。往復を最小限に抑えられ、スピーディーに意思決定に至るだろう。

メール・ドキュメントでの応用例

1. メール

メールはもともと“文章”が主体なので、B‑H‑D フレームを導入しやすいメディアといえる。たとえば件名に「[要確認：新規機能リリースの延期可否]」と明示し、本文冒頭で次のようにまとめる。

こう書いておけば、受信者は1行目を読んだ段階で「要確認の依頼が来た」とわかり、なぜチェックが必要かもすぐ理解できる。もし詳細なテスト結果などを添付する場合は、「添付資料をご確認ください」と加えればよい。

2. ドキュメント（Notion, Confluence など）

共同編集ツールで提案や仕様をまとめる際も、最初に B–H–D のセクションを設けると有効だ。たとえばテンプレートを以下のようにする。

• 背景（Background）: 解決したい課題や、既存機能の問題点

• 仮説（Hypothesis）: 改善の方向性、想定インパクト

• 意思決定（Decision）: 実装期限、判断基準、合意を得たい相手

同じツールを使いながらも、これがないと「あれ？ なぜ今この企画が必要なんだっけ？」とあとで他の人が読んだときに迷いが生じる。一方、冒頭で背景と仮説が明示されていれば、途中から参加するメンバーでもすぐに文脈を理解でき、不要な説明コストを減らせる。

B‑H‑D を導入した企業事例

GitLab──“すべてがドキュメント化される世界”の幕開け

かつて、GitLab という DevOps プラットフォームの企業は、世界中に散らばる 60 カ国以上のメンバーを束ねていた。時差がある国々で働くエンジニアやデザイナー、ビジネスチームが協働するには、チャットですらリアルタイムに返せない場面が多い。そこで彼らがたどり着いたのが、「まず書く」文化だった。
CEO の Sid Sijbrandij は「ハンドブック・ファースト」の方針を掲げ、あらゆる情報やルールをオンライン上のドキュメントに落とし込んだ。仕様変更や新機能の議論が出ると、担当者はまず Background（なぜこれを提案するか）や Hypothesis（どうなれば成功なのか）をしっかり書き、Decision（いつ誰が何を決定するのか）を GitLab Issue 上で明示する。そうしておけば、遠隔地にいるチームメンバーが時差を気にせず議論に参加できるのだ。
あるとき、新機能の UX デザインを巡って大きな論争が起きた。通常ならオフィスに集まってホワイトボードを囲むところだが、GitLab には集まるオフィスがない。そこで各々が Issue に長文コメントを投稿しながら、根拠データや想定ユーザーフローを逐一 B‑H‑D スタイルで書き込んだ。すると対面会議のようにダイナミックな議論は難しいものの、数日かけて世界各地の意見がまとまり、最終的にエンジニアリーダーが「OK、30% 以上のユーザーがこの機能を使いそうだという仮説が確認できたから、来月末にリリースしよう」と決断した。
もしこれが B‑H‑D の明確化なしに行われていたら、単なるチャットの応酬で埋もれてしまい、合意形成に倍の時間がかかったかもしれない。GitLab のように**「最初にすべての文脈と想定を洗いざらい書く」**スタイルは、一見手間に思えても、遠隔地の全員が一度に深い理解を共有できるため、結果的に早く決まるという逆説を証明している。

Basecamp──リアルタイムは“時々”、非同期が“ほとんど”の世界

米国シカゴに本拠を置く Basecamp（旧称 37signals）は、リモートワークの先駆者として有名な企業である。彼らの社内ガイドラインには「Real-time sometimes, asynchronous most of the time」というフレーズが掲げられているが、そこには面白い逸話がある。
あるとき、新機能開発の緊急度を巡ってチームが分裂しそうになった。A グループは「もうすぐ競合製品が出るから今すぐ会議を開いて決めよう」と主張し、B グループは「急いで決めすぎると不完全な仕様になりそうだ」と反対。通常ならすぐに Zoom 会議でぶつかり合いそうな場面だが、Basecamp では「まずは落ち着いて書こう」となった。
それぞれが提案文を B‑H‑D フォーマットでまとめ、Basecamp の社内ツールに投稿していく。A グループは「競合のデータ」を背景に示し、B グループは「長期的なブランドイメージへの影響」を仮説として示した。最終的に「ユーザー体験が 70 点未満のままリリースすると、将来的にサポートコストが増す」という B グループの仮説に多くの賛同が集まり、若干延期しつつも今すべき改修を優先する、という結論に落ち着く。
結局、リアルタイムの会議が全く開かれなかったわけではなく、要所要所で短いビデオチャットは行われたものの、基礎となる議論はすべてテキスト上で行われた。それも、書き手が B‑H‑D に即して自分の考えを具体化し、受け手が時間をかけて読み返しコメントをつける形で進んだため、慌てて結論を出すのではなく、じっくり最善策を練ることができた。これが Basecamp が掲げる「非同期が基本」のコミュニケーション文化であり、言い換えれば「生産的な意見交換とは、必要な情報を最初に出し尽くしておくこと」という思想にも通じる。

Atlassian──リモート体制での合意形成に欠かせない“文章の力”

Atlassian は Jira や Confluence など、チームコラボレーション系の SaaS を提供するグローバル企業として知られている。彼らもまた、フルリモート化の推進で多国籍に渡る従業員を抱え、社内で“ドキュメント文化”を広めてきた。
あるプロダクトマネージャーは、複数の開発拠点のメンバーとやり取りしながら、リリーススケジュールを詰める必要があった。時差は最大 14 時間、しかも全員が複数案件を並行しているため、簡単にミーティングを設定できない。そこで Confluence に「次期リリースで決めるべきこと」というページを作り、まず Background（既存リリースの遅れ、ユーザーからのフィードバック）をまとめた。さらに Hypothesis（今回の追加機能で離脱率が 20% 改善すると期待）を提示し、Decision（もしデモ版の指標が 15% 以下なら別案にシフト）を明記した。
このページを公開し、各担当者がコメントで異論を述べたりデータを追記したりする形で非同期に進めたところ、実際に「15% を下回りそうだから早めに別案に切り替える」という結論が 1 週間ほどで定まった。従来なら複数の時間調整や連続ビデオ会議が必要だった場面を、B‑H‑D フレームで書き込んだ提案ページ＋コメントという非同期ベースで乗り切ったわけである。担当者は「みんなが文章を書くことに慣れたら、むしろ短い時間で深い議論ができるようになった」と語り、それが Atlassian 全体の文化にも広がっている。

他職種への横展開：エンジニア・カスタマーサクセス・BizDev など

B‑H‑D フレームや仮説先出しの考え方は、プロダクトマネジメントだけでなく、あらゆる部門で有効活用できる。例えば以下のようなシーンが考えられる。

1. エンジニアリング領域

   • インシデント報告や新機能の設計レビュー時に、背景・技術的仮説・判断すべき点を先に書く。

   • 「障害原因は恐らく最新デプロイの API ミス。ロールバックすれば直るはず。1 時間以内に判断が必要」といった書き方をすれば、SRE チームやマネージャーが即座に合意できる。

2. カスタマーサクセス / サポート

   • 顧客からの要望をプロダクトチームへ連携する際に、背景（どんなユーザーがどう困っているか）と仮説（こういう機能を追加すれば解決しそう）が最初に整理されていると、エンジニアが正確に優先度を判断しやすい。

3. 営業 / BizDev

   • 新規パートナーとのアライアンスを提案する場合、「なぜこれが Win-Win なのか」「どんな指標を達成すれば合意とするか」を明記すれば、お互いの認識ズレを減らす。

   • 非同期のメールや共同ドキュメントで調整していくときにも有効。

4. マーケティング / クリエイティブ

   • キャンペーン企画書を作成するとき、「直近の売上低下を解消するのが目的で、このアイデアによってターゲット層の認知率が 10% 上がるはず」という仮説が明確なら、デザイナーや広告運用担当も効果測定を想定しやすい。

このように、「Background」「Hypothesis」「Decision」を意識して書くだけで、受け手が「何をすればいいか」「どんな確認が必要か」をすぐに把握できる。職種を問わず、互いの認識ギャップを最初から潰すことが、非同期コミュニケーション時代には重要な鍵だ。

なぜ今、仮説先出し型が必要なのか

1. リモートワークの常態化
   以前であれば対面会議やデスク越しの口頭確認で済んだことが、いまやテキストベースのやり取りに置き換わっている。時間差がある以上、最初から背景や仮説を共有しないと、確認のたびに半日～1日ロスしてしまうリスクが増大する。

2. コスト意識の高まり
   企業がコスト削減・効率化を徹底する中で、データ分析や仕様検討に余計な工数をかける余裕は少ない。一度のやり取りで意図を完璧に伝達できれば、トータルの作業時間が大幅に減る。

3. グローバル展開・多文化チーム
   GitLab や Atlassian のように多国籍・多言語のメンバーが混在する組織では、「一度書いた内容」は全員の共通情報になる。曖昧な表現や文脈不足を放置すると誤解が拡大する可能性が高い。B‑H‑D フレームを徹底すれば、文脈を揃えるハードルが下がる。

4. 情報過多・ノイズ増大
   Slack やメール、各種タスク管理ツールの通知が絶えず届く現代。すべてを詳細に読んでいられない以上、冒頭に必要情報を凝縮してある文章ほど読み手に親切であり、結果的にアクションも早くなる。

まとめ

非同期コミュニケーションの浸透は多くのメリットをもたらす一方、目的や背景があやふやなままやり取りが進んでしまうと、往復回数の増加や意思決定の遅延といった深刻な課題を招く。そこでB‑H‑D フレーム（Background–Hypothesis–Decision）を使い、最初に仮説を先出しして背景と判断基準を明示するだけで、コミュニケーションの生産性は大きく改善する。
GitLab や Basecamp、Atlassian といったリモートワーク先進企業の事例からも、「情報を最初に書き切る」ことが組織のスピードと質を高める秘訣だとわかる。チャットツールでの依頼文、メールの本文、ドキュメントの冒頭――どんな形式でもいいので、まず「なぜこれが必要で、どんな仮説を持っていて、どう判断してほしいのか」を示そう。そうすれば、読み手は手戻りなしに対応でき、意思決定も加速する。
この仮説先出し型のコミュニケーションは、言い換えれば「相手の頭の中を代わりに整理してあげる」やり方でもある。書く側があらかじめ整理する分、手間はかかるかもしれない。だが、その一手間がチーム全体の無駄を省き、ひいては自分の仕事もスムーズに進める近道となる。

コラム：箇条書きの落とし穴──「並んでいるだけ」では伝わらない

非同期コミュニケーションにおいて、情報を簡潔に伝える手段として箇条書きは非常に便利だ。SlackやNotion、Confluenceなど、ほぼすべてのビジネス向けツールで「箇条書き」を目にしない日はない。だが、「箇条書きにすれば伝わる」は誤解である。構造化されていない箇条書きは、むしろ読み手の思考を奪い、生産性を落とす原因になりうる。

一見まとまっていそうで、実は読みにくい箇条書き

たとえば、次のような共有メモを見たことはないだろうか。

このメモは情報量もそれなりにあり、単語の選び方にも粗はない。だが、読み手にとって「何がポイントなのか」「何を判断すべきか」がまるで見えてこない。
この原因は三つある。

文と文の関係性が示されていない

この箇条書きには、事実（KPIが下がった／競合が動いた）と仮説（ver3が有効）と判断材料（段階的にリリース可能）が混在している。それにもかかわらず、それぞれの文章同士の関係性──たとえば「因果関係」「前提と結論」「補足と要点」──がどこにも書かれていない。すべてが同じレベルで、同じ重みで並べられている。つまり、「並んでいるが、つながっていない」。
結果として読み手は、「何が起点で、何を根拠に、どこに向かって話が進んでいるのか」を自分で想像するしかなくなる。書いた本人の頭の中では論理的に整理されていたとしても、それは共有されていないのと同じである。

一文で意味をなしていない項目がある

「モバイル中心の動き」という一文を例にとってみよう。これが何を意味しているか、文脈がなければ判断できない。「ユーザーのアクセスの大半がモバイルからになっている」のか、「社内でモバイル対応に注力する方針になった」のか、「最近のユーザー行動がモバイルシフトしている」のか――複数の読み取りが可能だ。
つまり、主語と述語が省略されている曖昧な表現は、短く済ませたつもりでも、かえって理解を妨げる。非同期では、書かれたものがそのまま唯一のコミュニケーション手段になる。だからこそ、「言葉足らず」の影響は大きい。

意思決定の目的が明記されていない

そもそもこの情報群は「何を判断するためのものなのか？」が明記されていない。UI案 ver3 の是非を問うのか？リリーススケジュールを前倒しするかどうかを議論するのか？それとも競合対応の優先度を再調整するための議論か？
どの前提に立ってこの情報が必要なのかが曖昧なまま提示されると、受け手は解釈の自由を持ちすぎてしまう。それは“自由”ではなく“判断のブレ”であり、非同期では致命的なリスクである。

構造化するとは、情報に「意味の文脈」を与えること

箇条書きが悪いのではない。問題なのは、意味の関係性が提示されないまま、情報が「ただ並んでいるだけ」になることである。
では、どうすればよいか。たとえば、次のようにB‑H‑D フレームを用いながらナラティブに整理すれば、読み手の理解が一気に深まる。

◉ UI改修プロジェクト：状況の整理と検討事項

現在、機能Aの利用がモバイルを中心に増加しており、ユーザー行動の変化が観察されている。一方で、直近2週間の継続率（KPI）が5ポイント低下しており、UIに起因する体験上の問題が疑われる。
この状況を踏まえ、UI案 ver3 の導入を検討している。ver3 は既存機能の課題を反映しており、ヒアリング済みの6ユーザーからも一定の支持が得られている。また、BEチームからの報告によれば、段階的なリリースが技術的に可能とのこと。
なお、競合X社は今月類似機能の投入を予定しており、競争上のタイミングも無視できない。そこで、ver3案の採用有無と、今月中のリリース前倒し是非について、4/15（金）までに方針を固めたい。

こう書けば、読み手は「状況（背景）→仮説→意思決定」という流れで情報を受け取り、どこに注目してどう考えるべきかを自然に理解できる。同じ情報でも、構造のある言葉で書かれているか否かで、伝わり方はまるで違う。

最後に：情報の“粒”ではなく、“構造”を届ける

箇条書きは、あくまで整理の手段であって、構造化の代替にはならない。非同期コミュニケーションの本質は、「思考を文字で再現し、相手の脳内で再構築できるように伝えること」にある。
そのためには、短い文を並べるだけで満足せず、それらがどんな関係にあるのか、どんな判断を導きたいのかを、見出し・接続詞・文脈で補いながら書き切る必要がある。
「これは伝わるだろう」と思ったときこそ、ぜひ一度問い直してほしい。

• それは、並んでいるだけになっていないか？

• 文として意味を成しているか？

• 読み手が、構造として理解できる設計になっているか？

伝える力は、書き手が「構造まで渡せるかどうか」で決まる。

参考資料

• The importance of a handbook-first approach to communication
  GitLabが掲げる「ハンドブック・ファースト」文化の詳細な解説。すべての業務やプロセスをドキュメント化する方針が紹介されている。

• All remote from day one: How GitLab thrives
  GitLabのCEOであるSid Sijbrandij氏へのインタビュー記事。全社員がリモートで働く中での文化構築やチームの連携方法について述べられている。

• GitLab's top strategies for a remote-first workplace
  GitLabがリモートファーストの職場を構築するための主要な戦略やベストプラクティスを紹介している。

• The 37signals Guide to Internal Communication
  Basecamp（旧37signals）の内部コミュニケーションガイド。非同期コミュニケーションを基本とする方針やその理由が詳述されている。

• Group Chat: The Best Way to Totally Stress Out Your Team
  リアルタイムチャットの問題点と、Basecampが非同期コミュニケーションを推奨する背景について解説している。

• How Basecamp Communicates
  Basecampのコミュニケーション手法や、非同期文化の実践例を紹介するブログ記事。

• How Confluence can help remote teams
  AtlassianのConfluenceが、リモートチームのドキュメント管理やコラボレーションにどのように役立つかを解説している。

• How to Support Remote Workers
  リモートワーカーをサポートするためのガイド。ドキュメントの共有や非同期コミュニケーションの重要性が述べられている。

• Optimizing Remote Work with Atlassian's Software Products
  Atlassianの製品群（Jira、Confluenceなど）を活用してリモートワークを最適化する方法を紹介している。