eol-checklist

EOL チェックリスト

目的

製品終了の決定を、フェーズごとに何を実施し、どのライフサイクルフェーズで行い、誰が担当するのかを定めた、フェーズゲート付きの運用計画に落とし込みます。成果物は実際に使えるチェックリストです。戦略文書ではなく、動詞と担当機能を明記した付箋サイズの項目をまとめます。

チェックリストは製品終了の規模に合わせて調整します。社内の非推奨ツールなら、3つのフェーズにまたがる12項目ほどで十分です。規制対象のハードウェア製品ラインなら、6つのフェーズにまたがり、フェーズ間のゲート基準を含む部門横断型のプレイブックが必要です。どちらも適切ですが、規模に合わないチェックリストを使うことが問題です。

入力

最も役立つ情報： 製品終了の対象と、すでに確定している日程。

あるとさらに役立つ情報： 顧客数や売上規模、代替製品の有無と準備状況、契約上または規制上の義務、ハードウェア、在庫、販売チャネルパートナーが関係するかどうか。

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

何も準備できていなくても大丈夫です。 スキルは、何をどの規模で終了するのか、代替製品があるか、確定している期限は何かを最大3つの質問で確認し、その後、レベルを選んでチェックリストを作成します。不明点は作業を止める理由にせず、前提として明記します。

呼び出し例：

• 12月31日に終了する、レガシーのレポートモジュール向けEOLチェックリスト。アカウント数は約400。
• ハードウェアの廃止に向けた詳細なチェックリストを作成。サービス契約あり、再販業者8社、UL認証取得済み。

---

主なコンセプト

作成前に規模を適切に見極める

EOLの進み方は一様ではありません。 多くは中間の規模に当てはまります。レベルは慎重に選んでください。

	レベル1 — 簡易	レベル2 — 標準	レベル3 — 詳細
典型的な対象範囲	機能、社内ツール、バージョン管理されていないAPI	商用製品、アクティブな顧客	売上の中核となる製品、ハードウェア、規制対象製品
使用するフェーズ	2～3（NSC、EOS、EOL）	4～5（NSC、EOS、EOE、EOM、EOL）	全6（NSCからEOSRVまで）
担当機能	4	11	15
ゲート基準	不要	主要フェーズ間	承認者を含め、すべてのフェーズ間
成果物のイメージ	簡潔なタスクリスト	担当者と日程を含む実用的なチェックリスト	部門横断型のプレイブック

デフォルトはレベル2です。 レベルを推奨し、その理由を一行で説明して、ユーザーが変更できるようにします。より簡易なレベルにする場合は、対象から外れる機能を具体的に示し、判断材料を提供します。レベル3をデフォルトにしてはいけません。 簡易な製品終了に過剰に重いチェックリストを適用すると、チームはEOLプロセスを形式的なものだと捉え、次に本当に必要なときに省略してしまいます。

作成中にレベルを変更してもかまいません。法務の項目で新たな問題が見つかった後に「やはり詳しくして」と言われるのは、よくあることです。

ライフサイクルのゲート

• GA（一般提供）： 積極的に販売され、全面的にサポートされている状態です
• NSC（ステータス変更の通知）： 決定が伝達され、計画の策定が始まります
• EOS（販売終了）： 新規顧客は購入できなくなります
• EOE（拡張終了）： 既存顧客は容量やシート数を追加できなくなります
• EOR（更新終了）： 既存の契約は更新されなくなります
• EOM（メンテナンス終了）： バグ修正とパッチの提供が終了します
• EOL（ライフ終了）： 製品が廃止されます
• EOSRV（サービス終了）： すべてのサポートとサービスの義務が終了します

チェックリストのフェーズとして採用するもの： GAは状態であり、作業フェーズではないため、ここにはチェック項目を設けません。EORは契約に左右されるため、更新対象の契約がある場合にのみ含めます。そのため、実際のチェックリストは通常、実作業の対象となる6つのフェーズ、すなわちNSC、EOS、EOE、EOM、EOL、EOSRVにまたがります。サブスクリプション契約またはサービス契約がEOS後も続く場合は、EORを追加します。

採用するゲートだけでなく、採用しないゲートを明記することも有用です。 レベル1のチェックリストには、「拡張するものもサービスを提供するものもないため、EOEとEOSRVは該当しません」と記載します。

15の機能領域

レベル別に絞り込んでいます。括弧内は、それぞれが登場する最も低いレベルです。

領域	レベル
製品と戦略	1
エンジニアリングと技術	1
サポート	1
ドキュメントとトレーニング	1
法務と契約	2
財務計画	2
営業	2
マーケティング	2
カスタマーサクセス	2
IT システム	2
データ管理	2
在庫とサプライチェーン	3
チャネルとパートナー管理	3
規制とコンプライアンス	3
社内の組織的連携	3

付箋ルール

各項目は4〜8語で、動詞を含み、担当する機能を明記します（個人の予定表ではありません）。「法務が契約を確認する」は項目です。「顧客全体にわたるすべての関連する契約上の義務が適切に確認されるようにする」は、チェックボックスを付けた段落です。

**担当機能を必須にする理由：**担当者のいない項目は願望にすぎません。すべての行に担当機能を割り当てることで、部門間の連携不足が早期に明らかになります。「チャネルパートナーへの通知」の担当者が誰かを言えないなら、誰も担当していないことに気づいたことになります。

フェーズゲートは日付ではなく、コミットメントです

フェーズゲートとは、次に進む前に満たす必要がある条件と、その承認者を示すものです。「EOS から EOE へ：最終購入注文を締め切る — 承認者：営業担当 VP」。これにより、EOL の告知から6か月後に、誰かがひっそりとプラグを引き抜くような事態を防ぎます。

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

• **プロジェクト計画ではありません。**ガントチャート、依存関係図、リソースの割り当てはありません。
• **デフォルトで網羅的にするものではありません。**最大限の形式ではなく、リスクに応じた範囲を対象にします。
• **意思決定そのものではありません。**サンセット自体をまだ検討中なら、これを作るのは時期尚早です。
• 話し合いの代わりにはなりません。「法務と調整する」というチェックリスト項目は、法務との調整そのものではありません。

---

適用

ステップ 1：レベルを設定する

影響範囲（顧客、収益、契約、ハードウェア、パートナー）をもとにレベルを提案し、3つすべてを提示してユーザーに選んでもらいます。レベルがどうしても不明確な場合は、次のように尋ねます。

「このサンセットの複雑さはどの程度ですか？

1. 軽度 — 機能、社内ツール、またはバージョン管理されていない API。ユーザーが少なく、全員に連絡できます。
2. 標準 — 有料顧客と契約がある商用製品。
3. 重大 — 収益に不可欠、現場にハードウェアがある、チャネルパートナーがいる、または規制対象。

サンセットのほとんどは標準です。どれが近いですか？」

ステップ 2：対象フェーズを選択する

レベルをフェーズに対応付けてから、次の2つの例外条件を確認します。

• EOS 以降も契約が継続しますか？ EOR を追加します。
• サービス提供義務が一切ありませんか？ EOSRV を除外し、その旨を伝えます。

日付がどうしてもわからない場合は、TBD と記載します。日付をまだ設定すべきでない場合（移行経路が存在しない場合）は、Not scheduled と記載し、前提条件を明記した項目を追加します。根拠のない EOL 日付は、公の場で破ることになる約束です。

ステップ 3：フェーズごと、領域ごとに項目を作成する

対象となる各フェーズについて、レベルに応じた機能領域を確認します。各項目は次の条件を満たす必要があります。

• 動詞で始まる
• 4〜8語である
• 担当する機能を明記する
• ちょうど1つのフェーズに属する — 告知するフェーズではなく、作業を行うフェーズに属する

サンセットで最も見落とされやすい、次の4項目を最低限カバーします。

1. データ — エクスポート形式、利用可能期間、削除スケジュール
2. 契約 — 更新条項、SLA 条件、返金または付与すべきクレジット
3. アクセス — API キー、インテグレーション、SSO、データを読み取る下流システム
4. 資金 — 予測の調整、収益認識、サンセット自体のコスト

ステップ 4：ゲートの基準を記載する（レベル 2 以上）

フェーズの移行ごとに、満たすべき条件と承認者を列挙します。ゲートごとに3〜5つの基準で十分です。承認者を明記できない場合、そのゲートは実質的に存在していません。

ステップ 5: EOL 後のアクションと前提条件

常に短い EOL 後ブロックを含めてください — アーカイブ、最終レポート、そして振り返りレビューです。 このレビューは、チームが最初に削り、最も後悔する項目です。次回のサービス終了は、 今回何に驚いたかを誰かが書き留めておけば、いつもずっと楽になります。

検証すべき前提条件で締めくくります — ステップ 1 で挙げたすべての不明点を、率直に記述します。

最終ステップ: 次に何ができるかを提示する

「次はどこへ進みますか?

1. ステークホルダーとの会話を計画する — 誰と、どの順番で話すか(推奨)
2. 顧客向けアナウンスの下書きを作成する — eol-message を参照
3. 社内イネーブルメントパックを構築する — サポート FAQ、営業トークポイント、反論
4. これを日付入りのタイムラインに変換する — 各フェーズに対するカレンダー日付

番号、組み合わせ(『1 & 3』)、または独自の進め方で返信してください。」

---

例

• examples/sample.md — Fieldlight Classic Dispatch(SaaS、レベル 2、5 フェーズ)
• examples/sample-industrial.md — NFA-200 コントローラーライン(産業用、レベル 3、意図的に 日付を付けない EOL を含む 6 フェーズ)

---

よくある落とし穴

落とし穴 1: 儀式の膨張

症状: 「より徹底している」という理由で、すべてのサービス終了が 15 領域・6 フェーズの プレイブックになる。

結果: チームは EOL プロセスが芝居だと学び、次回は完全に飛ばしてしまう — そして 次回こそが契約を伴う案件である。

修正: 意図的に適正規模にします。使われるレベル 1 のチェックリストは、無視される レベル 3 に勝ります。

---

落とし穴 2: 担当者のいない項目

症状: 「顧客データがエクスポートされることを確認する。」担当者: 空欄、または「チーム」。

結果: 全員が誰か他の人がやっていると思い込む。シャットダウン当日、誰もやっていない。

修正: すべての項目に職能を明記します。職能を挙げられないなら、それが発見事項です — 覆い隠すのではなく、エスカレーションしてください。

---

落とし穴 3: 捏造された日付

症状: チェックリストのテンプレートに空欄があったからという理由で、EOL 日が書き込まれる。

結果: 日付を告知し、移行パスが存在しないことに気づき、延期する。 最初の日付を前提に計画した顧客は、二番目の日付を信じなくなる。

修正: Not scheduled は正当な記入です。それをスケジュールできるようにする 前提条件と組み合わせてください。

---

落とし穴 4: フェーズの崩壊

症状: すべてが「EOL」と呼ばれる 1 つのフェーズに収まってしまう。

結果: 販売を停止し、サポートを停止し、同じ日にシャットダウンする。顧客は 事前通知付きの障害として体験する。

修正: ゲートを分離します。販売の停止は安価で早めに、サービスの停止は高コストで最後に。

---

落とし穴 5: 下流の読み手を忘れる

症状: チェックリストが製品とその顧客をカバーしていても、その API を静かに クエリしている 4 つの社内システムをカバーしていない。

結果: 製品は予定どおりに廃止され、翌朝には 3 つのダッシュボード、1 つの請求ジョブ、 1 つのパートナー連携が壊れる。

修正: このために IT システムとデータ管理の領域が存在します。レベル 1 でも、一度は 尋ねてください: これは何から読み取っているか?

---

参考資料

関連スキル

これらは独立しています — どれもこのスキルの前提条件ではなく、このスキルも それらの前提条件ではありません。すでに別の場所でレベルを選んでいるなら、 「レベル 2」と言うだけで、このスキルはそれに合わせて構築します。引き継ぐ成果物は ありません。

• eol-readiness-advisor — 決定自体にまだ 根拠が必要な場合、またはレベルを推奨してほしい場合
• eol-stakeholder-sequence — 誰と、いつ話すか
• eol-internal-enablement — 顧客対応チームの準備
• eol-message — 顧客向けアナウンス

外部フレームワーク

• 業界の EOL ライフサイクル実践(GA/NSC/EOS/EOE/EOM/EOL/EOSRV)
• RACI — 各項目の担当者を割り当てるため

出典

• https://github.com/deanpeters/product-manager-prompts リポジトリの prompts/eol-checklist.md から改変。