mcpField
T
tool-design-sprint-brief

tool-design-sprint-brief

github.com/product-on-purpose生産性769622 回インストール4 日前に更新
リポジトリ

tool-design-sprint-brief について

Design Sprint チーム向けに、課題、問い、参加者、顧客募集、プロトタイプ、インタビュー、運営、成功基準をまとめた事前ブリーフを作成します。準備状況の確認後、月曜日までに計画を確定するチームを対象とします。

主な機能

  1. 01課題とスプリントの問いを定義
  2. 02役割と参加時間を割り当て
  3. 03顧客募集計画を策定
  4. 04プロトタイプとインタビュー形式を決定
  5. 05運営と成功基準を計画

活用シーン

  1. 01開始前にチームの認識をそろえる
  2. 02募集終了前に顧客募集を確定
  3. 03幹部にスプリントの範囲と費用を説明

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/product-on-purpose/pm-skills --skill tool-design-sprint-brief

インストール後、Claude Code で/tool-design-sprint-briefを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

HISTORY.md
references/
EXAMPLE.md
TEMPLATE.md

詳細

デザインスプリントの概要

月曜日の開始前に、課題、スプリントの質問、参加者、顧客の募集、プロトタイプの媒体、インタビュー形式、ロジスティクス、成功基準についてチームの認識をそろえる概要を作成します。よく練られた概要があれば、月曜日の朝に「今週は何をテストするのか」を再び議論する事態を防げます。不完全または曖昧な概要では、ほぼ確実にそうなります。

ファミリー契約:docs/reference/skill-families/design-sprint-skills-contract.md。このスキルは design-sprint-skills のメンバーです。

使用するタイミング

  • tool-design-sprint-readiness による準備状況の判定が Go(または前提条件が解消された Conditional Go)です。
  • スプリントの日程がカレンダーに確保されており、スプリントの目的を明記した成果物が必要です。
  • 顧客の募集が進行中で、募集の締め切り前に募集計画、謝礼予算、金曜日のスケジュールを確定する必要があります。
  • 懐疑的な経営幹部から「チームは5日間、顧客コストも含めて何をするのか」と問われ、2ページに収まる回答が必要です。

使用しないタイミング

  • スプリントがすでに始まっています。概要は準備用の成果物であり、スプリント中に作成する成果物ではありません。月曜日の活動が始まっている場合は、代わりに tool-design-sprint-map-and-target を実行してください。
  • 準備状況の判定が Wait です。概要を作成しても、準備が整っていないチームの状態は解消できません。まず前提条件を満たし、その後に準備状況を再確認してから、このスキルを実行してください。
  • チームがステークホルダー戦略の文書を必要としています。概要は内部準備用であり、外部向けの成果物ではありません。ステークホルダー向け文書が必要な場合は、後続の成果物(Friday scorecard または next-step memo)を作成します。
  • 顧客の募集が始まっていません。概要では募集計画を確定できますが、募集担当者の代わりにはなりません。募集担当者が決まっていない場合は、準備状況を確認し、Wait の判定に戻ってください。

このスキルが作成するもの

次の9つのセクションをまとめた単一の成果物です。

  1. 課題の説明と今取り組む理由:テスト可能な課題と、後日ではなく今週スプリントを行う緊急性を示す1段落。
  2. スプリントの質問:金曜日のテストで回答する具体的な質問を2~4件。以前の Foundation Sprint で特定された最もリスクの高い仮説を、最初の質問にします。
  3. 意思決定者の参加時間帯:重要な時間帯(最低でも月曜午前、水曜午前、金曜午後)。参加可能な時間帯はすべて確保します。
  4. 役割分担を含むチーム名簿:各日に参加する人と、その人が週を通して担う役割。
  5. 顧客募集計画:対象者のプロフィール、募集元、人数、謝礼、募集担当者、募集期限、金曜日のスケジュール。
  6. プロトタイプの媒体に関する決定:クリック可能なプロトタイプ、スライド資料、サービスのロールプレイ、紙、物理的なモック、その他の形式と、その理由。
  7. インタビュー形式:対面またはリモート、モデレーター付きまたはなし、録画と同意に関する方針、観察者用の部屋の設定。
  8. ロジスティクス計画:日程、時間、場所、形式(対面、リモート、ハイブリッド)、ツール、日々の進行。
  9. 成功基準:スプリントの成功・不成功を示す、観察可能な結果。

標準の構成については references/TEMPLATE.md を、Brainshelf の書籍カタログに関する概要の例については references/EXAMPLE.md を参照してください。

推論への入力

入力このスキルが行う処理
準備状況の判定と推奨事項(tool-design-sprint-readiness から)推奨参加者、顧客の募集計画、スプリント前の活動、プロトタイプの媒体案を取り込み、未解決の前提条件があれば明示します
課題の説明課題ステートメントに要約し、2〜4個のスプリント質問を導き出します
Founding Hypothesis(任意。以前の Foundation Sprint から)FS スコアカードで最もリスクの高い仮説を主要なスプリント質問にし、最有力案をデザインの方向性にし、予備案を金曜日に無効と判断された場合の代替判断にします
チーム構成必要な Design Sprint の役割(Decider、Facilitator、PM、Design、Engineering、Researcher または Customer Expert)にメンバーを割り当て、4〜7人の範囲に収まっていることを確認します
顧客の募集元と計画募集担当者、対象プロフィール、募集チャネル、謝礼予算、期限、金曜日のスケジュールを確定します
実施形式(対面、リモート、ハイブリッド。Ratified Decision 6 に従う)形式が作成内容に影響する箇所でブリーフの本文を分岐させます。募集計画(対面では地域を限定した参加者グループが必要。リモートではタイムゾーンをまたいだ募集が可能)、プロトタイプの媒体(一部の媒体は対面での作業に適しています。例:物理的なモック)、インタビュー形式(ライブまたはリモートでのモデレーション)、オブザーバーの設定(同室または Zoom のブレイクアウトルーム)
ロジスティクス上の制約日付/時間/場所/ツールの一覧表を作成し、スプリントが5日を超えて延長される、または暦週をまたいで分割される原因となる制約を明示します

ブリーフの長さに関する規律

ブリーフは2ページ(または2画面)に収める必要があります。DS ブリーフは、顧客募集、プロトタイプの媒体、インタビュー形式の各セクションに FS にはない要素があり、月曜日までに確定する必要があるため、意図的に FS ブリーフより長くなっています。

  • 課題ステートメント:1段落、最大4文。
  • スプリント質問:2〜4個の番号付き質問。それぞれ1文。
  • チーム構成:1人につき1行の表。
  • 顧客募集:表。
  • プロトタイプの媒体:理由を含む1段落。
  • インタビュー形式:1段落。
  • ロジスティクス:表。
  • 成功基準:3〜5個の箇条書きの成果。

ブリーフが2ページを超える場合、スプリント開始前に設計を過剰に練りすぎています。必要なのはブリーフを長くすることではなく、スプリント質問をより的確にし、プロトタイプの媒体をより明確に決定することです。

よくある落とし穴

  • 曖昧なスプリント質問。「ユーザーは気に入るだろうか?」はスプリント質問ではありません。「年間25冊以上読む読者は、途中でやめることなく、3秒未満でカメラ撮影を完了できるか?」はスプリント質問です。スプリント質問は、金曜日に行う5人の顧客へのインタビューから答えを得られるものでなければなりません。
  • **対象顧客に合っていない募集計画。**対象として定めた顧客とは年齢層や人口統計が異なる傾向のあるパネルから募集すると、金曜日に得られるデータでは実際の仮説を検証できません。募集元が準備状況の判定で示された顧客プロフィールに合っているか、照合してください。
  • **プロトタイプの媒体の決定を先送りする。**プロトタイプの媒体を木曜日の朝まで決めずにいると、チームはその場しのぎで選ぶことになり、金曜日にテストできないプロトタイプになるおそれがあります。ブリーフで確定してください。必要なら水曜日のストーリーボード作成後に変更できますが、最初に既定の選択肢を決めておきます。
  • **ブリーフをステークホルダー向けの成果物として扱う。**ステークホルダーが読むのは金曜日のスコアカードと Decider の次のステップに関するメモであり、ブリーフではありません。ブリーフを公開すると、スプリントで解決すべきスプリント前の議論を招くことになります。
  • ロジスティクスの方針が曖昧。「リモートか対面かはそのうち決めます」では、チームが決断できていないことが伝わります。形式を確定するか、準備状況の判定が誤っていたかのどちらかです。
  • **インタビュー形式を決めていない。**金曜日のインタビューモデレーター、観察室の設定、録画と同意の方針をブリーフに記載してください。これらを忘れることが、金曜日に予定より時間がかかる最も一般的な原因です。

正式な情報源

  • Knapp, J., Zeratsky, J., and Kowitz, B. Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days. Simon and Schuster, 2016. 第3章「Set the Stage」では、スプリントブリーフの作成について説明しています。
  • Character Capital.「Design Sprint pre-sprint guide.」 https://www.character.vc
  • Google Design Sprint Kit.「Sprint brief template.」 https://designsprintkit.withgoogle.com/
  • AJ and Smart「Remote Design Sprint」テンプレート。リモート形式およびハイブリッド形式のセクションに適用しています。

スキル間の利用

前提条件:tool-design-sprint-readiness。ブリーフでは、準備状況の評価結果を主要な入力として想定しています。prerequisites が適用される場合、ブリーフは準備状況の評価結果、顧客募集計画のドラフト、参加者の推奨事項、スプリント前のアクティビティを引き継ぎ、このスキルでそれらをさらに調整し、確定します。

準備状況評価スキルを明示的に実行せずに同等の準備を済ませているチーム(例:準備状況の評価基準を把握している経験豊富なスプリントファシリテーター)は、ブリーフスキルを直接呼び出せます。その場合、スキル本文で、ブリーフを作成する前に準備状況の評価基準を満たしていることをチームに確認します。

Foundation Sprint を経て参加するチームは、Founding Hypothesis と仮説スコアカードを入力として用意してください。ブリーフの「Sprint Questions」セクションでは、最もリスクの高い仮説をそのまま主要な質問として取り上げます。橋渡しとなるスキルは不要です。引き継ぎの流れは _workflows/foundation-to-design.md に記載されています。

スプリントで次に実行するスキル:月曜の朝に tool-design-sprint-map-and-target。

意思決定者の確認

このスキルは、references/TEMPLATE.md の意思決定者確認で終了します。意思決定者は、スコープ(課題とスプリントの質問)、チーム(参加者名簿と出席可能な時間帯)、募集計画(対象者のプロフィール、募集元、謝礼予算)、プロトタイプの媒体、インタビュー形式、明示的な成功基準を承認します。承認がなければ、ブリーフは助言にとどまります。承認があれば、次の5日間の契約となり、顧客募集費用の支出が許可されます。

コメント