Product Blueprint & Scopeは、製品の方向性を、実装に向けてより判断しやすい計画へと形にする業務です。製品が誰のためのものか、どのフローを最初に重視するか、どの機能を合意した範囲に含めるか、開発開始前にどの依存関係や除外事項を明らかにしておくべきかをチームが定める助けになります。ブループリントにより、判断が進むなかでも費用、時期、スコープを見える形で管理できます。後の開発フェーズの基盤となる、現時点での判断と前提を実践的に記録したものです。すべての詳細が固まったふりをせずに漠然としたアイデアから前に進む必要があるチームにとって、ブループリントは、より落ち着いた管理された土台となります。
何であるのか
この作業では、現実的な次のフェーズの判断を支えられる程度に詳しく、合意した製品の範囲を整理します。ユーザーロール、中核となるフロー、機能の優先順位、データと連携のニーズ、プラットフォームの選択、前提、除外事項、開発フェーズ、変更管理への影響を対象にできます。詳細さの度合いは目の前の判断に合わせて調整し、次のフェーズで重要となる機能に焦点を当てます。ブループリントでは、今含めるものと、意図的に最初のフェーズの外に置くものを記述します。また、クライアントのアクセス、外部システム、サプライヤーの意見、さらなる技術調査に依存する問いも記録します。本格的な開発や実装は、別途の開発スコープのもとで続けて実施します。目的はあいまいさを減らすことであり、根拠のない確実性をつくり出すことではありません。
誰のために
Product Blueprint & Scopeは、次のようなチームに適しています。
- 初期のディスカバリーを終え、製品の構想と実装計画とをより明確につなぐ必要があるチーム
- 複数の関係者がユーザーロール、機能の優先順位、開発フェーズ、除外事項について合意する必要があるチーム
- 社内の開発者や外部のサプライヤーとの協働を控え、より役立つ判断の記録を求めるチーム
- 構築を決める前に、連携、前提、将来の変更要望が及ぼす影響を理解する必要があるチーム
明確にするのに役立つこと
ブループリントでは、次の点が明確になります。
- 合意した最初のフェーズに必須のユーザーロールと中核となるフロー
- 現在の範囲の内側または外側に置くべき機能、連携、コンテンツ、運用上の依存関係
- 前提、除外事項、開発フェーズが、見積もり、担当体制、後の変更管理にどう影響するか
- さらなるアクセス、サプライヤーの意見、技術的な検証、別途の専門的なスコープが必要な問い
含まれる内容
- 製品上の判断、ユーザーロール、想定するフェーズ、入手できる情報についての書面による確認
- 中核となるフロー、機能の範囲、優先順位、連携、前提、除外事項を体系的にまとめた概要(技術アーキテクチャと技術スタックの推奨を含む)
- スケジュールの見積もりと概算の費用幅(計画用の目安)を含む開発フェーズの計画。当面のスコープと後のアイデアや依存関係を区別します
- 要件が未確定のままの箇所や、外部のアクセスやシステムに依存する箇所を説明する判断の記録
- 合意した範囲をひそかに広げることなく新しい要望を扱うための、実践的な変更管理の指針
- 創業者、プロダクトオーナー、技術チーム、開発パートナーに適した引き渡しの協議
含まれていないもの
- 別途スコープを定めない限り、本格的な開発、実装、本番環境へのデプロイ、継続的なプロダクトマネジメント
- スコープ、費用、時期、技術的アプローチを変更する必要が決して生じないという約束
- 合意した作業を超える、無制限の機能定義、画面作成、ベンダーとの交渉、修正
- 正式な法務、コンプライアンス、アクセシビリティ、セキュリティ認証、調達に関する助言
- 必要なアクセスと証跡がない状態での、外部システムの動作、可用性、料金の確認
それを選ぶべきとき
製品の方向性は計画できる程度に明確であるものの、実装開始前に、ユーザー、フロー、機能、依存関係、範囲についてより強い合意が必要な場合は、Product Blueprint & Scopeをお選びください。ディスカバリーの後、MVPスプリントの前、作り直しの前、あるいはサプライヤーとの話し合いに機能の要望一覧よりも明確な土台が必要な場合に役立ちます。現在のフェーズで何を達成し、何を解決の対象としないかを記録することで、避けられる意見の食い違いを減らせます。一方、チームが基本的な課題や対象ユーザーについてまだ確信を持てない場合にはあまり適していません。その場合は、ディスカバリーのほうがよい第一歩となることがあります。ブループリントが最も効果を発揮するのは、意思決定者が、すべてを含まれる可能性のあるものとして残すのではなく、トレードオフを判断し除外事項を明示する準備ができている場合です。
私たちのアプローチ
まず、想定するフェーズと、ブループリントで支えるべき判断を確定します。そのうえで、ユーザーロール、中核となるユーザー体験、機能、連携、コンテンツ、運用上の要件、制約を順に整理します。話し合いでは、要件と前提を区別し、最初のフェーズでの約束と将来のアイデアを区別します。範囲があってこそ後の見積もりや開発計画がより信頼できるものになるため、除外事項も含めるものと同じくらい丁寧に記録します。要件がアクセス、外部システム、ベンダーの協力、さらなる技術作業に依存する場合は、その依存関係を見える形で残します。ブループリントの費用と時期は、計画用の目安として提示します。引き渡し時には、製品の範囲、フェーズ、変更管理への影響、そして実装を責任をもって確定する前に引き続き必要な情報を、判断に使える形で把握していただけます。
よくある質問
関連記事
始めよう
製品の方向性を、より明確なスコープにしませんか?
スコープは、お支払いやお約束の前に書面で確定します。簡単なご依頼から始めていただければ、製品ブループリントが貴社チームにとって適切な次のステップかどうかを一緒に確認します。
Product Blueprintについて相談する