メインコンテンツへスキップ

通知 / 告知

関係者全員が差し迫ったローンチを把握し、ローンチ計画とそれぞれの役割・責任を理解していれば、ローンチを円滑に進めやすくなります。積極的に関わるチームへの通知に加え、何か問題が起きた際に支援が必要になる可能性のあるチームにも知らせておくと役立ちます。ローンチ時に待機要員を確保しておくことで、対応を迅速化できます。ソーシャルメディアを含め、顧客からの問い合わせに対応する可能性のあるチームは必ず特定し、通知してください。

通知先

  • 顧客
  • 必要に応じて、ビジネスパートナー
  • ローンチの影響を受けるアプリケーションチーム
  • サポートチーム
  • ネットワークチーム (ネットワーク変更時や問題発生時に備えて待機)
  • セキュリティチーム (問題発生時に備えて待機)
  • マーケティングチーム (告知の準備、問題発生時の対応)
  • ソーシャルメディアチーム (ソーシャルメディアの監視や対応の準備)
  • 営業チーム (顧客からの質問に対応できるよう準備)
  • カスタマーサクセスチーム (顧客からの質問に対応できるよう準備)

通知計画

通知計画には、対象の、その audience に伝えるべき重要事項、メッセージの内容、通知の配信計画、メッセージのテスト方法などの要素を含める必要があります。 計画に含める要素は次のとおりです。
  • 対象オーディエンス (社内向け・社外向けの両方を考慮)
  • メッセージ
  • タイミング
  • 依存関係
  • 担当者 (誰が送信するか)
  • 手段 (どのように伝えるか)
  • テストメッセージと配信 (該当する場合。通知が送信されることを確認するためにテストを実施)

通知の配信

よく使われる方法として、通知を一斉に配信するのではなく、複数のバッチに分けて配信し、初期の負荷集中を分散させるとともに、予期しない不具合が発生した場合の混乱の影響範囲を抑えるやり方があります。大規模な一斉公開の最中に対応するよりも、まずは小規模なグループで問題を修正するほうが容易です。
  • ひとつの方法は、比較的小さな通知バッチから始め、問題が見つからなければ、時間をかけてバッチの規模を大きくしていくことです。
  • また、世界各地に向けて時差に合わせたスケジュールで順次バッチ配信することで、システムに一度にかかる負荷を分散しつつ、各タイムゾーンで最適な時間に通知が届くようにして、メッセージが読まれる可能性を高めることもできます。
  • 個々の顧客や地域、あるいはアプリケーションに適したその他の区分など、ユーザーの一部を対象にソフトローンチを行うこともできます。

停止時間帯 (必要な場合)

組織によっては、ローンチにあたり停止やダウンタイムが発生する場合、正式な停止時間帯の申請が必要です。これが必要な組織では、カットオーバーやローンチ (またはその他の依存システム) でダウンタイムが必要かどうかを必ず確認し、必要なリードタイム要件を満たせるよう、必要な停止または変更の申請を事前に提出してください。

カットオーバー計画 (必要な場合)

ローンチによっては、既存のソリューションから新しいソリューションへのカットオーバーが発生します。プロジェクトがこのケースに当てはまる場合は、実施が必要な作業をすべて洗い出し、あわせて依存関係、各作業の担当者、必要なタイミングを明確にしておく必要があります。誰かが急に病気になったり、何らかの事情で対応できなくなったりする場合に備えて、重要な役割ごと、または各地域ごとに代替要員を計画しておくことも検討するとよいでしょう。カットオーバー計画で検討すべき項目のチェックリストは次のとおりです。
  • 必要に応じて、カットオーバー計画と切り戻し計画を文書化していますか?
  • 変更前に何らかのバックアップは必要ですか?
  • 事前に必要なデータ変更はありますか?
  • 変更が必要な DNS レコードはありますか?
  • ファイアウォールの変更はありますか?
  • 新たな監視対象はありますか?
  • 展開が必要なソフトウェアはありますか?

Go / no-go の基準

全体的なローンチ計画では、go/no-go の基準を設けておくことに加え、起こりうる問題の種類について、対処しながら進められるものと、ロールバックが必要になるものを事前に話し合っておくと役立ちます。ローンチ計画では、定期的な確認のタイミングや、各チェックポイントで何を評価するかという基準、さらに未解決の問題をどれくらいの期間許容するかを定めることができます。 ローンチの各段階では、計画どおりに進んでおり、そのまま継続できることを示す成功基準を定義しておくと役立ちます。たとえば、次のような基準が考えられます。
  • エラーを最小限に抑えながら、ユーザー登録数が増加している
  • 想定どおりの率でユーザーのログインが発生しており、エラーも最小限に抑えられている
  • 報告されるサポート課題が一定のしきい値を下回っている
  • データ破損につながるおそれのある問題が確認されていない
また、ローンチを停止する「no-go」の判断につながる基準をあらかじめ明確にしておくことも有用です。許容できるリスクの水準は環境ごとに異なりますが、たとえば次のような基準が考えられます。
  • ユーザー登録またはログインのうち、短時間では解決できないエラーになる割合が高い
  • 短時間では解決できないサポート課題の件数が多い
  • データ破損につながるおそれのある状態が確認された
  • 重大度の高いセキュリティ上の問題が見つかった

ロールバック

解決できない不測の事態が発生した場合に備えて、ローンチをロールバックまたは取り消す方法をあらかじめ計画しておくことは、常に重要です。変更を伴う各ステップについてローンチ計画を見直すことで、ローンチやカットオーバーを元に戻すために必要な作業や変更を洗い出しやすくなります。 ロールバック計画には、実施する手順、その順序、それぞれにかかる想定時間、および担当者を含める必要があります。ロールバックに必要な合計時間を把握することで、必要な停止時間内に収まるよう、最終的な go/no-go 判断のタイミングを決めやすくなります。 ローンチにあたって何らかのデータが移行または変更される場合は、必要に応じてそれをどのように元に戻すかも計画に含める必要があります。元に戻すには、運用上の変更を取り消すスクリプトの実行や、ローンチ作業の開始前に取得したバックアップからデータストアを復元する必要があるかもしれません。 また、元に戻す必要が生じる前に、新しいシステムに一部のデータが入力されるケースについても計画しておく必要があります。そのようなデータやトランザクションは、ロールバックに伴って破棄する必要があるのでしょうか。それとも、失われないように別の場所で取り込み、反映する方法を用意できるでしょうか。 問題の解決や差し戻しの手順に1シフト以上かかる可能性がある場合は、各勤務シフト中に対応できるよう、主担当者、そして場合によっては副担当者も確保し、準備しておく必要があります。問題への対応が1シフトを大きく超えて長期化する場合、人が休憩なしで現実的に動き続けられる時間には限界があります。必要に応じて、follow-the-sun 型のインシデント対応体制に使えるリソースを準備しておくと役立ちます。

待機連絡先

ローンチ日が近づいたら、トラブルシューティングや問題解決の際に必要になる可能性がある連絡先をすべて洗い出し、必要に応じてすぐ支援できるよう待機を依頼しておくとよいでしょう。ローンチリーダーは、連絡を迅速に取れるよう、待機リストに載っている各担当者の連絡先情報を把握しておく必要があります。 物理的または仮想的な「ローンチルーム」がある場合は、待機している人たちがその場所を把握し、必要に応じて参加できるようにしておくべきです。あらかじめ共通の部屋やビデオ会議を用意しておくことで、問題が発生した際に、関係者間の連絡やトラブルシューティングを迅速に進められます。

成功基準

ローンチを成功させるには綿密な計画が欠かせませんが、その成果をどのように評価するかは決まっていますか。ローンチ前に成功基準を定めておけば、何を監視すべきか、また評価のために追加の監視や確認が必要かどうかを判断できます。たとえば、成功基準の一つがサインアップ数やログイン数である場合、それを把握する手段はありますか。また、その数値が正確に取得できることを確認するテストは済んでいますか。 ローンチの成功をしっかりアピールするには、裏付けとなる統計が必要です。チームがローンチに注いだ多大な努力を示すデータをまったく取得できていなかった、とローンチ後に気づくような事態は避けたいものです。

リスクと緩和策の計画

起こりうる問題を考えるのは楽しいことではありませんが、いざ何かが起きたときには、事前に計画を立てておいてよかったと思うはずです。計画があれば、対応を早めることができます。あらかじめ想定しておきたい例としては、次のようなものがあります。
  • ソフトウェアのバグ
  • ユーザーのブラウザー設定とアプリケーションの互換性の問題
  • ネットワーク障害/停止
  • DoS攻撃
  • ホスティング環境の障害
  • 負荷/容量の問題
  • データ/破損に関する問題
  • セキュリティ脆弱性の発覚
ベータ期間があった場合は、その結果を振り返ることで、ほかに起こりうる障害シナリオを洗い出す助けになります。

プロジェクト計画ガイド

推奨戦略の詳細を確認できるよう、ダウンロードして参照できるPDF形式の計画ガイドを提供しています。 B2C IAM プロジェクト計画ガイド