Zscaler移行PM
実務ガイド
初めてZscaler移行PMを担当した人が、明日から何をすればいいか分かるサイト。
あなたは今日から、このZscaler移行プロジェクトのPMです。
PMが全部の設定をする必要はありません。PMの仕事は、次のことです。
初めて担当したら、まずこの10個を見る
初出の専門用語
このサイトで繰り返し出てくる用語をまとめました。本文中で分からない言葉が出てきたら、ここに戻って確認してください。
初日に確認するもの
前任者や既存資料から、プロジェクトの現在地を把握する工程。クリックすると詳細が開きます。
今の環境を洗い出す
18の調査領域を、担当・期限・状態・未確認事項・リスクで管理する。
IN SCOPE / OUT OF SCOPE
候補をクリックしてIN SCOPEとOUT OF SCOPEを切り替えると、影響が下に表示されます。
Scope Creep（対象範囲の後からの膨張）に注意。 「ついでにこれも」で対象が途中で増えると、スケジュール・体制・テスト計画がすべて崩れる。増える場合は変更管理として扱う。
設計判断が完了しているかを管理する
PMがZscalerの詳細設計を行うわけではない。19の論点について、決定済みかどうかを管理する。
架空プロジェクトでの判断例。Zscalerの唯一の推奨方式というわけではありません。
全体スケジュール
架空のサンプルであり、Zscalerの標準導入期間ではありません。
Dependency Map
工程をクリックして「遅延」にすると、影響を受ける後続工程が赤く表示されます。
プロジェクトを通じて作る成果物
RACI
R：実行担当 A：最終責任者 C：相談先 I：情報共有先。移行PMが全部を担当する表ではありません。
Risk / Assumption / Issue / Dependency
RAID：R＝リスク（起こりうる問題）、A＝前提条件（正しいと仮定していること）、I＝発生済み課題、D＝依存関係、をまとめて管理する台帳。
「設定完了」＝「パイロット可能」ではない
Critical項目が1つでも未完了ならパイロットは開始できません。
50ユーザーで先行検証する
IT・Security・一般ユーザー・リモート/オフィス勤務者を含む50名。合格・不合格・保留・未実施をダッシュボードで管理する。
Wave Planner
Waveごとの状態をクリックで変更できます。全体進捗は自動で更新されます。
プロジェクト状況を一目で見る
本番切替コントロールルーム
架空のタイムラインです。標準的な作業時間・所要時間を意味するものではありません。
移行可能かを判断する
実際の最終判断は、組織で定義された承認者やChange Authority（変更承認権限を持つ責任者・会議体）が行います。
Rollback
新環境で重大な問題が発生したとき、変更前の状態へ戻すこと。
ケースを選び、あなたの判断を選択してください。唯一の正解ではなく、判断の考え方を示す教育用シミュレーターです。
PMが判断すべきこと
技術的なトラブルシューティングの詳細ではなく、PMが判断すべき範囲に絞って整理する。
Hypercare（移行直後の集中サポート期間）
移行直後、問い合わせや障害が集中する期間を手厚く支援する。
運用チームへ引き継ぐ
全項目を確認できたらチェックを入れてください（この端末に保存されます）。
Project Close
完了条件をすべて満たすと、プロジェクト完了を宣言できます。
PMの1日
PMが開催・参加する会議
会議を開くこと自体を仕事にしない。必ずOutputを残す。
PMが全部やる必要はありません
Zscaler移行PMが失敗しやすいパターン
あなたがPMならどうする？
実際の判断は環境・契約・設計・組織ルールで異なります。ここでは考え方の一例を示します。
Zscaler Lab
ZIA・ZPA・認証連携・障害対応などの技術構成を、ブラウザ上で実際に操作して確認できるシミュレーターです。