March 2021
Beginner to intermediate
288 pages
5h 8m
Japanese
| ジェームズ・コプリエン | ![]() |
言葉はものごとを表す。「ユーザーストーリー」という言葉は、それがユーザー領域でのストーリーであることを示唆する。この言葉は、「Xとして、Yしたい。なぜならZだからだ」という定型の文章を意味するようになった。アジャイルな人のなかには、これを文字どおりに捉えて、まるで義務かのようにこの形式で書いている人もいる。だが、ロン・ジェフリーズがかつて指摘した(https://oreil.ly/kczbn)ように、この表現は、エンドユーザーと開発者の将来の会話への招待にすぎない。これはとても示唆に富んだ指摘だ。ストーリーテリングの可能性を取り戻すことで、私たちは安堵できるのである。
ストーリーはエンドユーザーのニーズを理解する上でとてつもなく価値がある。スプリントゴールは、主要なユーザーストーリーの見出しや意図を示すものになるべきだ。だがユーザーストーリーは、言うなればストーリーの始まりにすぎない。「ユーザーのナゾ」とでも呼ぶべきか。設計の仕事は、ナゾを解き、答えにあった実装を提供することだ。
スクラムは、ムリ(過度な負担)をなくし、代わりにフローをよくするというリーンの原則に従う。ユーザーがニーズを持って来たとしても、それを一夜にしてソリューションに変換することもないし、スプリントプランニングと呼ばれるミーティングですぐに扱うこともない。ビジネスのソリューションを設計するには、時間、対話、探索、フィードバックが必要だ。ソリューションは、実行可能な仕様としてプロダクトバックログの上位に来る過程で見えてくるものであり、そうなって初めて意味のあるものになる。 ...
Read now
Unlock full access