roadmap-planning

機能一覧ではなく、成果に基づいてロードマップを作成します。ロードマップが答えるのは、「どの問題を、どの順番で解決するのか？」であり、「どの機能を、いつリリースするのか？」ではありません。6週間を超えるロードマップの日付は作り話です。そのように扱ってください。

今／次／その後

確実性が段階的に低くなる3つの時間軸です。

今（確定済み — 今サイクル）

• 現在進行中、または着手間近です
• 内容が十分に具体化されています。問題が定義され、解決策の範囲が定まり、投入する工数が設定されています
• 担当チームが決まり、今サイクル中のリリースが見込まれています
• 最大1〜3項目です

次（具体化済み — 次の1〜2サイクル）

• 問題は検証済みで、解決策は部分的に具体化されています
• まだチームは割り当てられていません
• 「今」の項目から得られる学びに基づき、変更される可能性があります
• 最大3〜5項目です

その後（未整理 — 探る価値のあるアイデア）

• 実在すると考えているものの、まだ検証していない問題です
• 解決策はまだ具体化されていません
• 根拠が得られたら「次」に移すか、取り下げます
• 件数に上限はありませんが、四半期ごとに見直して整理してください

ロードマップ項目は機能ではなく成果です

各ロードマップ項目は、解決する問題または達成する成果として示します。

悪い例（機能一覧型のロードマップ）：

• チームのコラボレーション機能を構築する
• CSV エクスポートを追加する
• 設定ページを再設計する

良い例（成果ベースのロードマップ）：

• チーム登録から最初の価値を得るまでの時間を15分から5分未満に短縮する
• サポートに問い合わせずに、ユーザーが自分のデータを取得できるようにする
• 設定関連のサポート問い合わせを50％削減する

解決策は、ロードマップの計画中ではなく、具体化の過程で生まれます。

Shape Up サイクル計画

Shape Up サイクルを採用しているチーム向けです。

1. ベッティングテーブル： リーダーシップが具体化済みの提案を確認し、次のサイクルで取り組む内容を決めます。すべてが選ばれるわけではありません。
2. クールダウン： バグ修正、探索、今後の作業の具体化のため、サイクル間に1〜2週間設けます。
3. 持ち越しなし： サイクル内にリリースできなかった作業が自動的に持ち越されることはありません。再度提案する必要があります。

ロードマップの提示

1ページまたは1画面に収めます。ロードマップにスクロールが必要なら、詳細すぎます。

シンプルな表にまとめます。

期間	成果	根拠	ステータス
今	オンボーディングの離脱率を30％未満に下げる	5件のインタビュー、現在の離脱率は60％	進行中、2/3週目
次	セルフサービスでのデータエクスポートを可能にする	月12件のサポート問い合わせ	具体化済み、チームが必要
その後	複数のワークスペースへの対応	エンタープライズの見込み顧客3社から要望あり	未検証

ガイドライン

• 重要：6週間を超えるロードマップ項目には、絶対に日付を入れないでください。わからないことをわかっているふりをすれば、信頼が損なわれます。
• 機能一覧型のロードマップは絶対に作らないでください。成果と問題に基づいて整理します。
• 「今」は必ず1〜3項目に絞ってください。8つのことに取り組んでいるなら、どれも完了しません。
• 具体化と根拠の裏付けなしに、「その後」の項目を「今」に移すことは絶対に避けてください。
• 「その後」は必ず四半期ごとに整理してください。3か月間、根拠が得られていない項目は取り下げます。
• 四半期ごとだけでなく、各サイクルの開始時に必ずロードマップを見直し、更新してください。
• 各項目の根拠なしにロードマップを提示することは絶対に避けてください。根拠のないロードマップは願望リストです。

---

Shape Up（Basecamp）のサイクル計画と「今／次／その後」フレームワークに基づいています。productskills のスキルを活用しています。