7月：いざWindows 10 の本格導入へ！ 開始前の総点検
2019年7月14～19日に米国ラスベガスで開催されたMicrosoft最大のパートナー向けカンファレンス「Inspire 2019」に参加してきました。実はこの原稿、帰りの飛行機の乗り継ぎの合間に書いています。ロサンゼルスでの待ち時間は実に6時間！！ 日本とラスベガスの間には直行便がないのでつらいです・・・・・・。
さて、今回のInspireですが、例年よりもMicrosoftが掲げる「クラウドファースト」を強調するものに感じました。走る車から集められる大量のデータを処理することが可能な「Azure SQL Database Hyperscale」や3Dアバターを出現させ、AI（人工知能）による自動翻訳で本人に似せた自動通訳音声プレゼンテーション、TeamsやOfficeのPowerPoint、ExcelがAzureのAIと連携している様が見事にデモで表現されていました。Microsoftの全てはAzureにつながっています。まさに、「クラウドファースト」を体現してみせたデモでした。
実はこの「クラウドファースト」、読者の皆さんが面倒に思っているWindows 10のアップデートと密接な関係があります。従来オンプレミスのシステムでは、数年のスパンでハードウェアのリプレースとともに新しいソフトウェアが採用されることが一般的でした。そのため、ソフトウェアベンダーはどんなに早く新機能を開発して、ユーザーに提供したくてもこのハードウェアのリプレースサイクルに合わせて製品をリリースせざるを得ませんでした。
クラウドは、この状況を見事に変えてくれました。ハードウェアをユーザーに提供しない、クラウドという利用形態が登場したことで、ソフトウェアベンダーはハードウェアのリプレースサイクルに捕らわれずに、従来に比べてずっと早いサイクルでアップデートを提供できるようになりました。
このようにサーバーサイドのソフトウェアは、クラウドに持っていくことでライフサイクルを劇的に短くすることに成功します。しかし、デバイスまではクラウドに持っていくことはできません。人間とクラウドの接点となるデバイスは、どうしても手元に残さざるを得ないのです。そのデバイスが、頻繁にアップデートを繰り返し進化するクラウドと高度に緊密に連携するとしたらどうでしょうか？ 同じようにデバイスも頻繁なアップデートが必要になります。これが“Windows as a Service”というコンセプトが生み出された理由であり、年2回の大型アップデート「Feature Update」が必要になった理由ということは、この連載の第一回（1月号）でもお話しました。
さて、前置きが長くなりましたが、先月までの連載をお読みいただき、毎月1つのフェーズをWindows 10への移行準備を進めてきた皆さんであれば、今はもう問題なく、いつでも本格展開を始めることができる環境が整っているはずです。とはいえ、Windows as a Serviceの体験は誰もが初めてのことです。不安もあると思います。そこで今月は、1月以降の今までの連載を振り返ります。題して、「いざWindows 10の本格導入へ！開始前の点検」です。
強い心を持ちましたか？（1月）
Microsoftのクラウドファーストという戦略は、ユーザーに無益でも、害をもたらすものでもありません。ゼロトラストがセキュリティの常識と言われるクラウドの時代、単一のアーキテクチャーを続けていては悪意あるハッカーに研究され、攻略されてしまいます。常に最新のアーキテクチャーに刷新することで、セキュリティを保つことができるのです。また、ビジネスの進化は加速するばかりです。常に最新の技術を駆使し、最大のパフォーマンスを発揮することはビジネスパーソンとして必須だとも言えます。
まず、心を強く持ち会社やIT部門以外の方々の理解を得ましょう。Windows 10の移行、その後の運用は単に今までのPCの移行・運用の延長線にありIT部門だけががんばればいいだけのものではありません。これは、「利用部門の生産性を継続的に向上していくための仕組みづくり」です。全社で取り組むべき事柄であり、IT部門が抱え込むものではありません。そのためにもしっかりと強い心を持ち、ユーザーを含めた他のステークホルダーに説明しましょう。
予算は確保していますか？（2月）
「Windows 10は、もう買わなくていい」――そうお考えではないでしょうか。それは、今のところ事実ですが、実は別のところにお金がかかるようになるのがWindows 10です。それは、「運用」です。Windows 10への移行は、「継続したセキュリティと生産性の向上のための仕組みづくり」です。この仕組みを円滑に回すためには、やはりお金がかかるのです。そのために、予算を確保しましょう。
このタイミングで、「Device as a Service」の採用を検討してみるのもいいかもしれません。 「Device as a Service」はまだ新しい概念で、全てそろって提供し今すぐ使えるというものはないかもしれませんが、手間ばかり増える運用を「運用された状態をサービスとして受ける（as a Service）」ために、なるべくWindows 10以降のタイミングで不要なものなくし、標準的な環境でPCを使うようにすることをお勧めします。
トップコミットメントを得られていますか？（3月）
何度も繰り返しますが、Windows 10の運用は「利用部門のセキュリティと生産性を継続的に向上していくための仕組みづくり」です。全部IT部門が背負うものではありません。ユーザーも当事者として、相応の労力を担ってもらいます。クラウドと緊密に連携するWindows 10は、事前の厳密な検証が不可能です。そのため、段階的に展開し、問題が発生すれば対処して次の展開に生かすトライアンドエラーが必須の運用となります。この時、「エラーがなぜ起こったのか」「なぜテストをしていないのか」と騒ぎ立てる人がいるとすれば、情報システム部門の大きな精神的負担になります。これをなめてはいけません。こうならないように、きちんとその意義をトップからきちんと発信してもらい、不具合が起こることは当然で、その解決に協力することも当たり前であることを理解してもらいましょう。
組織構造にあったアップデート運用は決まりましたか？（4月）
Windows Updateにおけるパイロット運用のグループ分けは、大きく分けると下記の4つとなります。（Microsoftのレファレンスより）
Preview（IT部門内の検証）
Targeted（範囲を限定したアップデート）
Broad（広く展開していく）
Critical（問題が発生した場合の影響が大きく、広い対象）
この4つに分けた上で、従業員数が多い大企業では事業部門ごとにアプリ担当などが配されていると思いますので、そのメンバーをTargetedに加えるとか、ほとんどのメンバーはBroadに属するわけですが、この人数に同時に問題が発生したり問い合わせがかかってきたりしたら大変だということでしたらBroadをさらに複数に分けることをお勧めします。
Windows 10を一部に試験導入してみましたか？（5月）
上記（4月）のグループ分けは、最初のWindows 10の導入にも使えます。アップデートのみならず、初回の展開も上記のグループ分けで実施してみましょう。
Windows 10のアップデートは問題ありませんでしたか？（6月）
まずアップデートが自動で行われないようにグループポリシーを設定します
4月に検討したグループの単位でPCに命令を送れるようにします
実際にテストのためにアップデートを行います
その結果（進ちょく）を確認します
エラーの場合に備えて、対処方法を用意します
実際にアップデートを試すと分かることですが、Windows 10のアップデートは結構な確率で失敗します。失敗する理由は幾つかありますが、私の肌感覚では「Windows Update Database」が破損してしまう（原因不明）が一番多いように思います。
修復ツールを実行するだけで治るのですが、実行には管理者権限が必要であるため一定数PCがある場合は手間です。これを、手間をかけずに実行する方法や、そもそも失敗を検知できる仕組みを用意しておくようにしましょう。特に失敗の検知ですが、従来の資産管理ツールやパッチ管理ツールの中にはWindows 10のアップデートの対応をうたっていても、実行前は制御できても結果が分からない（ツール上ではアップデータを転送して実行開始すれば成功と判断している）ものが見られます。この場合、アップデートの完了までをきちんと追えません。実際にアップデートの失敗が起こった場合、ツールの問題なのか、OSの問題なのかさえ区別がつきにくくなるため、こういったところにきちんとケアがある製品を選定することをお勧めします。
