利用中のサービスが終了するとき、何から確認する？期限と取り出せない情報への対応

終了通知を受けたら、四つの期限を分けて確認する

終了通知と契約を手掛かりに、四つの期限を別々に確かめます。

利用停止、出力、契約終了、削除の条件は同じ日とは限りません。契約管理者と提供元に一つずつ尋ねます。

最初に、通知の提供元、対象の製品・契約、会社で使うアカウントを契約管理者と照合します。同じ提供会社の別製品や、通知と別の契約を調べても、自社の期限は決まりません。契約上の窓口と、実際にデータを取り出せる管理者が同じかも確かめます。

次の四つは、意味の違う時点です。表へ一つの終了日をコピーするのではなく、根拠となる通知や契約、提供元の回答、適用対象を対応させます。未回答の欄には、確認先と次に聞く内容を残します。

例えば、Zendesk Sellの公式終了通知では、2027年8月31日の提供終了を案内しています。データは、Sell契約が終わる時点か2027年8月31日からのいずれか早い方で、同社の削除ポリシーに従って削除すると説明しています。また、作成した出力をExport画面から確認できるのは作成後30日間という案内です。これは同製品の条件であり、架空例やほかのサービスの日付として使いません。

四つの時点が確認できるまで、停止日を見て「まだ余裕がある」と判断しないでください。分かった時点だけでも責任者へ伝え、出力に必要な準備と回答待ちを並行して進めます。延期や救済が受けられると見込んで作業を後回しにしません。

止められない仕事から、先に確保する情報を選ぶ

進行中の案件について、次の連絡に必要な情報をたどります。

顧客、案件、見積などの資料を対応づけて、止められない仕事から優先を考えます。後回しにする資料も所在と影響を残します。

終了までに全機能を作り直す話から入ると、必要な情報の確保が遅れます。まず営業担当へ、サービスが使えなくなると止まる仕事を具体的に聞きます。この例では、進行中の案件を開き、顧客への次の連絡と必要資料を確認する仕事を優先して検討します。

顧客一覧、案件一覧、添付の保管先がそれぞれ残っていても、対応関係をたどれなければ担当者は必要な資料へ戻れません。どの情報が必要かは、ファイルの種類からではなく、続ける仕事から決めます。終了通知を受けた時点で、その関連が保存・再現できていると扱わないことが大切です。

「全部移してください」ではなく、「進行中の案件から相手と資料へ戻り、次の連絡を続けたい。何をどの形式で取り出せるか」と質問します。必要情報を特定した後の一般的な受渡し条件は、提供会社を変えるときのデータ・設定・運用の引継ぎへつなげます。本稿では終了通知後の優先順に集中します。

出力できない・権限が分からないとき、誰に何を聞く？

出力できる人が分からないときの確認先を見ます。

社内の契約管理者には誰が出力できるか、提供元には期限と受渡し方法を尋ねます。権限不明を出力不可と決めず、回答待ちを記録します。

出力メニューが見えないときは、そのサービスで出力できないのか、現担当に権限がないのか、契約・プランや対象による制限かを分けて確かめます。画面が見えないことだけで、データが存在しない、すべて取得不可と結論づけません。

契約管理者には、管理者・提供元の窓口と、利用できるアカウントの管理主体を聞きます。提供元へは、出力できる人、必要な条件、対象、別の受渡し手段、その回答や作業に必要な期間を尋ねます。権限変更や代理での受渡しを実施してよいかは、会社の管理担当が判断します。

質問の例：「対象契約のデータを取り出したいのですが、現担当が出力できるか確認できていません。必要な権限、実施できる管理者、別の受渡し方法、それぞれの対象と最終期限を教えてください」。契約や権限の情報は、社内で決められた窓口から確認します。

管理者へ依頼したこと、権限を用意できたこと、出力を実行したこと、ファイルを受け取ったことは別の記録です。回答が来たら、四つの期限の表と、残したい仕事の対象を同じ内容へ更新してください。

必要な添付や履歴が、標準出力に入らないときは？

顧客・案件の一覧と、次の連絡に必要な添付や履歴を比べます。

標準出力に添付や履歴が含まれるかは未確認です。提供元へ取得対象、別の取得方法と利用条件を確認します。

標準の出力に含まれる情報を、業務で必要なものと突き合わせます。「全件」「アカウント全体」という出力名でも、履歴、文書、設定、関連づける項目まで必ず含むとは限りません。出力の案内と実際に受け取ったものを区別します。

Zendesk Sellの公式出力説明は、対象データと、活動履歴・予定・メール・通話記録・文書などの対象外を分けています。一部のシステム項目も出力方法による差があります。「出力できる」という案内だけから、必要なすべてが手元に残ると読まないための製品固有の例です。

APIや別の移行ツールなら対象外の情報を必ず取得できる、とは言えません。提供元の仕様と契約、自社の権限、期限内に利用できる条件を確認します。取得手段が変わったときは、形式だけでなく元の意味と関連を読み取れる説明も必要です。

残り時間が足りないとき、何を優先して頼む？

期限と作業時間が分からない場合の相談順を見ます。

責任者が次の連絡に必要な対象を優先し、取得、問い合わせ、仕事に使えるかの確認を分けます。後回しの対象と影響も残します。

実際の最終期限と、出力の準備・受取・確認・候補側での試行に必要な作業を並べます。必要時間が分からない段階で、残る日数だけから「間に合う」と認定しません。提供元の処理待ちや、管理者への依頼、取れない情報の回答待ちも作業の一部です。

時間が足りない可能性があれば、業務責任者へ早く返します。必要な仕事を守るため、先に保全する情報と、先に試す最小の業務、後で確認する範囲、外部支援へ頼む調査・変換・確認を分けます。すべてを急いで一括処理する方法だけに絞らないことが大切です。

返す文面の例：「停止日と出力条件を確認中です。営業が次の連絡を行うため、顧客と進行中案件の対応、必要資料を先に確保・確認したいです。添付の取得と候補側での利用には未確認があります。最低限の対象と依頼先、残る業務への対応を判断してください」。これは相談文であり、期限や切替を合意した記録ではありません。

保存できた後は、移行先で最小の仕事を試す

保存した後、顧客から案件と必要な資料へたどれるかを確認します。

担当者が次の連絡に情報を使えるかを試す計画です。実際の結果は未実施で、保存できたことと業務で使えたことを分けます。

取り出したファイルが開いたら、次は移行候補で必要な仕事を再現できるかを確認します。社内で使用を認めた試験環境と、安全な試験用データを用意します。顧客情報を入力・送信する先や、本番の契約を、この説明だけで決めるものではありません。

この例なら、顧客を探す、対応する進行中案件を開く、必要資料へ戻る、次の連絡の内容と担当を確認する、という一連の仕事で期待する結果を書きます。項目名が似ているだけでは、同じ意味や関連が保たれるとは限りません。

SalesforceのData Import Wizardの公式説明も、小さなCSVで先に試すことを勧めています。ただし同機能には対象と形式の条件があり、必要な文書・履歴・すべての関連を自動移行できる保証ではありません。この記事の手順は移行ツールの比較や推奨ではありません。

設定もデータと同じように出るとは限りません。Microsoftのデータ出力の説明にも、対象製品の顧客データと、技術設定など対象外の情報の区別があります。自社サービスの設定、権限、連携の引継ぎ条件は別に確認します。

提供終了後に元のサービスへ戻せるとは限りません。切替を中止する条件、保存物をどう使うか、業務を続ける別の方法と担当を、実際に可能な範囲で責任者へ確認します。自社で旧システムを止めてよいかの判断は、旧システムの利用・連携・履歴から廃止を判断する記事で扱っています。

まとめ：期限と三つの問題から、今日の確認先を決める

同じ架空の案件を例に、今日誰に何を聞くかを整理します。

契約管理者と提供元には期限と権限、業務担当には必要な情報、責任者には優先順を確認します。回答待ちと次の行動を残します。

外部サービスの終了通知を受けたら、まず自社の対象契約と、停止・出力・契約終了・削除開始の違いを確かめます。そのうえで、止められない仕事に必要な情報を先に選び、権限、対象外、時間不足を分けて確認先へつなげます。

通知を読んだこと、取得できると分かったこと、実際に取得したこと、移行先で仕事を試せたこと、切替を判断したことは別です。どこまで確認できたかを示し、未解決の問題を次の状態の完了に混ぜないでください。

未確認を0、権限なし、対象外、取得成功、移行済み、業務継続済みへ変えない。例の条件は一般期限や実顧客の事実ではない。

発注前に移す履歴の範囲や置き場所を決める説明は、旧システムから移すデータと履歴の要件へ案内します。終了通知後の対応と合わせ、必要な詳しさの箇所を参照してください。