公式スキル · プロダクト

関係者向けのロードマップの更新

v1.0.1・2026年11月4日更新

Now・Next・Later の形でロードマップの更新を書く。何がなぜ動いたか、機能でなく成果、日付つきの約束、やらないこと、依頼事項を分けて示す。

チームのPodに追加 SKILL.md をダウンロード

Claude・ChatGPT・コーディング用の AI で使えます。TeamとBusiness では、Pod に入れた公式スキルが改善のたびに自動で最新版になります。

使う場面

経営陣、営業、CS 向けの月次・四半期のロードマップレビュー
優先順位が変わり、何が遅れたか、なぜかを伝えたい

AI に渡すもの

今のロードマップか施策の一覧
前回の更新
変更の理由と読み手

できあがるもの

変わったこと、Now・Next・Later の成果、約束の表、やらないことの一覧、依頼事項をまとめたロードマップの更新。

手順

Now・Next・Later に分ける Janna Bastow の Now-Next-Later の形式：Now は取り組んでいて内容がはっきりしているもの、Next は Now が終わったら取りかかるもので詳細は少なめ、Later はまだ解決策に分解していない大きな課題。列の大きさはそろわなくてよい。
各項目を課題か成果として書く 「請求書作成ウィザード」ではなく、「最初の請求書を出すまでを2日から1時間に」。それが支える事業目標に結びつける。ロードマップは機能の一覧ではなく、課題と成果を示すべきだという Marty Cagan の指摘に沿っている。
何が動いたか、なぜかを示す 前回の更新と比べる。列を移った項目、追加した項目、外した項目ごとに、理由を1つ書く（新しい根拠、顧客との約束、人手、依存関係）。このセクションを最初に置く。
約束は分けて書く 日付を約束した項目（契約、法的な期限、発表イベント）は、日付と担当者つきの別のリストにする。Cagan はこれを high-integrity commitments（確度の高い約束）と呼ぶ。それ以外には日付をつけない。
やらないことを書く チームがやらないと決めた、または保留にした要望を2〜5個、理由つきで挙げる。いちばん必要としているのは営業と CS。
読み手に合わせる 経営陣：成果、リスク、必要な判断。営業と CS：顧客に伝えてよいことと、約束してはいけないこと。顧客：Now と Next だけ。社内の名前は出さず、約束した日付以外は書かず、「予定は変わることがあります」と一度だけ書く。
依頼事項で締める 必要な判断、リソース、情報を、だれから、いつまでにと書く。依頼がなければ「今回の依頼事項なし」と書く。

SKILL.md の全文

AI が読むファイルそのものです。ダウンロード

---
name: roadmap-update
description: 関係者（経営陣、営業、CS、投資家、顧客）向けのロードマップの更新を、Now・Next・Later の形で書く。各項目を成果に結びつけ、前回から何がなぜ動いたか、やらないこと、日付を約束した項目を分けて書き、依頼事項をはっきりさせる。ロードマップの更新、チーム向けのプロダクトの近況、四半期のロードマップレビュー、バックログや計画のメモや前回のロードマップから「これから何が来て、何が変わったか」を頼まれたときに使う。
---

# ロードマップの更新

関係者がロードマップの更新から知りたいのは3つ：何が変わったか、なぜか、自分にとって何を意味するか。動いたものから書く。各項目を、解決する課題か目指す成果に結びつけ、日付は本当の約束にだけつけ、チームがやらないことをはっきり書く。そうすれば、それを当てにして計画する人が出ない。

## 使う場面

- 経営陣、営業、CS、取締役会向けの月次・四半期のロードマップレビュー。
- 優先順位が変わり、何が遅れたか、なぜかを伝える必要があるとき。
- 顧客向けの「今後の予定」のお知らせ（手順6のより厳しい絞り込みを使う）。
- リリース済みの機能には使わない（release-notes を使う）。優先順位を決めるのにも使わない（先に feature-prioritization を使う）。

## 用意するもの

- 今のロードマップか、ステータスつきの施策の一覧。
- 前回の更新。何が動いたかを示すため。なければ一度だけ聞き、それでもなければ「初回の更新のため、変更点なし」と書く。
- 変更の理由。理由がなければ、作らずに「[要確認: 理由]」と書く。
- 読み手。指定がなければ社内の経営陣。

## 手順

1. **Now・Next・Later に分ける。** Janna Bastow の Now-Next-Later の形式：Now は取り組んでいて内容がはっきりしているもの、Next は Now が終わったら取りかかるもので詳細は少なめ、Later はまだ解決策に分解していない大きな課題。列の大きさはそろわなくてよい。
2. **各項目を課題か成果として書く。** 「請求書作成ウィザード」ではなく、「最初の請求書を出すまでを2日から1時間に」。それが支える事業目標に結びつける。ロードマップは機能の一覧ではなく、課題と成果を示すべきだという Marty Cagan の指摘に沿っている。
3. **何が動いたか、なぜかを示す。** 前回の更新と比べる。列を移った項目、追加した項目、外した項目ごとに、理由を1つ書く（新しい根拠、顧客との約束、人手、依存関係）。このセクションを最初に置く。
4. **約束は分けて書く。** 日付を約束した項目（契約、法的な期限、発表イベント）は、日付と担当者つきの別のリストにする。Cagan はこれを high-integrity commitments（確度の高い約束）と呼ぶ。それ以外には日付をつけない。
5. **やらないことを書く。** チームがやらないと決めた、または保留にした要望を2〜5個、理由つきで挙げる。いちばん必要としているのは営業と CS。
6. **読み手に合わせる。** 経営陣：成果、リスク、必要な判断。営業と CS：顧客に伝えてよいことと、約束してはいけないこと。顧客：Now と Next だけ。社内の名前は出さず、約束した日付以外は書かず、「予定は変わることがあります」と一度だけ書く。
7. **依頼事項で締める。** 必要な判断、リソース、情報を、だれから、いつまでにと書く。依頼がなければ「今回の依頼事項なし」と書く。

## 出力の形式

```markdown
# ロードマップの更新 — [期間]

**読み手:** [読み手] · **前回の更新:** [日付]

## 変わったこと
- **[項目]** が [移動元 → 移動先] — [理由]
- **追加:** [項目] — [理由]
- **削除:** [項目] — [理由]

## Now
- **[成果]** — [支える目標] · [状態：順調 / 要注意] · [担当者]

## Next
- **[成果]** — [支える目標]

## Later
- **[解決する課題]**

## 日付を約束した項目
| 約束 | 日付 | 担当者 | 状態 |
|---|---|---|---|

## やらないこと
- [要望] — [理由]

## 依頼事項
- [依頼] — [だれから]、[日付] まで
```

## 例

**入力:** 「経営陣向けの5月の更新。うちは小さな会社の経営者向けの請求書ソフトをつくっている。先月の Now は、遅れている請求書の自動リマインドと CSV エクスポート。Next は経営者が税理士と帳簿を共有するための閲覧専用ユーザーとスマホアプリ。CSV エクスポートはリリース済み。自動リマインドは、インタビューで経営者がメールではなく SMS で支払いを催促しているとわかったので遅れている。SMS に範囲を変える。SSO は6月30日までに北陽商事に約束している。スマホアプリはいったん見送り。スマホからのセッションは2%しかない。閲覧専用ユーザーを CS が顧客に約束してよいか、判断がほしい。」

**出力:**

```markdown
# ロードマップの更新 — 5月

**読み手:** 経営陣 · **前回の更新:** [日付]

## 変わったこと
- **CSV エクスポート** をリリース（Now から外れた）。
- **支払いのリマインド** は Now のまま、SMS に範囲を変更 — インタビューで、ユーザーはメールではなく SMS で催促しているとわかった。
- **追加:** 北陽商事向けの SSO — 6月30日までと北陽商事に約束済み。
- **削除:** スマホアプリ — スマホからのセッションは2%。

## Now
- **手作業の催促なしで、遅れている請求書を回収できるようにする**（SMS での支払いのリマインド） — 継続率の目標 [要確認: 目標の名前] · 要注意（範囲を変更） · [担当者]
- **北陽商事向けの SSO** — 顧客との約束 · [要確認: 状況] · [担当者]

## Next
- **経営者が税理士と帳簿を共有できるようにする**（閲覧専用ユーザー） — 拡大の目標 [要確認: 目標の名前]

## Later
- **スマホで使えるようにする** — スマホからのセッションが増えたら見直す。

## 日付を約束した項目
| 約束 | 日付 | 担当者 | 状態 |
|---|---|---|---|
| 北陽商事向けの SSO | 6月30日 | [担当者] | [要確認: 状況] |

## やらないこと
- スマホアプリ — スマホからのセッションは2%。いったん見送り。
- メールだけのリマインド — ユーザーは SMS で催促していると聞いた。

## 依頼事項
- 閲覧専用ユーザーがもうすぐ出ると、CS から顧客に伝えてよいか。Next にあり、約束ではない。 — [経営陣] の判断、[日付] まで
```

## 送る前のチェック

- [ ] 「変わったこと」が最初にあり、どの移動にも入力にある理由か「[要確認: 理由]」がある。
- [ ] Now と Next の項目はすべて、機能名だけでなく成果か課題として書いてある。
- [ ] 日付がついているのは約束だけ。
- [ ] 「やらないこと」が2つ以上あるか、空の理由が書いてある。
- [ ] どの依頼にも、だれが判断し、いつまでかが書いてある。
- [ ] 顧客向けの版に、社内の名前、担当者、約束していない日付がない。

## よくある失敗

- 確実そうに見せようと、Next と Later に日付をつける。その日付は約束として転送される。
- 遅れを Now の一覧に紛れこませる。理由つきで「変わったこと」に書く。
- 20項目を並べる。Now は、その期間にチームが実際にやっていることだけにする。

チームで使う

AI Skill Pod に追加すると、業務委託の方も含めてチーム全員が、自分の AI から同じ版を使えます。 AI スキルをチームで共有する方法を読む

チームのPodに追加

変更履歴

v1.0.1 · 2026年11月4日 · Example: SSO for Northwind is described as promised by June 30, as the input says, not as a signed contract, and its status is marked [check: status]; the input now gives the month, the audience, the product, why owners want texts and what read-only seats are for, and the Later item and the mobile reason no longer go beyond it.
v1.0.0 · 2026年11月4日 · First release.

出典

出典は英語のページです。

Why I Invented the Now-Next-Later Roadmap (ProdPad) (2026-11-04に確認)
The Alternative to Roadmaps - Silicon Valley Product Group (2026-11-04に確認)