オペレーション

まず、Windows 11デプロイに対する運用上の準備状況を判断します。 これには、次のフェーズで閉じる必要があるギャップの特定が含まれます。 この領域で準備状況を評価することをお勧めするタスクと成果物の一覧を次に示します。

運用準備基準を定義する

Windows 11機能更新プログラムをデプロイするときは、新しい運用上の問題が発生していないことを確認する必要があります。 さらに、インシデントが発生した場合は、必要なドキュメントとプロセスを使用できるようにする必要があります。 これを実現するには、運用チームとサポート チームと協力して、許容される傾向を定義し、更新が必要なドキュメントまたはプロセスを特定します。

• Call trend: Windows 11 機能更新に関連する呼び出しの増加率について、どの程度の上昇が許容されるか、またサポート可能であるかを定義します。
• Incident trend: Windows 11に関連するサポートを求めるインシデントチケットの増加率のうち、許容できるかサポート可能なパーセンテージを定義します。
• サポート ドキュメント: 更新が必要なサポート ドキュメントを特定します。 Windows 11機能の更新プログラムの一部として、新しいインフラストラクチャ ツールまたは構成のサポートに重点を置きます。
• Process changes: Windows 11機能の更新の結果として変更されるプロセスを特定します。

展開リングまたはフェーズを定義する

サービス管理モデルでは、代表的なデバイス グループに更新プログラムをロールアウトする効果的な方法が必要です。 多くの組織では、リングベースのデプロイが適切に機能することを発見しました。 Windows クライアントの展開リングは、以前のメジャー リビジョン アップグレード用に構築されたほとんどの組織の展開グループに似ています。 単にデバイスを展開タイムラインまたはフェーズに分割する方法です。

最上位レベルでは、各リングは、特定の更新プログラムを同時に受け取るユーザーまたはデバイスのグループで構成されます。 リングごとに、含めるデバイス、機能更新プログラムの提供を開始するタイミング、インストール期限を定義します。 また、更新プログラムを自分のスケジュールでインストールする機能をユーザーに提供することもできます。

デプロイに必要なリングの数やフェーズ間の移動速度に関する明確な規則はありません。 次の考えられるアプローチを検討してください。

• リスクベースのアプローチ: 最初にいくつかのテスト デバイスに展開し、その後に早期導入者の小規模なグループ、次にさまざまな事業単位を表す大規模なユーザー グループに展開してから、資産の残りの部分に展開します (First-Fast-Broad アプローチ)。
• ミッション クリティカルなデバイスのダウンタイムゼロ: ミッション クリティカルなデバイスを、他のすべてのデバイスの後に更新プログラムを受信する独自のリングに配置します。
• 大規模な組織の管理: 大規模な組織の場合は、地理的な場所に基づいてデバイスをリングに割り当てることを検討してください。 または、ヘルプデスク リソースをより利用できるように、リングのサイズに基づいてそれらを割り当てます。

従来の ファースト-ファスト-ブロード モデルを計画する方法を次に示します。

1. 通常、First リングには、ほとんどのビジネス領域、ビジネス アプリケーション、地理的な場所のクロス セクションを表すデバイス/ユーザー (多くの場合、IT 担当者または技術に精通したユーザー) が含まれます。 ここでのテスト結果が成功すると、ほとんどのビジネス領域が正常に更新できると確信できます。
2. 高速リングには、ビジネスのより多くの領域を表す幅広いデバイス/ユーザーが含まれます。
3. 最後に、ブロード リングは、組織の残りの部分にデプロイすることを意味します。

ビジネスのニーズを考慮し、組織に適したリングを導入しましょう。

(省略可能)概念実証の定義 (PoC)

運用環境に機能更新プログラムをデプロイする前に、オプションの概念実証 (PoC) を実行することもできます。 PoC または制限付きパイロットは、ラボ環境で通常実行されるオプションのフェーズです。 これは、運用環境における公式のファースト デプロイ リング内で、ユーザーやデバイスの代表的なサンプルよりも先に行われます。

PoC は、限られた数の IT 管理者テスト デバイスにWindows 11をダウンロードしてインストールするのと同じくらい簡単な場合があります。 これにより、Windows 11の新機能を確認したり、重要なビジネス アプリを検証したりできます。 また、デプロイ ツールを使用して更新プログラムをデプロイすることで、インフラストラクチャとデプロイ プロセスがWindows 11の準備ができていることを検証するためにも使用できます。

一部の PoC デバイスを Windows Insider Program for Business に登録して、新しいWindows機能をリリースする前に事前に確認することを検討してください。

役割と責任を特定して担当者に割り当てる

更新プログラムの展開準備の重要な部分は、プロセスのさまざまなタスクをサポートする担当者を配置することです。 チーム メンバーの一般的な役割と責任、およびさまざまなレベルの関与のフレームワークを確認しましょう。

主な役割はプロセス マネージャーです。 このロールは、プロセスをリードし、必要に応じてプロセスを進めたり停止したりし続ける権限を与えます。 あなたの責任、スキル、およびあなたが関与するフェーズが次の表にまとめられており、割り当てる必要があるその他の役割と責任も含まれています。

各ロールのアクティブなフェーズには、さまざまなレベルの関与を必要とするタスクが含まれる場合があります。 この期待を設定するには、RACI モデルを使用することをお勧めします。

• 責任： 特定のタスクの完了を担当する個人またはチーム
• 責任者： 全体的な結果の成功または失敗に責任を持つ1名の人物
• 相談： 意思決定またはアクションを実行する前に入力と専門知識が必要な個人またはグループ
• 通知： タスクまたは意思決定の進行状況について通知を受ける必要があるが、その実行に直接関与していないユーザー

プロセス マネージャーは、デプロイの全体的な成功に対する責任を負い、デプロイのすべてのタスクを整理します。 これには、このフェーズおよびその後のフェーズにおける特定のタスクに対し、スキルに基づいて担当者、相談先、および情報提供先を割り当てることが含まれます。 Excel RACI マトリックス テンプレートを使用するか、独自のテンプレートの作成方法を学習して、この計画段階で完了します。

たとえば、このプロセスのタスクのサンプルの RACI マトリックスは次のようになります。

この学習モジュールと次の学習モジュールの最後には、更新プログラムの展開の各フェーズで説明されているすべてのタスクの一覧が表示されます。

デバイスのサービス チャネルを定義する

サービス チャネルを使用すると、環境全体に更新プログラムを適用する頻度を組織が決定できます。 たとえば、できるだけ早くテストに使用するデバイス間で更新プログラムを適用することを選択できます。 一方、特殊な機能に使用されるデバイスは、後で更新プログラムを受信できます。 Windowsのサービス チャネルは次のように定義されます。

ハードウェア更新計画

Windows 11にはハードウェア要件があり、ハードウェア更新計画に影響を与える可能性があります。 既存のハードウェアの一部がWindows 11と互換性がないため、通常の更新サイクルで通常許可されるよりも早く交換する必要がある可能性があります。

必要なデバイス交換の範囲は、展開方法の選択に影響します。 たとえば、ほとんどのデバイスに互換性がある場合は、デバイス スワップ プログラムではなく、Windows 11へのインプレース アップグレードを検討する可能性が高くなります。

新しいハードウェアを選択するときは、Windows Hello for Businessの生体認証機能やCopilot+ PCを必要とするRecall機能などの利用をユーザーが望むかどうかを検討します。 また、よりエネルギー効率の高いデバイスを検討することもできます。

デバイス更新戦略を定義する

組織のWindows 11を正常に展開するには、更新プログラムの実行方法を定義することが重要です。 インプレース アップグレード、デバイスの交換、または再イメージ化を実行しますか?

インプレース アップグレードは、Windows Autopatch の段階的なFeature Updates を使用するか、System Center Configuration Manager のタスク シーケンスを使用して展開することで実行できます。

新しいデバイスは、Windows Autopilot または Windows Autopilot デバイスの準備 を使用して構築できます。または、ハードウェア ベンダーに対して、配信前にそれらを構成するようタスクを実行することもできます。

組織のニーズとデバイスの準備状況に応じて、これらのアプローチの組み合わせを採用する可能性があります。

フィードバック ループを設計する

新しいバージョンのWindowsをデプロイするときは、運用スタッフ、エンド ユーザー、主要な利害関係者など、さまざまなロールからのフィードバックのレビューを含める必要があります。 このフィードバックを収集する方法と、それを使用して意思決定を支援する方法を決定します。 フィードバック方法の例としては、電子メールアンケート、プロジェクト会議、Web フォーム、ユーザー フォーカス グループ、ユーザー グループ チャンピオンなどがあります。

ギャップを特定する

更新プログラムを正常にデプロイするために対処する必要があるギャップや問題を特定します。 たとえば、ヘルプデスク エンジニアは更新プログラムをサポートするためにさらに多くのトレーニングを必要としますか?

引き続きヘルプが必要な推奨タスクや成果物はありますか?