eol-process

EOL プロセス

目的

製品の提供終了を最初から最後まで進めます。実施するかどうかを決定し、中止を決められる関係者の合意を得て、運用計画を策定し、顧客対応にあたるチームを準備し、告知を行い、適切に終了します。意思決定の節目を挟んだ6つのフェーズで構成されています。

全体を通じて心に留めておくべき指針、そして覚えておく価値のある一文は、顧客を失うことなく製品を終了することです。 以下の大部分は、この文の後半を守るためにあります。

これはオーケストレーションスキルです。成果物を作るスキルに取って代わるものではなく、どれをいつ使うべきか、次に進む前に何が満たされている必要があるかを示します。

入力

最も効果的な入力： 終了する製品と、現在の段階（検討中、決定済み、計画の途中、または告知済みだが問題が起きている）。

あると役立つ情報： 規模（顧客数、売上、契約）、代替製品の有無、すでに知っている人。

スキルの呼び出し時に渡されたもの（スキル名の後に続くテキスト、貼り付けられたコンテキスト、または追記された ARGUMENTS: の行）は、すでに回答済みの内容として扱います。それを使用し、含まれている項目は再度尋ねないでください。

何も準備していなくても問題ありません。 このプロセスでは、まず終了する製品と現在の段階を確認し、その後、適切なフェーズに進みます。終了プロセスの途中で問題が起きている場合は、その旨を伝えてください。「途中から開始する場合」の診断で、飛ばしたフェーズを特定します。

呼び出し例：

• Run the full EOL process for our legacy reporting module — decision made, nothing else started.
• We announced a sunset three weeks ago and Support is drowning. What did we skip?

---

主要な概念

6つのフェーズ

#	フェーズ	答える問い	主な成果物
1	決定	これを終了すべきか、規模はどの程度か？	準備状況の評価＋強度レベル
2	合意形成	中止を決められるのは誰か、私たちが知らない情報を誰が持っているか？	ステークホルダーへの順序
3	計画	何をいつまでに行い、誰が担当するか？	フェーズごとのチェックリスト
4	準備	顧客に伝える前に、社内の担当者は準備できているか？	社内向け準備資料一式
5	告知	顧客に何を、いつ伝えるか？	顧客向けEOLメッセージ
6	終了	すべて完了したか、何を学んだか？	EOL後の振り返り

フェーズ6は、誰もが飛ばしてしまうフェーズです。 しかし、次回の終了プロセスをより低コストにするフェーズでもあります。 最初から予算を確保してください。後になってから自発的に担当する人はいないからです。

これはルートであり、パイプラインではありません

このスイートの各スキルは、それぞれ単独で使えます。ほかのスキルを先に実行しておく必要はありません。このプロセスは、独立した各段階を進むための推奨ルートであり、ベルトコンベアではありません。つまり、次のことが可能です。

• どのフェーズからでも開始できます。 すでに決定済みで、その根拠も明確ですか？ フェーズ2から始めてください。
• レベルに応じてフェーズを飛ばせます。 レベル1の終了であれば、多くの場合、フェーズ2から4までを1回の午後にまとめて実施できます。
• 前のフェーズに戻ることも、ときには必要です。 フェーズ2でフェーズ1に戻ることはよくあります。法務上の指摘や営業上のコミットメントによって、決定が無効になることもあります。これはプロセスの失敗ではなく、プロセスが機能している証拠です。
• 形式を引き継ぐ仕組みはありません。 フェーズ間でコンテキストを引き継ぐには、次のスキルに「レベル2」と伝え、手元の情報を貼り付けます。維持すべきスキーマはありません。

各フェーズが次のフェーズに必要な情報を明らかにするため、この順序には意味があります。順序を変える場合は、意図的に行い、うっかり変えてしまわないようにしてください。

プロセス全体の規模を適切に調整する

EOL の進み方は一様ではありません。 終了の規模に応じて、プロセスを短縮または拡張します。

	レベル 1 — 軽量	レベル 2 — 標準	レベル 3 — 大規模
一般的な対象範囲	機能、社内ツール、API	商用製品、アクティブな顧客	収益上重要な製品、ハードウェア、規制対象
経過期間	数日〜数週間	6〜12 か月	12〜24 か月
フェーズ 2 の停止条件	3〜4 件	7〜8 件	10 件以上
フェーズ 3 のゲート	2〜3 フェーズ、ゲート基準なし	ゲートを設けた 4〜5 フェーズ	全 6 フェーズ、承認者を設けたゲート
フェーズ 4 の成果物	サポート FAQ	＋ 営業向けポイント、反論への対応、エスカレーション	＋ 販売チャネル向け概要、トレーニング
フェーズ 5 のメッセージ	簡潔なお知らせ	フェーズ表を含む標準的な内容	コンプライアンスに対応した、段階的な詳細内容
フェーズ 2〜4	多くの場合、1 回の会議にまとめられます	個別に順を追って進めます	個別に進め、それぞれに独自の作業ストリームを設けます

レベル 2 をデフォルトにします。 フェーズ 1 でレベルを設定し、その後のすべての規模をそれに合わせます。 レベル 3 をデフォルトにしてはいけません。小規模な終了で形だけのプロセスを行うと、大規模な終了でもプロセスが無視されるようになります。

途中から参加する場合

このスキルを見つける人の多くは、終了プロセスの途中、それも問題が起きている最中であることがよくあります。症状から、抜けていたフェーズを特定できます。

症状	抜けていたフェーズ	今すべきこと
「法務が契約上の問題を見つけた」	2（調整）	いったん止めます。フェーズ 1 に戻ります。判断自体が維持できない可能性があります
「営業は、これを永久に提供すると約束したと言っている」	2（調整）	これ以上連絡する前に、現場での約束をすべて洗い出します
「サポートがチケット対応に追われている」	4（準備）	FAQ とエスカレーションの手順を今日公開し、残りは後から補います
「顧客から、そんな話は聞いていないと言われた」	5（告知）	日付を明記して再告知します。最初のお知らせは届いていませんでした
「誰が何を担当するのか、誰も知らない」	3（計画）	チェックリストを作成します。担当者がいないことが失敗の原因です
「停止したら、あちこちで問題が起きた」	3（計画）	下流で影響を受ける関係者が洗い出されていませんでした
「実施したのに、何も学べなかった」	6（完了）	今すぐ振り返りを行います。記憶はすぐに薄れていきます

ファシリテーションの信頼できる情報源

いずれかのフェーズを会話形式で進める際は、やり取りの手順として workshop-facilitation を使用します。事前に概要を伝え、背景情報を共有してもらい、番号付きの選択肢を提示し、特定のフェーズに移って終了できるようにします。

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

• プロジェクト計画ではありません。 タスクやリソースではなく、判断と成果物の順序を定めます。
• すべてを必ず実施するものではありません。 レベル 1 で 6 フェーズすべてを行うのは、この一連のスキルが防ごうとしている形式主義の失敗です。
• 会話の代わりにはなりません。 フェーズ 2 は、人々が話し合う場であり、文書ではありません。
• 一方向のプロセスではありません。 フェーズ 1 に戻るのは、ロールバックではなく、成功の条件です。

---

適用

進行中の終了プロセスを管理する 1 ページのトラッカーとして、template.md を使用します。

このワークフローでは、6 つのフェーズをそれぞれの後に判断ポイントを設けて進めます。期間はレベル 1 の数日からレベル 3 の 2 年までです。フェーズ 1 でレベルを設定し、残りの規模をそれに合わせます。各フェーズでは成果物を作成するスキルを示していますが、いずれのスキルも単独で実行できるため、実際にいるフェーズから始めてください。

---

フェーズ 1：判断する

問い： これを終了すべきでしょうか。また、どの程度の規模でしょうか。

アクティビティ

1. きっかけを正直に明らかにします。指標、戦略の転換、コストへの不満、経営幹部の発言などが考えられます。きっかけから、想定される失敗の形を予測できます。
2. 終了を示す兆候と、継続を示す兆候を評価します。強い終了の兆候が 2 つ以上あれば、終了を検討する十分な理由があります。ただし、義務による制約や移行先がないことは、そのすべてに優先する場合があります。
3. 規模のレベルを設定します。 影響範囲を基に推奨レベルを決めたうえで、慎重に選択します。これによって、後続のすべてのフェーズの規模が決まります。
4. 移行先を確認します。代替手段、移行先、または円滑な終了のいずれかと、それが準備できているかを確認します。

このフェーズでは eol-readiness-advisor を実行します。

出力

• 判定：Go、Go-with-conditions、Hold、Harvest のいずれか
• 強度レベル（1、2、または3）
• 準備状況を示すステータス付きの移行先の名称
• 発表前に確認すべき義務の一覧

判断ポイント 1：これは Go か。移行先は実在するか。

• Go → フェーズ2に進みます
• Go-with-conditions → フェーズ2に進み、条件をフェーズ5のゲートとして引き継ぎます
• Hold → 停止します。再検討のきっかけを設定します。より低コストの対応（販売終了のみ、価格変更、バグ修正）で実際のニーズを満たせるか検討します
• Harvest → 製品ではなく、投資を停止します。レビュー日を設定します

移行先の準備ができていない場合、フェーズ2〜4は進めてもかまいませんが、フェーズ5には進めません。まだ支えられない移行を発表しないでください。

---

フェーズ2：調整

質問： 誰がこれを止める可能性があり、その人たちは私たちが知らない何を知っていますか。

実施事項

1. 停止判断に関わる関係者を順序付けます：法務、財務、営業、マーケティング、CS、対応が難しい顧客、エンジニアリング、サポート（レベルに応じて絞り込み）、さらにレベル3では経営陣、チャネル、規制関連も含めます。
2. 各関係者について、相手から得る必要があるものと、相手に対して果たす義務を準備します。
3. 順番に話し合いを行います。それぞれの話し合いが次に活かされます。
4. 判明した内容、特に現場での約束、契約条件、隠れた依存関係を記録します。

このフェーズでは eol-stakeholder-sequence を実行します。

出力

• 各関係者との話し合いの結果を記録した一連のプロセス
• 発見した約束、義務、依存関係の一覧
• 最も対応が難しい顧客を踏まえて改訂した影響一覧

判断ポイント 2：判断を無効にする要因は見つかりましたか。

これはプロセスで最も重要なゲートであり、チームが形式的な手続きとして扱っているゲートでもあります。

• 妨げとなるものがない → フェーズ3に進みます
• 契約、規制、または約束がスケジュールを妨げる → フェーズ1に戻ります。新たな証拠を踏まえて再評価します。日程を変更するか、範囲を変更するか、判定を覆します
• 移行先が想定より脆弱だと判明する → フェーズ1に戻ります。これは最もよく見つかる問題であり、通常は対応が難しい顧客との話し合いで明らかになります

ここでフェーズ1に戻るのは容易です。フェーズ5の後で同じことが判明しても、そうはいきません。

---

フェーズ3：計画

質問： 何を、いつまでに実施し、誰が担当しますか。

実施事項

1. 対象とするライフサイクルのゲートを選びます。意図的に使用しないゲートも明記します。
2. 設定したレベルに応じて、フェーズごと、機能領域ごとに項目を作成します。各項目は動詞で始め、4〜8語で、担当する機能部門を明記します。
3. 各フェーズの移行に関するゲート基準を承認者とともに記載します（レベル2以上）。
4. 販売終了によって影響を受ける4つの項目を網羅します：データ、契約、アクセス、資金。
5. フェーズ4の「イネーブルメント完了」日を、フェーズ5の発表日より前に計画に記載します。

このフェーズでは eol-checklist を実行します。

出力

• 担当者と日付を記載した、フェーズごとのゲート付きチェックリスト
• 承認者を明記したゲート基準
• フェーズ6のレビューを含む、担当者が明確な販売終了後の対応
• 検証すべき前提条件

判断ポイント 3：すべての項目に担当者がいて、すべての日付に根拠がありますか。

• 担当者のいない項目 → それが明らかになった問題です。取り繕うのではなく、エスカレーションします
• 根拠を示せない日付 → TBD、または前提条件を添えて Not scheduled と記載します。根拠のない販売終了日を設定すれば、公の場で破ることになる約束をしてしまいます
• イネーブルメント日が発表日より前ではない → 今すぐ修正します。実際には両者が同じ日になってしまいます

---

フェーズ4：準備

質問： 顧客に伝える前に、社内の人員は準備できていますか。

アクティビティ

1. 顧客から実際に寄せられる質問に沿って、問い合わせ件数の多い順にサポート FAQ を作成します。
2. 正直な比較表を含むセールストークを作成します — 不足している点も含めます。
3. Acknowledge-Reframe-Offer を使って反論への対応を作成し、提案する内容はすべて事前承認を得ます。
4. エスカレーションの段階を明確にします — 4 段階で、実在する担当者を割り当てます。
5. レベル 3 では、チャネルパートナー向けの説明資料を追加し、ロールプレイを交えたライブトレーニングを実施します。

このフェーズでは eol-internal-enablement を実行します。

成果物

• レベルに応じたエネーブルメントパック
• 金曜日の午後 4 時でも営業担当者が使えるエスカレーションの段階
• 公開告知前に説明を受けたパートナー（レベル 3）

判断ポイント 4：エネーブルメントは本当に完了していますか？

ここが告知の前提条件です。 EOL の告知で最も避けるべきなのは、顧客への告知の 5 分前に、サポートと営業に告知内容を渡すことです。

確認しましょう。解約の恐れがある顧客について誰に連絡するかを営業担当者に尋ね、最も難しい反論への回答を声に出してもらいます。どちらかの答えが曖昧なら、告知の準備はできていません。

---

フェーズ 5：告知する

質問： 顧客には何を、いつ伝えますか？

アクティビティ

1. メッセージの規模を決めます：簡潔版、標準版、完全版。
2. 方針を選びます：代替、移行、または円満な終了 — それぞれ異なるメッセージになります。
3. 9 セクションのフレームワークに沿って草案を作成し、メリットを訴える前に影響を認めます。
4. 社内略語ではなく、顧客への影響を基準として各ゲートを明示します。
5. 付箋テストを実施します：一度読んだだけで、顧客は何をいつまでにすべきかを書き出せますか？
6. 必要に応じてセグメント分けします — エンタープライズ、SMB、リスクの高いアカウント、パートナーには、それぞれ異なる情報が必要です。

このフェーズでは eol-message を実行します。

成果物

• 規模と方針を考慮した顧客向け告知
• 必要に応じたセグメント別のバリエーション
• 1 回限りの送信ではなく、各ゲートに合わせたコミュニケーションカレンダー

判断ポイント 5：告知内容は実際の状況に耐えられますか？

送信前に、次の 3 点を確認します。

• 法務が確認している — 特に契約、返金、認証に関する記述
• 顧客に販売した内容と矛盾していない — フェーズ 2 で確認した現場でのコミットメントと照合します
• サポートに先に共有している — 読むための十分な時間を確保します

---

フェーズ 6：完了する

質問： 完了しましたか？ 何を学びましたか？

アクティビティ

1. 各ゲートに到達したら、その段階を確認します。移行ごとに基準を満たし、承認者の承認を得る必要があります — ゲートはカレンダー上の予定ではなく、コミットメントです。
2. フェーズ 3 の目標に照らして、移行または切り替えの進捗を追跡します。進捗がまったくないアカウントは、最終ゲートではなく早い段階でエスカレーションします。
3. 完了項目に対応します：データのエクスポート期間の遵守、削除のスケジュール、契約の終了、収益認識の終了、インフラの廃止、ドキュメントのアーカイブ。
4. 教訓の振り返りを実施します。 何が予想外だったか、どのフェーズへの投資が不足していたか、難しい顧客が何を見つけたか、予測に対して実際の維持率はどうだったかを確認します。
5. EOL の日付が未設定の場合は、前提条件を、レビュー日とともに明確な担当者へ引き継ぎます。

成果物

• 承認を得て完了した各ゲート
• 予測と照合した最終的な維持率または移行の数値
• 文書化された教訓の振り返り
• 繰り延べた判断と明確な担当者

判断ポイント 6：本当に完了していますか？

完了とは、サービスの停止日を迎えることではありません。データが削除または引き渡され、契約が精算され、収益が認識され、何が起きたかを誰かが記録した時点で完了です。振り返りを実施していなければ、サービス終了はまだ完了していません — ただ静かになっただけです。

---

ワークフロー全体：最初から最後までの概要

PHASE 1: DECIDE                          -> eol-readiness-advisor
  Trigger -> signals -> intensity level -> landing place
  DP1: Go / Go-with-conditions / Hold / Harvest
       Landing place not ready? Phases 2-4 OK, Phase 5 blocked
       |
PHASE 2: ALIGN                           -> eol-stakeholder-sequence
  Legal -> Finance -> Sales -> Marketing -> CS -> difficult customers
  -> Engineering -> Support  (+ Execs, Channel, Regulatory at L3)
  DP2: Did anything invalidate the decision?  --[yes]--> back to Phase 1
       |
PHASE 3: PLAN                            -> eol-checklist
  Gates in scope -> items with owners -> gate criteria -> data,
  contracts, access, money -> enablement date BEFORE announce date
  DP3: Every item owned? Every date real?
       |
PHASE 4: PREPARE                         -> eol-internal-enablement
  Support FAQ -> sales points with gaps -> objections (offers
  pre-approved) -> escalation ladder -> channel brief + training (L3)
  DP4: Enablement complete?  --[no]--> DO NOT ANNOUNCE
       |
PHASE 5: ANNOUNCE                        -> eol-message
  Size -> path -> draft -> sticky-note test -> segment -> comms calendar
  DP5: Legal read it? Consistent with field promises? Support has it?
       |
PHASE 6: CLOSE                           -> (this skill)
  Walk gates -> track progress -> close data/contracts/money ->
  LESSONS-LEARNED REVIEW -> own any deferred decisions
  DP6: Data settled, contracts closed, review written?

レベル 1 の簡略化： フェーズ 2、3、4 は、短いステークホルダー一覧、対応事項のリスト、サポート FAQ を用意するだけで、1 回の作業にまとめられることがよくあります。フェーズ 1、5、6 は引き続き実施します。特に 6 は必ず実施します。

---

例

• examples/sample.md — Fieldlight Classic Dispatch（SaaS、レベル 2、10 か月にわたる6つすべてのフェーズ）
• examples/sample-industrial.md — NFA-200 コントローラーライン（産業用、レベル 3、フェーズ 2 からプロセスがフェーズ 1 に戻り、結果が変わるケース）

---

よくある落とし穴

落とし穴 1：フェーズ 5 から始める

症状： 最初に作成する成果物が、顧客向けのお知らせになっています。

結果： お知らせを出した後に、契約条件や現場での約束、移行手段の欠如に気づきます。しかも、すでに日付を約束した状態で、公開されてしまいます。

対処法： お知らせが第5フェーズなのには理由があります。それまでのすべてのフェーズは、お知らせを無事に実施するためにあります。

---

落とし穴 2：意思決定ポイント 2 を形式的なものとして扱う

症状： ステークホルダーとの話し合いを行い、見つかったことを記録しても、計画は変更せずに進めます。

結果： 話し合いを行いながら、その内容を無視してしまいます。話し合いを省略するよりも悪い結果です。警告した証人がいることになるからです。

対処法： DP2 は実質的なゲートです。法務部門や対応の難しい顧客から重要な問題が明らかになった場合は、フェーズ 1 に戻って再評価してください。このループは、プロセスが機能している証拠です。

---

落とし穴 3：イネーブルメントの前に告知する

症状： フェーズ 4 とフェーズ 5 が同じ週に実施されるか、フェーズ 4 が遅れてフェーズ 5 が実施されなくなります。

結果： サポートチームが3日間、その場しのぎの対応を行い、その対応が一貫性のないまま事実上のポリシーになってしまいます。

対処法： DP4 で計画を確認し、DP5 の実施を判断します。日程は分けてください。イネーブルメントが遅れた場合は、告知も延期します。

---

落とし穴 4：小規模なサンセットでプロセスを過剰に演出する

症状： 廃止予定の機能に対し、10回ものステークホルダーとの調整やトレーニングプログラムを実施します。

結果： EOL プロセスは官僚的だと皆が学び、次回から省略するようになります。そして、次回は契約が関わる案件です。

対処法： フェーズ 1 でレベルを正直に設定してください。レベル 1 のサンセットを午後のうちに適切に完了できれば、それは成功です。

---

落とし穴 5：フェーズ 6 を省略する

症状： 製品の提供が終了し、チームは次に進み、誰も何も記録に残しません。

結果： 次のサンセットでも同じ失敗が繰り返され、データ削除や契約終了に関する項目がひそかに未対応のまま残ります。

対処法： 関係者の関心が残っているうちに、担当者を明記したレビューをフェーズ 3 のチェックリストに入れてください。完了はサービス終了日を意味するものではありません。

---

落とし穴 6：製品と一緒に顧客も失う

症状： すべてのフェーズを適切に実行しますが、測定対象は社内の完了状況だけです。

結果： 製品の終了はきれいに実施できても、解約が急増します。適切なプロセスを実施したにもかかわらず、顧客との関係を失います。

対処法： チェックリストの完了ではなく、顧客維持率を成果指標として追跡してください。目標は、顧客を失わずに製品の提供を終了することです。後半が実現しなければ、プロセスは成功していません。

---

参考資料

関連スキル

以下の各スキルは単独で利用できます。このプロセスではそれらを順に活用する方法を推奨していますが、どのスキルもこのスキルを必要とせず、このスキルもすべてのスキルの実行を求めるものではありません。「レベル 2」と伝え、手元にある情報を貼り付けて、フェーズ間でコンテキストを引き継いでください。

• eol-readiness-advisor — フェーズ 1
• eol-stakeholder-sequence — フェーズ 2
• eol-checklist — フェーズ 3
• eol-internal-enablement — フェーズ 4
• eol-message — フェーズ 5
• workshop-facilitation — 全体を通じたインタラクションプロトコル
• positioning-statement — フェーズ 5 の移行ソリューション用
• stakeholder-map — フェーズ 2 で幅広い把握が必要な場合の一般的なマッピング

外部フレームワーク

• 製品ライフサイクル（PLC）— EOL は衰退期にあたります
• 業界における EOL ライフサイクルの慣行（GA/NSC/EOS/EOE/EOR/EOM/EOL/EOSRV）
• Acknowledge-Reframe-Offer — フェーズ 4 での異議対応

出典

• https://github.com/deanpeters/product-manager-prompts リポジトリの EOL プロンプトシリーズを統括します。