よいブリーフには、誰が困っているのか、その人たちが何をする必要があるのか、そしてうまくいった状態とはどういうものかが書かれています。短い段落がいくつかと、ラフなスケッチ、具体的な例が一つあれば、話を始めるには十分です。
私はその内容をもとに質問をし、範囲とスケジュールを提案する前に、作業内容を一緒に整理します。このガイドでは、架空の予約サービスを例に、何を書けばよいかを紹介します。新しいアプリでも、ボットでも、既存プロダクトへの機能追加でも、考えるべきことは同じです。
課題と使う人から書き始める
誰がプロダクトを使うのか、その人が何をしようとしているのか、今はそれをどうやっているのかを教えてください。予約の例なら、「お客様はメッセージで希望の時間を問い合わせてきます。スタッフが共有カレンダーを確認し、支払いリンクを送り、予約を一件ずつ手作業で確定しています」といった具合です。これで、ソフトウェアが支えるべき業務がわかります。
実現したい結果も書いてください。手作業を減らすこと、きちんと動く予約の流れ、お客様が注文状況を確認できる仕組みなどが考えられます。今すでに数字で測っているものがあれば共有してください。なければ、うまくいった状態を言葉で説明していただければ十分です。
重要なタスクを一つ通して書く
大事なタスクを一つ選び、最初から最後まで書き出してください。たとえば、お客様がサービスを選び、空いている時間を選んで支払い、確認の連絡を受け取る。その後、管理者が予約を確認したりキャンセルしたりできる、という流れです。
例外的なケースも挙げてください。支払いが失敗したら、お客様の気が変わったら、二人が同じ時間を選んだらどうなるでしょうか。すべてをご自身で解決しておく必要はありません。疑問として挙げておくだけで、スケジュールを決める前に必要な作業を洗い出せます。
最初のリリースに必要なものを決める
最初の役に立つリリースに欠かせないものと、後回しにできるものを分けてください。予約サービスなら、公開時は決済サービス一つで足り、サブスクリプションや紹介特典は後からでもかまわないかもしれません。優先順位がわかれば、それだけで価値のあるリリースを提案できます。
機能名の裏には、いくつもの判断が隠れていることがあります。たとえば「顧客アカウント」なら、誰が登録できるのか、何を閲覧できるのか、スタッフの権限は違うのか、アクセスを失ったらどうなるのかを教えてください。決まっていなければ、一緒に決める疑問点として残しておいてかまいません。
機能が完成したとどう判断するかも書いておきましょう。「予約メールを送る」だけでは、人によって期待がずれます。「支払いが完了すると、予約番号、日時、キャンセル方法が書かれたメールがお客様に届く」と書けば、確認の基準がはっきりします。
こうした確認基準は、受け入れ条件と呼ばれることがよくあります。GOV.UK のユーザーストーリーに関するガイドでも同じ考え方が説明されています。まず利用者のニーズを書き、それが満たされたと確認できる結果を並べる、という方法です。
すでにあるものを共有する
現在のサイトやアプリと、それがすでに使われているかどうか。
デザイン、ブランド素材、コンテンツ、気に入っている画面の例。それぞれのどこが気に入っているのかも添えてください。
決済、メール、CRM、Telegram ボットなど、プロダクトと連携させる必要のあるサービス。
移行が必要な既存データと、関係するアカウントの所有者。
対応言語、対象デバイス、アクセシビリティの要件、すでに決まっている技術など、前提となる条件。
既存のプロダクトを改善したい場合は、最初にそう伝えてください。一つの機能が、今あるデータや権限、業務の流れの変更につながることがあります。既存のシステムを確認することも、範囲を把握する作業の一部です。
期限と決定権者を伝える
公開日が決まっている場合は、その日がなぜ重要で、それまでに何が必要かを教えてください。イベントに合わせた日付と、できればこの頃という目標では、取るべき判断が変わります。予算の目安があれば、提案をまとめる前に優先順位を話し合う助けにもなります。
優先順位を確定し、作業を承認できる人を決めてください。待っているコンテンツ、前任の開発者からのアクセス引き継ぎ、連携を担当する別チームなど、ほかに依存している事柄も教えてください。こうした要素は、コードと同じくらい進め方に影響します。
最初のブリーフの良い例
当社は予約制のサービスを提供しています。現在はメッセージで予約を受け付けており、空き状況はスタッフが手作業で確認しています。
最初のリリースでは、お客様がサービスと空いている時間を選び、今使っている決済サービスで支払い、予約確認を受け取れるようにしたいです。スタッフは予約を確認し、キャンセルに対応できる必要があります。
Web サイト、ブランド素材、決済アカウントはすでにあります。サブスクリプションのプランや紹介特典は後からで大丈夫です。
キャンセルや支払い失敗をどう扱うべきか、判断を手伝ってほしいです。希望の公開日はありますが、こうした点が決まってから、現実的な日程を相談したいと考えています。
この例でも、空き枠のルール、返金、スタッフの権限、確認メールに載せる内容など、まだ決めることは残っています。それで問題ありません。最初のブリーフは、そうした判断が必要な点を見つけるための材料になります。
そのまま使えるブリーフ
作りたいもの、または改善したいもの：…
使う人：…
今のやり方の問題点：…
利用者にとって一番大事なタスク：…
最初のリリースで必要なもの：…
後回しにできる機能：…
すでにあるもの（デザインや連携サービスを含む）：…
期限、制約、予算の目安（わかる範囲で）：…
成功とみなす状態：…
判断する人：…
まだ答えがわからない項目は空欄のままで大丈夫です。未決の点が見えるようにしておきましょう。範囲が決まった後に新しい要望が出た場合は、追加する前に作業とスケジュールへの影響を話し合います。
ブリーフはこちらから送れます。私はテキストでやり取りしているので、プレゼン資料や通話の準備は必要ありません。作業を決める前に、質問と次のステップをお返事します。