mcpField
S
story-mapping

story-mapping

github.com/borghei開発1.0k50 回インストール5 日前に更新
リポジトリ

story-mapping について

story-mapping は、Jeff Patton のユーザーストーリーマッピングを用いてユーザーの体験を可視化し、戦略を優先順位付きのリリース可能な作業に落とし込むプロダクトチーム向けスキルです。MVPの定義、リリース計画、チーム間の認識合わせを支援し、マップを契約ではなく計画ツールとして扱います。

主な機能

  1. 01ユーザー体験全体のマッピング
  2. 02優先順位付きタスクへの分解
  3. 03MVPとリリース単位の定義
  4. 04マッピングワークショップの進行
  5. 05マッピング時の問題点の把握

活用シーン

  1. 01新製品のMVP範囲の設定
  2. 02複数リリースにわたる作業の順序付け
  3. 03ユーザー体験を軸にしたチーム間の認識合わせ
  4. 04フラットなバックログへの文脈の追加

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/borghei/claude-skills --skill story-mapping

インストール後、Claude Code で/story-mappingを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

examples/
wayfinder-mobile-onboarding-story-map.md
references/
playbook.md
red-flags.md

詳細

ユーザーストーリーマッピングのエキスパート

概要

ユーザージャーニーを可視化し、Jeff Pattonのユーザーストーリーマッピング手法を使って、戦略を優先順位付けされた実行可能な作業に変換します。ストーリーマップを使うと、チームの考え方を機能優先からフロー優先へと切り替え、何をどの順序で構築するかを決める前に、ユーザー体験全体を理解できます。

ストーリーマップは2次元のグリッドです。背骨(アクティビティ → ステップ)は、ユーザーがジャーニーを体験する順に左から右へと並び、本体(タスク)は各ステップの下に優先順位の高い順で上から下へと配置され、横方向のMVPラインがリリース1とそれ以降を分けます。全体の構成と6段階の作成手順については、プレイブックのリファレンスを参照してください。

使用する場面

  • MVPの定義 — 「必ずリリースするもの」と「後回しにできるもの」の境界を明確にします。
  • リリース計画 — 複数のリリースやスプリントにわたる作業の順序を決めます。
  • チーム間の連携 — 複数のチームでユーザージャーニーについて共通理解を得ます。
  • バックログの再編成 — フラットなバックログに背景情報と優先順位を取り戻します。
  • 新製品のキックオフ — ビジョンをゼロから作業に分解します。
使用しない場面
  • ユーザージャーニーを伴わない、純粋に技術的なインフラ作業(技術的なスパイクを使用してください)。
  • チームがすでに、優先順位が適切で背景情報も充実したバックログを持っている場合。
  • 複数のユーザーアクティビティにまたがらない、単一機能の作業。

最初に確認すること

マップを作成する前に、次の情報を確認してください。不明または曖昧な項目があれば、推測せずに質問してください。

  • ユーザーとエンドツーエンドのジャーニー — 誰がそのジャーニーをたどり、アクティビティ → ステップがどの順序で進むのか(マップを左から右へ貫く背骨を定義します)
  • 対象リリース/MVP — 何を先にリリースし、何を後回しにできるのか(リリース1とそれ以降を分けるMVPラインの位置を決めます)
  • マップの目的 — MVPの定義、リリースの順序付け、チーム間の連携のいずれなのか(本体のタスクの分割方法と優先順位付けに影響します)

停止ルール:出力への影響が最も大きい2〜3項目だけ質問してください。ユーザーが「とりあえず草案を作って」と言った場合は、そのまま進め、成果物の冒頭に前提を列挙してください。

リファレンス

  • references/playbook.md — マップの作成時に参照してください。ストーリーマップの構成、6段階の作成手順、成果物のテンプレート、マップのパターン(ウォーキングスケルトン/厚いスライス/段階的な機能拡張)、ワークショップのファシリテーションガイド、トラブルシューティング、成功基準を扱います。
  • references/red-flags.md — リリース計画にマップを使用する前に参照してください。ストーリーマップでよくある失敗パターンを、良い例・悪い例として引用した例と修正方法とともに説明しています。

範囲と制限

対象範囲: ユーザーストーリーマップの作成、背骨と本体の分解、リリーススライスの定義、MVPのスコープ設定、ファシリテーションのガイダンス、ワークショップの計画、テンプレートとパターンのライブラリ。

対象外: 個別のストーリー作成と受け入れ基準(job-stories/ または agile-product-owner を参照)、技術アーキテクチャの決定、詳細な工数見積もり、スプリント計画の仕組み。

重要な注意事項: ストーリーマップは計画ツールであり、契約ではありません。チームが学びを得るにつれて更新してください。構築前に作成したマップは、細部において必ず誤りがあります。価値があるのは成果物そのものではなく、共通理解です。Jeff Patton:「マップは領土ではありません。対話こそが領土です。」

統合ポイント

統合方向連携内容
job-stories/受け取るJTBDディスカバリーキャンバスで、マッピングのためのナラティブを定義します
create-prd/渡すリリース1のタスクがPRDのスコープ(セクション7および8)に反映されます
prioritization-frameworks/補完するRICEスコアリングで、リリーススライス内の優先順位を決めます
brainstorm-okrs/補完するリリーススライスを四半期ごとのOKR目標に整合させます
outcome-roadmap/渡すリリーススライスをNow/Next/Laterのロードマップ期間に対応付けます
wwas/渡すタスクが、戦略的背景を伴うWWASのバックログ項目になります

さらに読む

  • Jeff Patton、『User Story Mapping』(2014)
  • Jeff Patton、「The New User Story Backlog Is a Map」(2005)
  • Productside のストーリーマッピングワークショップに着想を得ています

コメント