generated at
ユーザーストーリーマッピング
略名:USM

システムとの接点に関わるユーザーの行動を時系列に並べたユースケースで、リリースする優先順位が付いている

ユーザーストーリーマッピングとか、いいんだけど、ちょっと丁寧すぎるというか、トレードオフの発見がスコープにない


ユーザーが本当に欲しいものを作れるか

思いだしてフレームワークに書くだけで、見栄えのするものができちゃう問題
USMのアレなところは、フレームワークがある意味で優秀すぎて、使う人が考えなくてもそれっぽい物ができてしまって、USM以上のものをつくるときにとたんに壁にぶちにあたる
それっぽいのがつくれちゃうのが、ホントにダメ

USMで作ったワーク成果物は映える。ステークホルダーに対しても、プロジェクトの初期で見栄えのするものが作れるので、スタートダッシュを切れたように見えてしまう
でも、実態は、それほどドメインを理解したわけでもないし、スキルも上がってないので、途端に失速する。つまり、自分達の能力以上のものを作れてしまう。ところがそこに気づけない。

新製品開発という難しい仕事に取り組んでいく上で、非常に大きな障害となる自分達自身の「無知無能無関心」を見過ごしやり過ごし先延ばししてしまう。

ユーザーストーリーマッピングはユーザーのことばかり書いてあるので、ユーザとオペレーションのマッピングがあったほうがいい。




インセプションデッキやユーザーストーリーマッピングといったフレームワークは、見栄えがして、やった気もするので、スタートダッシュした感がでるが、それはフレームワークの力であって、チームの力ではない。なのでフレームワークの次のステップで急速に失速するチームが多い。

でも、見栄えのするフレームワークを最初に出すことによって、ステークホルダーの期待が高まりすぎていて、一方でチームは能力が追いついていないため、失速感が凄まじいことになる。

プロダクトマネジメントのフレームワークとか、見栄えのためのVC騙しみたいなものが多い。ICEスコアとか、10点がごろごろしているような状態じゃないのって危機的な状況なのに、バックログアイテムを分類して分析して仕事した気になってしまう。




ユーザーのアクティビティ
プロダクトを支えている人のアクティビティとユーザーとの接点
ユーザーから見える人
受付
ユーザーから見えない黒子の人
電源管理とか


ユーザーストーリーマッピングのサイクル化