App MVP Sprintとは？

App MVP Sprintは、明確になったアイデアを現実的な最初のリリースへと形にするための、対象を絞った製品開発の業務です。MVPとはMinimum Viable Product（実用最小限の製品）を意味しますが、あいまいで未完成な製品という意味であってはなりません。将来のあらゆる機能をバージョン1に入れるふりをせず、構築し、テストし、学びを得られる、最小限で一貫した体験を選ぶことを意味します。スプリントでは、製品上の判断、デザイン、技術計画、構築作業、リリース準備を一つの管理されたスコープにまとめます。目的は、多くの可能性を持つアイデアから、関係者が理解し、テストし、保守できる最初のリリースの範囲へとチームが進めるよう支援することです。

何であるのか

業務は、製品が解決すべき課題、主なユーザー、そのユーザーが最初に達成すべきことを明確にするところから始まります。そこから作業は主要なユーザーフロー、つまり初日から製品を役立つものにする少数の利用の流れに集中します。一般的なスコープには、製品の定義、必須の画面、合意したアプリの機能、データと連携に関する前提、品質チェック、実践的なリリース準備が含まれます。具体的な技術的アプローチは、製品、既存の資産、合意したプラットフォームによって異なります。スプリントは、合意した中核フローを軸に、一貫性のある最初のリリースを構築することに集中します。初期の選択を可視化し、テストし、実現可能なものにするための体系的な方法です。最初のリリースの中核となる成果を支えない機能は、固定されたスコープにひそかに追加するのではなく、将来の検討事項として記録します。

誰のために

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

明確な製品アイデアや事業上の課題があるものの、それを現実的な最初のリリースに形にする支援が必要なチーム
より広い製品ロードマップに投資する前に、対象を絞った顧客体験を検証したいチーム
製品スコープ、画面に関する判断、開発、リリース準備を、責任の所在が明確な一つの開発プロセスで進める必要があるチーム
非公式な試作品、スプレッドシート、手作業の手順を、最初の実用的なアプリ体験に置き換えようとしているチーム

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

MVPスプリントでは、次の点が明確になります。

最初のリリースで取り組むべきユーザーの課題と主要なフロー、そして後回しにすべきアイデア
構築を進める前に解決すべき前提、依存関係、コンテンツ、連携、クライアント側の承認
テスト可能なリリースに必須の機能と、後のロードマップに回す望ましい改善との違い
合意したスコープとスケジュールの中で現実的なテスト、担当体制、リリース準備

含まれる内容

最初のリリースの目的、プラットフォーム、合意したユーザーフロー、開発の範囲を記載した書面によるスコープ確認
スコープ内の必須の画面と操作に絞った製品とインターフェースの定義
合意したMVP機能の構築作業（前提と依存関係は発生した時点で記録）
引き渡しまたはリリース準備の前の、合意したユーザーフローの実践的なテスト
合意したプラットフォーム、アカウントへのアクセス、申請の責任分担に応じたリリース準備の支援
ソースコード、ドキュメント、そして納品した内容、オーナーの判断が必要な内容、将来のフェーズに属する内容を示す引き渡しサマリー

含まれていないもの

無制限の機能バックログ、無制限の修正、スプリント中に話し合ったすべてのアイデアの自動的な追加
別途スコープを定めない限り、複雑なバックエンド基盤、マーケットプレイス機能、リアルタイム映像、高度なデータ施策、広範なコンプライアンス対応
公開時期、App StoreやGoogle Playの審査通過、ユーザーの定着、事業上の成果、外部サービスが途切れなく提供されることの約束
納品したスコープ内の項目に対する期間限定の公開後サポートを超える、業務終了後の継続的なプロダクトマネジメント、保守、将来の機能開発
入手できないコンテンツ、アカウント、法的判断、外部ベンダー、スコープで確定していない連携に依存する作業

それを選ぶべきとき

中心となる課題が、最初の有用なバージョンを何にするかを決め、そのバージョンを規律をもって提供することにある場合は、App MVP Sprintをお選びください。初期段階のチーム、新しいサービスモデルを試す既存企業、手作業の顧客対応を対象を絞ったアプリ体験に置き換える必要があるチームに適しています。最も効果を発揮するのは、意思決定者が明確で、ユーザーの課題を理解している人に相談でき、バージョン1を意図的に絞り込む意思がある場合です。一方、製品の方向性がまだ大きく不確かな場合、中核となるユーザーフローをまだ説明できない場合、必要な連携や運用上の依存関係が分かっていない場合にはあまり適していません。そのような場合は、構築を決める前に、ディスカバリーや製品ブループリントのフェーズから始めるほうが有用なことがあります。

私たちのアプローチ

まず、目指す成果、主なユーザー、プラットフォーム、開発の範囲を書面で確定します。初期の話し合いでは、長い機能一覧ではなく中核となる利用の流れに焦点を当てます。ユーザーが何をできなければならないか、どの情報が必要か、何があれば最初のリリースが一貫したものになるかを確認します。コンテンツ、連携、アカウント、承認の責任、外部の依存関係に関する前提を記録し、後から隠れた開発リスクにならないようにします。構築中は合意したスコープを常に見える状態に保ち、新しい要望はスコープに含める前にその影響を説明します。テストは合意したユーザーフローと現実的なリリース条件に基づいて行います。引き渡し時には、最初のリリースの範囲、完了した作業、後のロードマップや別スコープに移すべき項目を明確に把握していただけます。

App MVP Sprintのサービスページを見る