lifecycle-play-advisor について
成長が止まった製品について、拡張、置き換え、終了、または現状維持のどれが適切かを診断するスキルです。ライフサイクルと圧力の要因を分析し、実行に使う別のスキルへ案内します。
主な機能
- 017つの質問で段階を診断
- 02需要・コスト・能力の圧力を区別
- 03製品拡張の実現性を検証
- 04拡張・置き換え・終了・保留を提案
- 05判断根拠と次の進め方を提示
活用シーン
- 01横ばいの製品に変更が必要か評価
- 02販売経路と製品自体の不調を区別
- 03拡張・置き換え・終了を比較
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/lifecycle-play-advisorを入力して読み込まれたか確認します。
詳細
ライフサイクルプレイアドバイザー
目的
成長が止まった製品に何をすべきかを判断します。選択肢は 拡張、置き換え、終了 の3つです。このスキルでは議論を重ねるのではなく、診断を通じて適切な選択肢を導き、その実行を担うスキルへ引き継ぎます。
多くのチームは、製品の段階を確認する前に、どの選択肢にするかを議論します。実際に製品に何が起きているのかについて、誰も合意できていないため、そのやり方では結論が出ません。4つの質問で解決できます。
このスキルは、ためらわずに 「まだ何もしない」 と提案します。サポートコストが管理可能で、利益を生み出している成熟製品には、特別な対応は必要ありません。そのままにして、状況を見守ればよいのです。
入力
特に役立つ情報： 対象製品と、何かを変える必要があると考える理由。
あるとさらに役立つ情報： 収益の推移とその期間、サポートの負荷、顧客の声、社内の要因（コスト、キャパシティ、戦略）が本当に問題の背景にあるのか、どの程度の投資意欲があるのか。
スキルの呼び出しと同時に提供された情報（スキル名の後に続くテキスト、貼り付けられたコンテキストのダンプ、追記された ARGUMENTS: 行など）は、回答済みの情報として扱います。それを使い、該当する内容については質問を省略してください。
何も準備していなくても大丈夫です。 診断は、PM がすでに把握していることに基づいて回答できる質問で進みます。レポートを取り寄せる必要はありません。「わかりません」も有効な回答であり、推奨内容に明示的な前提として記載されます。
呼び出し例：
当社のレポートモジュールは6四半期にわたって横ばいで、再構築を望む声があります。拡張、置き換え、終了のどれがよいでしょうか？経営陣は当社の部品モジュールを廃止したがっています。それが正しいか、一緒に検討してください。
重要な概念
3つの選択肢
- 拡張 — 既存の製品ラインにバリエーションや機能を追加します。製品の運用を続けながら、既存ラインに追加します。最も安価でリスクが低く、魅力に欠けるため最も見落とされがちな選択肢です。
- 置き換え — 後継製品をリリースし、旧製品を段階的に廃止します。互いに競合する2つの製品について、GTM と EOL を同時に進めます。最も費用のかかる選択肢です。
- 終了 — 自社で後継製品を用意せず、段階的に廃止します。顧客は、場合によっては競合他社の製品など、別の選択肢へ移ります。目標は、顧客を失わずに製品を終了することです。
そして、選択肢ではない4つ目の答えが 収穫 です。投資を止め、運用を続け、見直し日を設定します。
選択肢を決める前に診断する
7つの移行に関する質問で段階を把握し、圧力の源を見極めて、どの選択肢が適切かを判断します。何かを推奨する前に両方を確認し、判断の根拠を示してください。ユーザーが検証できる推奨内容なら、他の人にも説明できます。
拡張を優先して検討する
実際の圧力に対処できる、最も安価な選択肢をデフォルトにします。 ほとんどの場では、拡張が十分に検討されません。置き換えのほうが開発の面で興味を引き、終了のほうが発表しやすいからです。拡張を明示的に検討し、うまくいかなかった場合は、その理由を記録してください。
アンチパターン（このスキルが扱わないこと）
- 成長戦略ツールではありません。 次の成長をどこから得るかは別の問いです。
ansoff-matrixとorganic-growth-advisorを参照してください。 - 終了スイッチではありません。 「まだ何もしない」と「収穫」は、どちらも正当な結果です。
- 実行そのものではありません。 選んだ施策を実行するスキルへ引き継ぎます。
ファシリテーションの基準
対話の進め方には workshop-facilitation を使ってください。冒頭で、4つの質問に約15分かかることを伝え、ユーザーがコンテキストをまとめて提示できるようにして、先へ進めてください。
適用
このスキルでは 最大4つの適応型質問 を行い、その後、判断の根拠、注意点、次の行き先とともに選択肢を推奨します。
質問 1／4 — どの製品について、何がおかしいと考えていますか？
エージェントが尋ねます：
「どの製品について話しているのでしょうか。また、何がきっかけでこの質問が出たのでしょうか。きっかけは製品と同じくらい重要です。売上の横ばい、サポートコストの上昇、競合の動き、経営幹部の発言では、診断が大きく異なります。」
きっかけが社内要因か社外要因かに注目してください。 社内要因（製造部門が生産ラインを求めている、エンジニアリング部門が書き直しを望んでいる、財務部門がコスト削減を求めている）は正当な理由ですが、顧客にとっての変更の必要性が弱く、移行を全面的にあなたが担わなければならないことを意味します。早い段階で明確にしましょう。必要な取り組みが変わります。
質問 2／4 — ライフサイクルのどの段階にあるのでしょうか？
エージェントが尋ねます：
「まず段階を確認しましょう。簡単な質問が7つあります。はい／いいえで答えてください。直感的な回答でかまいません。
- 市場シェアの維持は、まだ利益につながっていますか？
- 顧客ロイヤルティの取り組みでは、ユーザーをつなぎとめられなくなっていますか？
- レガシー製品のサポートコストが持続不可能な水準になりつつありますか？
- ロイヤルティ施策より、移行キャンペーンを実施すべき段階ですか？
- 特定の流通チャネルで赤字になっていますか？
- 付加価値バンドルの効果が薄れてきていますか？
- データが予測型から移行型へと変化していますか？」
スコアを確認します：
| はいの数 | 段階 | 意味 |
|---|---|---|
| 0-1 | 成熟期で健全 | 対応は不要です。投資するか、現状を維持してください |
| 2-3 | 成熟期で軟化 | 延命策を検討する段階です。四半期ごとに注視してください |
| 4-5 | 衰退期への移行中 | 今、意図を持って対応策を選んでください |
| 6-7 | 衰退期 | 置き換えるか、終了してください。延命策では先送りになるだけでしょう |
スコアを伝え、数だけでなくパターンも示してください。 5と6（チャネルと価格）に「はい」が集中している場合と、3と7（サポートコストとデータ）に集中している場合では、対応が大きく異なります。前者は、流通の問題が製品の問題に見えているパターンです。
質問 3／4 — 圧力の本当の原因は何でしょうか？
エージェントが尋ねます：
「原因は3つあります。最も大きいのはどれでしょうか？
- 需要側 — 顧客ニーズの変化、セグメントの移動、競合による差別化
- 供給／コスト側 — 部品、生産コスト、サポート負荷、戦略変更
- 能力側 — テクノロジーの陳腐化、またはアーキテクチャの限界到達
2つ当てはまる場合でも、主要なものを1つ選んでください。」
この質問で原因を見分けられる理由：
| 圧力 | 示唆される対応 | 理由 |
|---|---|---|
| 需要側 | 延命 | その製品は、まだ誰かの現実の課題を解決しています。その顧客を見つけましょう |
| 供給／コスト側 | 置き換え | 問題は顧客のニーズではなく、自社の経済性です |
| 能力側 | 置き換えまたは終了 | ニーズがテクノロジーの変化後も残るかどうかで決まります |
落とし穴をはっきり伝えてください。 供給側の圧力は、顧客の問題を装ってロードマップに持ち込まれます。「これを作り直す必要がある」は、多くの場合「コストに問題がある」という意味です。これは置き換えの正当な理由ですが、率直に伝えることで、成功の定義と移行を担う人が変わります。
質問 4／4 — 延命策を検証します
エージェントが尋ねます：
「さらにコストのかかる提案をする前に、今あるものを延命できるか、4つの質問で確認しましょう。
- バリアントで対応できるセグメントはありますか？
- アーキテクチャを作り直さずに追加できる機能はありますか？
- 再パッケージ化やブランド変更で、別の購入者に届けられますか？
- 衰退しているのは製品ですか。それとも、その周囲のチャネルや価格ですか？」
質問4は、この中で最もコストのかかる誤診を見つけます。流通チャネルが機能しなくなったり、バンドルの魅力が薄れたりしたために、健全な製品が見限られてしまうケースです。製品を置き換えるより、原因となる要素を修正する方がはるかに安価です。修正しなければ、問題を抱えた要素は後継製品にもそのまま引き継がれます。
4つすべてが「いいえ」なら、延命は本当に選択肢から外れています。その場合、3か月後に誰かから尋ねられたときのために、「いいえ。その理由は……」という記録が残ります。
最終ステップ：プレイを推奨する
次の構成で提示します：
## Lifecycle Play Recommendation: [Product]
**Stage:** [stage] — [n]/7 transition questions, clustered on [which]
**Primary pressure:** [demand / supply-cost / capability] — [evidence]
**Trigger was:** [internal / external] — [what that means for the transition]
### Recommended Play: [Extend / Replace / Retire / Harvest / Nothing yet]
**Because:** [two or three specifics from their answers]
**Extension test:** [passed and how, or failed and why — always state it]
**What this play costs:** [rough shape]
**What you're accepting by choosing it:** [the tradeoff, plainly]
### Hazards to plan for
- [The 2-3 hazards that apply to this play, from the seven]
### Assumptions I made
- [Anything answered "I don't know"]
次に、番号付きの次のステップを提示します：
「次はどこへ進みますか？
- 廃止をきちんと実行する — go/no-go の判断には
eol-readiness-advisor、全体を進めるにはeol-processを参照してください - ** replacement のリスク登録簿を構築する** —
product-lifecycle-plays、特に 7 つの危険要因を参照してください - 延長を計画する — その派生版がどの成長パスに寄与するかについては
organic-growth-advisorを参照してください - これをライン全体で実行する —
product-lifecycle-playsのポートフォリオワークシートを参照してください
番号を選ぶか、組み合わせるか、あるいはやりたいことを教えてください。」
Replace の推奨では、必ず次の一行を追加してください：「置き換えとは、資金提供された 2 つのワークストリーム — 立ち上げと廃止 — です。廃止に資金がついていないなら、あなたが選んだのは余分なステップを伴う延長です。」
例
例 A — SaaS、答えは「壊れているのはチャネルであって、製品ではない」
PM：「当社の Parts モジュールは 5 四半期にわたって横ばいです。経営陣はこれをコアプラットフォームに統合し、個別販売をやめたいと考えています。」
エージェント（Q1）：「きっかけは何でしたか — 顧客からのシグナルですか、それとも社内のものですか？」
PM：「社内です。最も小さい科目で、誰かが気づいたのです。」
エージェント：「承知しました — それは社内のトリガーです。つまり、移行を支える助けとなる顧客からの圧力がありません。製品が経営陣に同意するか見てみましょう。」
エージェント（Q2）： 7 つの質問を実行します。 5（特定のチャネルで損失が出ている）と 6（バンドルの効果が失われている）が「はい」。それ以外はすべて「いいえ」。
エージェント：「7 つ中 2 つ — 成熟して軟化しているのであって、衰退しているのではありません。そしてパターンが興味深い点です：あなたの『はい』は両方ともチャネルと価格に関するものです。製品そのものについて否定的な結果は何も返ってきませんでした。サポートコストは問題なく、維持率も問題ありません。」
エージェント（Q3）：「圧力の原因は何ですか？」
PM：「正直に言うと？ 当社は他と同じ動きでこれを販売していますが、それが合っていません。営業担当はこれを前面に出しません。」
エージェント（Q4）： 延長テスト。 セグメント — はい、ディストリビューターは読み取り専用ティアを求めています。ケイパビリティ — はい、読み取り専用ビューは軽微な作業です。再パッケージ — はい、まさにそれが要望です。チャネルか製品か — チャネル。
推奨：延長し、チャネルを修正する。 ステージは成熟・軟化を示しています。両方の衰退シグナルは流通と価格にあり、製品にはありません。読み取り専用のディストリビューターティアは、積極的に要望を出したセグメントに対応し、軽微な作業です。これをコアに統合すると、販売動線の問題を解決するために健全な製品を廃止することになり — しかも販売動線の問題は統合後も生き残ったでしょう。
あなたが受け入れるもの： ディストリビューターティアとは、新しい買い手タイプをサポートすることを意味します。小さいですが、ゼロではありません。
例 B — 産業機器：答えは「置き換えて、廃止のための資金を確保する」
PM：「製造部門が、NFA-500の生産能力を確保するためにNFA-200のラインを求めています。そこでNFA-200を廃止します。」
エージェント（Q1）：「それは社内のきっかけです。顧客のニーズではなく、生産能力の制約です。最初に指摘しておくと、ここでは顧客向けの変更理由が弱いため、移行の負担はすべて自社が負うことになります。売上の推移はどうですか？」
PM：「4四半期横ばいです。サービス売上は実際には伸びています。」
エージェント（Q2）： 7つの質問を実施します。 4、6、7が「はい」、1はやや当てはまります。サポートコストは問題なく、顧客維持率は高く、チャネルも利益を上げています。
エージェント：「7つ中4つです。成熟して弱まりつつありますが、衰退しているわけではありません。既存顧客はロイヤルティが高く、契約中で、サービスの利益率も健全です。これは重要です。つまり、製品の不具合が原因ではありません。工場の床面積を取り戻したいという話です。」
エージェント（Q3）：「主な圧力は何ですか？」
PM：「供給側です。製造能力の問題です。」
エージェント（Q4）： 拡張性を検証します。 セグメント — 部分的に可能です。モジュール式I/Oのバリアントがあれば、より大規模な案件に対応できます。再設計せずに機能を拡張 — できません。新しいバックプレーンが必要です。再パッケージ — できません。産業機器の購入者は機能を指定します。チャネル変更または製品変更 — どちらも該当しません。
エージェント：「率直に言っておくべきことがあります。顧客が求める拡張機能は、まさに NFA-500 です。これは置き換えが正しい選択であることを強く示しています。同時に、決定する前に答えるべき問いも浮かび上がります。NFA-500は、既存の設置環境にそのまま置き換えられますか？」
PM：「……そうだと思っていました。実際には確認していません。」
推奨：置き換え — ただし、その問いへの回答を判断条件とします。
計画すべきリスク： 社内の不一致（中）、カニバリゼーション（意図的、影響は小）、そして**EOL管理の不備（影響大）**です。EOL管理のリスクは、既存環境にそのまま置き換えられるかどうかで決まります。NFA-500に異なる取り付け方法や現地作業が必要なら、移行パスがあるのではなく、プロジェクトが必要になります。その場合、EOLの日付を約束しても守れません。
ラベル付けした前提： そのまま置き換えられる互換性は未検証です。
そして、「置き換え」を選ぶときに必ず伝えること： 置き換えには、資金を確保した2つの作業計画が必要です。新製品の立ち上げと、旧製品の廃止です。改修エンジニアリングに資金を確保していないなら、余計な手順を加えた拡張を選んだことになります。
よくある落とし穴
落とし穴 1：段階を見極める前に戦略を推奨する
症状： ユーザーが最初のメッセージで戦略を挙げ、会話がその最適化に進みます。
結果： 診断を行わずに意見を肯定してしまい、その中にあるコストの高い前提が検証されません。
対策： ユーザーが確信を持っていても、Q2を実施します。2分で済み、考えを裏付けるか、1年を無駄にせずに済みます。
落とし穴 2：件数で傾向を判断する
症状：「7つ中4つだから、衰退しています。」
結果： チャネルと価格に集中した「はい」4つと、サポートコストとアーキテクチャに集中した「はい」4つでは、意味がまったく異なります。件数だけでは、判断を誤らせます。
対策： どの質問が「はい」だったかを必ず挙げ、その組み合わせが何を意味するかを伝えます。
落とし穴 3：社内のきっかけをそのまま受け入れる
症状：「製造部門がこのラインを求めている」が「製品を廃止すべき」に変わります。
結果： 実際のニーズを、販売終了、価格変更、または再パッケージでより安く満たせるのに、全面的な廃止を進めてしまいます。
対策： きっかけが社内のものであると明示したうえで、具体的に何が必要なのかを尋ねます。多くの場合、より安価な対応で実現できます。
落とし穴 4：明白なケースだからと拡張性の検証を省く
症状： 製品が明らかに衰退しているため、Q4を簡単に済ませます。
結果： 拡張がうまくいかなかった理由を記録できません。3か月後に誰かに尋ねられても、肩をすくめるしかありません。
対策： どの場合でも4つすべてを尋ねます。本当に終わっている製品なら90秒で済み、根拠のある「いいえ、その理由は……」という回答を残せます。
落とし穴 5：「まだ何もない」を無回答として扱う
症状： 成果を出すことが価値を生み出すように感じられるため、毎回施策を提案してしまいます。
結果： 健全で成熟したプロダクトに、本来必要のなかったプロジェクトが生まれ、もっと有効に使えるはずだった予算が投入されます。
対処法： 「はい」が 0～1 件なら、施策はありません。そう伝え、レビュー日を設定して、そこで終了します。
参考資料
関連スキル
これらはそれぞれ独立して使えます。いずれもこのスキルの前提ではなく、このスキルもそれらの前提ではありません。
product-lifecycle-plays— このトリアージの基盤となるフレームワーク：戦略グリッド、7 つの落とし穴、リスク登録簿、ポートフォリオ用ワークシートeol-readiness-advisor— 製品終了施策の実行可否判断eol-process— 製品終了を最初から最後まで進める方法organic-growth-advisor— 拡張がどの成長経路に貢献するかansoff-matrix— 次の成長の段階がどこから生まれるかworkshop-facilitation— 対話プロトコル
外部フレームワーク
- プロダクトライフサイクル（PLC）— 5 段階の経済モデル
- PLC 戦略グリッド — 各段階のマーケティングミックスの施策
出典
- ソフトウェア、ハードウェア、規制産業におけるプロダクトライフサイクルの移行と製品終了を実践した経験から要点を抽出しています。