はじめに
親父...1 nikkieです。
ユーザストーリーの分割について、いくつかの書籍に渡ったつながりを発見しました！
現時点のバックアップとしてアウトプットします。
目次
- はじめに
- 目次
- ユーザストーリーとは
- 『アジャイルな見積りと計画づくり』 12章 ユーザーストーリーの分割
- 『達人プログラマー』 （第2版） 12 曳光弾
- 曳光弾（『アジャイルな見積りと計画づくり』）と、縦スライス（『アート・オブ・アジャイル デベロップメント』）
- 終わりに（考え方を練習するんだ！）
ユーザストーリーとは
ユーザーストーリーという表記が一般的な気がしますが、このエントリではユーザストーリー表記で行きます！
アジャイルプラクティスマップに「ひとまずここを見ればおｋ」という充実のまとめがありました！2
チームが作り出す成果を簡潔に説明したもの。顧客目線で、ビジネスの成果という観点で表現する。（「解説」より）
ユーザストーリー自体については過去に私もアウトプットしており3語りたいことは尽きないのですが、今回はここまで！
このエントリではユーザストーリーの分割にフォーカスします。
マイク・コーンは『アジャイルな見積りと計画づくり』の第12章にユーザーストーリーを分割するいろいろな方法をまとめている。（「どうやるか」の「ユーザーストーリーの分割方法」より）
『アジャイルな見積りと計画づくり』 12章 ユーザーストーリーの分割
ユーザストーリーの分割ガイドライン（指針）を示す章です。
ガイドラインだけでなく、どんなときに分割するのか、逆操作としてまとめるについても扱われます4。
ガイドラインの概要は、アジャイルプラクティスマップでもさっと確認できます（例えば、「操作の境界で分割する（よくあるのはCRUD）」）。
『アジャイルな見積りと計画づくり』12章の中で今回注目したいのが「7.ストーリーをタスクに分解してはならない」。
悪い例（タスクになっている例）はこちら（p.143より）：
- ユーザーインターフェイスを実装する
- 中間層を実装する
「実装する」は開発者の作業ですから、ユーザ価値（ユーザは何ができるのか。もっと言うと、ビジネスの成果）はたしかに見えづらいですよね
ガイドラインは以下です（p.144より）：
大きなストーリーをタスクに分解するのではなく、ストーリーを曳光弾にするための作戦を考えること。
曳 光 弾！（Tracer ammunition）
これは『達人プログラマー』の言葉なのですが、『アジャイルな見積りと計画づくり』の中での解説はこちら：
「曳光弾」とは、あるフィーチャに必要なシステムの論理層すべてをまたいで実装することを指す。各層の実装は部分的なもので構わない。（p.143-144）
例として、実装箇所がユーザーインターフェイス、中間層、データベースの3層にまたがるとします。
タスクになっている悪い例では、ユーザーインターフェースだけ全て実装、中間層だけ全て実装になっていて、システムは完成しません。
一方、曳光弾にすると、システムの限られた機能としてユーザーインターフェイス、中間層、データベースのすべての層を通して実装することになります。
ごくごく限られた部分ですが、システムは完成するのです。
『達人プログラマー』 （第2版） 12 曳光弾
第2章「達人のアプローチ」の1つが曳光弾！
兵士は曳光弾を使って自らの照準を調整します。曳光弾は実際の状況下でリアルタイムのフィードバックが得られる実践的なものなのです。(Kindle の位置No.1800-1801)
『アジャイルな見積りと計画づくり』の解説の図解と言える（カラフルな）図があります(Kindle の位置ではNo.1834らしいです)。
図では未実装な箇所（波線）を多く残していますが、矢印➡️に注目すると、ユーザーインターフェース、認証、業務ロジック、データモデル、データベースと貫通して実装しています！
ごくごく限られた部分の実装、これがシステム全体を照らします（曳光弾）。
また、限られた機能が提供可能になることで、アジャイルに進めていく上で重要な、作るシステムについての学びの機会も得られるわけですね。
『プリンシプル オブ プログラミング』の連載で曳光弾についても言及されています
プログラミングにおける「曳光弾」とは、優先的に検証したい部分を、先行的にプログラミングすることです。簡易で構わないので、実際の環境下で動作して、確認できる、エンド・ツー・エンドのソフトウェアを作成します。
ここで作成するコードは、フレームワークであり、土台となります。プロジェクトを通じて肉付けされていき、最終的な成果物にも残る「本物のコード」です。
引用箇所を読むと曳光弾とはたいそうなものと思われるかもしれませんが、『達人プログラマー』の例を知ると、「名前知らなかったけどやってる習慣じゃん！」となるかもしれませんね。
最初の曳光弾は単に「プロジェクトを作成し、『hello world!』を追加した後、コンパイルと実行を行って確認する」というもの (Kindle の位置No.1826-1827)
『達人プログラマー』の曳光弾は、優先的にフィードバックを得たい部分を限定的に動かすコードで、それが続く開発の土台となるという紹介です。
このエントリの主題「ユーザストーリーの分割」の観点からは、すべての層をまたいで限定的な機能を実装としてとらえられると私は理解しました5。
曳光弾（『アジャイルな見積りと計画づくり』）と、縦スライス（『アート・オブ・アジャイル デベロップメント』）
すべての層をまたいだ限定的な機能という意味での曳光弾で、『アート・オブ・アジャイル デベロップメント』68章の「8.2 リリース計画」にある縦スライスを思い出しました。
8.2は英語がWebで公開されているようです。
その中で縦スライスを説明する図がこちら。
縦があるということは横もあります。
図が示しているのは以下のようになります：
- 横スライス（horizontal stripes）
- ストーリー例（※タスクになっている悪い例です）
- Get data（顧客データ・配送先・請求情報を入力できる）
- Validate data（顧客データ・配送先・請求情報を検証する）
- Write to database（顧客データ・配送先・請求情報をデータベースに保存する）
- ストーリー例（※タスクになっている悪い例です）
- 縦スライス（vertical stripes）
- ストーリー例（曳光弾に通じる考え方！）
- Customer data（顧客データを入力でき、検証してデータベースに保存できる7）
- Shipping address（配送先を入力でき、検証してデータベースに保存できる）
- Billing information（請求情報を入力でき、検証してデータベースに保存できる）
- ストーリー例（曳光弾に通じる考え方！）
「8.2 リリース計画」は、チームの生産性が変わらないとしても、リリースする順序で投資対効果が変わることを指摘し、考え方を紹介する章です。
ポイントとなるのは、ユーザストーリー単体でリリースしても問題ない状態にすること8。
横スライスはユーザストーリー単体ではリリースできない状態にします。
データの入力・検証・保存と3つ揃って初めてリリースできるわけで（言い換えると0か1の2択）、データの入力ができたからリリースとはなりません。
「8.2 リリース計画」で紹介される考え方からするとこれは望ましくありません。
ビジネス上のチャンスがあって方向転換9するようなときに、横スライスだと途中まででリリースができない（それまでの開発＝投資は、リリースできないので回収できない）のがたしかにネックだと思います。
縦スライスはどうでしょうか。
例えば「顧客データを入力でき、検証してデータベースに保存できる」。
機能は非常に限定されますが、ユーザストーリー単体でリリースしても問題ありません！
なので、方向転換する場合でも、縦スライスのストーリーであればリリースしてしまって、それまでの開発＝投資を回収できます。
なお、「8.2 リリース計画」では、価値が高いストーリーから順に着手するのが前提になっているという理解です。
曳光弾にしても、縦スライスにしても、すべての層をまたいだ限定的な機能であればリリースできるというのがポイントなのかなと考えています。
リリースできればフィードバックが得られ、次に繋がっていきますからね！
終わりに（考え方を練習するんだ！）
ユーザストーリーをタスクに分解しないための考え方についてアウトプットしました。
1つは「曳光弾」、すべての層をまたいだ限定的な機能のユーザストーリーに分割するという理解です。
これを言っている別の言葉が（横スライスに対する）「縦スライス」だと思います。
ぶっちゃけ私も横スライスばっかりやってたんですよ（横スライスしか知らなかった）。
で、縦スライスを知り「常にリリースできるのいいな」と思って考え方の練習を続けています。
- 横スライスのユーザストーリーを作るということは、どの層でどういう実装が必要かは見えている
- 例：UIで入力できる・DBに保存できる・ロジックで検証できる
- 層ごとにユーザストーリーを作りたいという衝動に抵抗する
- 機能を限定して、すべての層を実装することを考える
- どういうふうに限定するかは状況によって異なります
- 上の例で言えば、特定の種類のデータだけ入力・保存・検証ができるといった感じになりそうです
- 考え方をインプットした後は、ここが本当に練習あるのみだと思っていて、経験値を積んでいく中で「あのときもっといい感じの縦スライスできたな」とかやっちまってたことにたびたび気付きます😅
- 縦スライスが上達していくと、小さい単位でリリースできていって、非常に開発しやすく感じます（最近思うんですが、小さいは正義！）
- 分解といえばこの方 https://dic.pixiv.net/a/%E3%82%AA%E3%83%BC%E3%83%90%E3%83%BC%E3%83%9B%E3%83%BC%E3%83%AB%28%E5%83%95%E3%81%AE%E3%83%92%E3%83%BC%E3%83%AD%E3%83%BC%E3%82%A2%E3%82%AB%E3%83%87%E3%83%9F%E3%82%A2%29↩
- アジャイルプラクティスマップ、これはc2 wikiみたいな感じなうえに、日本語で読め、2023年時点では最新に近いと素晴らしすぎますね👏 オススメリソースです↩
- XP祭り2022で発表しました！（レポートブログ） ↩
- XP祭り2022の懇親会で教えていただいたこちらの読書会資料、12章の概要がつかめます！ ↩
- 『達人プログラマー』の意味で「曳光弾」を撃ってその学びを計画に反映するのも、全然ある（個人的にはかなり好ましい）と思います。今回の記事から外れるので深追いしていません↩
- 2版も英語で読んでいますが、ユーザストーリーの分割は『アジャイルな見積りと計画づくり』の12章にリダイレクトされます↩
- 「入力」「保存」「検証」でそれぞれユーザストーリーを分けられますね。好みだと思いますが、小さいストーリーは開発をリズミカルにするので私は分けたいです（ユーザに価値を届けるリリースはもとの単位が妥当だとも思います）↩
- 「リリースできるようにしておく」（8.2.6）。ユーザストーリー単体で常にリリースしなければならないとは異なります↩
- LLMsを目の当たりして、非常にピンときました↩
