
もうだいぶ前に調べたことのあるツール「Linear」が、AI時代で注目を集めはじめているそうでまた触りはじめています。するとユーザ一覧に「user-story-is-dead」さんという方が登場して「なんじゃこいつは?」となりました。調べてみると「Write issues not user stories」という記事を発見したので、彼らの主張を読んでみました。
ユーザーストーリーはプロダクト開発におけるアンチパターン
Linear では、ユーザーストーリーを作成しておらず、アンチパターンと考えているそう。その代わりに(きっと Linear を使って)タスクを平坦な言葉で記述しシンプルな課題(Issue)を作成しているみたいです。
なんでこういう考えに至ったかというと・・・
- ユーザーストーリーは20年以上前に誕生して変化していないが、ソフトウェア開発は大きく変化して、方法が時代にマッチしていない
- たとえば、「カート機能」と言えば、それがどういうものなのかだいたい理解できるし、必要となる機能も標準的・一般的なものが思いつける時代になっている
- 結果的に、タスクを遠回しに説明する古い儀式のようになってしまっている
という感じ(要約)。
これを避ける方法として提案しているのが
- ユーザーストーリーの作成に時間を使わない
- そのかわりに、タスクを想像しやすいシンプルな言葉で書いた課題を書き出す
- 製品・機能レベルでUXを議論する
といったところ。
ユーザーストーリーが複雑で範囲設定が難しい理由の一つは、プロダクトレベルの詳細をタスクレベルに持ち込んでしまうからです。(One reason user stories are complicated and difficult to scope is because they bring what should be product-level details into the task level. )
とあるので、ユーザーストーリーがプロダクトレベルで書くべきものと、タスクレベルで書くべきものがごちゃまぜになってしまうのを嫌悪しているのかもしれません。
提案の詳細をもうちょっとまとめるとこんなかんじでしょうか。
- 課題は明確な成果を伴うタスクを記述する。タスクにならないものは登録しない
- 短く簡潔な課題を作成する。説明は任意でよく関連する情報のリンクなどは入れていい。
- 誰かに書いてもらうのではなく自分で書くことで迅速かつ容易となる
- UXに関しては製品レベルで議論する。こういったものはタスクを議論するのではなく、作業をチームに委任することで成果を期待する
これまでにアジャイル開発は何十回と死んできたので、ユーザーストーリーも死んでしまうと、次は何が死ぬのか気になってしまいます。
彼らのいわんとしていることを完全に理解できたとは思いませんが、タスク管理ツールを提供するベンダーとして、「タスク」というものを中心にプロダクト開発を行っているのだろうとは推測できます。
そして、ユーザーストーリーはタスクではないので、戦う相手が間違っている気もします。ようはやりようで、 Linear を使ってユーザーストーリーをうまく扱うこともできるだろうし、 ユーザーストーリー中心の開発でも Linear をうまく活用できるでしょう。
ま、結局、生きようが死のうが、プロダクト開発がうまくいけばなんでもいいんじゃない?