ユーザーストーリーマップの作り方｜機能の優先順位を並べる手順

2026年2月13日

＠SOHO編集部

この記事のポイント

✓ユーザーストーリーマップの作り方を
✓優先順位の決め方の順に解説します
✓一列のバックログとの違い

ユーザーストーリーマップは、作りたいサービスの機能を「使う人の行動の順番」に沿って並べ、どこから作るかを決めるための地図です。機能の一覧を作ったものの、どれも大事に見えて優先順位が決められない、関係者ごとに思い描いている完成形が違う、という悩みを持つチームほど効果が出ます。

この記事では、ユーザーストーリーマップの基本、作る前の準備、6つの手順、具体例、優先順位の決め方、よくある失敗の直し方を順番に整理します。でき上がったマップのカードを、担当と期限を付けて進める道具の1つとして、プロジェクト管理のPinateca（ピナテカ）にも途中で触れます。

ユーザーストーリーマップとは：行動の順番で機能を並べる地図

ユーザーストーリーマップを一言で言うと、横に「使う人の行動の流れ」、縦に「その行動を支える機能の候補を優先順に」並べた表です。プロジェクト管理ツールの解説では、次のように定義されています。

ユーザーストーリーマップとは、アジャイル開発やスクラムといったソフトウェア開発手法で使用されるツールの一つです。商品・サービスのユーザー視点から見た行動・体験を時間軸に沿って視覚的にマッピングしたものを指します。出典: lychee-redmine.jp

アジャイル開発とは、大きな計画を最初にすべて決めるのではなく、短い期間で作っては確かめることを繰り返しながら完成に近づける開発の進め方のことです。スクラムは、その代表的なやり方の1つです。

マップの形は、だいたい次の3段で成り立っています。

一番上の段：使う人の大きな行動（アクティビティとも呼ばれます）。例として「探す」「予約する」「受講する」「支払う」
2段目：大きな行動を細かくした手順（ステップやタスクとも呼ばれます）。例として「先生を検索する」「プロフィールを見る」
3段目より下：それぞれの手順を実現する機能のアイデア（ユーザーストーリー）。上ほど優先度が高い

この3段の上の2段は、マップの「背骨」と呼ばれることがあります。使う人がサービスを最初から最後まで使う流れを表していて、ここが抜けていると、どれだけ機能を作っても使い物になりません。

マップには、もう1つ大事な線があります。横に引く「リリースの線」です。線より上が最初に出す範囲、線より下が次以降に回す範囲です。この線を引くことで、「全部が大事」という状態から、「最初はここまで」と決めた状態に変わります。

ユーザーストーリーとプロダクトバックログの基本

マップに並べる1枚1枚のカードを、ユーザーストーリーと呼びます。ユーザーストーリーとは、機能を「誰が、何のために、何をしたいか」という使う人の言葉で書いた短い文のことです。よく使われる書き方は次の形です。

「（使う人）として、（目的）のために、（したいこと）がしたい」

たとえば「保護者として、子どもに合う先生を選ぶために、指導できる科目で先生を絞り込みたい」と書きます。「検索機能を作る」と書くより、何のための機能か、どこまで作れば十分かが分かりやすくなります。

スクラムでは、作るものの候補をまとめた一覧を「プロダクトバックログ」と呼びます。スクラムの公式の手引きであるスクラムガイドの日本語版では、次のように説明されています。

プロダクトバックログは、創発的かつ順番に並べられた、プロダクトの改善に必要なものの一覧である。これは、スクラムチームが行う作業の唯一の情報源である。出典: scrumguides.org

ここでいう「創発的」とは、最初に全部が決まっているのではなく、作りながら新しい項目が生まれ、変わっていくという意味です。

プロダクトバックログは「順番に並べられた一覧」、つまり1本の縦の列です。一方、ユーザーストーリーマップは、その列を使う人の行動の流れに沿って横に広げたものだと考えると、関係が分かりやすくなります。マップで優先順位を決めたら、その順番でバックログに並べ直す、という使い方が一般的です。

一列のバックログだけだと何が困るのか：マップを作るメリット

機能の候補を一列に並べるだけでも、優先順位は付けられます。それでもマップを作る理由は、一列の一覧には見えにくい問題が3つあるからです。

1つ目は、全体の流れが見えないことです。一列の一覧では、「検索」「お気に入り登録」「決済」「通知」のように機能が並ぶだけで、使う人がどの順番でそれらを使うのかが分かりません。その結果、優先度の高い機能だけを作ったのに、途中の手順が抜けていてサービスとして使えない、ということが起きます。

2つ目は、最初に出す範囲が決めにくいことです。一覧の上から順に作っていくと、ある手順だけが作り込まれ、別の手順は手つかず、という偏りが出がちです。マップなら、行動の流れのすべての段に最低限のカードがそろっているかを、目で確かめられます。

3つ目は、関係者で話がかみ合いにくいことです。営業は「この機能がないと売れない」、開発は「この機能は手間がかかる」と、それぞれの立場から意見を出します。マップがあると、「この機能は使う人のどの行動を支えるのか」という共通の目線で話せるので、議論が整理されます。

マップの全体像については、先ほどの解説でも次のように述べられています。

ユーザーストーリーマップの特徴の一つは、その全体像から商品・サービスがユーザーにどのような体験を提供するかを把握しやすい点にあります。出典: lychee-redmine.jp

まとめると、マップを作るメリットは、使う人の体験を最初から最後まで見渡したうえで、最初に作る範囲を全員で合意できる点にあります。

作る前に準備するもの

ユーザーストーリーマップは、準備が半分と言っても大げさではありません。作り始める前に、次の4つをそろえておきます。

1つ目は、参加者です。サービスの方針を決める人、作る人、使う人の声を知っている人（営業やサポートの担当）の3つの立場がそろっていると、偏りのないマップになります。人数は4〜8人程度が話し合いやすい規模です。多すぎると意見がまとまらず、少なすぎると抜けが出ます。

2つ目は、ペルソナです。ペルソナとは、サービスを使う人を、年齢や状況、困りごとまで具体的に描いた人物像のことです。ペルソナの作り方について、ある解説では次のように説明しています。

はじめに、ペルソナを設定します。ペルソナとは、製品やサービスを実際に利用する顧客をイメージしたユーザー像のことです。〇〇会社の✕✕部の人、という風に、プロダクトを利用するユーザーがどのような属性なのかを想像でいるようなペルソナを設定します。ペルソナが複数いる場合は、複数洗い出したうえで、ペルソナごとのユーザーストーリーマップを作成します。出典: aslead.nri.co.jp

使う人が何種類もいるサービスでは、最初から全員分を作ろうとせず、一番大事な1人から始めるのが現実的です。

3つ目は、ゴールです。「このサービスで、使う人が何を達成できたら成功か」を1文で書いておきます。たとえば「保護者が、子どもに合う先生を見つけて初回の授業を予約できる」です。マップの右端は、このゴールにたどり着く地点になります。

付箋を使う場合は、色を段ごとに分けておくと見やすくなります。たとえば大きな行動は黄色、細かい手順は青、機能のアイデアは白、まだ答えの出ていない疑問はピンク、というように決めておくと、遠くからでもマップの構造が読み取れます。疑問の付箋は、会議の後で誰が調べるかを決めるときの手がかりにもなります。

4つ目は、道具と時間です。対面なら付箋と大きな模造紙かホワイトボード、オンラインならホワイトボードの機能を持つツールを用意します。時間は、初回なら2〜3時間を見ておくと、背骨からリリースの線まで一通り作れます。

ユーザーストーリーマップの作り方：6つの手順

準備ができたら、次の6つの手順で作っていきます。

手順1：ペルソナとゴールを全員で読み合わせる

最初に、準備したペルソナとゴールを全員で読み、認識をそろえます。ここを飛ばすと、参加者がそれぞれ別の人を思い浮かべてカードを書くことになり、後でまとまらなくなります。

手順2：使う人の大きな行動を左から右へ並べる

ペルソナがサービスを知ってからゴールにたどり着くまでの大きな行動を、付箋に書いて左から時間順に並べます。この段階では機能の話をせず、使う人の動詞で書くのがコツです。「会員登録画面」ではなく「登録する」と書きます。数は5〜10枚程度に収まることが多いです。

手順3：大きな行動を細かい手順に分ける

それぞれの大きな行動の下に、より細かい手順を並べます。「探す」の下に「科目で絞り込む」「プロフィールを読む」「口コミを見る」のように書きます。ここまでで背骨ができ上がります。背骨を左から右へ読み上げて、使う人の流れとして自然か、抜けている手順がないかを全員で確かめます。

手順4：手順ごとに機能のアイデアを縦に並べる

各手順の下に、その手順を実現するためのユーザーストーリーを書いて並べます。最初は優先度を気にせず、思いつく限り出します。1枚に1つのアイデアだけを書くことが大切です。

手順5：縦の並びを優先度の順に入れ替える

手順ごとに、カードを優先度の高い順に上から並べ直します。判断の基準は、後の「優先順位の決め方」の節で詳しく説明します。迷ったら「これがなかったら、使う人はこの手順を終えられないか」と問いかけます。

手順6：リリースの線を引いて最初の範囲を決める

最後に、横に線を引いて、最初のリリースに含めるカードを決めます。このとき、すべての手順の列に、線より上のカードが少なくとも1枚あるかを確かめます。どこかの列が空いていると、使う人はゴールまでたどり着けません。

最初のリリースに含める範囲は、MVPと呼ばれることがあります。MVPとは、使う人に価値を届けられる最小限の機能を持った製品のことで、少ない手間で出して反応を確かめるために作ります。

具体例：オンライン家庭教師の予約サービスで作ってみる

手順を、オンライン家庭教師の予約サービスに当てはめてみます。ペルソナは「小学5年生の子どもを持ち、算数の苦手を家で補いたい共働きの保護者」、ゴールは「子どもに合う先生を見つけて、初回の授業を予約できる」とします。

大きな行動	知る	探す	予約する	受講する	支払う
細かい手順	サービスを知る	科目で先生を絞り込む	空いている日時を選ぶ	ビデオ通話に入る	料金を確かめて払う
最初のリリース	紹介ページ	科目と学年での絞り込み	日時の選択と確認メール	通話へのリンクの案内	カード払い
次のリリース	体験談のページ	口コミの表示	予約の変更と取り消し	授業の録画	月ごとの請求書
その次以降	紹介の特典	相性の診断	定期予約	宿題の共有	兄弟の割引

表を見ると、最初のリリースは、どの列にも最低限の機能がそろっています。口コミの表示や授業の録画は魅力的な機能ですが、なくても「先生を見つけて予約し、授業を受ける」というゴールにはたどり着けます。そのため、次のリリースに回しています。

この例で分かるように、マップの価値は「作らないものを決められる」点にあります。機能を出し合う段階では、どのアイデアも良く見えます。行動の流れに沿って並べ、ゴールにたどり着くために本当に必要なものだけを線の上に残すことで、限られた時間と予算で出せる範囲が決まります。

優先順位の決め方：迷ったときの3つの物差し

手順5で優先度を決めるとき、話し合いが長引く原因の多くは、物差しがそろっていないことです。次の3つの物差しを使うと、判断がぶれにくくなります。

1つ目は、使う人にとっての価値です。「この機能がないと、ゴールにたどり着けないか」「あると、使う人の手間がどれだけ減るか」を考えます。ゴールに必須の機能は上、あると便利な機能は下です。

2つ目は、作る手間です。同じくらいの価値なら、手間の小さいものを先に作ります。開発の担当者に、カードごとの手間を「大・中・小」の3段階で付けてもらうだけでも、判断の材料になります。

3つ目は、つながりです。ある機能を作るには、先に別の機能ができている必要がある、という関係があります。たとえば「予約の変更」は「予約」ができてからでないと作れません。つながりのあるカードは、元になるカードより上に来ないように並べます。

物差しをそろえる方法として、「必須」「できれば」「今回は見送り」の3つに分けてから、それぞれの中で順番を付ける方法も使えます。いきなり1位から順に並べるより、まず大きく3つに分けたほうが合意しやすくなります。

優先順位は、一度決めたら終わりではありません。最初のリリースを出して使う人の反応を見たら、マップに戻って線の位置を引き直します。マップは計画書ではなく、学んだことを反映し続ける地図です。

ユーザーストーリーの書き方を良くする6つの確認点

マップに並べるカードの質は、そのまま優先順位の決めやすさにつながります。カードを書き終えたら、次の6つの点で見直すと、話し合いが進めやすくなります。英語の頭文字を取って「INVEST」と呼ばれる確認の観点です。

独立している：ほかのカードと切り離して、単独で作れて並べ替えられる
話し合える：細かい作り方まで決めつけず、作る人と相談する余地が残っている
価値がある：使う人にとって意味のある変化を生む。作る側の都合だけの作業になっていない
見積もれる：作る人が、だいたいの手間を見積もれる程度に中身がはっきりしている
小さい：1回の作業の区切りの中で作り終えられる大きさになっている
確かめられる：できたかどうかを判断する条件が書ける

6つ目の「確かめられる」を満たすために、カードには「受け入れ条件」を書き添えます。受け入れ条件とは、そのカードが完成したと言えるための具体的な条件のことです。たとえば「科目で先生を絞り込みたい」というカードなら、次のように書きます。

算数、国語、英語、理科、社会の5科目から1つ以上を選べる
選んだ科目を指導できる先生だけが一覧に出る
該当する先生がいないときは、その旨と、条件を変える案内が出る

受け入れ条件があると、作る人は迷わずに作業を進められ、頼む人は完成したかどうかを同じ基準で確かめられます。マップを作る会議の場ですべてのカードに書く必要はありません。リリースの線より上に来たカードから順に書き足していけば十分です。

マップからバックログと作業の計画へつなぐ

リリースの線を引いたら、マップを日々の作業の計画に落とし込みます。ここでつまずくと、せっかく作ったマップが壁に貼られたまま使われなくなります。

最初にするのは、線より上のカードを、作る順番に一列に並べ直すことです。並べ方の基本は、マップの左から右へ、つまり使う人の流れの順に、各列の一番上のカードを先に並べることです。こうすると、どの段階でも、使う人が最初から最後まで通して使える状態に早く近づきます。この一列が、スクラムでいうプロダクトバックログになります。

次に、作業の区切りを決めます。スクラムでは、1か月以内の決まった長さの期間を「スプリント」と呼び、その中で作るものを決めて作業します。小さなチームなら、1〜2週間を1つの区切りにすると、進み具合を確かめる機会を多く持てます。区切りごとに、バックログの上からいくつのカードを作れるかを、作る人が見積もって決めます。

区切りが終わるたびに、できたものを関係者で見て、マップに戻ります。作ってみたら思ったより手間がかかった、使う人に見せたら別の機能を求められた、といった学びを、カードの並びと線の位置に反映します。この「作る、見せる、マップに戻る」の繰り返しが、マップを生きた地図として保つ方法です。

計画の段階で大切なのは、マップとバックログのどちらか一方だけを見ないことです。日々の作業はバックログで、全体の流れと次の範囲はマップで確かめる、と役割を分けると、目の前の作業に追われて全体を見失うことを防げます。

オンラインでマップを作るときの進め方のコツ

参加者が離れた場所にいて、オンラインでマップを作る場面も増えています。対面より話し合いの勢いが出にくいので、進め方を少し工夫します。

1つ目のコツは、事前の準備を厚くすることです。ペルソナとゴール、背骨の案を、会議の前日までに共有しておきます。会議の時間は、背骨を確かめることと、機能のアイデアを出し合うことに集中できます。

2つ目のコツは、書く時間と話す時間を分けることです。オンラインでは、全員が同時に話し始めると聞き取りにくくなります。「5分間、各自で黙ってカードを書く」「その後、1人ずつ自分のカードを説明する」という流れにすると、発言の少ない人の意見も拾えます。

3つ目のコツは、進行役と記録役を分けることです。進行役は話し合いの流れと時間を見て、記録役はカードの並べ替えや重複の整理を担当します。1人で両方を受け持つと、どちらかがおろそかになります。

4つ目のコツは、休憩を必ず入れることです。画面を見続ける作業は、対面より疲れが早く来ます。1時間ごとに10分程度の休憩を入れ、合計の時間も対面より短めに区切って、2回に分けて作るほうが、最後まで質を保てます。

よくある失敗と直し方

ユーザーストーリーマップを作るときに、よく見られる失敗と、その直し方を整理します。

失敗の1つ目は、背骨を機能の名前で書いてしまうことです。「ログイン画面」「検索画面」「決済画面」と並べると、作る側の目線の一覧になり、使う人の流れが見えなくなります。直し方は、すべての付箋を「使う人の動詞」で書き直すことです。「ログインする」ではなく、使う人の目的に近い「続きから見る」のように書けると、さらに良くなります。

失敗の2つ目は、カードの大きさがばらばらなことです。「決済機能を作る」という大きなカードと、「ボタンの色を変える」という小さなカードが同じ段に並ぶと、優先順位を比べられません。大きすぎるカードは、使う人の目線で2〜3枚に分けます。

失敗の3つ目は、リリースの線を引かずに終わることです。カードを出し合って満足してしまい、最初に作る範囲を決めないまま会議が終わる、という例は少なくありません。その日のうちに、仮でもよいので線を引いておくことが大切です。

失敗の4つ目は、作ったマップを誰も見返さないことです。会議の後に写真を撮って共有しただけでは、開発が進むにつれて現実とずれていきます。マップのカードを、日々の作業を管理する場所に移し、進み具合と一緒に見られるようにしておく必要があります。

ソフトウェア以外にも使える：社内の手続きやイベントの設計

ユーザーストーリーマップはソフトウェア開発の道具として生まれましたが、考え方そのものは、使う人がいて、手順があるものなら何にでも使えます。たとえば、社内の新しい手続きや、お客様向けのイベントの設計です。

社内の経費精算の手続きを見直す場面を考えてみます。使う人は「出張から戻った営業担当者」、ゴールは「立て替えた交通費を、月末までに迷わず精算できる」とします。大きな行動は「領収書を受け取る」「申請する」「上司が確かめる」「経理が確かめる」「振り込まれる」と並びます。それぞれの手順の下に、「領収書を写真で残せる」「申請の書き方の見本が見られる」「差し戻しの理由が分かる」といったアイデアを並べ、最初に変える範囲に線を引きます。

お客様向けのセミナーなら、大きな行動は「知る」「申し込む」「参加の準備をする」「参加する」「参加した後」です。案内のメール、申し込みの受付、当日の入室の案内、終了後のアンケートと資料の送付といった施策を各列に並べると、手薄な段階が一目で分かります。申し込みの案内には力を入れているのに、参加した後のフォローが何もない、といった偏りに気づけます。

ソフトウェア以外で使うときも、コツは同じです。背骨を「使う人の動詞」で書くこと、各列に最低1枚のカードがそろうように線を引くこと、そして実際に試した後でマップに戻って見直すことです。部署の業務改善の会議で、いきなり改善策を出し合う前に背骨だけを描いてみると、議論の焦点が定まりやすくなります。

マップをチームで共有する道具の選び方

ユーザーストーリーマップを作る道具は、大きく分けて3つあります。

1つ目は、付箋とホワイトボードです。全員が同じ部屋に集まれるなら、最も手軽で、議論も活発になります。弱点は、会議の後に残しにくいことと、離れた場所の人と共有できないことです。

2つ目は、オンラインのホワイトボードです。付箋を自由に並べられるので、マップを作る作業そのものに向いています。離れた場所の人とも同時に作業できます。一方で、カードに担当や期限を付けて、日々の進み具合を追う用途には向かないことがあります。

3つ目は、表計算ソフトです。列を大きな行動、行を優先度に見立てれば、マップの形を作れます。誰でも使える点が強みですが、カードを入れ替えるたびにセルを動かす手間がかかります。

マップを作った後、カードを実際の作業として担当と期限を付けて進めたい場面では、プロジェクト管理の道具に移すのが一般的です。その候補の1つがPinatecaです。公式サイトによると、カンバン、ガントチャート、カレンダー、リスト、ディスカッション、グリッド、時間割、リソースの8種類のボードを、無料プランから使えます。グリッドボードは縦横2軸のマトリクスにカードを並べる種類のボードで、横に使う人の行動、縦にリリースを取れば、マップに近い形でカードを並べられます。カードには担当と締切を付けられ、優先度や見積もりの手間のような項目を、カスタムフィールドとして自由に追加できます。

料金は、公式の料金ページによると、5人まで、ボード10個までなら無料です。6人目または11個目のボードからはスタンダードプランになり、1人あたり月額500円（税抜、年払いなら1人あたり月額400円）です。カードごとのコメントと、ワークスペースごとのチャットが内蔵されているので、カードの優先度を変えた理由を、そのカードに残しておけます。

Pinatecaは、@SOHOを運営する株式会社ライフスケープが開発・提供しています。

なお、Pinatecaにユーザーストーリーマップ専用のひな形があるわけではありません。マップの考え方で並べたカードを、日々の作業として進める場面で使う道具です。

開発を外部に頼むときにもマップが役立つ

自社に開発の担当者がいない場合、サービスの開発を外部の会社やフリーランスに頼むことになります。このとき、ユーザーストーリーマップは、頼む側と受ける側の認識をそろえる資料として大きな力を発揮します。

機能の一覧だけを渡して見積もりを頼むと、受ける側は一覧にない部分を推測で補うしかなく、見積もりの幅が大きくなります。マップがあれば、使う人の流れと、最初のリリースの範囲が一目で伝わるので、見積もりの精度が上がり、後からの食い違いも減ります。

アジャイル開発を外部に頼むときの契約については、情報処理推進機構（IPA）が情報システム・モデル取引・契約書（アジャイル開発版）を公開しています。IPAのページでは、頼む側と受ける側が、開発に着手する前にアジャイル開発について適切な理解を持っていることを確かめ、期待を共有しておくことの大切さが示されています。このモデル契約は、アジャイル開発の手法としてスクラムを採用した前提で作られています。

アジャイル開発では、最初にすべての仕様を決めないので、「何を作るか」を頼む側と受ける側が一緒に決め続ける必要があります。その話し合いの土台になるのが、ユーザーストーリーマップとプロダクトバックログです。契約の前にマップを一緒に作るだけでも、相手がこの進め方に慣れているかどうかが分かります。

マップを作れる人に頼まれる仕事と、運営者として見てきたこと

ユーザーストーリーマップを作り、優先順位を整理できる力は、開発やデザインの仕事で重宝されます。使う人の流れを考えられる人は、作る人と頼む人の間をつなぐ役を任されやすいからです。

アプリケーション開発のお仕事では、Webアプリやスマートフォンのアプリを作る仕事の内容と進め方を紹介しています。開発の受け手がマップを読めると、頼む側との話し合いがずっと早く進みます。業務の流れを整理してAIで省力化する提案をするAIコンサル・業務活用支援のお仕事でも、使う人の行動を順番に並べる考え方はそのまま使えます。

画面の設計や体験の設計に関わるなら、デザイナーの年収・単価相場も参考になります。使う人の流れから画面を考えられるデザイナーは、見た目だけを整えるデザイナーより、上流の工程から関わる機会が多くなります。働く場所の自由度を高める制度の情報としては、テレワーク助成金 2026で、テレワークの導入に使える助成金をまとめています。マップの共同作業をオンラインで行うチームにとっても、環境を整えるきっかけになります。

在宅ワークとフリーランスの仲介を2004年から続けてきた運営者として見てきた限りでは、開発の依頼でもめる原因の多くは、技術の問題ではなく「どこまで作るか」の食い違いです。最初に使う人の流れと最初の範囲を一緒に決めてから着手した依頼は、途中で話がこじれにくく、次の依頼にもつながりやすい傾向があります。受け手の側から「まずマップを一緒に作りませんか」と提案できる人は、それだけで頼む側の安心感が違います。

依頼する側と受ける側が直接やり取りできると、話し合いの回数を重ねやすくなります。手数料0%で直接取引できる形なら、間に入る費用がない分、同じ予算で頼む側は話し合いや手直しの時間を確保しやすく、受け手は手取りが厚くなります。マップを何度も引き直すアジャイルの進め方とも相性のよい関係です。

よくある質問

Q. ユーザーストーリーマップは、開発の経験がなくても作れますか？

作れます。マップに並べるのは、使う人の行動と、その行動を助ける機能のアイデアなので、技術の知識は必要ありません。むしろ、使う人の困りごとをよく知っている営業やサポートの担当者が加わると、抜けの少ないマップになります。作る手間の見積もりだけは、開発の担当者に付けてもらうと優先順位を決めやすくなります。