eol-readiness-advisor

EOL 準備状況アドバイザー

目的

製品や機能を実際に廃止すべきかどうか、また廃止する場合、どれほどの対応を講じるべきかを判断します。このスキルでは、根拠を明示した実施可否の判定と、選択した対応レベル、そして無視すると問題になる義務の短いリストを提示します。

ほとんどの EOL ガイダンスは、すでに決定が下されたことを前提にして、計画の策定に飛びつきます。このスキルが扱うのは、もっと早い段階です。「たぶん廃止すべきだ」という話が、会議の場で誰かが説明し、支持できる決定へと変わる、その対話の段階です。

廃止しないという判断も、同じようにためらわずに伝えます。「保留」や「収益確保」という判定も、慰めの賞品ではなく、ここでの正式な結果です。

入力

最も役立つ情報： 検討対象の製品や機能と、この話が持ち上がったきっかけ（利用者数の減少、戦略の転換、サポートコストへの不満、役員の何気ない発言など）。

あると便利な情報： 売上と顧客数、代替製品の有無、契約上または規制上の義務、すでに把握している政治的な懸念事項。

スキルの呼び出し時に渡された内容（スキル名の後のテキスト、貼り付けたコンテキスト、追記された ARGUMENTS: 行など）は、すでに回答済みの情報として扱います。これを利用し、該当する内容については聞き直さないでください。

何も用意できていなくても大丈夫です。 まず、何を検討しているのか、なぜ検討しているのかを尋ね、影響範囲、対応レベル、移行経路について、一度に一つずつ確認していきます。事前に数値を揃える必要はありません。「わかりません」も有効な回答で、判定では明示的な仮定として扱われます。

呼び出し例：

• Should we retire our legacy reporting module? Usage is down 60% and support costs are climbing.
• EOL readiness check on our NFA-200 controller line — 120 installs, channel partners, UL certified.

---

主な概念

適切な規模に調整するダイヤル

EOL はどれも同じように進むわけではありません。 変更履歴への記載とサポート用の定型文だけで済むものもあれば、3四半期にわたって会社全体を巻き込むものもあります。その中間に位置するものがほとんどです。EOL で最もよくある失敗は、どちらの方向でも、終了の規模と対応の規模が釣り合わないことです。主力製品の廃止を Jira チケット一つで済ませたり、機能の非推奨化に運営委員会を立ち上げたりするケースです。

したがって、対応レベルはフレームワークが提示する判定ではなく、自分で設定するダイヤルです。

寸法	レベル 1 — 軽量	レベル 2 — 標準	レベル 3 — 大規模
想定される対象	機能、社内ツール、バージョン管理されていない API	顧客が利用中の商用製品	売上に不可欠な製品、ハードウェア、規制対象
関係者の確認回数	3〜4	7〜8	10 以上
使用するライフサイクルゲート	2〜3（NSC、EOS、EOL）	4〜5（NSC、EOS、EOE、EOM、EOL）	8 すべて（GA から EOSRV まで）
関係する部門	製品、エンジニアリング、サポート、ドキュメント	＋ 営業、マーケティング、カスタマーサクセス、財務、法務、IT、データ	＋ サプライチェーン、チャネル、規制対応、組織
対応準備	サポート向け FAQ のみ	＋ 営業用の説明要点、反論対応、エスカレーション	＋ チャネル向け概要、アカウントの優先度区分、トレーニング
顧客向けメッセージ	簡潔なお知らせ	フェーズ表を含む標準的な案内	コンプライアンス項目を含む詳細な案内
一般的なリードタイム	数週間	6〜12か月	12〜24か月

ほとんどの廃止案件に適しているのはレベル 2 です。 これを初期設定として、レベルを上げるか下げるかを検討してください。

ダイヤルを動かすのはあなたです。 レベルを提案して理由を説明したうえで、ユーザーがどちらの方向にも変更できるようにします。後から再度変更することもできます。「組織のことはわかっているので、軽量版にしてください」と PM が言うのは、誤りではなく判断を示しています。その選択を尊重し、軽いレベルでは対応されない事項を一行で記して、ユーザーが情報を踏まえて選べるようにしてください。

ライフサイクルのゲート（共通語彙）

EOL は一つの日付ではありません。一連のゲートで構成されており、これらを一つの告知にまとめてしまうことが、顧客の不満の大半を招きます。

• GA (General Availability)： 積極的に販売され、全面的にサポートされている状態
• NSC (Notice of Status Change)： 決定が伝えられ、計画が始まる段階
• EOS (End of Sale)： 新規顧客が購入できなくなる段階
• EOE (End of Expansion)： 既存顧客が容量やシートを追加できなくなる段階
• EOR (End of Renewal)： 既存の契約が更新されなくなる段階
• EOM (End of Maintenance)： バグ修正とパッチの提供が終了する段階
• EOL (End of Life)： 製品が廃止される段階
• EOSRV (End of Service)： すべてのサポートとサービスの義務が終了する段階

段階的な廃止では、このうち3つを使用します。大規模な廃止では8つすべてを使用します。使用するゲートを挙げるのと同じくらい、使用しないゲートを明示することも有用です。

4つの廃止シグナル

廃止を進める判断を裏付ける証拠です。2つ以上が強く当てはまる場合、廃止を進める十分な根拠になります。

1. 財務的な実現可能性 — コストが収益を上回っている、サポート負荷が不釣り合いに多くのリソースを消費している
2. 戦略との整合性 — 会社の方針と衝突している、この市場から撤退する
3. 代替ソリューション — 社内の後継製品に置き換えられる、プラットフォームを統合している
4. 市場での存在意義の喪失 — ニーズが変化した、テクノロジーが進歩した、根本的な問題が存在しなくなった

4つの保留シグナル

廃止シグナルが強くても、今すぐ廃止することに反対する証拠です。

1. 義務による制約 — 契約、SLA、規制上の約束、「永久」とした約束がまだ有効である
2. 戦略上の人質 — 収益は少ないものの、最も重要な顧客のアカウントに組み込まれている
3. 移行先がない — 代替製品もサードパーティの代替手段もなく、顧客が取り残される
4. 撤退コストが維持コストを上回る — 廃止にかかるコストが、もう1年間ひっそりと保守を続けるコストを上回る

アンチパターン（これは何ではないか）

• 追認するだけのものではありません。 保留シグナルが優勢であれば、結論は保留となり、このスキルはそのように示します。
• ポートフォリオの選別ではありません。 これは1つの製品を評価します。製品カタログの選別は別の作業です。
• 計画そのものではありません。 結論と強度レベルは計画を立てるための入力であり、計画そのものではありません。
• 財務モデルではありません。 収益とコストを定性的に検討しますが、予測は行いません。

---

適用

このスキルでは、デフォルトの対話プロトコルとしてworkshop-facilitationを使用してください。

このスキルでは最大4つの適応型質問を行い、その後に結論、強度レベル、番号付きの次のステップを提示します。開始時に、質問は4つで所要時間はおよそ15分であること、また、途中でいつでも背景情報をまとめて伝えれば先に進めることを案内してください。

---

質問 1 / 4 — 何を見直していて、きっかけは何ですか？

エージェントの質問：

「EOL を検討している製品や機能は何ですか？　また、検討のきっかけは何でしたか？　きっかけは製品そのものと同じくらい重要です。指標の低下、戦略の転換、サポートコストへの不満、経営幹部の何気ない一言では、評価の方向性が大きく異なります。」

まだ終了を検討する段階ではない可能性はありませんか？ このスキルで評価するのは、製品を終了するという選択肢です。成熟期から衰退期への移行点では、選択肢は 3 つあります。製品を延長する、後継製品に置き換える、または終了することです。ユーザーが終了を選択肢として決めていない場合は、その旨を伝えて、前段階の診断を提案します。

「終了の評価に入る前に、終了する方向で決めていますか？　ほかに、延長するか後継製品に置き換えるという選択肢もあります。どれが適切かを判断するには、lifecycle-play-advisor をご利用ください。方針が決まっているようでしたら、このまま評価を進めます。」

寄り道を無理に促す必要はありません。「決定済みなので、終了を評価してください」と言うユーザーには、そのまま評価を進めます。

きっかけの種類に注目してください。 想定される失敗のパターンがわかります。

きっかけ	確認すること
指標の低下	実際に低下しているのか、それとも季節性や測定方法の変更によるものか？
戦略の転換	製品が戦略に合わなくなったのか、それとも単に流行遅れになっただけか？
サポートコスト	解決策は終了なのか、それともバグ修正なのか？
経営幹部の発言	根拠はあるのか、それとも肩書きのある人の意見にすぎないのか？
後継製品の出荷	後継製品は、対象となる顧客に必要な機能を本当に備えているのか？

きっかけが、裏付けとなる根拠のない経営幹部の発言であれば、最終判断の際にその点を率直に伝えてください。これは、時期尚早な終了を招く最もよくある原因です。

---

質問 2 / 4 — 影響範囲はどのくらいですか？

エージェントの質問：

「影響の規模を把握するため、教えてください。概算で構いませんし、『わかりません』という回答でも問題ありません。

1. 顧客： 何社、または何人のユーザーが利用していますか？
2. 収益： おおよそどのくらいの収益を占めていますか？　また、一部の顧客に集中していますか？
3. 契約上の義務： 契約、SLA、更新日、規制上の義務など、関連するものはありますか？
4. 物理的な製品や販売チャネル： ハードウェア、在庫、予備部品はありますか？　またはパートナーが再販していますか？」

この確認が重要な理由（必ず伝えてください）： この 4 つの回答によって、必要な対応の規模が決まります。3 つ目の項目を最初に尋ねるのには理由があります。「簡単な」終了が法的な問題に発展する原因として、最も多いのがこれだからです。

不明な項目は、最終判断で明記する前提として扱います。数値を調べるために進行を止めないでください。前提を 3 つ明記した評価のほうが、実施されない評価よりも役に立ちます。

---

質問 3 / 4 — 対応の規模を決める

エージェントは推奨案を提示してから、規模の選択を委ねます：

「お話しいただいた内容に基づき、必要な対応の規模について、次のように判断しました。

推奨：レベル [N] — [軽量 / 標準 / 大規模] 理由：[回答内容に基づく具体的な理由を 2～3 点]

1. レベル 1 — 軽量。 簡単なチェックリスト、関係者 3～4 人、短い告知期間。影響範囲が社内に限られる場合や、ユーザーが少なく連絡を取りやすい場合に適しています。
2. レベル 2 — 標準。 部門横断のチェックリスト、関係者 7～8 人、段階的な顧客向け告知。実際に顧客がいる商用製品で、規制上の制約がない場合に適しています。ほとんどの製品終了はこのレベルです。
3. レベル 3 — 大規模。 包括的な実施計画、関係者 10 人以上、8 つすべてのゲート、販売チャネルと規制対応のワークストリーム。収益が極めて重要な場合、現場でハードウェアが稼働している場合、またはコンプライアンスが適用される場合に適しています。

推奨案を採用するか、別のレベルを選んでください。組織のことはあなたが一番よくご存じです。後から変更することもできます。この選択によって、後続の作業が固定されることはありません。」

ユーザーがレベルを下げた場合は受け入れて、次の一文を加えます。「推奨より簡略化することで、[確認が漏れる具体的な項目。通常は法務レビュー、販売チャネルへの通知、または移行サポート] が対象外になります。意図的な選択であり、予想外の事態にならないよう、念のためお伝えします。」

ユーザーがレベルを上げた場合は、異議を唱えずに受け入れます。EOL に向けて準備しすぎても、コストのかからない失敗です。

---

質問 4/4 — 顧客はどこへ移行しますか？

エージェントの質問：

「利用者には何が起こりますか？大きく分けて、次の 3 つの道筋があります。

1. 置き換え — 貴社の別の製品が引き継ぎます
2. 移行 — 別の構成、プラン、またはプラットフォームに移ります
3. 円満な終了 — 代わりのものはなく、データ、告知、代替手段が必要です

どの道筋で、現時点でどれくらい準備ができていますか？」

道筋の準備状況は、詳細事項ではなく、実施可否を判断する材料です。 対象となる 特定の顧客 に対して機能が同等でない製品は、まだ移行先にはなりません。道筋の準備ができていない場合、判断は通常、「実施する。ただし、[具体的な準備条件] が整うまで告知を待つ」です。

---

最終ステップ：評価を提示する

次の構成で提示します。

## EOL Readiness Assessment: [Product]

**Verdict:** [Go / Go-with-conditions / Hold / Harvest]
**Intensity:** Level [N] — [Light/Standard/Heavy] *(user-selected)*
**Confidence:** [High/Medium/Low] — based on [what's known vs. assumed]

### The Case to Retire
- [Retire signal + the evidence behind it]

### The Case Against (or: Conditions)
- [Hold signal + the evidence behind it]

### Assumptions I Made
- [Anything answered "I don't know," stated plainly]

### Obligations to Check Before Announcing
- [Contracts, SLAs, regulatory, "lifetime" promises, channel agreements]

### Landing Place
- **Path:** [Replacement / Migration / Graceful exit]
- **Readiness:** [Ready / Gap: specific gap / Not started]

### What This Level Covers — and Doesn't
- Covers: [gates, stakeholder count, artifacts implied by the level]
- Does not cover: [what the level deliberately skips]

続けて、次のステップを番号付きで提案します。

「次はどのように進めますか？

1. 運用計画を作成する — レベル [N] の終了に向けた、フェーズごとのチェックリスト
2. ステークホルダーとの対話を整理する — 誰と、どの順番で話し、それぞれ何を話すべきか
3. 社内チームの準備を整える — サポート向け FAQ、営業向け説明、反論への対応
4. 顧客向け告知を作成する — eol-message を参照してください
5. 不明点を確認して、より正確な数値が揃ったら この評価を再実行する

番号を選ぶか、組み合わせる（「2 と 4」など）か、別の希望を教えてください。」

判断名について：

• Go — 終了します。根拠は明確です
• Go-with-conditions — 終了しますが、告知の前に特定の条件を満たす必要があります
• Hold — 今は終了しません。保留の要因が優勢です。具体的な条件が整ったら再検討します
• Harvest — 終了も投資もしません。残る収益を得るために最小限の運用を続け、見直し日を設定します
• Extend — 終了しません。まだ成長の余地があります。保留の要因が優勢で、圧力の原因が需要側または流通面にあるとわかった場合に選びます。別バージョンで対応できるセグメントがある場合や、製品の問題に見えて実はチャネルや価格の問題である場合が該当します。施策の規模を見積もるため、lifecycle-play-advisor に引き継ぎます

Hold と Extend は異なる判断です。 Hold は 今は実行しない という意味で、Extend は この製品にはまだ打ち手がある という意味です。混同しないでください。「Hold」と伝えられた PM は待ちますが、「Extend」と伝えられた PM は行動します。

---

例

例 A — SaaS、推奨レベルより引き下げ

PM：「Fieldlight Classic を終了すべきでしょうか？ レガシーの配車モジュールです。経営陣はこの2四半期、終了をほのめかしています。」

エージェント（Q1）：「その示唆のきっかけは何ですか？ 指標、戦略の変更、それともコストへの不満でしょうか？」

PM：「サポートチケットです。Classic はサポート件数の約40％を占めていますが、売上の割合はおそらく15％程度です。それに昨年 Fieldlight Next をリリースしました。」

エージェント（Q2）：「影響範囲はどのくらいですか？ 顧客、売上、契約上の義務、販売チャネルやハードウェアへの影響はありますか？」

PM：「約800アカウントで、ARRは240万ドルです。年間契約で、標準的な条件です。規制関連の要件はありません。純粋なSaaSで、直販です。」

エージェント（Q3）：「推奨：レベル2 — 標準。 年間契約を結んでいる顧客が800アカウントあり、実際の売上もあるため、段階的なコミュニケーションと部門横断のチェックリストが必要です。ただし、規制対応や販売チャネルの作業はないため、重い対応は不要です。[3つのレベルを提示]」

PM：「正直、うちは40人の会社です。レベル1にしてください。」

エージェント：「レベル1で進めます。ここで対応を軽くすると、更新日の文言に関する法務部門の正式なレビューと、段階的な営業支援を省くことになります。年間契約が800件あるので、更新日について見落としがないようにしたいところです。これは不意打ちではなく、ご自身で選択した結果だとわかるようにお伝えしています。レベル1に法務部門の確認を1回だけ追加する形にしますか？ よくある中間案です。」

PM：「はい、そうしましょう。」

エージェント（Q4）：「800アカウントの移行先はどこですか？ Fieldlight Next でしょうか、それとも別の製品でしょうか？」

PM：「Next です。カスタム配車ルールを使っている約30アカウントを除けば、機能は同等です。」

**判定：**条件付きで進行。レベル1＋法務部門の確認。条件：告知前に、カスタムルールを使う30アカウントへの対応計画を明確にする必要があります。そうしないと、エスカレーション対応に追われることになります。前提として明記：サポート件数は記憶に基づく数字であり、実データを抽出したものではありません。

---

例 B — 産業機器、引き上げた結果「保留」

PM：「NFA-200 改修用コントローラーを廃止したいと考えています。NFA-500 が発売され、製造部門は生産ラインを空けたがっています。」

エージェント（Q1）：「つまり、きっかけは社内事情、すなわち製造能力の確保と後継機の出荷ですね。顧客側からの兆候もありますか？ それとも完全に供給側の事情でしょうか？」

PM：「完全に供給側の事情です。顧客は200で問題ありません。」

エージェント（Q2）：「影響範囲はどのくらいですか？ 設置台数、売上、契約上の義務、ハードウェアや販売チャネルへの影響はありますか？」

PM：「約120台が設置済みです。販売代理店が8社あり、再販しています。一部のサービス契約は2028年まで続きます。ULとCEの認証を取得しています。それに、交換部品の在庫もあります。」

エージェント（Q3）：「推奨：レベル3 — 重対応。 2028年まで続くサービス契約、8社の販売代理店、規制認証、現物の交換部品という、軽いレベルでは対応しきれない4つの作業項目があります。」

PM：「同意します。レベル3で。」

エージェント（Q4）：「設置済みの120台はどこに移行しますか？ NFA-500 は既存の200にそのまま置き換えられますか？」

PM：「正確には違います。500には別の取り付けブラケットが必要で、改修ケースでは……現地訪問が毎回必要になります。」

**判定：**保留。 廃止の兆候は確かにありますが、供給側の事情だけです。一方で、2028年まで続くサービス契約という義務上の制約があり、そのまま移行できる代替品もありません。120件の現地訪問は移行計画ではなく、別途予算が必要なプロジェクトです。顧客はこれを求めていません。

代わりに推奨する対応：今すぐEOS、EOLは後日。 NFA-200 の販売を終了し、契約満了まではサービスを継続します。ブラケットや改修作業への資金を、実際の前提条件として確保します。改修の道筋ができるか、契約が終了するか、いずれか早いほうの時点で再検討します。EOSの時点で製造部門は生産ラインを空けられます。これが本来の要望でした。

判定では、表面上の問題（製品の廃止）と根本的な問題（製造ラインを空けること）を分け、後者をより低コストで解決しています。

---

よくある落とし穴

落とし穴 1：肩書きのある人の意見

症状： ケース全体が、ある幹部の「それを廃止すべきだ」という発言に基づいています。

結果： ひそかに利益を上げていた製品の廃止に2四半期を費やし、解約が発生したときには、誰のアイデアだったのか誰も覚えていません。

対策： 評価の中で、きっかけを明示してください。根拠が一つの発言だけなら、判定は「保留 — 根拠待ち」であり、「実行」ではありません。

---

落とし穴 2：一律の廃止措置

症状： すべてのEOLに同じ対応を適用します。すべてをチケットとして処理するか、すべてに運営委員会を招集します。

結果： 小規模な廃止では、形式的な手続きに政治的資本を浪費します。大規模な廃止では、公に大きな問題を引き起こします。

対策： 対応の強度を意識して設定し、それを明言したうえで、選択したレベルでは何を省略するのかを明らかにしてください。

---

落とし穴 3：義務の確認を省略する

症状： 影響範囲を顧客数と売上で測り、契約や認証については確認しません。

結果： 記録に残る最悪のEOLの失敗は、商業上の問題ではなく法的な問題です。「生涯」保証のハードウェアに対する返金命令や、適切な代替手段のないサービスを廃止したことによる罰金などです。

対策： 売上と同時に、契約上の約束についても確認してください。質問2であるのには理由があります。

---

落とし穴 4：「代替品なし」を細部として扱う

症状： 判定は「実行」ですが、顧客の移行先は「顧客が何か見つけるでしょう」です。

結果： 製品を廃止するのではなく、顧客を追い出すことになります。顧客はそれを忘れません。

対策： 円滑な終了は正当な道筋ですが、データのエクスポート、長めの告知期間、誠実な代替案が必要です。まだ何もない場合、判定は「条件付きで実行」です。

---

落とし穴 5：表面化した問題を解決する

症状： 誰かが製品の廃止を求め、評価では製品の廃止そのものを検討します。

結果： 実際のニーズには販売終了（EOS）、値上げ、またはバグ修正で対応できたのに、完全な廃止を実施してしまいます。

対策： きっかけの本質を確認してください。「製造ラインを空ける」は、EOLではなくEOSで解決できます。より低コストな解決策が見つかったら、それを明示してください。

---

参考資料

関連スキル

それぞれ単独で利用できます。事前にこのスキルを実行しておく必要はなく、このスキルもそれらの前提ではありません。この評価を実施した場合は、開始時に「Level 2」と伝えるだけで強度レベルを引き継げます。引き継ぎ用の形式を保つ必要はありません。

• eol-message — 顧客向けのお知らせ
• incoming-request-advisor — EOLの依頼が、まず内容を読み解く必要のあるメッセージとして届いた場合
• stakeholder-map — 一般的なステークホルダーマッピング
• business-health-diagnostic — きっかけが財務上の問題で、数値を適切に分析したい場合
• workshop-facilitation — 対話の進行プロトコル

外部フレームワーク

• 製品ライフサイクル（PLC）— EOLの判断を行うのは衰退期です
• メンデロウのマトリクス — 権限／関心に基づくステークホルダーの優先順位付け

出典

• https://github.com/deanpeters/product-manager-prompts リポジトリの prompts/eol-readiness-assessment.md を基に作成。