こんにちは！開発チームのベロシティを極限まで高めるアジャイルコーチの先輩です。
日々、Jiraの重さに絶望したり、Slackの流れていくメッセージの海に重要な顧客要望を沈めてしまったりしていませんか？「顧客の声をもっとプロダクト開発に直結させたい」「俺たちが作っている機能が、本当にユーザーに届いているというライブ感を共有したい」――そんなプロダクト開発の悩みを一撃で解決してくれるのが、今回紹介するLinear（リニア）の「Public Roadmap（パブリック・ロードマップ）機能」です。
Linearといえば、エンジニアの間で「最高にモダンで爆速な課題管理ツール」として知られていますよね。でも実は、外部のユーザーやステークホルダーを巻き込むための強力な武器も隠し持っています。
今回は、初心者の方でも迷わず実装できるように、Linearのロードマップ公開から顧客フィードバックの回収、そして感動のリリース通知までの裏技的ワークフローを、優しく丁寧に解説していきます。これをマスターすれば、あなたのチームとユーザーの距離が一気に縮まり、開発のモチベーションが爆発的に上がりますよ！
—
1. Public Roadmap機能の有効化と公開範囲の設定手順
まずは、Linearの要塞から外部へ向けて「窓」を開く作業から始めましょう。
LinearのPublic Roadmapは、単なる「予定表」ではありません。開発チームの現在地と未来を美しく可視化し、プロダクトの透明性を担保するための最強のインターフェースです。
1-1. なぜLinearのロードマップなのか？
従来のツールでは、スプレッドシートを手動で更新したり、専用のロードマップツールとJiraを行き来したりと、二重管理の地獄が待っていました。Linearなら、普段エンジニアがイシュー（タスク）を動かしている「ステータス」とロードマップが完全に直結しています。手動更新ゼロ、嘘をつかないロードマップが作れるのです。
1-2. 有効化のステップ（迷子にならないための道案内）
1. ワークスペースの設定へ移動する
Linearのサイドバー左下にあるワークスペース名をクリックし、「Settings（設定）」を開きます。
2. Public Roadmapのメニューを探す
サイドバーの「Workspace」セクションにある 「Public roadmap」 をクリックします。
3. 公開のスイッチをオンにする
「Enable public roadmap」のトグルをONにします。これだけで、あなた専用の公開URL（例: `linear.app/your-team/roadmap`）が生成されます。
1-3. 公開範囲と見せ方の極意
初心者がつまずきやすいのが、「開発中の未完成なタスクまで全部見えてしまうのでは？」という不安です。ご安心ください。Linearでは、どのプロジェクトをロードマップに載せるかを完全にコントロールできます。
- マイルストーンの整理:
ロードマップに載せるプロジェクトには、必ず `Q3リリース` や `AI機能強化` といった分かりやすいプロジェクト名をつけましょう。
- ステータスのマッピング:
外部に見せるステータスは、「Planned（予定）」「In Progress（進行中）」「Completed（完了）」の3つにシンプルに絞るのが、ユーザーを混乱させないコツです。
—
2. 顧客からの要望（Feature Requests）をスムーズにLinearのTriageへ取り込む仕組みづくり
ロードマップを公開したら、次に起きる魔法は「ユーザーからの要望の殺到」です。「この機能が欲しい！」「ここを直して！」という声が、ロードマップのページ経由で集まり始めます。
ここで情報のサイロ化を防ぐのが、Linearの「Triage（トリアージ）」機能です。
2-1. Triage機能という名の「優秀な受付係」
外部から入ってきた要望やバグ報告は、いきなり開発スプリントのバックログに突っ込んではいけません。カオスになります。
LinearのTriageは、いわば「開発チームへの荷物を一旦受け取るロビー」です。
- 仕組みの流れ:
1. ユーザーがパブリックページからフィードバックを送信する。
2. そのデータが自動的にLinearの指定チームの「Triage」受信箱に飛んでくる。
3. プロダクトマネージャー（PdM）やテックリードが、それを「採用（Accept）」「拒否（Decline）」「既存イシューと重複（Duplicate）」に仕分けする。
2-2. 精度を高めるための「HelloWorld」的セットアップ
実際にフィードバックを受け付けるフォームと、Triageの連携を確認してみましょう。
1. フィードバック受信用チームの作成
Linear内で `Customer Feedback` という専用のチームを作るか、既存のプロダクトチームのTriage機能を有用します。
2. インテグレーション（Slack連携など）の設定
`Settings > Integrations` から Slack や Linear公式のAPI連携を有効にし、「新しいフィードバックがTriageに入ったら、#feedback チャンネルに通知する」ように設定します。
3. 動作確認（HelloWorld）の儀式
実際に自分のパブリックロードマップページを開き、テスト用の機能要望（例: 「ダークモードの色味をもう少し優しくして」）を送信してみましょう。
数秒後、LinearのTriage受信箱にピカピカの新しいイシューとして着弾していれば成功です！
[ユーザー]
↓ (パブリックロードマップから要望送信)
[Linear Public Page]
↓ (自動ルーティング)
[Linear Triage受信箱] ← ★ここでチームがトリアージ（精査）
↓ (「Accept」ボタンを押す)
[開発バックログ（Backlog）へ昇格！]
このフローを確立するだけで、「あの顧客の要望、どこだっけ？」というSlackの過去ログ漁りから解放されます。
—
3. ユーザーへの完了通知（Release Notes連携）までの自動化ワークフロー
さて、顧客の要望をトリアージし、エンジニアがコードを書き、PRをマージして、ついに機能がリリースされました！
ここで多くのチームがやりがちなのが、「作ったのに、ユーザーに伝えていない」というもったいないミスです。
ユーザーエンゲージメントを最高潮に高める最後のピースは、「完了通知の自動化」です。
3-1. ステータス「Done」が魔法をかける
Linearでは、イシューのステータスが `Done` に変わった瞬間、あるいはプロジェクトが完了（Completed）した瞬間に、外部のユーザーへシグナルを送ることができます。
3-2. ラベルとRelease Notesの連動テクニック
リリースノートを自動化・半自動化するための極意は、「ラベル（Labels）」のルール決めです。
1. 専用ラベルの作成
`Release Notes` や `Customer Facing` というラベルを定義します。
2. ワークフローの運用
ユーザーから要望があったイシュー（Triageから昇格したもの）や、ユーザーに告知すべき改善には、必ずこのラベルを貼るルールをチームで徹底します。
3. Changelog / Release Notes ツールとの連携
LinearのWebhook機能や、Zapier、あるいは Linear公式の連携機能（※類似のChangelogツールなど）を使い、`Release Notes` ラベルがついたイシューが `Done` になった瞬見、そのタイトルと説明文を自動で外部向けChangelogに下書き保存するワークフローを組みます。
> 💡 先輩エンジニアからの現場の知見:
> 「リリースノートを書くのめんどくさい問題」は、エンジニアに文章を書かせるのではなく、Linearのイシューのタイトルをそのままリリースノートの原典にすることで解決します。だからこそ、イシューのタイトルは「〇〇機能の実装」ではなく、「〇〇画面でCSVエクスポートができるようになりました」というユーザー視点の分かりやすい文言で書く習慣をチームに根付かせてください。これだけでプロダクトの品質と透明性が劇的に跳ね上がります。
—
まとめ：明日から始める第一歩
お疲れ様でした！ここまでで、LinearのPublic Roadmapを起点とした、以下の強力なエコシステムがあなたの頭の中に構築されたはずです。
1. 見せる: Public Roadmapで開発の未来をオープンにし、ユーザーの期待感を高める。
2. 集める: 外部からの要望をTriage機能でエレガントに受け止め、サイロ化を防ぐ。
3. 伝える: 完了したイシューを自動的・継続的にユーザーへ届け、信頼関係を築く。
これをマスターすれば、毎日のタスク管理や顧客対応のストレスが劇的に軽くなり、あなたは「コードを書くこと・良いプロダクトを作ること」だけに集中できるようになります。
さあ、今すぐLinearのワークスペースを開き、Public RoadmapのスイッチをONにしてみましょう。あなたのプロダクトの新しい扉が、今、開きます！