垂直スライス (Vertical Slicing)

概要

垂直スライス（Vertical Slicing）とは、大きすぎる作業項目やユーザーストーリーを、システムの全層（画面・API・データ）を貫きながら独立して価値を提供できる薄い単位へ分割する技法である。フロントエンド／API／データベースといった技術レイヤーごとに分ける「水平分割」とは異なり、垂直スライスは分割後の各断片が単独でユーザーに価値を届けられることを条件とする。この条件（価値保存性）を満たさない分割は、たとえ規模が小さくなっていても垂直スライスとは呼ばない。

垂直スライスの目的は、スプリントやインクリメントの単位に収まる大きさへ作業を薄くしながら、途中で作業が止まっても既に届けた分の価値が失われない状態を保つことにある。

詳細

垂直スライスを実際に切り出す際は、「何を最初のスライスとして残し、何を後続のスライスへ回すか」という切り口（分割軸）を選ぶ。分割軸には、ビジネス上の価値の切り口（誰に・どの範囲の価値を先に届けるか）と、コード構造上の関心事の切り口（実装のどの部分を先に通すか）の2種類がある。以下は代表的な12の分割軸である。各軸は「最初のスライス」「後続スライス」「価値が保たれる理由」「陥りがちな水平分割の例」の4点で構成する。

1. Happy Path（正常系）と例外系・エラーハンドリングの分離

• 適用範囲: ビジネス／コードどちらの切り口でも使える、最も汎用性の高い軸^[1][2][3]。
• 最初のスライス: 入力が正しく外部連携も成功する前提の正常系だけを、入力から結果表示まで一気通貫で完成させる。エラー時は汎用のエラーメッセージ1種類のみ表示する。
• 後続スライス: 入力バリデーション（不正入力の検知と項目ごとのエラー表示）、外部連携の失敗・タイムアウト時のリトライと案内、権限不足・競合など業務上の例外ケースごとの振る舞いを1つずつ積み上げる。
• 価値が保たれる理由: 正しい入力で使う利用者には最初のスライスだけで完全な価値が届く。例外系は価値を守るための追加であり、切り離しても入口から出口までの一貫性は壊れない。
• 陥りがちな水平分割: エラーハンドリング共通基盤（例外クラス・ログ・エラー画面の枠）を先に作ることは、正常系の価値を何も届けない水平分割になる。

2. Read（参照）とWrite（更新）の分離

• 適用範囲: コード構造の切り口^[4][2]。
• 最初のスライス: 一覧・詳細の表示など参照（Read）側だけを、画面（またはAPIレスポンス）から取得ロジック・データ取得まで一気通貫で完成させる。更新系の操作（作成・編集・削除）はUIに出さない。
• 後続スライス: 新規作成（Create）、編集（Update、競合制御は後回し）、削除（Delete）とそれに伴う参照側の表示更新を1つずつ追加する。
• 価値が保たれる理由: 参照だけでも利用者は実データを見て意思決定できる。読み取りモデルと書き込みモデルは関心事が異なるため、分けても各スライスは全層を貫いたままになる。
• 陥りがちな水平分割: 参照用のデータベーステーブルとAPIだけを先に作り、画面は次のスプリントへ回すことはレイヤー分割になる。参照スライスは画面まで含めて初めて価値になる。

3. データ量の制限（件数・期間を絞る）

• 適用範囲: ビジネス価値の切り口^[2][3][5]。
• 最初のスライス: 画面に表示中の上位100件（または直近30日分）に限定し、即時に結果を返す形で完成させる。件数上限は画面上に明示する。
• 後続スライス: 期間指定（任意の開始日・終了日）への拡張、全件対応（非同期処理と完了通知）、履歴・過去分を含む大量データへの対応（分割ダウンロード等）を積み上げる。
• 価値が保たれる理由: 多くの利用者の日常業務は直近・少量のデータで完結するため、件数を絞っても必要なデータを取り出せるという価値はそのまま届く。全件対応は利用実績を見てから投資できる。
• 陥りがちな水平分割: 全件処理に耐えるバッチ基盤・キュー・ストレージを先に整備し、利用者向け機能を後回しにすることは水平分割になる。少量データで先に一気通貫させる。

4. フォーマットの限定（出力形式を1つに絞る）

• 適用範囲: ビジネス価値の切り口^[6][7]。
• 最初のスライス: 出力形式を最も利用頻度が高い1形式（例: CSV）に限定して完成させる。他形式の選択肢はUIに出さない。
• 後続スライス: 2つ目の形式（例: Excel）の追加、帳票・PDFなどレイアウトを伴う形式の追加、形式ごとのオプション（文字コード・区切り文字等）の指定を積み上げる。
• 価値が保たれる理由: 主要な利用者は1形式で業務を完結できる。形式追加は出力レイヤーの差し替えだけで済み、入口から出口までの流れは最初のスライスで確立済みになる。
• 陥りがちな水平分割: 全形式に対応できる汎用エクスポートエンジンをあらかじめ設計することは、どの形式も利用者へ届かない水平分割になる。

5. ユーザー種別・顧客セグメントの限定

• 適用範囲: ビジネス価値の切り口^[2][8]。
• 最初のスライス: 最も価値が高い、または要望が明確な1つのユーザー種別・プラン・テナントに限定して完成させる。対象外の利用者には機能を表示しない。
• 後続スライス: 2番目のユーザー種別への展開（権限・表示の差分のみ追加）、全ユーザー種別への展開と種別ごとの設定差分を積み上げる。
• 価値が保たれる理由: 対象セグメントの利用者にとっては最初のスライスで完全な機能になる。セグメントを広げる作業は権限・表示条件の追加であり、機能の一貫性は保たれる。
• 陥りがちな水平分割: 全ユーザー種別に対応する権限モデル・設定画面を先に作ることは水平分割になる。1セグメントに対して先に価値を届ける。

6. 業務フローの最初のステップに限定

• 適用範囲: ビジネス価値の切り口^[2][4]。
• 最初のスライス: 一連の流れのうち最初のステップ（例: 申請の登録と内容確認）だけをシステム化して完成させる。後続ステップ（承認・通知など）は当面、既存の手段（メール・対面）で運用する。
• 後続スライス: 2番目のステップ（例: 承認・差し戻し）のシステム化、ステップ間の通知・リマインド、履歴・監査ログなどフロー全体を横断する機能を積み上げる。
• 価値が保たれる理由: 最初のステップがシステム化されるだけで、入力の正規化・記録が始まり利用者の手作業が減る。後続ステップは既存運用で補えるため業務は途切れない。
• 陥りがちな水平分割: 全ステップ共通の状態遷移エンジンを先に作ることは水平分割になる。1ステップを入力から記録まで縦に通す。

7. チャネル・プラットフォームの限定

• 適用範囲: ビジネス価値の切り口^[2][4]。
• 最初のスライス: 利用者が最も多い1チャネル（例: Webブラウザ版のみ、通知はメールのみ）に限定して完成させる。
• 後続スライス: 2番目のチャネル（例: モバイルアプリ）への展開、チャネルごとの表示・通知の最適化を積み上げる。
• 価値が保たれる理由: 主要チャネルの利用者には最初のスライスで完全な価値が届く。他チャネルは表示層の追加であり、業務ロジックは共有される。
• 陥りがちな水平分割: 全チャネル共通の通知基盤・配信APIを先に作ることは水平分割になる。先に1チャネルへ届ける。

8. 手動トリガーから始めて自動化は後回し

• 適用範囲: ビジネス／コードどちらの切り口でも使える軸^[9][10]。
• 最初のスライス: 利用者（または運用担当）がボタン・コマンドで手動実行する形にして完成させる。スケジュール実行・自動判定は含めない。
• 後続スライス: スケジュール実行（定期実行）の追加、条件を満たしたときの自動実行とその結果の通知を積み上げる。
• 価値が保たれる理由: 手動でも処理そのものの価値（結果が得られること）は届く。自動化はトリガーの差し替えであり、処理本体は最初のスライスで完成している。
• 陥りがちな水平分割: ジョブスケジューラ・キュー基盤を先に整備することは水平分割になる。まず手動で一気通貫させる。

9. 設定・オプションを既定値に固定

• 適用範囲: ビジネス／コードどちらの切り口でも使える軸^[8]。
• 最初のスライス: 条件指定・並び替え・カスタマイズなしの既定動作（例: 直近順で固定、フィルタなし）で完成させる。
• 後続スライス: 最もよく使われる1つの条件指定（フィルタ）の追加、並び替え・複数条件の組み合わせ、利用者ごとの設定保存を積み上げる。
• 価値が保たれる理由: 既定動作で大半の利用シーンは満たせる。オプションは入口のパラメータを増やすだけで、処理の流れは最初のスライスで確立済みになる。
• 陥りがちな水平分割: 設定画面と設定保存テーブルを先に作ることは水平分割になる。既定値で先に価値を届け、設定は必要性が確認されてから足す。

10. 入力バリエーションを1件・1種類に限定

• 適用範囲: コード構造の切り口^{[2][4][11][12]}。
• 最初のスライス: 1件（または1種類）の入力だけを扱う形で完成させる。複数選択・一括処理はUIに出さない。
• 後続スライス: 複数件の選択と逐次処理、一括処理（部分失敗時の扱いを含む）を積み上げる。
• 価値が保たれる理由: 1件ずつでも処理は完結し、利用者は結果を得られる。一括化は入力の繰り返しであり、1件の縦スライスの上に積み上げられる。
• 陥りがちな水平分割: 一括処理用のバッチ基盤・進捗管理を先に作ることは水平分割になる。1件を先に通す。

11. 同期処理から始めて非同期化は後回し

• 適用範囲: コード構造の切り口^[7][13]。
• 最初のスライス: リクエストの中で同期的に処理し、その場で結果を返す形（処理対象が小さい前提）で完成させる。
• 後続スライス: 処理時間が閾値を超える場合の非同期ジョブ化と受付応答、進捗表示・完了通知を積み上げる。
• 価値が保たれる理由: 小さな入力に対しては同期処理でも十分に価値が届く。非同期化は実行方式の差し替えであり、処理内容は最初のスライスで完成している。
• 陥りがちな水平分割: キュー・ワーカー・ジョブテーブルを先に整備することは水平分割になる。同期で先に一気通貫させる。

12. 扱う項目（フィールド）を必須項目に限定

• 適用範囲: コード構造の切り口^[14]。
• 最初のスライス: 業務上必須の最小セット（例: 名称と日付だけ）に限定し、入力から保存・表示まで一気通貫で完成させる。
• 後続スライス: 任意項目の追加（1項目ずつ縦に）、複雑な項目（添付ファイル・関連エンティティ参照）の追加を積み上げる。
• 価値が保たれる理由: 必須項目だけでレコードとして成立し、参照・更新の流れが通る。項目追加は各層に薄く足すだけで、一貫性は保たれる。
• 陥りがちな水平分割: 全項目分のテーブル定義とマイグレーションを先に作ることは水平分割になる。必須項目を先に縦へ通す。

分割の進め方

複数の軸が同時に当てはまる場合は、ビジネス価値の切り口（誰に・どの範囲の価値を先に届けるか）を先に選び、選んだスライスに対してコード構造の切り口（実装のどの部分を先に通すか）を当てはめる、という2段階で進めると絞り込みやすい。どの軸で切っても、各スライスが単独でリリース可能であること（受け入れ基準を満たしてDoneにできること）を最終確認とする。

水平分割の兆候チェックリスト

受け入れ条件が次のような技術レイヤー単位の語彙で書かれている場合、水平分割（画面／API／データベースをそれぞれ別の作業単位に分けてしまう分割）の兆候である。2つ以上のレイヤーがこの形で現れたら、垂直スライスへの書き直しを検討する。

• データベース: 「DB」「データベース」「テーブル」「スキーマ」「マイグレーション」＋「作成」「設計」「定義」「追加」「変更」「実装」「構築」「移行」「導入」
• API: 「API」「エンドポイント」「バックエンド」「サーバー側」＋「作成」「実装」「追加」「開発」「構築」「連携」「接続」
• 画面: 「画面」「フロント」「フロントエンド」「UI」＋「作成」「実装」「追加」「開発」「作る」「接続」「構築」
• インフラ: 「インフラ」「環境」「基盤」＋「構築」「整備」「準備」「導入」

このチェックリストで水平分割の兆候を指摘するときは、該当する受け入れ条件を要約・言い換えせず、逐語で引用すること。「〜という受け入れ条件が技術レイヤー単位である」のような一般化した指摘は、どの入力にも当てはまる当たり障りのない指摘になり、根拠として弱い。

分割後の確認

分割した各スライスを独立したPBI（ユーザーストーリー）として起票したら、受け入れ基準を1件以上持つこと（S1）、各受け入れ基準がFunctional/NonFunctionalのいずれかに分類されていること（S2）を、validate_scrum_data（format: ‘json’ の stories[].acceptanceCriteria）に通して確認する。「分割したスライスが検証可能な単位になっているか」の決定論的な確認はこのツールが担い、本ページは分割そのものの判断（どこで切るか）だけを扱う。

分類・所属

• 所属タグ: Vertical Slice Story Splitting INVEST
• カテゴリー: Related Fields

脚注

1. Happy path — 正常系（happy path）を、例外・エラー条件を伴わない既定の実行シナリオとして定義し、代替パス・例外パスと明確に区別してモデリングすべき基本形とする（訳）（ライセンス: CC BY-SA 4.0） ↩

2. Comparing Requirements Decomposition Within the Scrum, Scrum with Kanban, XP, and Banana Development Processes — 「As these are specific techniques for decomposing a large user story into smaller ones in an Agile context, we integrated their proposals into the following list」（訳: Lawrence(2009)/Verwijs/Irwin(2014)の実務家ブログが提案する分割技法を整理したもので、Happy/unhappy flow、Operations (CRUD)、Workflow steps、Roles、Input options/platform、Major effort、Simple/Complex、Data types/parametersを含む18技法のリストとして掲載されている）（ライセンス: CC BY 4.0） ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷

3. Rapid Value Stream Mapping — 「Limit Scope: If the stream is too large…, slice it」「…happy path bias」（訳: 対象が大きすぎる場合はスコープを絞ってスライスし、正常系偏重を避けて例外フローも意識するよう促している）（ライセンス: CC BY 4.0） ↩ ↩²

4. Design Practice Repository (DPR): Practice/Technique Story Splitting — 「Operations completion: create, read, update (full, partial), delete; search, find, archive; undo」「Workflow step: from process initiation to processing activities…to process termination」（訳: 操作の完了度でRead/Write等を分ける技法と、業務フローの開始から終了までの各段階で分ける技法を、Richard Lawrenceの分割パターンとして整理している）（ライセンス: CC BY 4.0） ↩ ↩² ↩³ ↩⁴

5. Pagination — 「Pagination is an approach used to limit and display only a part of the total」（訳: ページネーションは全体の一部のみに限定して表示する手法である）（ライセンス: CC BY-SA 4.0） ↩

6. INVEST (mnemonic) — 「it would be acceptable for a coded/text response…to be simply shown…as text…and have a better representation of that response to be covered in another story」（訳: 装飾のないテキスト形式で示すに留め、より優れた表現は別ストーリーへ分割してよいと述べている）（ライセンス: CC BY-SA 4.0） ↩

7. Split Poker (User Story Split Master) — 「INTERFACE VARIATIONS: Does the story have a complex interface? … Is there a simple version you could do first?」「DEFER PERFORMANCE: …Can you split the story to just make it work first and then enhance it to satisfy the non-functional requirement?」（訳: 複雑なインターフェースはまず単純な版を先行させ、性能等の非機能要件は後回しにしてまず動く状態を作る、というRichard Lawrenceの分割パターンを教材化している）（ライセンス: CC BY-ND 3.0 FR） ↩ ↩²

8. Feature toggle — 「defining a default value」「Feature flags…allow targeting by geographic locations or even user attributes」（訳: 既定値を定義し、地理的位置やユーザー属性でターゲティングするカナリアリリースの仕組みを解説している）（ライセンス: CC BY-SA 4.0） ↩ ↩²

9. Lean startup — 「Instead of building a website and a large database of footwear, Swinmurn approached local shoe stores, took pictures…bought the shoes…after he’d made a sale, and then shipped them directly to customers」（訳: Zapposの創業者は在庫データベースを構築せず、注文を受けてから近隣店舗で仕入れて発送する手作業で価値を検証した）（ライセンス: CC BY-SA 4.0） ↩

10. Wizard of Oz experiment — 「the experimenter simulated the system in toto, performing all the database queries and composing all the responses…by hand. As the process matured, the experimenter replaced human interventions, piece by piece, with newly created developed code」（訳: 初期は人間が全処理を手作業で代替し、成熟に応じて段階的にコード化していく）（ライセンス: CC BY-SA 4.0） ↩

11. Batch processing — 「flow processing…only need data from a single input at once…lowers latency for individual inputs」に対し「many applications require data from all records…the entire batch must be completed before one has a usable result」（訳: 単一入力のみを扱うフロー処理は低遅延だが、全件処理を要するバッチは完了するまで結果が得られない）（ライセンス: CC BY-SA 4.0） ↩

12. What we should do with tasks which estimated time bigger than sprint?（回答: Ashok Ramachandran） — 「if you are going to accept Visa, MasterCard and PayPal, you can first implement PayPal…and then have separate stories to add Visa and Mastercard…you can first implement single payments and then add the recurring payments in another sprint」（訳: 決済手段は1種類だけ先に実装し、単発決済を先に完成させてから定期課金を後続スプリントで追加する）（ライセンス: CC BY-SA 3.0） ↩

13. Transaction processing system — 「Real time systems attempt to guarantee an appropriate response…quickly enough」「Batch processing…results of each transaction are not immediately available…there is a time delay」（訳: リアルタイム処理は即時応答を保証するのに対し、バッチ処理は結果が遅延する、という計算モデルの違いを対比している）（ライセンス: CC BY-SA 4.0） ↩

14. How to take out dependancies among tasks within a scrum sprint?（回答: Daniel） — 「Instead I could create a form where you put in your appt number and it sends a text or call to the on-call maintenance person…Next I allow you to add extra information…Finally, I might add nice-to-haves」（訳: まず予約番号だけの最小フォームで完成させ、次に詳細情報フィールドを追加し、最後にnice-to-haveを積み上げる）（ライセンス: CC BY-SA 4.0） ↩