Discovery Sprint：開発前の計画づくり

Discovery Sprintは、製品、機能、アプリの構築に踏み切る前に行う、体系的な計画づくりの業務です。初期のアイデア、分かりにくい要件、相反する複数の要望を、最初にどの課題を解決すべきかというより明確な判断へと整理する助けになります。この作業により、実現可能性、予算、時期についての判断に向けた、証跡に基づくより明確な根拠が得られます。現状、対象ユーザー、優先すべきユーザー体験、前提、依存関係を実践的に把握し、次の投資をより慎重に行えるようにします。重要な問いが固まる前に開発を始めるよう迫られていると感じるチームにとって、ディスカバリーは、立ち止まって証跡を確認し、現実的な次のステップを選ぶための、範囲を区切った場となります。

何であるのか

スプリントでは、製品上の判断の枠組みをつくるために必要な情報を集めます。事業目標、現在のプロセス、ユーザー層、入手できるデータ、既存のシステム、優先すべきユーザー体験、初期の実現可能性に関する問いを調べることができます。具体的なスコープは書面で合意し、業務に提供される資料と参加者を反映したものになります。ディスカバリーは、長い文書を作ること自体を目的とするのではなく、判断に焦点を当てます。すなわち、今検討すべきこと、検証が必要なこと、計画を支えている前提、まだ約束として扱うべきでないことです。ディスカバリースプリントの成果物には、優先順位を付けた課題の記述、ユーザーフローの概要、判断の記録、依存関係のマップ、推奨する次のフェーズのスコープが含まれることがあります。本番の開発、最終的なUIデザイン、完全なアーキテクチャの構築は、別途合意する成果物として続けて実施できます。

誰のために

Discovery Sprintは、次のようなチームに適しています。

製品アイデアや業務上の課題があるものの、構築の見積もりを依頼する前により明確な要件が必要なチーム
考えられる複数のユーザー体験、機能、市場の優先順位の中から選ぼうとしているチーム
創業者、プロダクトオーナー、技術担当者が同じ前提に基づいて作業する必要があるチーム
予算、サプライヤーの工数、開発スケジュールを決める前に、依存関係と判断の空白を特定したいチーム

明確にするのに役立つこと

ディスカバリーでは、次の点が明確になります。

次のフェーズの軸とすべき課題、対象ユーザー、優先すべきユーザー体験
現状について分かっていることと、証跡、調査、アクセス、判断がまだ必要な問い
開発に影響し得る前提、連携、コンテンツ、承認、外部の依存関係
妥当な次のステップが、ブループリント、UX/UIの方向性づくり、MVPのスコープ、技術評価、あるいは別の業務のいずれか

含まれる内容

ディスカバリーで扱う問い、入手できる資料、参加者、判断の範囲についての書面による確認
現状、対象ユーザー、優先すべきユーザー体験、既知の制約、初期の実現可能性に関する問いの体系的なレビュー
前提、依存関係、未解決の問い、担当者を決める必要がある判断の記録
次のフェーズに最も関連する課題とユーザーフローの実践的な優先順位付け
現実的で焦点を絞った次のスコープについての平易な言葉による推奨
所見、範囲、妥当な次の対応を説明する引き渡しの協議

含まれていないもの

別途スコープを定めない限り、本番の開発、最終的なUIデザイン、完全なデザインシステム、本格的なアーキテクチャの構築
事業上の成功、技術的な実現可能性、最終的な予算、サプライヤーの対応可否、納期の約束
合意した業務を超える、無制限の調査、ワークショップ、コンセプト、インタビュー、修正
正式な法務、コンプライアンス、投資、市場調査に関する助言
ディスカバリー中に挙がったすべてのアイデアの自動的な実装

それを選ぶべきとき

最も重要な問いが、まだ「何を、誰のために、なぜ作るのか」である場合は、Discovery Sprintをお選びください。MVP、大規模な作り直し、新しい社内ツール、顧客体験の変更の前に役立ちます。根底にあるスコープがまだ明確でないために、受け取った見積もりにばらつきがあると感じているチームにも有用です。一方、製品の範囲がすでに固まっていて、定義済みの機能を開発すればよいだけの場合には、ディスカバリーはあまり役立ちません。その場合は、対象を絞った構築スコープのほうが適切なことがあります。スプリントが最もうまく機能するのは、関係する意思決定者が参加でき、現在の資料を共有でき、チームが一部のアイデアを当面の約束ではなく将来の可能性として扱う意思がある場合です。

私たちのアプローチ

まず、スプリントで支えるべき判断について合意します。そのうえで、作業は現状から目指す姿へと進みます。ユーザーが何をしようとしているのか、現在の体験やプロセスのどこで問題が生じているのか、有用な次のユーザー体験はどのようなものかを確認します。前提を将来の構築計画に埋め込むのではなく、見える形にします。データ、コンテンツ、ベンダー、アクセス、社内承認、既存のシステムといった依存関係は、それによって生じる問いとともに文書化します。初期の推奨は、その重みが明確になるよう、根拠となる証跡と未解決の問いとともに示します。最終的な引き渡しでは、観察された情報、作業上の前提、制約、次の判断を区別します。これにより、より対象を絞ったブループリント、デザインの方向性、MVP、技術評価を選ぶための根拠をチームに提供し、後のスコープ、費用、時期は証跡が増えるにつれて精緻化します。

Discovery Sprintのサービスページを見る