> ## Documentation Index
> Fetch the complete documentation index at: https://auth0-feat-init-gt-translations.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

> ステークホルダーへの通知、カットオーバーとロールバックの手順、ゴー／ノーゴー基準、待機担当者、成功指標を網羅した計画により、Auth0 B2Bロールアウトのローンチ当日を調整し、本番稼働を円滑かつ確実に元に戻せるようにします。

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

<h2 id="notifications-announcements">
  通知 / お知らせ
</h2>

すべての関係者が差し迫ったローンチを把握し、ローンチ計画と自分の役割や責任を理解していれば、ローンチは円滑に進みやすくなります。積極的に関与するチームへの通知に加えて、何か問題が発生した場合に支援が必要になる可能性のあるチームにも知らせておくと役立ちます。ローンチ中に待機担当者を置いておくことで、迅速な対応につながります。ソーシャルメディア上の問い合わせを含め、顧客からの質問に対応する必要がある可能性のあるチームは、必ず特定して通知してください。

<h3 id="parties-to-notify">
  通知先
</h3>

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

<h2 id="notification-plan">
  通知計画
</h2>

通知計画には、対象となる<Tooltip tip="Audience: 発行されたトークンのaudienceの一意の識別子。トークンではaudという名前で、ID トークンの場合はアプリケーション（Client ID）のID、Access Tokenの場合はAPI（API 識別子）のIDがその値に含まれます。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=audience">audience</Tooltip>、そのaudienceに伝える重要なポイント、メッセージ内容、通知の配信計画、メッセージのテスト方法などの要素を含める必要があります。

計画に含める要素は次のとおりです。

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

<h2 id="notification-distribution">
  通知の配信
</h2>

一般的には、通知を段階的に配信して、初期の急激な負荷集中を分散させるとともに、予期しない不具合が発生した場合の混乱の影響範囲を抑えます。大規模な一斉ローンチの最中よりも、小規模なグループを対象にしたほうが問題を修正しやすくなります。

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

<h2 id="outage-windows-if-needed">
  停止時間帯 (必要な場合)
</h2>

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

<h2 id="cutover-plan-if-needed">
  カットオーバー計画 (必要な場合)
</h2>

ローンチによっては、旧ソリューションから新しいソリューションへのカットオーバーが必要になることがあります。プロジェクトがこのケースに当てはまる場合は、必要な作業をすべて洗い出し、依存関係、各タスクの担当者、必要なタイミングを確実に明確にしておく必要があります。誰かが急に病気になったり、その他の理由で対応できなくなったりした場合に備えて、重要な役割ごと、または各リージョンで代替要員を計画しておくとよいでしょう。カットオーバー計画で検討すべき項目のチェックリストは次のとおりです。

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

<h2 id="go-no-go-criteria">
  ゴー／ノーゴーの基準
</h2>

全体的なローンチ計画では、ゴー／ノーゴーの基準を設け、発生しうる問題の種類について、対処しながら進められるものと、切り戻しが必要になるものを事前に話し合っておくと効果的です。ローンチ計画では、定期的な確認の時間枠を定め、各チェックポイントで何を評価するか、また問題が未解決のままどれくらい継続することを許容するかという基準を明記できます。

ローンチの各ステージでは、ローンチが計画どおりに進んでおり、このまま継続できることを示す成功基準を定義しておくと役立ちます。基準の例としては、次のようなものがあります。

* エラーを最小限に抑えつつ、ユーザーのサインアップ数が増加している
* ユーザーのログイン数が想定どおりに推移しており、エラーも最小限である
* 報告されるサポート案件が一定のしきい値を下回っている
* データ破損につながる可能性のある問題が確認されていない

また、ローンチを停止する「ノーゴー」の判断につながる基準を特定しておくことも有効です。各環境でリスク許容度は異なりますが、基準の例としては次のようなものが挙げられます。

* ユーザーのサインアップまたはログインのうち、短時間では解決できないエラーになるものの割合が高い
* 短時間では解決できないサポート案件の件数が多い
* データ破損につながる可能性のある状態が確認された
* 重大度の高いセキュリティ上の問題が発見された

<h2 id="rollback">
  ロールバック
</h2>

解決できない不測の事態が発生した場合に備えて、ローンチをロールバックまたは取り消すための計画を用意しておくことは、常に賢明です。変更を伴う各ステップについてローンチ計画を見直すことで、ローンチやカットオーバーを元に戻すために必要な作業や変更を洗い出しやすくなります。

ロールバック計画には、実施する手順、その順序、それぞれにかかる想定時間、そして担当者を含めるべきです。ロールバックに必要な合計時間を把握しておくことで、必要な停止時間帯に収まるよう、最終的な実施／中止の判断をいつ行うべきか見極めやすくなります。

ローンチに伴ってデータを移行または変更する場合は、必要に応じてそれをどのように元に戻すかも計画に含める必要があります。元に戻すには、運用上の変更を取り消すためのスクリプトを実行したり、ローンチプロセス開始前に取得したバックアップからデータストアを復元したりする必要が生じる場合があります。

また、ロールバックが必要になる前に、新しいシステムに何らかのデータが入力されるケースについても計画しておく必要があります。そのようなデータ / トランザクションは、ロールバックに伴って破棄しなければならないのでしょうか。それとも、失われないように別の場所で取り込み、反映できる方法を用意できるでしょうか。

問題の解決や元に戻すための手順に1シフトを超える時間がかかる可能性がある場合は、各勤務シフトで対応できるよう、主担当者に加えて必要に応じて副担当者も確保し、準備しておくことが重要です。問題への対応が長期化し、1シフトを大きく超える対応が必要になった場合、人が休憩なしで現実的に動き続けられる時間には限界があります。必要に応じて、時差を活用して引き継ぎながら対応する体制のための要員を準備しておくと役立ちます。

<h2 id="standby-contacts">
  待機担当者
</h2>

ローンチ日が近づいたら、トラブル対応や問題解決のために必要になる可能性がある関係者をすべて洗い出し、必要なときにすぐ対応できるよう待機を依頼しておくとよいでしょう。連絡を迅速に取れるよう、ローンチの責任者は待機リストにいる各担当者の連絡先情報を把握しておく必要があります。

物理的または仮想の「ローンチルーム」がある場合は、待機担当者がその場所を把握しており、必要に応じてすぐ参加できるようにしておくべきです。あらかじめ中心となる部屋やビデオ会議を用意しておくことで、問題が発生した際に、関係者全員の連絡やトラブル対応を迅速に進められます。

<h2 id="success-criteria">
  成功基準
</h2>

ローンチを成功させるには多くの計画が必要ですが、その成果をどう評価するかまで見えているでしょうか？ ローンチ前に成功基準を定義しておけば、何を監視すべきか、またローンチを評価するために追加の監視やチェックが必要かどうかを判断できます。たとえば、成功基準の1つがサインアップ数やログイン数である場合、それを監視する手段はありますか？ また、その数字が正確であることを確認するためのテストは済んでいますか？

ローンチの成功をしっかりアピールするには、統計データが必要です。チームがローンチに注いだ多大な努力を裏づけるデータを何も取得できていなかった、とローンチ後に気づくような事態は避けたいものです。

<h2 id="risks-mitigations-plan">
  リスクと緩和策の計画
</h2>

問題が起こり得る事態を考えるのは楽しいものではありませんが、いざ何かが起きたとき、事前に計画を立てておいてよかったと思うはずです。計画があれば、対応を迅速に進められます。計画しておくべき事例には、次のようなものがあります。

* ソフトウェアのバグ
* ユーザーのブラウザー設定との非互換
* ネットワーク障害／停止
* DoS攻撃
* ホスティング環境の障害
* 負荷／容量の問題
* データの破損に関する問題
* 発見されたセキュリティ脆弱性

ベータ期間を設けていた場合は、その結果を振り返ることで、起こり得る追加の障害シナリオを洗い出すのに役立つことがあります。

<h2 id="project-planning-guide">
  プロジェクト計画ガイド
</h2>

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

[B2B IAM プロジェクト計画ガイド](https://assets.ctfassets.net/cdy7uua7fh8z/63F0WOPJdVzsPMxV1Xvp8x/7a329487c5e890d8e820f6a48983b46a/B2B_Project_Planning.pdf)