使っていた機能が終了すると告知されたとき、やった3つのこと

• 最初にやるのは、データの取り出し
• 代わりを探すのは、取り出した後でよい
• 期限を記録して、実施日を先に決める

よく使っていた機能に終了の告知が出た。3か月の猶予があったが、やることを先に決めて動いた記録を書く。

告知を読んだ日にやること

その日のうちに、3つだけ確認した。

• いつ終わるか。日付を記録する
• 何が使えなくなるか。機能全体か、一部か
• データはどうなるか。消えるのか、残るのか

3つ目が最優先だった。データが消えるなら、取り出す期限が実質の締め切りになる。

1. データを取り出す

代わりを探す前に、まず取り出した。

• 取り出す手段があるか確認する
• あれば、その日のうちに実行する
• 無ければ、手で控える範囲を決める

2つ目を先延ばしにしないのが要点だ。終了が近づくと、取り出し機能が混み合うことがある。

取り出した形

独自形式でしか出せない場合は、読める形に変換してから保存した。変換の手段も、サービスが動いているうちにしか使えない。

2. 代わりを探す

データを確保してから、落ち着いて探した。

• 同じことができるものを3つ挙げる
• 移行の手間を見積もる
• 1か月は並行して使う

3つ目の期間を取れたのは、早めに動いたからだ。締め切り直前だと、試す時間が無く、残っているものを選ぶことになる。

3. 実施日を決める

終了日ではなく、自分が移る日を決めた。

• 終了の2週間前を実施日にする
• その日を予定に入れる
• 前日までに準備を終わらせる

2週間の余裕を取ったのは、移った後に問題が見つかることがあるからだ。元が動いているうちなら、戻れる。

猶予期間の使い方

3か月あると、何もしないまま2か月が過ぎる。配分を決めた。

• 最初の2週間 — データの取り出しと、代わりの候補選び
• 次の1か月 — 候補を並行して使う
• 残り — 移行して、問題が出ないか様子を見る

前半に寄せたのが効いた。後半に余白を残しておくと、想定外が起きても間に合う。実際、移行先で不具合が見つかり、別の候補に切り替える時間が必要になった。

やらなかったこと

告知を見た直後にやりたくなるが、やめたことがある。

• すぐ別のサービスに乗り換える。焦って選ぶと後悔する
• 終了の理由を調べる。分かっても対処は変わらない
• 他に使える機能を探し回る。本題から逸れる

1つ目は以前やって失敗した。慌てて契約したものが合わず、二重に移行することになった。

移行の作業を小さく分ける

まとめてやろうとすると腰が重い。分けて進めた。

• 1日目 — データの取り出しだけ
• 2日目 — 代わりの候補を3つ挙げるだけ
• 3日目 — 1つ試すだけ

1回30分以内に収まる単位にすると、着手しやすい。「移行する」という大きな塊のままだと、締め切り直前まで動かない。実際、以前はそうなって慌てた。

記事を書いている場合

その機能について書いた記事があれば、そちらも対応が要る。

• 該当する記事を探す
• 終了した旨を、記事の冒頭に追記する
• 代わりの手段を示す

2つ目を冒頭に置くのは、読んでから「使えない」と分かると時間を無駄にさせるからだ。

告知の読み方

終了の案内は、丁寧に読まないと範囲を取り違える。

• 機能全体が終わるのか、一部の設定だけか
• 新規の受付が止まるだけで、既存は続くのか
• 別の機能に統合されるのか、完全に無くなるのか

2つ目と3つ目はよくある形だ。統合される場合は、移行が自動で行われることもある。慌てて別のサービスを探す前に、どの形の終了なのかを確認する。実際、今回は一部の設定が変わるだけで、想像していたより影響が小さかった。

次に備える

今回の経験から、運用を少し変えた。

• 使っている機能の一覧を作る。何が終わると困るか見える
• 代わりが効かないものを把握しておく
• データの取り出し方を、使い始めた時点で確認する

3つ目が根本的な対策だった。終了してから取り出せないと気づいても遅い。

まとめ

• 告知を読んだ日に、終了日・範囲・データの扱いを確認する
• 代わりを探す前に、まずデータを取り出す
• 終了の2週間前を実施日にして、予定に入れる
• 焦って別のサービスを契約しない
• その機能に触れた記事があれば、冒頭に追記する