eol-stakeholder-sequence

EOL ステークホルダーの会話順序

目的

EOL に関する会話の順序と、それぞれで取り上げるべき内容を計画します。出力は、順序立てた一連の訪問先です。各訪問先について、相手から得る必要がある情報、相手に伝えるべき内容、注意すべき危険信号、会話を通じて生み出すべき成果をまとめます。

EOL は一斉通知ではありません。それぞれの会話が次の会話に情報を与え、前の会話で見落とされた何かを明らかにする、一連の対話です。順序よく進めれば、気まずい発見は会議室で起こります。順序を誤れば、発表後に顧客の前で公になることになります。

入力

最も役立つ情報： 終了する製品と、すでにそのことを知っている人。

あるとさらに役立つ情報： 規模（顧客数、売上、契約）、販売パートナーや規制当局が関与するかどうか、配慮すべき政治的事情、関係の悪化、過去に起きた予想外の問題。

呼び出し時に渡された情報（スキル名の後に続くテキスト、貼り付けられたコンテキスト、追加された ARGUMENTS: 行など）は、回答済みの情報として扱います。その情報を使い、含まれている内容については再質問しないでください。

何も用意していなくても大丈夫です。 このスキルでは、終了するものと、それを知っている人、影響の大きさ、考慮すべき過去の経緯について、最大3つの質問をしてから順序を組み立てます。政治的事情の共有は任意です。なくても順序を作成でき、あればさらに精度が高まります。

呼び出し例：

• レガシーのレポートモジュールを終了するための、ステークホルダーとの会話の順序を組み立ててください。
• リセラーが8社いるハードウェア製品ラインを終了するにあたり、誰とどの順番で話せばよいですか？

---

主要な概念

順序決定の原則

計画を中止させる可能性のある人には、実行を担う人より先に話してください。

それぞれの会話が次の会話に情報を与えるようにします。まず法務リスクを確認します。契約条項によって議論が終わる可能性があるためです。次に財務への影響を確認し、以降のすべての規模を把握します。その後、売上を担うチーム、顧客対応チーム、そして実行を担う技術チームの順に進みます。

この順序を逆にして、最初にサポートへ説明し、最後に法務へ相談すると、たった一つの契約条項で無効になる計画を、40人に伝えてしまうことになります。

順序の規模を適切にする

すべての EOL が同じように進むわけではありません。 多くの場合、規模は中間に当たります。

	レベル1 — 小規模	レベル2 — 標準	レベル3 — 大規模
典型的な対象	機能、社内ツール、API	商用製品、利用中の顧客	売上に不可欠な製品、ハードウェア、規制対象
訪問先	3～4	7～8	10以上
含める相手	エンジニアリング、サポート、影響を受けるユーザー	＋法務、財務、営業、マーケティング、カスタマーサクセス、対応が難しい顧客	＋経営幹部、チャネル、規制当局、重要顧客
特段の理由がない限り省略	法務、財務、営業、チャネル	チャネル、規制当局	—

デフォルトはレベル2です。 適切なレベルを推奨し、その理由を説明したうえで、ユーザーに変更してもらいます。最も大規模な順序をデフォルトにしてはいけません。 機能の廃止に対して訪問先を10か所も回ると、本当に大規模なEOLで必要となる信頼を損ないます。

規模を小さくする場合は、省略する訪問先と、通常そこで確認できる内容を具体的に伝えてください。契約のある製品で法務を省く場合は、一度だけ再考を促し、その後は相手の判断を尊重してください。

基本の順序

レベルに応じて絞り込みますが、相対的な順序は変わりません。

レベル 1 以上

1. エンジニアリング — 技術面で何が依存しているか
2. サポート — サポート業務にどのような変更が生じるか
3. 影響を受けるユーザーまたは社内チーム — 誰が最初に影響を受けるか

レベル 2 以上（以下を上記の前に追加）

1. 法務 — 契約上および規制上のリスク
2. 財務 — 収益への影響と予測の変更
3. 営業 — パイプライン、バンドル、そして現場で交わされたものの、契約やチケットには記録されなかった約束
4. マーケティング — 廃止した機能の需要創出に、四半期分の予算を投じたばかりだと後から知るのは避けたいものです
5. カスタマーサクセス — 影響を最も受けるのはこのチームです。迂回せず、連携しましょう
6. 最も対応が難しい顧客 — 半年後に問題を引き起こしていたはずの、見落とした3つの点を見つけてくれます

レベル 3 以上

• 経営幹部 — 戦略的な承認
• チャネルパートナー — 在庫、コミットメント、独自の顧客関係
• 規制当局 — 届け出とコンプライアンス
• 主要アカウント — 個別の移行に関する対話

最も対応が難しい顧客をこの順序に含める理由

直感に反しますが、チームが最もよく省略する段階です。チケットを最も多く起票し、QBRで最も強く要求する顧客は、必然的に自社製品を最も深く、独特な方法で使っています。忘れていた連携機能、誰も読んでいなかった契約条件、代替製品に相当するものがないワークフローを見つけてくれます。

今、予定した通話でそれを知ることもできますし、後日、公開フォーラムで知ることもできます。

必要なこと／相手に提供すべきこと

どの段階にも、2つの方向があります。2つ目を省くと、ステークホルダーは聞き手になるだけです。

• 相手から得る必要があること — 相手だけが持っている情報、承認、知識
• 相手に提供すべきこと — 相手が仕事を進めるために必要な背景情報、確約、準備期間

情報を引き出すだけの会話では、協力は得られても、それ以上のものは得られません。双方向の会話をすれば、相手が尋ねられていなかったことも明らかになります。

付箋のルール

各項目は4〜8語にします。順序は、廊下や会議前、スマートフォンで読まれるものです。

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

• ステークホルダーマップではありません。 権力／関心のマトリックスはありません。これは順序を定めた行程表です。
• 一斉告知の計画ではありません。 顧客への告知は別の成果物です。
• 既定で並列化できるものではありません。 価値は順序にあります。記載がある場合に限って並列化してください。
• RACIではありません。 意思決定権限は、会話の順序とは別の問題です。

---

適用方法

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

影響範囲に基づいて推奨レベルを示し、3つすべてを提示して、ユーザーに選んでもらいます。判断が難しい場合は、次のように尋ねます。

「この廃止はどの程度複雑ですか？

1. 軽度 — 機能または社内ツールです。ユーザーは少数で、全員に連絡できます。
2. 標準 — 有料顧客と契約を持つ商用製品です。
3. 重大 — 収益に不可欠、ハードウェアを含む、チャネルパートナーがいる、または規制対象です。

ほとんどは標準です。あなたのケースに近いのはどれですか？」

ステップ 2：各段階の順序を決める

基本の順序を適用し、レベルに応じて絞り込みます。調整を検討すべき点は2つあります。

• 過去の経緯から必要な場合は、段階を前倒しする — 前回、営業が不意を突かれたのであれば、テンプレートの順序よりも早く営業に説明し、その理由を記録します。
• 1つの部門に異なる2つの対話がある場合は、段階を分割する — 「法務（契約）」と「法務（規制）」は、担当者も回答も異なることがよくあります。

ステップ 3：各段階の内容を作成する

各段階について、次の5項目を記入します。

1. タイミング — どのマイルストーンまたは別の段階の前か後か
2. この段階がEOLで重要な理由 — 4〜8語
3. 相手から得る必要があること — 「意見」ではなく、具体的な質問
4. 相手に提供すべきこと — 背景情報、準備期間、確約
5. 注意すべき危険信号 — この段階で阻害要因が見つかったことを示す兆候

次に、成果物を明記します。会話によって生み出すべき決定、承認、または成果物です。成果物のない段階は、状況報告であって、段階とは言えません。

Step 4: 並行と順次を区別する

厳密に順次で進めなければならない段階と、その理由、そして安全に並行して進められる段階を示してください。ここを明確にすることで、重要な依存関係を損なわずに、10段階の流れを3週間に圧縮できます。

Step 5: 前提条件

最後に、何を前提としたかをまとめます。誰が事情を把握していると思うか、契約に何が記載されていると思うか、どの関係が維持されていると思うかを記します。

最後のステップ: 次の作業を提案する

「次はどれにしますか？

1. フェーズごとのチェックリストを作成する — 運用計画（推奨）
2. 特に慎重さが求められる3つの段階について、話す内容を下書きする
3. 社内向けイネーブルメントパックを作成する — サポート FAQ、営業向け説明、反論への対応
4. 顧客向け告知を下書きする — eol-message を参照

番号、組み合わせ（「1 & 3」など）、または独自の進め方で返信してください。」

---

例

• examples/sample.md — Fieldlight Classic Dispatch（SaaS、レベル2、8段階）
• examples/sample-industrial.md — NFA-200 コントローラー製品ライン（産業用、レベル3、11段階）

---

よくある落とし穴

落とし穴 1: 確認する前に告知する

症状: 最初の段階で全社メールを送信します。

結果: その後の会話はすべて、事情を誤った形で知らされ、協力する代わりに自分の縄張りを守ろうとする人との交渉になります。

対策: 告知は社内の流れの始まりではなく、終わりに行います。

---

落とし穴 2: 法務への相談が最後になる

症状: 計画を作成してから、「確認のために」法務を巻き込みます。

結果: 契約条項や規制上の義務によって、すでに40人が合意した計画が無効になります。実行する代わりに、計画を一から見直すことになります。

対策: レベル2以上では、法務への相談を最初の段階にします。「ここに何か約束が含まれていますか？」と5分確認するほうが、計画を練り直すのに5週間かけるより効果的です。

---

落とし穴 3: 営業を単なる告知先として扱う

症状: 営業に EOL 日を知らせるだけで、顧客に何を約束したかを尋ねません。

結果: 契約に記載されていない現場での約束が、告知後に顧客側から不誠実な対応だと非難される形で明らかになります。

対策: 営業には、誰かがこの製品の今後について何を約束したか、明確に尋ねます。知らせる前に尋ねてください。

---

落とし穴 4: 対応が難しい顧客を避ける

症状: 社内の部門を対象にしたところで、流れが終わります。

結果: 難しいケースは、それについて黙っている可能性が最も低い人たちによって明らかになります。

対策: 公開告知の前に、特に対応が難しい顧客を2〜3社選び、必要であれば NDA を締結して話を聞きます。彼らが見つける問題に対応するための時間を確保してください。

---

落とし穴 5: 情報を引き出すだけの会話

症状: どの段階でも、こちらが必要とすることを並べるだけで、何も提供しません。

結果: 関係者は聞かれたことには答えますが、自分から何も提案しません。計画を頓挫させる問題は、誰も尋ねようと思わなかったことから生じます。

対策: 各段階を実施する前に、「相手に提供すべきこと」をすべて記入してください。

---

参考資料

関連スキル

これらのスキルはそれぞれ独立しており、このスキルの前提条件となるものも、このスキルが前提条件となるものもありません。ほかの場所ですでにレベルを選択している場合は、「レベル2」のように伝えると、このスキルでそのレベルに合わせて進められます。

• eol-checklist — フェーズごとの運用計画
• eol-internal-enablement — これらの会話の後に顧客対応チームへ提供する情報
• eol-readiness-advisor — 意思決定にまだ根拠が必要な場合
• eol-message — 顧客向け告知
• stakeholder-map — EOL 以外の業務における一般的な権力・関心マッピング

外部フレームワーク

• メンデロウのマトリックス — 権力と関心による優先順位付け。各段階でどの程度詳しく対応するかを決めるのに役立ちます
• DACI / RACI — 意思決定権限。会話の順番とは別の論点です

出典

• https://github.com/deanpeters/product-manager-prompts リポジトリの prompts/eol-stakeholder-sequence.md を改変。