EN 日本語

2026 年 8 月 14 日

GitHub Projects だけでストーリーマッピングをやる

ストーリーマップは、専用の道具がなくても GitHub Projects だけでかなりの所まで組めます。ステップをボードの列に、リリースを横のレーンにします。実際の手順と、行き詰まる場所を 3 つ書きます。

ストーリーマップとは何か

考案したのは Jeff Patton です。2008 年のエッセイ The new user story backlog is a mapで、縦に一列に並んだだけのバックログを利用者の行動の流れに沿って並べ直すやり方として提案し、のちに一冊の本 User Story Mappingにまとめました。日本語では「ユーザーストーリーマッピング」の題でオライリー・ジャパンから出ています。この記事では、その形を GitHub Projects の中に作っていきます。

課題の一覧で分かるのは、あと何が残っているかです。ストーリーマップで分かるのは、次のリリースで利用者に何ができるようになるかです。形は 1 枚の表です。いちばん上に並ぶのがジャーニー、つまり利用者がやりたいことで、「商品を探す」「注文する」「受け取る」といった単位です。その下に並ぶのがステップで、「商品を探す」の下なら「検索する」「比較する」になります。さらにその下に課題が並びます。そして全体を横に貫くのが、リリースごとの行です。

効くのは行です。1 行を左から右へ読むと、そのリリースで何が通しでできるようになるかが分かります。行の途中が空いていれば、そのリリースでは最後まで届かないジャーニーがあると、ひと目で気付けます。課題が 80 件並んだ一覧では、同じ穴は見えません。

手順 1 — Project にフィールドを 2 つ足す

Project を開き、フィールドの見出しの右端にある + を押します。Settings の Fields からでも同じです。単一選択 (single select) のフィールドを 2 つ作ります。

この並び順は見た目の問題ではありません。GitHub はこの順をそのままボードの列の順に使います。並び順はあとから変えても大丈夫です。フィールド側で選択肢を並べ替えても、課題に入っている値はそのまま残ります。ただし、ボードの列を掴んで動かすことはできません。利用者が最初にすることから最後にすることまで、読みたい順に並べておいてください。なお単一選択の選択肢は 50 個までなので、これがマップに置けるステップ数の上限です。

手順 2 — 値を入れる

Table 表示に切り替え、いま作った 2 列を出して、課題ごとに値を入れます。複数行を選んでまとめて設定できるので、100 件の Project でも半日ではなく 10 分ほどで終わります。

Step が空のままの課題があっても構いません。まだマップに載せていない積み残しは、どの現場にも必ずあります。

手順 3 — 行はマイルストーンで作る

行には独自フィールドではなく、GitHub のマイルストーンを使ってください。マイルストーンは Project ではなくリポジトリに属するので、Project を作り直しても消えません。課題そのものにも表示されますし、もとから付いている進捗バーが、そのままリリースの進み具合を示すようになります。それぞれに期日を入れておきます。

手順 4 — ボードを組む

新しいビューを作り、表示を Board にします。ビューのメニューで次の 2 つを設定します。

見落とされやすいのは 2 つ目です。ボードのグループ化は並べ替えではなく、横のレーンへの分割です。列がステップ、レーンがリリース、交わったマスに課題が入ります。いま持っている課題だけで、ストーリーマップの表ができあがります。

必要なら Slice by → Journey も足せます。ジャーニーが左側の一覧に出て、選ぶとそのジャーニーだけに絞り込めます。

ここまでで手に入るもの

カードを掴んで動かせる、本物の表です。動かしているのは写しではなく課題そのもので、レーンをまたげばマイルストーンが変わり、列をまたげば Step が変わります。複製は生まれず、同期も要らず、リポジトリを見られる人は全員同じものを見ます。

小さい製品なら、これで足ります。かかるのは上の 20 分だけです。ここで止めても、縦一列の課題一覧を眺めていた頃よりずっと見通しはよくなっています。

どこで行き詰まるか

3 つあります。困る順に並べます。

1. リリースの行を、望む順に並べられない

マイルストーンでグループ化したボードでは、レーンの順を自分で決められません。GitHub 自身がこの表示順は並べ替えられないと認めています。だから 1.1 が 1.0 の上に来ることも、来期が今週の上に来ることもあります。

地味に見えて、これがいちばん重い制約です。ストーリーマップが成り立つのは、いちばん上の行が次のリリースで、下に行くほど先の話、という約束があるからです。順が成り行きで決まると、行は順序ではなくただのラベルになります。どれが先に出るのかという、マップが答えるはずだった問いが画面から消えてしまうのです。

2. ジャーニーは帯ではなく、絞り込みになる

Slice by で見えるのは、一度に 1 つのジャーニーだけです。しかしストーリーマップを描く動機は、製品の全体を一度に眺めて、誰も手を付けていないジャーニーに気付くことにあります。1 つずつ見るのでは、抜け出したかったはずの状態に戻るだけです。短くなっただけで、結局はただの一覧です。

回避策はあります。ステップの選択肢の名前に、ジャーニーを頭に付けてしまう方法です。探す: 検索、探す: 比較、注文: カートのようにすると、ジャーニーが列の見出しに残り続け、同じジャーニーのステップが自然に隣り合います。代償は 2 つ。列の見出しにジャーニー名が毎回並ぶことと、ジャーニーを改名したら選択肢を 1 つずつ手で直すことです。

3. ソートと優先順は両立しない

ステップの中でのカードの並びには意味があるはずです。上にあるものほど先に作る、という優先順です。ところが GitHub の文書には、ソートを掛けたボードでは列の中を手で並べ替えられないと明記されています。ソートを取るか、手で決めた優先順を取るか。両方は選べません。

新しい Hierarchy view はどうか

GitHub は 2026 年 3 月にHierarchy viewを正式版にしました。新しいビューでは既定で有効です。サブ課題を 8 階層まで入れ子で表示でき、入れ子を保ったままグループ化も絞り込みもソートもできます。ジャーニーとステップをフィールドではなく親課題として表すなら、ストーリーマップの 3 階層は本物の階層になります。

ただし、ボードの代わりにはなりません。Hierarchy view が使えるのは Table 表示だけで、ボードにもロードマップにも出せないからです。階層を取るか、縦横の盤面を取るか。1 つのビューで同時には使えません。GitHub は階層を Table に、縦横の 2 軸を Board に、別々のビューとして持っています。ストーリーマップに要るのは、その両方が同時にある画面です。

それでもやる価値はあるか

あります。ジャーニーが 1 つか 2 つ、動いているリリースが 2 つか 3 つの規模なら、行の順が決められなくても大して困りません。順番くらい頭に入っているからです。かかる手間もせいぜい半日です。

足りなくなるのは、そのマップを他人に見せたくなった時点です。レーンの順は無視してください、1.0 は真ん中のやつです、と説明しないと読めないマップは、マップの仕事をしていません。

私が作ったもの

この 3 つには、私も自分の製品で全部ぶつかりました。結局 2 週間おきにホワイトボードへ描き直しては、変更点を GitHub に手で打ち直していました。その往復をなくすために作ったのが Fervio です。既存の GitHub Project を読んで、同じ課題をストーリーマップとして並べます。ジャーニーは上の帯に出て、リリースの行は期日順に並びます。カードを動かすと、本物の課題とマイルストーンが書き換わります。ベータ期間中は無料で、コードは読みません。何に触るかは権限のページに全部書いてあります。

とはいえ、まずは上の 4 つの手順を試してみてください。それで足りるなら道具を増やさずに済んだのですから、それに越したことはありません。