サービス終了を伝えるプレゼン：利用者ごとの移行先と案内を整理する

サービス終了を伝えるプレゼンでは、何が使えなくなるのか、誰の作業に影響するのか、その人が今後どう作業を続けられるのかを示します。終了日だけでは移行計画になりません。利用者の具体的な作業ごとに、移行先、担当者、告知前に決める事項を結び付けることが大切です。

この記事では、架空の予約ポータルを例に説明します。ブラウザー利用者、API連携の管理者、過去の記録を使う人では、必要な案内が異なります。まず移行経路を短い説明文書にまとめ、PresentiでWord文書からプレゼンの下書きを作成できます。資料は移行を説明するためのもので、アカウント、予約、過去の記録を移す機能ではありません。

何が使えなくなるのかを具体的に示す

「旧ポータルを終了します」という表現は、開発側には明確でも、利用者には疑問が残ります。ログインはできるのか。既存の予約は有効なのか。API連携は動かなくなるのか。昨年の記録を取り出せるのか、といった疑問です。

ライフサイクルの用語を使う前に、変わる動作を説明します。例えばMicrosoftのライフサイクル用語集（英語）では、同社のポリシーにおける非推奨化、削除、サービス終了を区別しています。その呼び名だけで、自社サービスの具体的な変更内容を説明したつもりにならないようにします。

架空のポータルで最初に予定しているのは、旧ブラウザー画面で新規予約の受け付けを停止することです。それだけで、既存の予約、APIリクエスト、記録へのアクセス、サポートの扱いまで決まるわけではありません。別々の行に示しましょう。

この表があれば、小さな変更の告知が、意図せず大きな約束になるのを防げます。サポート担当者も、その場で方針を推測せずに変更を説明できます。

契約プランではなく、利用者の作業ごとに移行を整理する

1社がブラウザーを使い、API連携を運用し、過去の記録も取得することがあります。この3つは重なり得る利用経路であり、互いに排他的な顧客区分ではありません。影響を受ける組織数を数えるなら、別途重複を除きます。3つの経路の件数を足すと、同じ組織を重複して数える可能性があります。

GOV.UKのサービス終了ガイド（英語）は、終了後も利用者に必要なことを起点に、直接の利用者とAPI利用者を区別しています。この資料でも「それぞれの人が、引き続き何をできる必要があるか」と問いましょう。

「新プラットフォーム」へ矢印を引くだけで完了にしないでください。移行先で行う作業を示します。新規予約は作れても、旧予約をキャンセルする方法がないかもしれません。後継サービスの機能が多くても、その不足は資料に残す必要があります。

API連携では、項目の対応を具体的にします。旧サービスの「予約参照番号」が、後継サービスでは別の識別子になる場合があります。呼び出し元が元の番号を保持するのか、新しい番号を保存するのか、照合が必要なのかを記録します。ここでの項目名は例です。実際の仕様は資料作成者の推測ではなく、APIドキュメントで確認します。

社内の予定と、顧客への約束を分ける

社内資料には、未解決の依存関係がある段階でも予定日を示せます。一方、顧客への通知で約束するのは承認済みの範囲に限ります。スライドが転送されても仮の日付が確定事項に見えないよう、社内の予定にはその状態を明記します。

予約の例では、APIの項目対応より先にブラウザーでの利用準備が整うかもしれません。記録へのアクセスには別の条件があることも考えられます。3本のレーンに分け、移行先の準備、利用者への通知、利用者の作業完了、旧経路の停止という節目をそれぞれ置きます。図をきれいに見せるために、すべてを同じ終了日に合わせないでください。

会議で決めるのは「ブラウザーの変更は告知してよいが、APIの終了日はまだ公表しない」という狭い範囲かもしれません。サービス全体の終了承認とは異なります。日程の横に、実際の判断範囲を記します。

契約、返金、アクセシビリティ、記録の保管義務が移行に関わる場合は、適用する承認済み方針と責任者を説明資料に含めます。汎用の通知テンプレートでは、その条件を決められません。「継続的な記録アクセスを承認するのはどのチームか」のように未解決事項を具体化し、広い注意書きで埋めないようにします。

3つの作業に合わせて通知を書き分ける

以下は、架空の予約ポータルのための通知例です。利用前に角括弧の項目を承認済みの内容に置き換えてください。どの通知も、影響する作業から始め、必要な行動と問い合わせ先を続けています。

ブラウザーから新規予約を作る人への通知

[日付・時刻・タイムゾーン]以降、新規予約には[後継ポータルのリンク]をご利用ください。同時刻に、現行ポータルでの新規予約の受け付けを停止します。切り替え前に作成した予約は、[確認済みの既存予約の操作経路]で閲覧、変更、キャンセルできます。次の予約を作成する前に、[承認済みのアクセス手順]に従って後継ポータルにログインしてください。アクセスできない場合は、組織名と行おうとしている作業を添えて[問い合わせ先]にご連絡ください。

既存予約についての一文は重要です。それがないと、翌月の予約がある人は、自分にも関わる告知かどうか分かりません。その操作経路がまだ決まっていないなら、ブラウザー利用者全体を対象とする通知を送る前に解決します。

API連携の管理者への通知

お使いの連携は、予約送信に[対象のAPIまたはバージョン]を使用しています。このAPIは、[承認済みの日付・時刻・タイムゾーン]にリクエストの受け付けを停止する予定です。後継APIのドキュメントは[ドキュメントへのリンク]にあります。認証、必須項目、応答の識別子、エラー時の動作を確認し、[技術担当窓口]と切り替えを調整してください。連携名と希望する切り替え時間帯を[問い合わせ先]へお知らせください。ブラウザー利用者が移行しても、この連携は自動では更新されません。

契約窓口だけでなく、連携を保守している人に届けます。一斉告知だけでは、ソフトウェアを変更し、作業時間を確保する担当者に届かないことがあります。

過去の記録が必要な人への通知

現行予約ポータルの記録が必要な場合は、[承認済みの取得経路]をご利用ください。[権限のある利用者または役割]が、[確認済みの記録範囲・形式]を取得できます。現行ポータルからのアクセスは、[承認済みの日付・時刻・タイムゾーン]に変更されます。提供範囲外の記録やアクセス条件については、[記録に関する問い合わせ先]へご連絡ください。適用する保存方針は[承認済み方針へのリンク]で確認できます。

範囲と動作を確認できていない限り、「すべてのデータが自動で移行されます」と加えてはいけません。ダウンロードできる報告書、検索できるアーカイブ、編集できる予約履歴は、それぞれ別の提供物です。実際に受け取れるものを示しましょう。

移行経路と通知を中心に、短い資料を作る

冒頭で「ブラウザーの新規予約を後継ポータルへ移す。APIと記録の経路は別途確定する」と変更案を具体的に述べます。次に対象範囲の表と3つの利用経路を示せば、日程を見る前に影響を議論できます。

中盤には節目の予定と、代表となる通知を1つ置きます。他の2つの通知は付録か添付文書に移すと、本会議の資料を読みやすく保てます。最後のスライドには、求める判断、権限のある判断者、その判断に含まれない未解決事項を記します。

Wordの説明文書では、利用経路ごとに見出しを分けます。対象範囲の表、承認済みの通知文、各節目の状態を入れてください。スライドを下書きするときも、3つの経路を分け、未定の日付は未定のまま残すよう指定します。製品名だけを渡して移行日程を作らせないようにします。

より広い告知活動には、ステークホルダーとのコミュニケーション計画が役立ちます。相手、連絡手段、メッセージの責任者を整理する計画に対し、サービス終了の資料は各通知で伝える具体的な変更を提供します。

旧経路の停止後、誰が対応するかを示す

旧ポータルの最終日が、移行作業の最終日とは限りません。保存したブックマークから来る人、以前の予約について尋ねる人、一覧に載っていなかった連携に気付く人がいるかもしれません。問い合わせを受けるチームに、明確な対応経路を用意します。

この例では、ブラウザー窓口が後継サービスへのアクセス、技術窓口がAPI連携、記録窓口が取得依頼を扱います。どの窓口が何を担当し、どの情報を引き継ぐかをスタッフに伝えます。担当が不明な共通受信箱だけでは、利用者が同じ説明を繰り返すことになります。

会議の最後には、承認された範囲と残る判断を分けて記録してください。利用者の次の行動が分かり、チームが「自分の作業はどうなるのか」という問いに推測なしで答えられる資料にします。