更新日：
最近、「ユーザへ価値ある機能をすばやく提供するには」といったテーマでお話する機会がありました。この中で、あるプロダクトオーナーは「ユーザへ提供する価値として、自分が仮説した機能があり、ユーザストーリーとして定義しているので、開発チームには最大限のパフォーマンスを発揮して機能の実装をして欲しい」、一方で、スクラムマスターからは「ユーザストーリーに定義された受入条件を満たす開発をすればよい」といった発言があり、少し違和感を覚えたので、ユーザストーリーやMVP（Minimun Viable Product）の捉え方について振り返ってみました。
まず、MVPとは何か、についてですが、MVPは正式なプロダクトの簡易版つくるのではなく、プロダクトとして重要な仮説（アイデア）を検証するためのプロセスです。初期のアイデアは、対象ユーザ、ユーザの課題に対する効率的な解決策、プライシング、マーケティング計画など非常に多くの仮説を前提にしていきます。これらの仮説の中で、リスクの大きい仮説から順に、効率よく検証していくTry＆Errorのプロセス自身がMVPとなります。効率よく検証していくためには、ユーザ検証をいつ、どの単位で行うかを意識した準備が必要になります。ここで陥りがちなのは、ユーザニーズを仮説した後、MVPを「プロダクトの簡易版」と位置付けてしまいサービス提供者視点で機能一覧を作成し実装を進めてしまうケースです。これを行ってしまうと、ユーザ検証に必要な機能が集まるのに時間がかかり、いつまでたっても検証とリリースができないといった状況にもなりがちです。冒頭で私が違和感を覚えたのは、この陥りがちなケースになりそうだなと感じたからでした。
では、リリースに時間がかかることは問題となるのでしょうか？
昨今、ビジネス環境の変化が早くなっており、システム開発もそれに応じて素早く変更可能であることが求められています。これに向けて、開発手法はウォーターフォールからアジャイルへ変わってきていますが、一部のアジャイル開発では、まだまだ、「プロダクトの簡易版」の開発になってしまっています。サービス提供者が素早くユーザに価値を提供するためには、ユーザ視点で要求を可視化することが重要です。まずは、「なぜユーザ視点が必要なのか」常に自ら問うことも重要ではないかと思います。
