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

> B2C IAM の導入における、ローンチに向けた準備で考慮すべき事項。

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

<div id="notifications-announcements">
  ## 通知 / 告知
</div>

関係者全員が間近に迫ったローンチを把握し、ローンチ計画と自身の役割・責任を理解していると、ローンチは円滑に進みやすくなります。実際に関与するチームに通知するだけでなく、何か問題が発生した際に対応が必要になる可能性のあるチームにも知らせておくと有効です。ローンチ中に待機要員を確保しておくと、対応を迅速に進める助けになります。ソーシャルメディアも含め、顧客からの問い合わせに対応する必要が生じる可能性のあるチームは、必ず特定して通知してください。

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

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

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

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

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

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

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

通知は、一度にすべて配信するのではなく、バッチに分けて段階的に配信するのが一般的です。こうすることで、初期の負荷集中を分散できるほか、予期しない不具合が発生した場合の混乱の範囲も抑えられます。問題の修正は、一斉リリースの最中よりも、小規模なグループを対象にしたほうが容易です。

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

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

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

<div id="cutover-plan-if-needed">
  ## 切り替え計画 (必要な場合)
</div>

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

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

<div id="go-no-go-criteria">
  ## 実施 / 中止の基準
</div>

全体的なローンチ計画では、実施 / 中止の基準を設けるとともに、起こりうる問題の種類や、そのまま対処しながら進められるものと、ロールバックが必要になるものについて事前に話し合っておくと役立ちます。ローンチ計画には、定期的な確認のタイミングを設定し、各チェックポイントで何を評価するかという基準や、問題が未解決のままどれくらい継続を許容するかを明記できます。

ローンチの各段階について、計画どおりに進んでおり、このまま継続できることを示す成功基準を定義しておくことも重要です。たとえば、次のような基準が考えられます。

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

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

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

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

解決できない不測の事態に備えて、ローンチをロールバックまたは取り消す方法をあらかじめ計画しておくことは、常に重要です。変更を伴う各手順ごとにローンチ計画を見直すことで、ローンチや切り替えを元に戻すために必要な作業や変更を洗い出しやすくなります。

ロールバック計画には、実施する手順、その順序、それぞれにかかる見込み時間、および担当者を含める必要があります。ロールバックに必要な合計時間を把握しておくことで、必要な停止時間帯内に収まるよう、最終的な実施可否判断のタイミングを見極めやすくなります。

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

また、元に戻す必要が生じる前に、新しいシステムに一部のデータが入力される場合についても計画しておく必要があります。そのようなデータやトランザクションは、ロールバックに伴って破棄する必要があるのでしょうか。それとも、失われないように別の場所に取り込み、反映する方法があるのでしょうか。

問題の解決や差し戻しの手順に1シフト以上かかる可能性がある場合は、各勤務シフトで対応できるよう、主担当者と、必要に応じて副担当者も確保し、準備しておくことが望まれます。問題によって1シフトを大きく超える長時間の対応が必要になる場合、人が休憩なしで現実的に動き続けられる時間には限界があります。必要に応じて、follow-the-sun 方式のインシデント対応体制を取れるよう、リソースを準備しておくと役立ちます。

<div id="standby-contacts">
  ## 待機連絡先
</div>

ローンチ当日が近づいたら、トラブルシューティングや問題解決のために必要になりそうな関係者を洗い出し、必要に応じてすぐ支援に入れるよう待機を依頼しておくとよいでしょう。ローンチ責任者は、連絡を迅速に取れるよう、待機者リストに載っている各人の連絡先情報を把握しておく必要があります。

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

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

ローンチを成功させるには綿密な計画が欠かせませんが、その成果をどう評価するかまで見通せているでしょうか。ローンチ前に成功基準を定めておけば、何を監視すべきか、またローンチを評価するために追加の監視や確認が必要かどうかを判断できます。たとえば、成功基準の一つが登録数やログイン数である場合、それを把握する手段はありますか。また、その数値が正確であることを確認するためのテストは実施されていますか。

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

<div id="risks-mitigations-plan">
  ## リスクと対応策の計画
</div>

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

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

ベータ期間があった場合は、その結果を見直して、起こりうる追加の障害シナリオを洗い出すと役立つことがあります。

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

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

[B2C IAM プロジェクト計画ガイド](https://assets.ctfassets.net/cdy7uua7fh8z/3er1aEQ7Ul0q3c9leJWczR/b1f18b4c16abb7e78b01e4eb2b52bb8e/B2C_Project_Planning.pdf)