Microsoft 365 変更ガイド

クラウドでの継続的な変更

Microsoft 365 クラウド環境は、絶えず変化するハイパースケールのサービス オファリング スイートです。 テクノロジ業界では、一貫して最先端を行うことが、生産性、セキュリティ、ユーザーの幸福にメリットをもたらします。 Microsoft クラウドの変更には、顧客価値を提供し、環境をセキュリティで保護し、ユーザーを喜ばせるという目的があります。 Microsoft 365 の変化のペースは急速かつ継続的です。両方の形容詞は、このモデルが役立つ顧客価値パイプラインを記述します。 Microsoft は、革新的な機能とセキュリティで保護されたサービスを提供することで、ユーザーが組織の効率を高めるのに役立ちます。

Microsoft では、迅速な開発を促進するアジャイル開発モデルを使用しています。 このモデルは、変更が開始されてから運用環境に入るまでの時間を短縮します。 ユーザビリティの向上に役立てるために、お客様の機能実装と価値実現の間の時間を短縮することを目指しています。 最新のクラウド環境では、アジャイル開発が重要です。 これを使用して、お客様からのフィードバック、市場のダイナミクス、規制要件、新たなリスクに基づいて、エンジニアリングの優先順位を迅速に調整できます。 環境への変更の迅速な統合は、フィードバック データをより迅速に受け取り、サービスを反復的に改善できることを意味します。

多くの変更は、ユーザー エクスペリエンスを向上させるために設計された新機能に関連しています。 これらの変更は、より広範なセット内にある変更のカテゴリです。 より広範なカテゴリの変更には、絶えず変化する規制とコンプライアンス環境のニーズを満たすサービス メンテナンス、セキュリティ更新プログラム、更新プログラムが含まれます。

Microsoft は常に Microsoft 365 サービスを改善し、地球上のすべての人とorganizationがより多くのことを達成できるように支援しています。 ユーザー エクスペリエンスの向上に対するコミットメントは、サービスに対する継続的な更新プログラムのストリームを提供することを意味します。 また、デプロイ計画を容易にするために、リリース サイクルに合わせてクライアント更新プログラムをリリースします。 生産性を向上させ、ユーザーを喜ばせる新機能を設計します。 同様に重要なのは、機能がセキュリティで保護された準拠環境で動作することです。 Microsoft は、共有責任モデルの一環として、環境をセキュリティで保護するための広範な対策を講じています。 Microsoft Service Trust Portal でホストされている認定資格は、100 以上のフレームワークに準拠している証拠です。 責任モデルの残りの半分 (お客様の環境) もセキュリティで保護され、準拠している必要があるため、変更と周囲のプロセスを構造化する際に、お客様の潜在的な影響を慎重に検討します。

これまで、顧客組織内での変更の展開は、IT 部門によって厳しく制御されてきました。 テナント内でのデプロイの制御は、最新のクラウド環境の場所を保持しますが、機能のデプロイの高速化は、ユーザーの価値を実現するための鍵です。 Microsoft クラウドが継続的な更新モデルをさらに採用するにつれて、組織は、きめ細かい評価を必要とし、すぐに実装できる変更に関するリスクベースの意思決定を行う能力が最も重要になります。

Microsoft が機能を追加し、ユーザーがこれらの機能を利用すると、データによってサポートされるユーザー エクスペリエンスが向上します。 執筆時点で、継続的更新チャネル (現在のチャネル) を使用している顧客と Semi-Annual Enterprise Channel の間のネット プロモーター スコア (NPS)[1] の比較は、Microsoft 365 Appsの継続的な更新チャネルに対して 10 ポイントの利点 [2] を示しています。 図 1 に比較を示します。

図 1

目標は、organizationに影響があると見なされた場合に制御できる変更 (可能な場合) をorganizationに提供しながら、ほとんどの変更をユーザーにフローさせ、価値、生産性、コラボレーション、およびセキュリティを強化できるようにすることです。

変更の制御: 課題と戦略

迅速な機能リリースと導入の圧倒的な利点にもかかわらず、堅牢な変更管理戦略を使用することが重要です。 変更の管理、特に継続的なクラウド変更は、組織にとって困難な場合があることを認識しています。 IT 部門やその他の防御ラインは、環境に新しいソフトウェアを展開する前に、各変更を詳細に確認する必要があると考えることがよくあります。 これは影響の大きい変更のサブセットにとって有利な戦略かもしれませんが、変更の 100% を確認することは、ユーザーを可能にする無限に進化する機能のデプロイを遅らせる負担の大きい戦略です。

すべての機能や変更がセキュリティやコンプライアンスの統計に影響を与える可能性があるわけではないため、すべての変更を深く分析する必要がない場合があります。 影響を与える変更については、関連する機能を制御するための構成オプションを提供します。 ユーザーが新しい機能を採用できるように、既定では、これらの変更は一般にオンになっています。これらの機能を無効または制限するには、ユーザーのパーツでアクションが必要です。

影響を与える変更を制御する機能は、Microsoft によって提供される差別化要因です。 テクノロジ業界は主にイノベーションに重点を置いています。これは一般に、ユーザーにプラスの影響を与えるものと見なされます。 テクノロジ リーダーや他のクラウド プロバイダーによって提供されるこれらのイノベーションに対する制御の細分性を見つけることは一般的ではありません。 影響の大きい変更を制御する権利を尊重することで、パートナーシップへのコミットメントと最終的な成功を示します。 さらに、全体的な変更エクスペリエンスの向上に取り組んでいます。 変更プロセス、手順、ロードマップの透明性を提供し、お客様のフィードバックを監視することで、お客様がリリースする更新プログラムの急速に増加する量を評価してデプロイできるようにしたいと考えています。

課題

業界の観察、フィードバック、サポート データから、Microsoft 365 の継続的リリース ポリシーに非常に制限の厳しい変更インジェスト モデルを適用する際に、お客様が直面する重要な課題を特定しました。 課題は、Microsoft が最新のクラウドでサービスを更新する頻度です。 この課題を説明するために、Microsoft が線形にリリースされた年間 720 の変更をプッシュするとします。 これらの変更が評価に制限されている場合、変更を適用している IT 部門は、最初の 1 か月後に最大 60 の変更の背後にある可能性があります。 結果として生じる変更のバックログにより、環境内のエントロピが高まり、ユーザーが最新の機能や更新プログラムを利用できなくなります。 問題は、既存の手順に従ってこれらの迅速な変更を処理できるorganizationか、またはリリースのペースに一致できないために変更が無効のままにされていますか?

課題は、"自動車のメタファー" によってさらに説明できます。 多くの組織では、機能とセキュリティのみに重点を置いています。 車両のコンテキストでは、これはポイント A からポイント B への取得に焦点を当てるのと同じです。この場合、所有者は、車両を修理できる場合、車両の動作がわかっている場合、および車両にセキュリティ用のシート ベルトがあるかどうかに満足しています。 ただし、ユーザーを考慮するために、これを読む IT プロフェッショナルに挑戦します。 平均的な自動車消費者にとって、交通機関はBに対してA以上です。ユーザー(消費者ドライバー)は、便宜上、エンターテイメント用のラジオ、空調用のエアコン、パワーウィンドウを望んでいます。 ドライバーは、セキュリティのためにアンチロック ブレーキ システム、エアバッグ、およびシート ベルトを必要とします。 ユーザーが目的地に到達できるようにすることだけに焦点を当てている場合は、より安全で快適で効率的な体験を望む人口を減らしている可能性があります。 組織の防御ラインが、重要な機能、ユーザーが気にする機能、IT 環境の中断を引き起こしている機能について、貴重な時間を費やすと、その負担は持続不可能になります。 これは、変更評価の民主化を求める。詳細については、「 評価民主化の変更」セクションを参照してください。

Microsoft では既定のオフ オプションを提供していませんが、環境の機能を無効にするために提供するオプションを利用する顧客はごくわずかです。 組織が提供されている構成を活用して "すべてオフ" 戦略を採用すると、その結果はオンプレミスソフトウェアの管理に似ています。 もともとクラウドへの移行によって求められる利点は、ユーザーが関心を持つイノベーションが利用できないため、このアプローチによって大部分が疎外されています。 さらに、Microsoft エコシステムは、この戦略によって作成された使用状況データのギャップに苦しんでいます。 たとえば、診断データ [3] は 、お客様が機能をどのように使用するか、機能がどのように全体的なエクスペリエンスを改善しているか (またはそうでないか)、および広範な問題の把握を維持するのに役立つクラッシュ レポートに関する貴重な情報を Microsoft に提供します。 お客様に診断データの制御を提供しますが、これらの制御を実行すると、サービスをセキュリティで保護し、最新の状態に保ち、期待どおりに機能するために必要なデータが制限されます。

これは、環境の制御、適切なトレーニングの確保、従業員のエキサイティングな新機能の提供の間で実現しなければならない微妙なバランスを認識しているため、課題として挙げます。 IT プロフェッショナルは、このバランスを維持する最前線に立っています。そのため、Microsoft はリスクベースのデプロイに関する意思決定を行うツール、透明性、ガイダンスを提供しています。 構成管理ツール、製品ロードマップ、変更通知、およびドキュメントは、変更リスクの均衡に到達するのに役立つ当社のコミットメントの現れです。

この会話は、バックグラウンドで発生するセキュリティ更新プログラムではなく、Microsoft が提供する機能に焦点を当てています。 生産性とユーザー満足を高めるために、徹底的な市場調査で開発したのと同じ機能。 アジャイルな方法で否定的なフィードバックを調整するためのオープン フィードバック チャネルを使用して、お客様がより多くのことを達成するのに役立つ機能。 機能を検証するには、お客様の参加が必要です。つまり、ユーザーが利用するには、まず顧客環境に機能をデプロイする必要があります。

戦略

顧客の 3 つのカテゴリは、観察された変更戦略に基づいて識別できます。変更の最大化、影響の最も制限の多い許可、すべての変更の制限です。 図 2 は、これらのカテゴリをまとめたものです。

図 2

変更の最大化戦略は、ユーザーの生産性を最適化し、コンプライアンスや規制要件なしで動作する中小企業に最も適しています。

[影響の大きい影響を最も制限する] カテゴリは、特に、organizationが規制された環境で動作する場合、または厳格なセキュリティ要件 (金融サービス、医療、航空宇宙業界など) がある場合に、ターゲットにすることをお勧めする戦略です。 変更を評価するためのリスクベースのアプローチを実装するケースは、図 1 の NPS データでサポートされています。

Microsoft は、変更を無効にし、すべての変更を無意識に無効にしないように、意図的に決定を下すことをお客様にアドバイスします。 Microsoft では、詳細な評価が必要な変更に関するリスクベースの意思決定を可能にするとともに、残りの変更を最小限の評価 (およびリスク) ですぐにデプロイできるように努めています。 変更の分類と通知で説明されている変更の影響レベルを事前に特定し、変更情報のソースで説明されている今後の変更を把握することで、評価が必要な変更に関するリスクベースの決定を行うのに役立ちます。

Microsoft 業界の観察によると、すべての変更を制限する戦略は、継続的なイノベーションの利点を制限するため、ユーザーのエンパワーメントに対する負担が過度に大きく、効果が低くなることが示されています。

変更の使用と管理 – メッセージ センターとPlanner

すべての変更戦略では、ユーザーが変更を使用して対処するためのコミュニケーションとメッセージングが必要です。 メッセージ センターは、計画された変更やその他の重要な Microsoft 365 のお知らせの通知ハブです。 メッセージ センターはMicrosoft 365 管理センターにあります。 これには、今後の新機能と変更された機能、計画メンテナンス、その他の重要なお知らせが含まれます。 メッセージには次の 3 つのカテゴリがあります。

• 問題の防止または修正
• 変更を計画し、
• 最新情報を入手する

メッセージ センターで提供されるメッセージ属性には、発行日、メッセージ ID (特定のメッセージの追跡用)、タイトル、および (変更/イベント) 説明が含まれます。 メッセージ センターは、Microsoft 365 全体の変更計画と更新の使用に重要な重要な情報の重要なソースです。 これらのアクションが多い通知からプロジェクトとタスクを構築することは、変更戦略を成功させるために不可欠です。 このコンテンツの理解を深めるために、Plannerはメッセージ センターと統合されており、メッセージをPlannerと直接同期できます。

Planner機能は次のとおりです。

• メッセージ センターからのメッセージの同期。
• 同期されるメッセージの種類を選択します。
• メッセージ同期のケイデンスを設定する。

メッセージがPlannerに同期されると、タスクとしてPlannerに表示されます。 メッセージ センターの投稿タイトルには、関連付けられているサービスのプレフィックスが角かっこで囲まれています。 メッセージが更新されると、その更新はPlanner タスクにも同期されます。

各タスクは、次のように構成されます。

• メッセージ投稿のタイトルには、投稿が関連付けられているサービスを示すプレフィックス ("[SharePoint] 新機能" など) があります。 図 3 に例を示します。
• [開始日] は、タスクがPlannerで作成された時刻に設定されます。
• メッセージ投稿の公開日は、ノートにあります。

図 3

Plannerを使用してタスクを管理したり、タスクをグループ化したり、タスクを戦略的に完了するための計画を作成したりすると、ボードをレビューしたり、管理チームを変更したりして、変更を効率的に追跡できます。

型と制御メソッドを変更する

Microsoft では、戦略に沿った方法で変更を制御および展開するのに役立つさまざまなリリースの選択肢とツールを提供しています。 以前に推奨される戦略について説明しました。このセクションでは、この戦略を実装する方法について説明します。

Microsoft 365 の変更は、両方のサービス (SharePoint Online や Teams など) とクライアントにリリースされます。これは、Microsoft 365 Apps (Microsoft Word、Excel、PowerPoint など) と呼ばれます。 サービスとクライアントにはさまざまなリリースの選択肢と展開制御があるため、リリース管理戦略を実装する際の違いを理解することが重要です。

Microsoft 365 サービスとクライアントの変更の種類

Microsoft 365 の変更は、変更の性質に応じて、計画または計画外にすることができます。 たとえば、セキュリティ更新プログラムは、製品やサービスの新たなリスクや問題に対する反応であるため、常に計画されているわけではありません。 変更の種類によっては、通信チャネルも異なる場合があります。 通信チャネルについては、「 分類と通知の変更」セクションで詳しく説明します。 サービスとクライアント アプリケーションの両方の変更の種類の概要については、表 1 を参照してください。

表 1: Microsoft 365 サービスとクライアント アプリケーションの種類を変更する

アイテム	機能	セキュリティ以外の更新プログラム	セキュリティ
変更の種類	機能の更新 新機能またはアプリケーション 推奨されない機能	問題に関するクライアント修正プログラム	セキュリティ修正プログラム
事前の通知	アクションが必要な変更に関する 30 日分の通知	いいえ;これらは、すべてのチャネルの月次ビルドに含まれます	いいえ;これらは、すべてのチャネルの月次ビルドに含まれます
通信チャネル	Microsoft 365 管理センターのメッセージ センター Microsoft 365 ロードマップ Microsoft 365 ブログ Microsoft Tech Communityの Microsoft 365 領域	Microsoft 365 Apps の更新プログラムに関するリリース情報	セキュリティ情報または CVE
管理者アクションが必要ですか?	時々	まれに	まれに
必要なアクションの種類	設定の変更 ユーザーへの変更の伝達 カスタマイズの検証	管理設定の変更

これらの変更を管理する責任は、Microsoft と Microsoft 365 テナントの管理者の間で共有されます。 詳細については、 Microsoft 共有責任モデルに関するページを参照してください。

次のセクションでは、Microsoft 365 サービスとクライアント アプリケーションから期待できる変更の種類 (関連する責任を含む) について説明しました。次のセクションでは、さまざまなリリースの選択肢と、それぞれに使用できるコントロールについて説明します。

サービス リリース のオプションとコントロール

サービス リリース オプション

Microsoft 365 サービスには、新しい製品の更新プログラムと機能が利用可能になったときに受け取るための 2 つのオプション (Standard Release と Targeted Release) が用意されています。[4] これらのリリース オプションは、organizationがサービス更新プログラムを受け取る方法を管理するのに役立ちます。 リリース オプションの 1 つへの関連付けに基づいて、更新プログラムを受け取るユーザーを指定するためのコントロールを提供します。

Microsoft が製品と機能を開発するにつれて、新しいリリースはさまざまな段階で検証されます。 図 4 は、これらのステージを示し、各検証ステージが広範な対象ユーザーに到達しています。 次のステージに移行する前に、前のステージのデプロイのしきい値を問題なく完了する必要があります。

図 4

Microsoft の機能チームは、まず、開発する機能を検証します。

特定されたバグや問題が解決されると、この機能は Microsoft 365 organizationにリリースされ、検証のための広範なユーザー ベースにまたがってリリースされます。

機能の準備が整ったと見なされた後、更新プログラムが一般に公開される前に、すべての Microsoft にリリースされます。これは、問題を特定するために製品を内部的に "ドッグフード" と呼びます。

次のステージはパブリック リリースです。 対象リリースは、テナントまたは特定のユーザーをターゲット リリース オプションに設定した顧客で構成されます。 お客様が多くの国または地域、クラウド アーキテクチャ、IT プロフェッショナルまたはパワー ユーザーに対して統合テストと広範な検証を実行すると、この段階で大量のフィードバックと製品パフォーマンス データが収集されます。 テナントまたはユーザーのサブセットが Standard リリース用に構成されている場合、この最後のステージは、これらのユーザーと他のユーザーが新しい機能を受け取る段階です。

organization内で変更戦略の民主化を実装するには、IT ユーザーとパワー ユーザーの両方にターゲット リリースを活用します。

サービス リリース コントロール

サービス更新プログラムを受信するための主な制御は、リリース オプションの構成です。 Microsoft では、ユーザーが更新プログラムを受け取る頻度を制御できますが、これらの変更は (IT インフラストラクチャで実行されているソフトウェア インストールではなく) ハイパースケール クラウド サービスにデプロイされます。 Microsoft が特定のテナントに対して実行されている特定のバージョンのサービスを持つグローバル クラウドを管理、更新、セキュリティで保護することは現実的ではありません。 つまり、Microsoft 365 Appsにはリリース チャネルとさまざまな展開ツールの両方が使用可能であるため、サービスの変更により、Microsoft 365 Appsよりもデプロイの制御の細分性が低くなります。

「管理センターでリリース オプションを設定する」の説明に従って、Microsoft 365 管理ポータルでリリース オプションを構成できます。 ポータルに移動し、[設定] [組織の>設定] > [組織プロファイルの>リリース設定] の順に選択します。 図 5 は、Standard リリースのすべてのユーザー、対象リリースのすべてのユーザー、またはターゲット リリースの特定のユーザーを選択できる構成ウィンドウを示しています。

図 5

変更戦略の一部として、ステージングまたはテスト テナントを用意することが重要です。 一部の機能では、ユーザー エクスペリエンスで表示される前にテナントの変更が必要です。 これらのテナントの変更はステージング テナントに実装できるため、運用環境のテナント構成を維持しながら機能をプレビューできます。

クライアント リリース チャネルとコントロール

クライアント リリース チャネル

Microsoft では、ユーザーがクリックして実行するクライアントの更新プログラムをサブスクライブできるさまざまな更新プログラム チャネルを提供Microsoft 365 Apps。 これらのチャネルは、お客様の構成に応じて、テナント全体またはサブスクライブされたサブディビジョンに対して変更がリリースされる頻度を決定します。 チャネルは、IT 部門とパワー ユーザーが今後の変更を評価およびテストするための強力なメカニズムであり、ユーザー人口の増加に対するリリースを妨げることはありません。 詳細については、「Microsoft 365 Apps の更新チャネルの概要」を参照してください。

表 2 に、Microsoft 365 Apps チャネル、現在のチャネル、月次エンタープライズ チャネル、Semi-Annual エンタープライズ チャネルの比較を示します。

表 2: Microsoft 365 Apps更新チャネル

チャネル名	最新チャネル	月次エンタープライズ チャネル	半期エンタープライズ チャネル
推奨される使用	準備ができたらすぐに新しい Office 機能をユーザーに提供しますが、設定されたスケジュールでは提供しません。	月に 1 回だけ、予測可能なスケジュールで新しい Office 機能をユーザーに提供します。	新しい Office 機能をロールアウトする前に広範なテストが必要なorganizationの一部のデバイス。 たとえば、規制、政府、またはその他の組織の要件に準拠する場合などです。[5]
リリース頻度	少なくとも月に 1 回 (多くの場合)、設定されたスケジュールには含まれません	月に 1 回、月の第 2 火曜日	月に 1 回、月の第 2 火曜日
機能の更新プログラム	準備ができたらすぐに (通常は月に 1 回)、設定されたスケジュールでは使用できません	月に 1 回、月の第 2 火曜日	年に 2 回 (1 月と 7 月)、月の第 2 火曜日
セキュリティ更新プログラム (必要な場合)	月に 1 回、月の第 2 火曜日	月に 1 回、月の第 2 火曜日	月に 1 回、月の第 2 火曜日
セキュリティ以外の更新プログラム (必要な場合)	通常、少なくとも 1 か月に 1 回 (多くの場合)、設定されたスケジュールには含まれません	月に 1 回、月の第 2 火曜日	月に 1 回、月の第 2 火曜日[6]
特定のバージョンのサポート期間	次のバージョンが新機能でリリースされるまでは、通常は約 1 か月です	2 か月	14 か月

Microsoft では、organization内のデバイスのMicrosoft 365 Apps更新チャネルを変更するための 3 つのメイン方法を提供します。

• グループ ポリシーを使用して更新チャネルを変更する

• Office 展開ツール (ODT) を使用して更新プログラム チャネルを変更する

• Configuration Managerを使用して更新チャネルを変更する

チャネルを切り替える場合、ユーザーを現在のチャネルからエンタープライズ チャネルに切り替えるときの機能の損失など、特定 Semi-Annual 考慮事項があります。 考慮事項の完全な一覧については、「 チャネルを変更するときの考慮事項」を参照してください。

クライアント リリース コントロール

Microsoft は、本質的に自身を制御するリリース チャネルと組み合わせて、Microsoft 365 クライアントをさらに展開、制御、管理するためのさまざまなツールと構成を提供します。 デバイスとデバイスにインストールされている Microsoft 365 クライアントを管理するためのツールは、これまで分散化されています。 Microsoft ソリューションには、利用可能な多数のサード パーティ製オプションに加えて、次のツールが含まれています。

• Microsoft Configuration Manager

• Microsoft Intune

• Autopilot

• Microsoft 365 Apps管理センター。Cloud Policy と統合されています

• Device Management Admin Consoleにおけるその他の機能

IntuneをConfiguration Manager展開にアタッチすることで (共同管理と呼ばれます)、強力な方法で Microsoft 365 クラウドからワークフローにインテリジェンスをアタッチできます。 次の操作を行うことができます:

• Windows アップグレードの互換性テストを完全に自動化します。
• クライアントの更新プログラムを迅速にデプロイして、organizationを安全かつ迅速に準拠させることができます。
• デバイスで直ちにアクションを実行します。

Microsoft Configuration Managerを使用してMicrosoft 365 Appsの更新プログラムを管理することが理解のソースです。

• Microsoft Configuration Managerを使用してMicrosoft 365 Appsを更新するときに必要な前提条件。

• Configuration Managerが Microsoft 365 クライアント パッケージの通知を受信できるようにする方法。

• Microsoft 365 クライアントがConfiguration Managerから更新プログラムを受信できるようにする方法。

• クライアントがConfiguration Managerから更新プログラムを受信できるようにするオプション。[7]

デプロイ戦略を構成するための包括的な手順については、Microsoft Configuration Managerドキュメントを参照してください。

Microsoft 365 Apps管理センターは、管理者が総保有コストを削減しながら、Microsoft 365 Appsを使用して機能、セキュリティ、品質の更新プログラムをすばやく提供できるように設計されています。 分析情報と制御機能を使用すると、ユーザーのダウンタイムを最小限に抑えるために、より深くほぼリアルタイムのデプロイ情報、問題通知、クイック アクション (スヌーズ、復元、一時停止、再開) を提供できます。

Microsoft 365 Apps管理センターには、Microsoft 365 Appsのデバイス更新プログラムをより適切に管理するためのインベントリと Cloud Update が用意されています。

Office インベントリ

• Office デバイスとアドイン情報の詳細ビューを詳しく調べてみます。
• チャネル/ビルドスプレッドなどの分析情報を表示し、多様性を追加します。
• データをエクスポートします。

セキュリティ通貨

• クロスチャネルのセキュリティ更新プログラムのコンプライアンス状態のダッシュボードを表示します。
• 目標目標とタイムラインを設定して追跡および報告します。
• 障害が発生しているデバイスを特定し、軽減措置を講じてください。

Cloud Update

• 月次エンタープライズ チャネルまたは現在のチャネル上のデバイスの更新プロファイルを設定して、更新プログラムを自動的に受信します。
• Windows 配信の最適化を利用します。
• 更新期限と更新日の除外に対するデバイスのコンプライアンスを維持します。
• 更新プログラムのデプロイを監視し、分析情報と、デプロイを一時停止またはロールバックするオプションを提供します。

クライアント構成コントロール

Microsoft 365 Appsをデバイスとユーザーに展開した後、定義した間隔でエンタープライズ レベルのツールを使用すると、詳細なクライアント構成制御が提供されます。 Microsoft 365 Appsには 2,000 を超える構成オプションがあり、organizationのリスク、コンプライアンス、運用プロファイルに合わせてクライアントの動作を変更できます。

グループ ポリシーは、これまでクライアント設定を適用するために使用されてきましたが、まだ実行可能な方法ですが、ポリシーをユーザーとローミングできるようにするクラウドベースの同期ネクサス サービスを開発しました: Cloud Policy。 このサービスを使用すると、デバイスがドメインに参加していない場合や管理されていない場合でも、ユーザーのデバイスでMicrosoft 365 Apps for enterpriseのポリシー設定を適用できます。 ユーザーがデバイスで Microsoft 365 Apps for enterprise にサインインすると、ポリシー設定がそのデバイスにローミングされます。 また、サインインしているユーザーと匿名でドキュメントにアクセスするユーザーの両方に対して、Office Web アプリに対して一部のポリシー設定を適用することもできます。

図 6 は、ポータルと、Microsoft 365 Apps 管理センターで構成に使用できる膨大な数のポリシー設定を示しています。 Microsoft Intune管理センターでクラウド ポリシーを直接使用することもできます。

図 6

一部の構成オプションは、Excel でのスクロール バーの表示や PowerPoint でのライブ 字幕の利用など、基本的なクライアント動作を制御しますが、他の構成はセキュリティ、コンプライアンス、またはリスク部門にとって重要な場合があります。 図 7 は、デスクトップ クライアント (Translator、Bing イメージ検索、3D マップなど) から Web ベースのサービスをユーザーに提供する、Microsoft 365 Appsの接続エクスペリエンスを有効または無効にするクラウド ポリシー オプションを示しています。

図 7

Microsoft では、運用地域に関係なく、グローバル規模でコンプライアンスとセキュリティの義務を満たすことができるように、プライバシー制御を提供しています。 Cloud Policy では、ドロップダウン メニューを使用してこれらの設定を変更し、そのプロファイルを使用するデバイス全体に変更を適用できます。

評価の民主化を変更する

以前は、継続的な更新を提供する現在のチャネルでのユーザー値をサポートするデータを共有しました。 更新プログラムの評価とテストを迅速化するための 2 つのソリューションとして、このチャネルと月次エンタープライズ チャネルをお勧めします。 Microsoft では、次のチャネルを使用するための 2 つのモデルをお勧めします。

• テスト テナント: 顧客は、受信機能を評価してテストするために、運用環境を模倣するテスト テナントを使用します。 クライアントの場合は、テスト テナントを現在のチャネルまたは月次エンタープライズ チャネルにサブスクライブすることをお勧めします。 サービスの場合は、テスト テナントをターゲット リリース オプションにサブスクライブすることをお勧めします。 テスト テナントは、運用環境とは別の統合テストと製品評価に使用されます。 従来、IT 部門はテスト テナントを所有し、その中でテスト アカウントを運用しています。 これは IT 中心のモデルであり、ボトルネックや不完全な評価が発生する可能性があります。 テスト テナントには、さまざまな部門やロールのユーザーを含めることをお勧めします。 IT 部門はすべての製品に関する専門家ではなく、特定の製品評価を実行するのに常に最適とは限りません。 Microsoft 365 サービスの場合は、対象リリースオプションと標準リリース オプションを使用できます。

  • Microsoft 365 Apps: 特典と更新チャネルを登録または変更する方法については、「organization内のデバイスのMicrosoft 365 Apps更新チャネルを変更する」を参照してください。 利点の詳細については、この記事の 「クライアント リリース チャネル 」セクションを参照してください。

  • Microsoft 365 サービス: これらの更新プログラム チャネルに登録する利点と方法については、「 Standard または Targeted リリース オプションの設定」を参照してください。 チャネルの概要については、この記事の前の 「サービス リリース オプションとコントロール 」セクションを参照してください。

• Power User (専門知識):更新プログラムの評価を民主化するには、運用テナント内のパワー ユーザーを特定し、現在のチャネルまたは月次エンタープライズ チャネル (Microsoft 365 Apps) とターゲット リリース オプション (サービス) にサブスクライブします。 指定されたパワー ユーザーのみが継続的または早期の更新プログラムを受け取り、さまざまなビジネスおよびユーザーの専門知識にわたるフィードバック、バグ、エクスペリエンスの重要なソースとして機能します。

これら 2 つのモデルを同時に使用して、受信更新プログラムの包括的で効果的で効率的な評価を提供できます。 IT 中心の受け入れモデルから離れ、organization全体で評価を民主化すると、作業の速度と品質が向上します。 organizationの残りの部分 Semi-Annual Enterprise Channel または Standard Release オプション (Microsoft 365 Apps サービスと Microsoft 365 サービス) にサブスクライブしている場合、IT ユーザーとパワー ユーザーによってテスト テナントで評価された更新プログラムは、摩擦を減らしてデプロイする準備が整います。

内部的には、Microsoft は Microsoft Elite と呼ばれるプログラムでこれらの変更評価戦略を採用しています。 Microsoft Elite プログラムは dogfood を超え、早期導入プログラムとして機能します。 従業員は、機能と特定のシナリオをテストします。お客様や同僚にリリースされる前に、プログラムと機能を改善する品質フィードバックを提供します。 前に説明したリリースの頻度と変更戦略を使用して、独自の環境でこのプログラムを模倣できます。

Microsoft の変更計画、ポリシー、手順

Microsoft の変更ミッションは、迅速な配信を可能にし、生産性を向上させ、摩擦と中断を最小限に抑えながら、新しいアプリケーションと機能をお客様に喜ばせるようにすることです。 変更の管理は、ユーザーに継続的なイノベーションを提供する常緑化プログラムです。 製品とサービスをセキュリティで保護し、最新の状態に保ち、期待どおりに機能するためには、変更が必要です。 イノベーションはユーザー価値を提供するための鍵ですが、環境に影響を与える変更により、法的、規制、セキュリティ、コンプライアンスのリスクが生じる可能性があることを認識しています。 潜在的なリスクを軽減するために、Microsoft は次の取り組みを行います。

• 定義された変更制御ポリシーと手順に従います。
• 少なくとも 30 日前に影響を及ぼす変更を通知します。
• コミュニティのフィードバックを聞いて、変更リリース プロセスを改善する。

変更管理計画

Microsoft 365 変更管理プランは、お客様が変更を計画および管理できるようにするために不可欠です。 図 8 は、プランの柱を示しています。

図 8

Microsoft Change Management プランでは、各アクションに関連付けられている 3 つの変更フェーズと推奨される顧客アクションについて説明します。 表 3 は、3 つの変更フェーズをまとめたものです。

表 3: Microsoft Change Management Plan のフェーズ

フェーズ 1: 変更前	フェーズ 2: 変更中	フェーズ 3: 変更後
ビジネスの各防御ラインの担当者と共に、エクセレンスまたはクラウド ガバナンス ボードの変更センターを特定します。 既存の変更ポリシーを検証し、必要に応じてポリシーを作成します。	organizationとユーザーへの変更の影響を考慮してください。	メッセージ センターの通信を使用して、今後のサービス変更に関するフィードバックを提供します。
変更について知る: - 製品ロードマップを確認する - Microsoft 365 管理センターでメッセージ センターを確認する	積極的な導入と変更管理を通じて、デプロイ チームを支援し、ユーザーの生産性を向上させるために、ワークフローの変更に注意してください。	organizationでのデプロイの成功を促進し、影響を軽減し、認識と効率を高めるために適応する要因を確認します。
メッセージ センターの通信を使用して、今後のサービス変更に関するフィードバックを提供します。	顧客プロファイルの関係者と連絡先セクションが完了し、Technical Account Manager (TAM) に提供されていることを確認します。	変更は、顧客に利益をもたらすよう設計されています。 ユーザーが変更を認識し、理解し、それらを最大限に活用できるようにします。

変更戦略に関係なく、導入を成功させるには、ユーザーが最新の変更を確実に理解することが重要です。 Microsoft が継続的な変化に向けて市場を動かすにつれて、導入と変更管理の重要性は引き続き上昇しています。

分類と通知を変更する

Microsoft では、お客様が更新プログラムごとに適切に理解と計画を行う際に役立つ変更を分類します。 主要な更新プログラムは、今後の変更を評価および分析するお客様にとって重要な焦点である必要があります。 変更が主要な更新プログラムとして分類されている場合、Microsoft は、アクションが必要になる可能性がある実装の少なくとも 30 日前にお客様に通知することをコミットします。

メジャー更新プログラムとして分類するには、変更が次の条件の 1 つ以上を満たしている必要があります。

• 受信トレイ、会議の委任、共有、アクセスなど、毎日の生産性に対する変更。
• カスタマイズに影響を与える可能性があるテーマ、Web パーツ、およびその他のコンポーネントに対する変更。
• ストレージ、ルールの数、項目、期間などの表示容量を増減します。
• ユーザーの混乱を引き起こしたり、ヘルプ デスク/担保の変更や URL の変更につながる可能性のあるブランド変更。
• 新しいサービスまたはアプリケーション。
• 管理アクションを必要とする変更 (prevent/fix を除く)。
• データが格納される場所に対する変更 (規制または法的要件に影響する可能性があります)。

Microsoft 365 管理センター のメッセージ センターは、変更情報の主要なソースです。 メッセージ センターは、重要度の高い変更 (主要な更新) を赤い感嘆符 (❗) でマークします。これにより、リリースのさまざまな段階で簡単に識別および追跡できます。 図 9 にスクリーンショットを示します。

図 9

メッセージは、上記の右側の列で、次の 3 つのカテゴリのいずれかで識別されます。

問題の防止または修正: これらのメッセージは、organizationに影響を与える既知の問題を通知し、サービスの中断を回避するためにアクションを実行する必要がある場合があります。 問題の予防または修正は、問題を回避するために積極的な対応を促すため、サービスの正常性メッセージとは異なります。

変更を計画する: これらのメッセージは、サービスの中断を回避するために対処する必要がある Microsoft 365 の変更を通知します。 たとえば、今後のシステム要件の変更や削除される機能について通知されます。 サービスを正常に実行し続けるために、管理者が行動する必要がある変更を少なくとも 30 日間通知するよう努めています。

最新情報: これは、organizationでオンになっている新機能または更新された機能について通知する場所です。 機能は通常、「Microsoft 365 ロードマップ」で最初に通知されます。 また、情報に基づくメッセージは、サービス レベル契約に従って計画メンテナンスについてお知らせする場合もあります。 計画メンテナンスにより、ユーザーまたはユーザーが Microsoft 365、特定の機能、メールや OneDrive などのサービスにアクセスできない時間が発生する可能性があります。 詳細については、 メッセージ センターのドキュメントを参照してください。

"問題の防止または修正" メッセージと "変更の計画" メッセージの両方で、管理者からのアクションが必要になる場合があります。 優先順位付けと計画を立てるのに役立つ [ Act by]\(行動\ ) 列には、アクションが必要な日付が含まれています。

メッセージ センター管理ユーザー インターフェイスは、サービス変更情報を取得する 1 つの方法です。 Office 365 Service Communications API を使用して、次の関連データに対してクエリを実行する自動化されたソリューションを構築できます。

• サービスの取得: サブスクライブしているサービスの一覧を返します。
• 現在の状態を取得する: 現在および進行中のサービス インシデントのリアルタイム ビューを返します。
• 履歴の状態を取得する: サービス インシデントの履歴ビューを取得します。
• メッセージの取得: 変更情報を含むインシデントとメッセージ センターの通信を検索します。

変更の分類と通知プロセスを継続的に改善することにコミットします。 お客様の環境に影響を与える可能性のある変更を予測する取り組みは、変更分類の基礎ですが、これらの予測は、お客様のコミュニティからの入力なしに制限されています。 さまざまなチャネルを通じてお客様からのフィードバックを受け取り、アジャイルで民主化された顧客中心の方法で変化の懸念に対応する能力を高めます。

情報源とフィードバック チャネル

広範な普及とアクセシビリティを確保するために、Microsoft はさまざまな場所で変更情報を公開しています。 Microsoft 365 管理 ポータルのメッセージ センターはテナント固有の情報の重要なソースですが、ソーススイート全体に注意して、タイムリーに総合的に情報を得られるようにする必要があります。

変更情報のソース

Microsoft 365 ロードマップ

Microsoft 365 ロードマップは、開発中、ロールアウト中、または発売中の製品の状態を中継するパブリック Web サイトです。 各機能またはワークロードの状態を表示し、タグを使用して検索し、1 つのポータルからリリース日を確認できます。 図 10 に示すように、フィルター処理を使用すると、目的のサービスや機能を簡単に見つけることができます。

図 10

メッセージ センターの毎週のダイジェスト

管理者は、メッセージ センターの毎週のダイジェストを使用して、メールを介したメッセージ センターのコミュニケーションを、ダイジェスト形式で簡単に共有できるサマリー形式で確認できます。 ダイジェストは、お客様のフィードバックに応じて作成され、Microsoft コミュニティの影響がプロセスで変化する革新的な方法を示しています。 お客様は、管理ポータルで設定を変更することで、ダイジェスト メールをオプトアウトできます。 図11はダイジェストの一例を示す。

図 11

Microsoft 管理者モバイル アプリ

Microsoft 365 管理者モバイル アプリには、外出先で会社を管理するのに役立つ 80 を超える機能があります。 このアプリは、Apple App Storeと Google Play でダウンロードできます。 モバイル アプリを使用すると、ユーザーパスワードのリセット、グループへのユーザーの追加、変更通知とアラートの確認などの一般的なタスクを実行できます。 モバイル アラートを有効にすることをお勧めします。これにより、更新プログラムがリリースされた時点で最新情報を確認できます。 図 12 は、モバイル アプリのスクリーンショットを示しています。

図 12

Microsoft 365 管理者モバイル アプリの機能を利用するには、 アプリをダウンロードします。

その他の変更情報リソース

サービスの変更に加えて、Microsoft 365 クライアントも更新します。 どちらの変更セットも、変更管理プランに従い、メッセージ センターで伝達されます。 クライアントの変更に関するドキュメントについては、次を参照してください。

• Microsoft 365 Apps 用更新プログラム チャネルの概要

  • これらの更新チャネルミラー、変更管理プランで前述したチャネルです。

• Microsoft 365 Apps の更新プログラムに関するリリース情報

  • クライアント リリース ノートには、さまざまなプラットフォーム (Mac など) の最新のセキュリティ更新プログラム、更新プログラムのサイズ、更新プログラムに関する豊富な情報が記載されています。

• Microsoft 365 のニュースとお知らせ

  • 正式 なドキュメントとは別に、ブログ投稿の最新のリリースと機能についてお読みください。

• Microsoft 365 サービスの説明

  • セキュリティと生産性を向上させるために利用できる既存の機能の詳細については、Microsoft 365 のサービスと機能に関するページを参照してください。

正式なドキュメント以外では、お客様がMicrosoft Tech Communityに参加して、業界のピアによって変更がどのように管理および展開されるかを把握することをお勧めします。 Microsoft Tech Communityは、アクティブで生のリアルタイムの情報ソースです。 プラットフォームを積極的に監視し、変更がどのように受け取られているかをよりよく理解します。

フィードバック チャネル

Microsoft は、お客様と製品の間に好ましいフィードバック ループを確立します。 顧客から送信されたフィードバックのためにロールバックまたは変更された変更の例がいくつかあります。 お客様は、複数のチャネルを通じてフィードバックを提供できます。

• Microsoft 365 管理ポータル
• メッセージ センター
• Microsoft Tech Community

Microsoft 365 管理ポータル
管理ポータルの各ページの右下にある [フィードバックの提供] ボタンをクリックすると、お客様は フィードバック を提供できます。これは図 13 に示されています。

図 13

メッセージ センター

[ フィードバックの送信 ] ボタンもメッセージ センターに存在するため、ポータル ページを切り替えることなく、受信した変更やその他の通知に関するフィードバックを提供できます。 メッセージ センターからのフィードバックは、Microsoft 内の所有するエンジニアリングチームとマーケティング チームに直接送信されます。 Microsoft の所有者は、送信された新しいフィードバックの日次レポートを受け取ります。 特定の変更またはメッセージに関するフィードバックがある場合は、フィードバックを正しく関連付けることができるように、メッセージ センター ID を必ず含めます。 図 14 では、メッセージ センターの右下にある [ フィードバックの提供 ] ボタンを確認できます。

図 14

メッセージ センターでは、図 15 に示すように、メッセージごとに Like ボタンと Dislike ボタンもサポートされています。 これらを使用すると、フィードバックをすばやく提供できます。 このフィードバックを集計し、それを使用して、最近の変更に関する一般的な顧客の受信を理解します。

図 15

Microsoft Tech Community

このコミュニティは、同僚からの変更情報のソースとして、およびフィードバックを提供するためのフォーラムとして機能します。 Tech Community フォーラムで貴重なフィードバックを監視し、情報を使用して内部の意思決定に影響を与えます。 図 16 は、フィードバック フォーラムの一覧を示しています。

図 16

脚注

1: Net プロモーター スコア (NPS) は、製品またはサービスのユーザー設定を測定する業界の計算です。 NPS は、調査の対象を損なう、サポートする、または中立的なユーザーを考慮して計算されます。 プロモーターの割合からデトラクターの割合を差し引くと、Net プロモーター スコアが得られます。これは、低い -100 (すべての顧客がデトラクターの場合) から 100 (すべての顧客がプロモーターの場合) の高値に及ぶ可能性があります。

2: エラーのマージンが 1.5 です。

3: Microsoft では、「ポリシー設定を使用してMicrosoft 365 Apps for enterpriseのプライバシー制御を管理する」で説明されているように、ユーザー エンドポイントから収集された診断データを制御します。 Microsoft が GDPR の対象となる個人データの処理者またはサブプロセッサーである場合、 Microsoft Online Services Data Protection 補遺 添付ファイル 3 の GDPR 条項は、その処理を管理し、当事者もこのサブセクションの以下の条項に同意します (「個人データの処理。GDPR")。

4: これらのサービス リリース オプションのオプトインに関するガイダンスについては、「 Standard または Targeted リリース オプションの設定」を参照してください。

5: organization全体が半期の間隔にある場合、機能更新の間の 6 か月間の期間により、リリース間のこのような延長期間を待つと、クライアントが規制要件や内部ポリシーに準拠しなくなる可能性があります。

6: これは、Semi-Annual エンタープライズ チャネルのセキュリティ以外の更新プログラムの選択されたサブセットで構成されます。

7: Configuration Managerが Office の更新プログラムを管理できるようにするには、Office がインストールされているコンピューターで Office COM オブジェクトを有効にする必要があります。 Office COM オブジェクトは、クライアント更新プログラムをダウンロードしてインストールするために、Configuration Managerからコマンドを受け取ります。 Office COM オブジェクトを有効にするには、Configuration Manager、グループ ポリシー、または Office 展開ツールでクライアント ポリシーを使用します。 複数のメソッドを使用する場合は、グループ ポリシー設定によって最終的な構成が決まります。