product-roadmap

プロダクトロードマップ

概要

プロダクトロードマップとは、何をいつ作るかを示す計画です。ひとりで事業を営む方にとって、ロードマップはスコープクリープを防ぎ、影響の大きい作業に集中できるようにし、気を散らすものにノーと言う助けになります。このプレイブックでは、機能をむやみに増やすのではなく、ビジネス上の成果につながるロードマップの作り方を紹介します。

---

ステップ 1：ロードマップとは何か（そして何ではないか）を理解する

ロードマップとは：

• 解決する問題や達成する成果を優先順位順に並べたもの
• 今後 3～12 か月の計画
• 顧客やステークホルダーに方向性を伝えるためのツール
• 柔軟なもの — 学びに応じて進化します

ロードマップではないもの：

• 約束（「Y 日に X をリリースします」）
• これまでに受け取った機能リクエストをすべて並べたもの
• 一度決めたら変えられないもの — 四半期ごとに見直すことを想定しましょう

**重要な原則：**ロードマップで扱うのは機能ではなく成果です。「ダッシュボードを作る」ではなく、「ユーザーがデータの概要をひと目で把握できるようにする」としましょう。

---

ステップ 2：情報を集める（機能のアイデアはどこから来るか）

優先順位を決める前に、あらゆる情報を集めます。アイデアはさまざまなところから生まれます。

情報源：

1. 顧客からのフィードバック（サポートチケット、機能リクエスト、ユーザーインタビュー）
2. 自分のビジョン（長期的にプロダクトをどのような方向へ進めたいか）
3. 競合とのギャップ（競合にはあるが、自分のプロダクトにはない機能）
4. データ／分析（利用パターン、離脱ポイント、利用率の低い機能）
5. ビジネス目標（収益や成長の目標を達成するには何が必要か）

収集方法：

• バックログ（すべてのアイデアを継続的に記録するリスト）を作成します。Notion、Trello、Linear、または Google Sheet を使いましょう。
• 各アイデアについて、情報源、解決する問題、リクエストした人、おおまかな見積もり（小／中／大）を記録します。

**ルール：**情報を集めている間は優先順位を決めません。まずはすべて記録しましょう。

---

ステップ 3：フレームワークを使って優先順位を決める

すべてを作ることはできません。優先順位を決めるとは、何を作らないかを選ぶことです。

フレームワーク：RICE スコア

RICE = リーチ × インパクト × 確信度 ÷ 労力

各機能またはプロジェクトを採点します。

**リーチ：**一定期間内に何人のユーザーに影響しますか？

• 例：月 100 人 = 100

**インパクト：**そのユーザーにどの程度の影響を与えますか？

• 非常に大きい = 3、高い = 2、中程度 = 1、低い = 0.5、最小限 = 0.25

**確信度：**リーチとインパクトの見積もりにどの程度自信がありますか？

• 高 = 100%、中 = 80%、低 = 50%

**労力：**何人週かかりますか？

• 例：2 週間 = 2

RICE スコア =（リーチ × インパクト × 確信度）/ 労力

例：

Feature: "Add bulk export"
Reach: 200 users/month
Impact: 2 (high)
Confidence: 80%
Effort: 1 week

RICE = (200 × 2 × 0.8) / 1 = 320

バックログを RICE スコア順に並べ替えます。スコアが最も高いものが最優先です。

代替フレームワーク：価値と労力のマトリックス

RICE よりもシンプルです。各機能を 2×2 のグリッドに配置します。

        High Value
            |
  Quick Wins | Big Bets
------------|------------
 Time Sinks | Low Priority
            |
        Low Value

• クイックウィン（価値が高く、労力が低い）→ まず取り組みます
• 大きな賭け（価値が高く、労力も高い）→ クイックウィンの後に取り組みます
• 時間の浪費（価値が低く、労力が高い）→ 決して取り組みません
• 優先度が低いもの（価値が低く、労力も低い）→ 余裕があれば取り組みます（通常は余裕がありません）

どちらを使うか：

• リーチとインパクトに関するデータがある場合は、RICE を使います
• まだ初期段階で見積もりが大まかな場合は、価値と労力を使います

---

ステップ 4：ロードマップを構成する

ロードマップを期間ごとに整理します。ひとりで事業を営む方は月単位ではなく四半期単位で計画しましょう（変化が速すぎて、月単位のロードマップでは正確さを保てません）。

ロードマップの構成：

NOW (Current Quarter)
  Theme: [What's the focus this quarter?]
  Features/Projects:
    1. [Highest priority item from Step 3]
    2. [Second highest priority]
    3. [Third highest — only if capacity allows]

NEXT (Next Quarter)
  Theme: [What's the likely focus?]
  Features/Projects:
    - [Top 3-5 candidates, but not committed]

LATER (6-12 months out)
  Theme: [Strategic direction]
  Features/Projects:
    - [High-level goals, not specific features]

**テーマが重要な理由：**テーマを設けることで、四半期の重点が明確になります。「継続率を改善する」はテーマの一例です。機能リクエストが現在の優先事項に合っているか、後回しにすべきかを判断する助けになります。

**四半期あたりの機能数は？**ひとりで開発する場合、意味のある機能やプロジェクトは 2～4 件です。引き受けすぎないようにしましょう。バグ、顧客の問題、生活上の事情が生じるため、計画のうちリリースできるのは 60～70% にとどまると考えてください。

---

ステップ 5：ロードマップを共有する

頭の中にあるだけのロードマップは役に立ちません。顧客や関係者と共有しましょう。

共有先：

• 公開ロードマップ（Trello、Notion、または Canny や ProductBoard などの専用ロードマップツール）
• 製品内（アプリのメニューやヘルプセクションからロードマップへのリンクを設置）
• メールでの最新情報（「次に開発する機能はこちらです」という四半期ごとの顧客向けメール）
• ソーシャルメディア（進捗を共有し、リリースした機能を祝う）

公開情報と非公開情報の使い分け：

• 公開： テーマ、最優先事項、おおまかな時期（第 1 四半期、第 2 四半期など。具体的な日付は示さない）
• 非公開（社内のみ）： 詳細な仕様、技術的な判断、採用しなかったアイデア

ロードマップ項目の表現：

• 次のような表現ではなく：「3 月 15 日に X をリリースします」
• 次のように伝えましょう：「第 1 四半期に X のリリースを予定しています。学びを踏まえて時期が変わる場合があります。」

重要な理由： 約束した以上のことを約束して実行できなければ、信頼を損ないます。約束を控えめにして期待を上回ることで、信頼が築かれます。

---

ステップ 6：顧客からのフィードバックを取り入れる

顧客から機能の要望が寄せられます。非常に価値のあるものもあれば、大半はノイズです。要望を見極めるのがあなたの役目です。

機能リクエストへの対応方法：

1. 受け止めて感謝を伝えます。「ご提案ありがとうございます！この件は記録しています。」
2. 確認の質問をします。「この機能でどのような問題を解決しようとしていますか？」（実際の問題に対して、要望された機能が最善の解決策ではない場合がよくあります。）
3. バックログに記録します。 開発を約束するのではなく、追跡できるようにします。
4. パターンを探します。 同じ要望を 10 人が寄せていれば、それは需要の表れです。1 人だけなら、ノイズかもしれません（または特殊なケースかもしれません）。

要望を優先する場合：

• 複数の顧客から要望がある（需要の表れ）
• 製品のビジョンや事業目標に沿っている
• RICE または価値対工数の評価が高い

断る場合：

• 単発の要望で、共通するパターンがない
• テーマや戦略的な注力分野から外れてしまう
• 大多数を犠牲にして、ごく少数の人だけにメリットがある
• 得られる価値に見合わない複雑さが加わる

断り方：

"Thanks for the suggestion! We're focused on [current theme] right now, so this
won't make it into the next few months. We'll keep it on the radar and revisit
as priorities evolve."

原則： 何かに「はい」と言うことは、別の何かに「いいえ」と言うことです。ロードマップは妥協なく守りましょう。

---

ステップ 7：四半期ごとに見直して調整する

ロードマップは常に更新される文書です。四半期ごとに見直し、更新しましょう。

四半期ごとのロードマップレビュー（60～90 分）：

1. 振り返る： 今四半期に何をリリースしましたか？ 何をリリースできませんでしたか？ その理由は何ですか？
2. 影響を測定する： リリースした機能は、重視していた指標（継続率、売上、アクティベーションなど）を改善しましたか？
3. 新しい情報を集める： どのようなフィードバックが寄せられましたか？ 市場にどのような変化がありましたか？ 何を学びましたか？
4. 優先順位を見直す： バックログに優先順位付けのフレームワークを再適用します。次の四半期に「今すぐ」に移すべき項目は何ですか？
5. テーマを決める： 次の四半期の重点は何ですか？
6. 共有する： 更新したロードマップを顧客と共有します。

注意すべき危険信号：

• 大量の機能をリリースしているのに、重要な指標がまったく改善していない（取り組む内容を間違えています）
• ロードマップが 6 か月間変わっていない（学習も適応もできていません）
• 最も声の大きい顧客の意見に常に反応している（戦略的な方向性を見失っています）

---

ステップ 8：迅速な反復と戦略的なビジョンのバランスを取る

ソロプレナーは大企業より迅速に動けます。その強みを活用しましょう。

機敏さを保つ方法：

• 小さくリリースし、すばやくテストします。「完璧な」機能をリリースするのに 3 か月も待たないでください。2 週間で小さなバージョンをリリースし、学び、反復します。
• 新しい機能は、完全版の開発に取り掛かる前に MVP を構築します。
• フィーチャーフラグやベータアクセスを利用し、全員に展開する前に少人数のグループでテストします。

戦略性を保つ方法：

• 目新しいものすべてに飛びつかないでください。重大な変化がない限り、四半期のテーマを守りましょう。
• 基盤となる作業（リファクタリング、パフォーマンス、UX の仕上げ）に、時間の 20～30％を確保します。これらは顧客向けロードマップには載りませんが、重要です。

バランス： ロードマップの実行に 70％、探索と学習に 30％を充てます。

---

プロダクトロードマップで避けるべき間違い

• 顧客が求めるものをすべて作ること。 機能を量産するだけの存在ではありません。機能を集めるのではなく、問題の解決に注力しましょう。
• ノーと言わないこと。 何かにイエスと言うことは、別の何かにノーと言うことです。ビジョンに合わない機能リクエストは断るようにしましょう。
• 具体的な日付をあまりにも早く約束すること。 ロードマップは計画であり、約束ではありません。日付ではなく、四半期を示しましょう。
• リリース後に効果を測定しないこと。 機能によって状況が改善したかを確認しなければ、効果の低いものを作り続けることになります。
• ロードマップを秘密にすること。 顧客は透明性を高く評価します。取り組んでいる内容を（概要レベルで）共有しましょう。
• ロードマップを古いままにしておくこと。 6 か月以上更新していないロードマップは役に立ちません。四半期ごとに見直しましょう。