ローンチ当日の準備（B2B）

通知 / 告知

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

通知先

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

通知計画

通知計画には、対象の、対象者に伝えるべき重要なポイント、メッセージの内容、通知の配信計画、メッセージをどのようにテストするかといった要素を含める必要があります。計画に含める要素は次のとおりです。

対象読者 (社内・社外の両方を考慮)
メッセージ
タイミング
依存関係
担当者 (誰が送信するか)
手段 (どのように伝えるか)
テストメッセージと配信 (該当する場合。通知が確実に送信されることを確認するためにテストします)

通知の配信

一般的な方法として、通知をバッチに分けて配信することで、配信開始直後の負荷集中を分散し、予期しない不具合が発生した場合の混乱の影響範囲を抑えるやり方があります。問題の修正は、大規模な一斉リリース時よりも、小規模なグループを対象にしているほうが容易です。

1 つの方法は、まず比較的小さなバッチで通知を配信し、問題が見つからなければ、時間をかけてバッチの規模を徐々に大きくしていくことです。
また、世界各地で順次配信するスケジュールにすれば、同時にシステムへ集中する負荷を分散できるうえ、各タイムゾーンで最適な時間に通知を届けられるため、メッセージが読まれる可能性を高められます。
個別の顧客、地域、またはアプリケーションにとって適切なその他の単位など、ユーザーの一部を対象にソフトローンチを行うこともできます。

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

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

切り替え計画 (必要に応じて)

ローンチによっては、従来のソリューションから新しいソリューションへの切り替えが必要になることがあります。プロジェクトがこのケースに当てはまる場合は、実施すべき事項をすべて洗い出すとともに、依存関係、各タスクの担当者、必要なタイミングも必ず明確にしてください。想定外の病気やその他の理由で誰かが対応できなくなる場合に備え、重要な役割すべて、または各地域ごとに代替要員を計画しておくことも有効です。切り替え計画で検討すべき項目のチェックリストは次のとおりです。

必要に応じて、切り替え計画とロールバック計画を文書化しましたか？
変更前にバックアップは必要ですか？
事前に必要なデータ変更はありますか？
変更が必要なDNSレコードはありますか？
ファイアウォールの変更はありますか？
新たな監視対象はありますか？
デプロイが必要なソフトウェアはありますか？

Go / no-go の基準

全体的なローンチ計画では、go/no-go の基準を設け、発生しうる問題の種類について、対処しながら進められるものと、切り戻しが必要になるものを事前に話し合っておくと役立ちます。ローンチ計画には、定期的な確認のタイミングを設け、各チェックポイントで何を評価するか、その基準、また未解決の問題をどのくらいの期間まで許容するかを明記できます。ローンチの各段階について、計画どおりに進んでおり、そのまま継続できることを示す成功基準を定義しておくことも有効です。たとえば、次のような基準が考えられます。

エラーを最小限に抑えながら、ユーザー登録数が増加している
想定どおりの割合でユーザーログインが行われ、エラーも最小限に抑えられている
報告されたサポート案件が一定のしきい値を下回っている
データ破損につながるおそれのある問題が確認されていない

また、ローンチを停止する「no-go」の判断につながる基準をあらかじめ特定しておくことも有効です。リスク許容度は環境ごとに異なりますが、例としては次のような基準が考えられます。

ユーザー登録またはログインの一定割合で、短時間では解決できないエラーが発生している
短時間では解決できないサポート案件が多数発生している
データ破損につながるおそれのある状態が確認された
重大なセキュリティ問題が発見された

ロールバック

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

待機連絡先

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

成功基準

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

リスクと軽減策の計画

何がうまくいかない可能性があるかを考えるのは気が進まないものですが、実際に何か起きたときには、事前に計画を立てておいてよかったと思うはずです。あらかじめ計画があれば、対応を迅速に進められます。計画しておくべき項目の例として、次のようなものがあります。

ソフトウェアアプリケーションの不具合
ユーザーのブラウザー設定とアプリケーションの非互換
ネットワーク障害／停止
DoS攻撃
ホスティング環境の障害
負荷／容量の問題
データ破損の問題
セキュリティ脆弱性の発見

ベータ期間があった場合は、その結果を見直して、追加で想定される障害シナリオを洗い出すとよいでしょう。

プロジェクト計画ガイド

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

​通知 / 告知

​通知先

​通知計画

​通知の配信

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

​切り替え計画 (必要に応じて)

​Go / no-go の基準

​ロールバック

​待機連絡先

​成功基準

​リスクと軽減策の計画

​プロジェクト計画ガイド