開始日の準備（B2C）

スムーズな開始に備え、すべての関係者に開始が迫っていることを知らせ、計画ならびに各自の役割と責任について周知徹底しましょう。主要な役割を果たすチームだけでなく、なにか問題が発生した場合に支援を要請する可能性のあるチームにも予め知らせておくことが大切です。開始時に待機している担当者がいるかいないかで、いざという時の対応のスピードが変わります。ソーシャルメディアを含む、顧客からの問い合わせに対応するチームも確認して、必ず知らせておきます。

• ［顧客］

• ビジネスパートナー（該当する場合）

• 開始の影響を受けるアプリケーションチーム

• サポートチーム

• ネットワークチーム（ネットワーク変更、問題発生に備えて待機）

• セキュリティチーム（問題発生に備えて待機）

• マーケティングチーム（発表準備、問題への対応）

• ソーシャルメディアチーム（ソーシャルメディアの監視準備と対応）

• 営業チーム（顧客からの問い合わせへの対応準備）

• カスタマーサクセスチーム（顧客からの問い合わせへの対応準備）

通知計画には、対象者、対象者にとって重要なポイント、メッセージの内容、通知の配信計画、メッセージのテスト方法などを含める必要があります。

この計画に含む項目は以下の通りです。

• 対象者（社内と社外の両方の対象者を考慮）

• メッセージ

• タイミング

• 依存関係

• 責任者（送信する人）

• メカニズム（通信方法）

• メッセージと配信のテスト（該当する場合 - 通知が確実に送信されるようにテストする）

一般的な戦術としては、通知を何回かに分けて送信することで、初期の負荷を分散し、予期しない不具合が生じた場合の混乱を小さくします。問題の修正は、一度に大人数に対処するよりも、少人数のグループに対処する方が簡単です。

• 1つの方法として、最初は少ない対象者から始め、問題がなければ、徐々に1回の通知の対象者数を増やしていくやり方があります。

• あるいは、世界中に一定の間隔で送信して、システムに一度にかかる負荷を分散する方法もあります。この方法だと、各タイムゾーンで最適な時間帯に通知が届くように設定でき、メッセージが読まれる可能性を高めることもできます。

• 個人の顧客、地域、その他アプリケーションにとって合理的な分類に基づき、一部のユーザーに対してソフトローンチを行うこともできます。

組織によっては、開始に伴う停止やダウンタイムが必要な場合、正式に停止期間を要請する必要があります。該当する組織は、切り替えや開始（または他の依存システム）にダウンタイムが必要かどうかを必ず確認し、リードタイム要件に先立って必要な停止または変更の要請を提出してください。

開始作業に、以前のソリューションから新しいソリューションへの切り替えが含まれる場合があります。該当するプロジェクトは、それに伴う必要な作業、依存関係、各タスクの責任者、必要なタイミングをすべて把握してください。また、誰かが病気になった場合や何らかの理由で急遽対応できなくなった場合に備え、すべての重要な役割や地域ごとに控えの担当者を計画しておくと安心です。切り替え計画で考慮すべきチェックリストは以下の通りです。

• 切り替え計画とロールバック計画（必要な場合）を文書化したか

• 変更前にバックアップは必要か

• 事前にデータ変更は必要か

• DNSレコードの変更は必要か

• ファイアウォールの変更はあるか

• 新たな監視対象はあるか

• デプロイするソフトウェアはあるか

開始計画全体で実行の可否基準を設定しておくと役立ちます。起こりうる問題の種類を特定し、解決できる問題と、元に戻す必要のある問題を事前に話し合っておきましょう。開始計画で定期的な確認スケジュールを指定し、各チェックポイントでの評価内容や問題を解決するまでの猶予期間の基準を定めることができます。

開始の各段階で、開始が計画通りに進行しており、続行できることを示す成功の基準を定義しておくとスムーズです。基準の例として以下が挙げられます。

• 最小限のエラーでユーザー登録が増加している

• 最小限のエラーで、期待通りのユーザーログイン率

• 報告されているサポート案件が一定のしきい値以下

• データの破損につながる可能性のある問題が確認されていない

また、開始の中止を決定しうる基準を決めておくことも大切です。リスク許容度は環境によって異なりますが、例として次のような基準が挙げられます。

• ユーザーのサインアップまたはログインで迅速に解決できないエラーの発生率が高い

• 迅速に解決できないサポート案件が多数発生

• データの破損につながる可能性のある状況が見つかった

• 重大なセキュリティ問題が見つかった

解決できない予期せぬ事態が生じた場合に備え、開始をロールバックまたは元に戻す方法を計画しておくことが賢明です。変更を伴うすべての手順の開始計画を確認して、開始または切り替えを元に戻すために必要なタスクや変更を把握しましょう。

ロールバック計画には、実行する手順、順序、それぞれの所要時間、および責任者を含める必要があります。ロールバックに必要な累積的な時間を把握しておくことで、許容される停止時間内に収まるように最終的な続行の可否の決定をくだすタイミングを決められます。

開始のためにデータを移行または変更する場合は、必要に応じて、そのデータを元に戻す方法を計画に含める必要があります。元に戻す作業には、操作上の変更を元に戻すスクリプトの実行や、開始プロセスが始まる前に保存されたバックアップを使用したデータストアの復元が必要になるかもしれません。

さらに、一部のデータが新しいシステムに入力された後に、元に戻す必要が生じた場合も考慮する必要があります。そのようなデータ/トランザクションは、ロールバック時に破棄する必要があるのか、それとも失われないようにキャプチャして他の場所に適用する方法があるのか。

問題の解決や元に戻すプロセスが、担当者の1日の業務時間内で終わらないことも考えられます。そこで、各シフトで対処できる主担当者と、できれば副担当者も割り当て、準備して臨むことをお勧めします。問題により、担当者の1日の業務時間を大幅に超える長期的な対応が必要になった場合、現実的に言って、1人で休憩なしに対処できる時間には限界があります。必要に応じて、問題対応作業のための24時間体制のリソースを準備しておくと良いでしょう。

開始日が近づいたら、トラブルシューティングや問題解決に必要になる可能性のあるすべての関係者の連絡先を把握し、必要に応じて迅速に支援するために待機してもらうよう依頼するのがお勧めです。開始責任者は待機する各担当者の連絡先を手元に準備しておき、いざという時に素速く連絡が取れるようにします。

物理的または仮想の「開始本部」がある場合には、待機中の人が事前に場所を確認し、必要なったらすぐに駆けつけられるようにします。開始の本部となる部屋やビデオ会議を準備しておくと、問題が発生したときにすべての関係者が迅速にコミュニケーションを取り、トラブルシューティングにあたることができます。

開始を成功させるには多くの計画が必要ですが、開始を評価する方法は知っていますか？開始前に成功の基準を決めておくと、開始を評価するために何を監視すべきか、追加の監視や確認を実施する必要があるかを判断できます。たとえば、成功基準の要素の1つにサインアップ数やログイン数がある場合、その数値を監視するための手段はあるか、その数値が正確であることはテスト済みかが重要になります。

統計データを使って、開始の成功を知らせましょう。すべてが終わった後に、チームが開始のために費やした努力を定量化するためのデータを一つも収集してなかった、なんてことになっては大変です。

問題について考えるのは決して楽しい作業ではありませんが、いざ何かが起こった場合には、迅速な対応を可能にする計画が手元にあることに必ずや感謝することでしょう。計画に含めるべきリスク例は以下の通りです。

• ソフトウェアアプリケーションのバグ

• ユーザーのブラウザー設定とアプリケーションの互換性の問題

• ネットワークの失敗/停止

• DoS攻撃

• ホスティング環境の失敗

• 負荷/容量の問題

• データ/破損の問題

• セキュリティ脆弱性の判明

ベータ期間がある場合は、ベータ版の結果を見直すと、起こりうる失敗のシナリオの想定に役立ちます。

当社では、PDF形式の計画ガイダンスを提供しています。ダウンロードして、推奨される戦略の詳細を参照してください。