フレームワーク活用ガイドひとことで言うと#
**B（Background）R（Reason）I（Information）E（End）F（Follow-up）**の5要素で、あらゆるコミュニケーションを簡潔にまとめる。「長い＝丁寧」ではない。短く、的確に、相手が動ける形で伝えるのがBRIEF。
押さえておきたい用語#
- Background（背景）
- 相手が状況を把握するために必要な最低限の文脈情報のこと。1〜2文に収める。
- Reason（理由）
- 「なぜこの話をあなたにするのか」という目的と期待するアクションのこと。最初に宣言すると聞き手の姿勢が変わる。
- Information（核心情報）
- 伝えるべき最大3つのキーポイントを指す。人間が一度に処理できる情報量に合わせて絞る。
- End（結論）
- メッセージ全体の結論・要約を1文で表したもののこと。ここだけ読めば判断できる状態が理想。
- Follow-up（次のアクション）
- 相手に求める具体的な行動と期限である。「誰が・何を・いつまでに」を明確にする。
BRIEFの全体像#
こんな悩みに効く#
- 「で、何が言いたいの？」と聞き返されることが多い
- メールが長文になりがちで、書くのにも時間がかかる
- 報告や説明が冗長で、相手の集中力が切れてしまう
基本の使い方#
相手が状況を把握するのに必要な最低限の背景情報を伝える。
- 何の話か
- なぜ今この話をするのか
例:
- 「先月開始したWebリニューアルプロジェクトの進捗です」
- 「以前からWebサイトのデザインが古いという意見がありまして、昨年末の会議で検討が始まり、今年1月に予算が承認されて…」
コツ: 相手がすでに知っている情報は省略する。
なぜこの話をあなたにするのか、相手に何を求めているのかを明示する。
- 「判断をお願いしたい」
- 「情報共有です。対応は不要です」
- 「アドバイスをいただきたい」
これを最初に言うだけで、相手の聞く姿勢が変わる。 目的がわからないまま話を聞くのは、相手にとってストレス。
伝えるべき情報を最大3つに絞る。
人間が一度に処理できる情報は限られている。5つ以上の要点を並べると、相手は何も覚えていない。
絞り方:
- 「もしこの中で1つしか伝えられないとしたら？」と自問する
- 残りの情報は「補足資料」として別途共有する
- 箇条書きで構造化する
E（End）: 結論・要約を1文で。
F（Follow-up）: 次に何が起きるか、相手に何をしてほしいかを具体的に。
- 「以上の理由から、B案を推奨します。来週月曜日までにご判断いただけますか？」
- 「追加の質問があれば、明日のミーティングで対応します」
最後に「質問はありますか？」で締めると、双方向のコミュニケーションになる。
具体例#
BRIEFなし（ありがちな報告）: 「お疲れ様です。Webリニューアルの件なんですが、実はデザイナーさんが先週から体調を崩していて、それでモックアップの確認が遅れていまして、さらにクライアントからの追加要望もあって、もともと今月末が締め切りだったんですけど、ちょっと厳しくなっていて…」 → 3分経っても上司は何を判断すべきかわからない
BRIEFあり:
- B: 「Webリニューアルプロジェクトの進捗報告です」
- R: 「スケジュール変更の判断をお願いしたく」
- I: 「デザイナーの体調不良とクライアントの追加要望により、納期が2週間遅れる見込みです。対応策は3つ。リソース追加・スコープ縮小・納期延長」
- E: 「コスト面から納期延長を推奨します」
- F: 「明日までにご判断いただければ、クライアントに連絡します」
→ 所要時間30秒。上司も即座に判断でき、プロジェクトの遅延対応が1日早く始まった。
20人のプロジェクトチーム。メールの平均文字数が800字で、返信率が48%、平均返信時間が26時間だった。
BRIEFルールを導入:
- 件名に[判断依頼][情報共有][対応依頼]のラベルを必須化（=R）
- 本文は箇条書き3項目以内（=I）
- 最後に「期限：○月○日」を必ず記載（=F）
導入1ヶ月後の変化:
- メールの平均文字数: 800字→280字（65%削減）
- 返信率: 48%→87%（81%改善）
- 平均返信時間: 26時間→4.2時間（84%短縮）
→ メール平均文字数800字→280字、返信率48%→87%、平均返信時間26時間→4.2時間。「短いメールは失礼」という思い込みを捨てた結果である。
深夜2時にシステム障害が発生。CTOが経営陣グループチャットに報告する場面。
BRIEFなし: 「DBのレプリケーション遅延によりRead Replicaとの不整合が発生し、APIのレスポンスタイムが閾値を超過してサーキットブレーカーが作動し…」 → 経営陣は技術用語が理解できず、影響度がわからない
BRIEFあり:
- B: 「本日2:00にWebサービスの障害が発生しました」
- R: 「状況の共有です。現時点で経営判断は不要です」
- I: 「1. ユーザーの注文処理が約2時間停止。2. 影響は約1,200件の注文。3. 現在は復旧済み、データ損失なし」
- E: 「サービスは正常稼働に戻りました」
- F: 「明日10時に詳細レポートを共有します。顧客対応が必要な場合は別途相談します」
→ 経営陣は深夜でも30秒で状況を把握し、「了解。明日詳細を確認する」と即返信。非エンジニアに技術障害を伝える場面こそ、BRIEFの真価が問われる。
やりがちな失敗パターン#
- 背景説明が長すぎる — 相手がすでに知っている情報まで丁寧に説明してしまう。「相手が知らないことだけ」に絞る
- 理由（R）を省略する — 「何をしてほしいか」を言わずに話し始めると、相手は「で？」となる。目的を最初に宣言する
- 情報を全部伝えようとする — 「念のため」で情報を追加し続けると、核心が埋もれる。3つに絞る勇気を持つ
- Follow-upが曖昧 — 「ご検討ください」では相手は動けない。「何を・いつまでに」を具体的に書くことで、アクションが起きる確率が3倍になる
まとめ#
BRIEFフレームワークは、あらゆるビジネスコミュニケーションを「背景→理由→核心情報→結論→次のアクション」の5要素で簡潔にまとめる技術。話が長いと感じたら、まず「相手に何をしてほしいか」を明確にし、情報を3つ以内に絞ることから始めよう。