← 記事一覧
正しいものを作る
実際に使われる1ページのプロダクトブリーフの書き方
FabricLoopチーム · 2026年5月 · 4分で読めます
ほとんどのプロダクトブリーフは同じ運命をたどります。プロジェクト開始前に丁寧に書かれ、キックオフミーティングで一度レビューされ、その後は二度と開かれません。チームが開発の中盤に差し掛かる頃には、ブリーフは歴史的な遺物と化しています。スコープをめぐる議論で時折参照されることはあっても、意思決定の生きたガイドとして扱われることはほぼありません。
これはプロセスの失敗であり、フォーマットの失敗ではありません。ブリーフが使われないのは、使われることを前提として書かれていないからです。「要件を定義した」というチェックボックスを満たすために書かれており、不確実な状況下でチームがよりよい意思決定をする手助けをするために書かれているわけではありません。
実際に使われるブリーフは、短く、意見がはっきりしており、チームが開発中盤に実際に問いかける疑問——何を解決しているのか、誰のために、そしてうまくいったとどうやって判断するのか——に基づいて構成されています。
「ブリーフは要件定義書ではありません。意思決定のリファレンスです。デザインの選択やスコープの判断に迷ったとき、チームがいつでも戻れる1枚のページです。」
重要な5つのセクション
プロダクトブリーフのすべての内容は、5つの問いのいずれかに答えるものでなければなりません。どの問いにも答えていないセクションは、おそらく1ページのブリーフには属さないものです。より詳細な別の仕様書に属するものです。
課題
ユーザーは重要度の高い通知（タスクのアサイン）と重要度の低い通知（ウォッチ中のスレッドへのコメント）を区別できないため、重要な更新を見逃しています。その結果、すべての通知を無視するか、完全にオフにするかのどちらかになっています。今四半期のプロダクト関連クレームの18%が「知らなかった」というサポートチケットです。
対象ユーザー
主対象: メンションが頻繁で通知量についていけないチームリーダーやプロジェクトオーナー。副対象: デフォルトで静かな環境を求めつつ、重要なアサインは見逃したくない個人貢献者。対象外: 管理者ユーザー（通知ニーズは管理者パネルで対応済み）。
成功指標
主要指標 リリースから60日以内に通知関連のサポートチケットが40%減少。
副次指標 通知設定をカスタマイズしたWAUが12%から35%に増加。
先行指標 オプトアウト率（全通知をオフにしたユーザー）が23%から15%未満に低下。
スコープ外
- メール通知設定（別作業項目——インフラが異なる）
- ワークスペースごとの通知設定（将来対応；今回のリリースはユーザーごとのみ）
- 通知スケジュール／おやすみモード（ニーズは確認済み、Q3ロードマップ）
- モバイルプッシュ通知の細分化（ウェブ優先；検証後にモバイル対応）
未解決の問い
ブロッキング 通知を2段階（重要／その他）に分けるか、タイプごとに細かく制御するか？ユーザーインタビューでは2段階が支持されているが、エンジニアリングは柔軟性の観点から細分化を好む。デザイン開始前に決定が必要。
非ブロッキング 設定変更は既存の通知に遡って適用すべきか？技術コストに基づいて開発中に決定可能。
「スコープ外」がもっとも重要なセクションである理由
チームは何を作るかを書くことに多くの時間を費やします。一方、何を作らないかを書くことには、ほとんど時間を使いません。この非対称性がスコープクリープの主な原因です。デザイナーが「おやすみモード」トグルを追加したり、エンジニアがすでにその領域にいるからとワークスペースごとの設定を追加したりするのは、たいていの場合、それらがスコープ外であると誰かが明示的に決定していなかったからです。
スコープ外の項目を書き出すことで、開発の途中で発生するよりもはるかに変更コストが低い段階で、境界についての議論が促されます。また、PMが追加要件に対して明確に断る根拠も与えられます。「それはブリーフでスコープ外と決定しました——理由はこうです。」
スコープ外の書き方
何を作らないかを列挙するだけでなく、簡単にその理由を添えてください。「メール設定（インフラが異なる）」と書くことで、その決定が意図的かつ合理的なものであり、見落としではないことが伝わります。これにより、スプリント中に同じスコープの問いが何度も浮上することを防げます。
未解決の問い：多くのブリーフが省略するセクション
すべてのプロジェクトは未解決の問いを抱えた状態で始まります。ほとんどのブリーフはそれをごまかします。著者自身はわかっていても、すべての決定が下されたかのように書かれるのです。その結果、チームは開発の中盤で未解決の問いを発見することになり、そのときがもっとも混乱をもたらします。
未解決の問いを明示的にリスト化することには、2つの効果があります。ひとつは、作業開始前に解決が必要な問い（ブロッキング）と、開発中に決められる問い（非ブロッキング）を浮き彫りにすること。もうひとつは、ブリーフが完成した仕様書ではなく、進行中のドキュメントであることをチームに示すことです。これにより、チームがブリーフに戻り、決定が下されるたびに更新する可能性が高まります。
長さのワナ
1ページを超えたブリーフはもはやブリーフではなく、仕様書です。仕様書には仕様書の役割がありますが、目的が異なります。1ページを超える必要がある場合は、詳細をリンク先の付録に切り出し、ブリーフは5つのコアセクションにとどめてください。
FabricLoopでブリーフを生き続けさせる方法
ブリーフが役に立ち続けるためには、チームがいつでも見つけて更新できる必要があります。FabricLoopはブリーフをプロジェクトスレッドにピン留めすることで、常にワンクリックでアクセス可能にします。そして、その周辺の会話（下された決定、解決された未解決の問い、スコープ変更）が、メールやSlackに散在するのではなく、すぐそこにコンテキストとして残ります。
この記事から持ち帰るべき10のポイント
- ほとんどのプロダクトブリーフはプロセスを満たすために書かれており、チームがよりよい意思決定をする助けになるためではありません。だから二度と使われないのです。
- ブリーフは要件定義書ではなく、意思決定のリファレンスです。開発中盤に生まれる問いに答えられるものでなければなりません。
- 重要な5つのセクション: 課題、対象ユーザー、成功指標、スコープ外、未解決の問い。それ以外は仕様書です。
- 課題セクションは、可能であればデータを用いて、対象領域を名指しするだけでなく、ユーザーの痛みを具体的に説明するものでなければなりません。
- 誰のために作らないかを明示することは、誰のために作るかを明示することと同じくらい重要です。ユーザーに関する曖昧さはデザインのスコープクリープを招きます。
- 成功指標は、測定可能で期限があり、開発開始前に合意されている必要があります。後から使用データで推測するのではありません。
- スコープ外のセクションがもっとも重要です。書かれていないスコープの境界は、開発中に確実に拡張されます。
- スコープ外の項目には簡単な理由を添えて、スプリント中に同じ問いが再浮上するのを防いでください。
- 未解決の問いはブロッキング（開発前に決定）または非ブロッキング（開発中に決定）として明示的にタグ付けしてください。
- 1ページを超えたブリーフは仕様書になっています。詳細を付録に切り出し、ブリーフをタイトに保ってください。
