issueトラッカーから作る三列の公開ロードマップ

公開ロードマップとは、顧客が見られる場所に公開された、あなたが構築しようとしているものの一覧だ。仕事をしている言葉は意図するだ。ロードマップとは未来についての一連の約束であり、そこにある項目のそれぞれは、守られるか、守られなかったと見なされるかのどちらかになる。それこそがロードマップを公開する理由であり、同時に、ほとんどの公開ロードマップが四半期のうちに古びてしまう理由でもある。生き残るバージョンは小さく、すでに維持しているデータから導出され、その先の端でチェンジログに接続されており、誰かがそれを再入力することなく約束が事実に変わっていく。

公開ロードマップは何のためにあるのか

公開ロードマップは、依頼を持つ顧客に、その依頼が出荷される前にすでに聞き届けられていたことを伝える。それはループを閉じることの前半にあたる。「計画済み」は「誰かがこれを読んだか」という問いに答え、「構築中」は「実際に起きているのか」という問いに答える。どちらも最後のステップ、つまり出荷されたときに依頼者に伝えることの代わりにはならないが、両方とも、その間に尋ねてくる人の数を減らしてくれる。

それはチームのためにも一つのことをしてくれる。公開のコミットメントを強制することであり、それは誰も作らない四百個の項目を静かに抱え込んだバックログに対する、知られている中で最も安価な治療法だ。

固定された順序での三つの列で十分だ。四つ目の列（「検討中」「レビュー待ち」「バックログ」）は、善意が博物館になっていく場所であり、顧客が最初に無視することを学ぶ列でもある。

ロードマップを公開すべきか

小さく正直に保てるなら公開しよう。その代替が「かもしれない」の長いリストなら非公開にしておこう。公開ロードマップのコストは公開すること自体とは関係がない。そこにあるすべての項目は今や、サポート、営業の電話、更新の会話の中で誰かが尋ねてくる問いになる。あなたが構築する十個の項目は資産だ。あなたが構築するかもしれない六十個の項目は、なぜやらなかったのかについての六十回の未来の会話だ。

公開しない正直な理由が二つある。あなたの計画が四半期より速く変わる場合、あるいは競合他社が顧客よりも注意深くあなたのロードマップを読んでいる場合だ。どちらも現実的であり、どちらにも、何も公開しないことではなく、より少なく公開することで答えられる。「構築中」だけを公開し、「計画済み」は社内に留めておいても、依頼者に自分のissueが動いていることは伝わる。

GitHubのissueからどうやって公開ロードマップを構築するか

すでに追跡しているissueに列ごとのラベルを付け、ラベル付きのissueをロードマップとしてレンダリングしよう。何も再入力する必要はなく、ロードマップが実際の作業からずれることはなく、顧客の依頼として始まった同じissueが、アイデンティティを変えることなく列を移動していく。

私たちが実行している仕組みはこうだ。

1. 列ごとに一つのラベル、固定されたプレフィックス付き：roadmap:planned、roadmap:building、roadmap:shipped。接続されたリポジトリの中でこれらのいずれかを持つissueは、その列に現れる。どれも持たないissueはロードマップに載らない。それがほとんどのissueであり、それは正しい。
2. 列は常に同じ順序の配列だ。 計画済み、構築中、出荷済み。名前をキーとするマップではないため、読み手（あるいはウィジェット)が順序を推測する必要は一度もない。
3. issueが二つのラベルを持つ場合、最も進んでいる方が勝つ。 誰かがroadmap:plannedを外す前にroadmap:shippedを追加することもあるだろう。「最後に届いたウェブフックがどちらか」で動く状態機械は、イベントの到着順によって項目を異なる列に置いてしまう。ラベルの集合だけから決めることで、イベントがどんな順序で届いても答えは同じになる。
4. 出荷済みは、他と同じくラベルの状態だ。 issueにroadmap:shippedが付いたとき、またはそのラベルが付いたままクローズされたときにカードが移動する。カード自体はチェンジログの項目にリンクしない。詳細が載るのは、issueをクローズしたpull requestから下書きされた項目のほうだ。
5. データとして提供する。 ロードマップはこの三つの列を持つJSONドキュメントであり、チェンジログのフィードと同じキャッシュヘッダーとともに公開される。そうすればドキュメントサイト、ウィジェット、ステータスページは、二つ目の統合を作ることなくそれをレンダリングできる。フィードのドキュメントが正確な形を示している。

ラベル一つはメンテナーに求めるものとしては小さく、それが統合のすべてだ。同期を保つべきボードもなく、ログインすべき別のツールもなく、顧客がファイルした依頼こそがロードマップ上の項目であり、それが出荷されたときも、同じ項目のままだ。

公開ロードマップに含めるべきでないものは何か

日付、見積もり、そして九か月後に尋ねられて困るようなものは含めるべきではない。日付は典型的な間違いだ。ロードマップ上の四半期は営業資料の中でコミットメントになり、それは「あなたはQ3と言った」というタイトルのチケットになる。列で十分に伝わる。「構築中」はすでに「誰かが取り組んでいるくらい近い」を意味している。

社内のバックログも含めるべきではない。三百個の項目を持つロードマップは約束ではなく検索の問題であり、自分の依頼が212番目にあるのを見つけた顧客は、あなたが伝えるつもりのなかったことを学んでしまう。

ロードマップはチェンジログとどうつながるか

ロードマップとチェンジログは、同じissueを二つの側から記述するものであり、一方は未来のため、もう一方は過去のためだ。別のボードでカードを動かす人はいない。メンテナーはすでに作業しているissueのラベルを変え、項目はpull requestから下書きされ、人間がその項目を承認すると、ウィジェットからのフィードバックがそのissueになった依頼者は、そこで知らされる。カードを出荷済みに動かすのは依然として独立したステップ、つまりroadmap:shippedラベルなので、同じレビューの一部にしよう。項目を承認しても、それは代わりに行われない。

これはフィードバックループの記事がチェンジログ側から説明しているのと同じループであり、ロードマップはその途中で顧客が目にするものだ。チェンジログツールのまとめは、どの製品がロードマップビューを提供し、どれを別のボードとして扱っているかを取り上げている。それこそが、それが正確であり続けるかどうかを決める違いだ。

良い公開ロードマップとはどんなものか

短く見え、そこにあるすべての項目が誰かが開けるissueである。テストは、顧客がある項目からその背後にある議論へ、そして出荷済みの項目から実際に何が変わったかを説明する項目へと辿れるかどうかだ。入り口のない機能名の一覧であるロードマップはパンフレットにすぎない。

ウィジェットが取得するJSONとしての具体例を挙げよう。

{
  "columns": [
    { "column": "planned", "hasMore": false, "items": [
      { "id": "6b0c1f...", "column": "planned",
        "publicTitle": "Saved views on the inbox",
        "publicDescription": "Keep a filter you use often and come back to it.",
        "publishedAt": "2026-09-16T10:04:11.000Z" }
    ]},
    { "column": "building", "hasMore": false, "items": [
      { "id": "71a4e2...", "column": "building",
        "publicTitle": "Roadmap column in the widget",
        "publicDescription": "See what is coming without leaving the page.",
        "publishedAt": "2026-09-12T08:20:02.000Z" }
    ]},
    { "column": "shipped", "hasMore": false, "items": [
      { "id": "5c9d70...", "column": "shipped",
        "publicTitle": "Feedback filed as labelled issues",
        "publicDescription": "Widget submissions arrive as issues your triage already handles.",
        "publishedAt": "2026-09-02T15:41:37.000Z" }
    ]}
  ],
  "enabled": true,
  "language": "en"
}

三つの列にわたる三つの項目は、それだけで十分に良い公開ロードマップだ。何が来るのか、何が起きているのか、何が起きたのかを述べており、そのすべての行が確認可能だ。ナウ・ネクスト・レイターから成果ベースまで、ほかの5つのレイアウトは、サンプルの項目とともにプロダクトロードマップの例で示している。

FAQ

公開ロードマップにはいくつの項目があるべきか? 擁護できる範囲でできるだけ少なく。小さな製品であれば全列合わせて十未満が普通であり、「計画済み」に三十以上あるのは、ロードマップの衣をまとったバックログだ。

公開ロードマップに日付を入れるべきか? いいえ。列は締め切りを作らずに順序を伝える。顧客が日付を必要としているなら、それはロードマップの項目ではなく会話の話題だ。

顧客はロードマップの項目に投票すべきか? 投票は何が重要かではなく、誰が現れたかを測定してしまう。今日使っている回避策を説明するissueへのコメント一つの方が、五十票よりも価値があり、それは投票者に何かを費やさせるという点が重要だ。

キャンセルされたロードマップの項目はどうなるか? ラベルを外し、理由をissueで述べよう。公開の場での「これは行わない」はループの一部であり、それはほとんどのチームが決して送らないメッセージだ。

この記事の技術的な記述は第三者による確認を受けていません。誤りがあればお知らせください。修正します。

changeloopの関連ページ： 開発者向けドキュメント, changelogツール比較