月刊 Windows 10移行の心・技・体

4月:組織構造に合ったWindows 10のアップデート運用を決める!

松尾太輔 (横河レンタ・リース)

2019-04-15 06:00

 Microsoftは、2019年4月4日(米国時間)に公式ブログ「Improving the Windows 10 update experience with control, quality and transparency」で、今後はPreview Releaseの期間を長くとり、広範にわたってテストを行ってから正式リリースすることを発表しました。

 これにより、本来であれば2019年4月にリリースされるはずだった「バージョン1903(19H1)」は4月の段階ではPreview Releaseであり、正式リリースは5月の下旬になる見込みです。バージョン1809では、ユーザーデータの消失という不具合が発生しましたが、その原因と言われているSlow RingやPreview Releaseの期間が短すぎる問題への対策について、同社が真剣に向き合っていると、筆者は好意的に解釈しています。ただ、年2回定期的にアップデートを提供するという方針は再び変更される可能性があり、まだまだWindows 10アップデートの混乱は続きそうです。

 とはいえ、Windows 7のサポート終了まで、もう残すところ9カ月。Windows 10への移行は待ったなしです。Windows 10の移行を先延ばしにすることはできません。先月(3月)までは、Windows 10を企業に導入する前にその意義や心構えなどの準備について説明しました。今号からは、具体的に導入していくに当たりどのような体制、運用を検討するべきかを説明していきます。「1月:Windows 10導入にくじけない“強い心”を持つ」で述べた通り、Windows 10への移行は、新しい運用への移行です。組織構造にあったアップデートの運用を考えていきましょう。

Windows 10におけるパイロット運用

 Windows 10は、半年に一回の大型アップデート(Feature Update)という大きな変更が加えられるため、IT部門内で完璧な動作試験は困難です。そのために、ある程度をIT部門内で動作試験を行ったら、すぐに本番環境に適用し、段階的に適用先を広げながら問題を解決していくパイロット運用が当然になります。このパイロット運用のやり方について、組織構造と規模から2つのパターンが考えられます。

パターン1:ある程度の従業員規模があり、アプリケーションの担当者が事業部門ごとに存在する

 幾つもの事業部門に分かれている規模の大きな企業だと、事業部門ごとにアプリケーションの担当がいることが多いはずです。事業部門ごとにIT担当者を設置している企業もあるでしょう。この場合は、パイロット運用で最初にアップデートを行うべきは、このアプリケーション担当者になります。パイロット運用は、

  1. Preview(IT部門内の検証)
  2. Targeted(範囲を限定したアップデート)
  3. Broad(広く展開していく)
  4. Critical(問題が発生した場合の影響が大きく、広い対象)

 という段階(Microsoftはこれを「リング(Ring)」と呼んでいます)に大きく分けられます。

 まず(1)Previewは、IT部門の主にインフラ担当、PC担当が対象となるリングです。Windows 10のアップデートができること、各種アプリケーションがひとまず起動することなどを確認します。

 次に(2)Targetedです。このリングが最も重要で、自社内の全ての設定やアプリケーションのパターンに対してアップデートを試すことができる必要があります。ここで限定的な数ではあるが、「全てのパターンのPCにアップデートを適用でき、問題ある、ない」を確認できていれば、この後の(3)Broadで問題が出ることは少なくなるでしょう。逆にカバーできていないパターンがあり、(4)Broadでその問題が出ると、当然(2)Targetedよりも(3)Broadの方が数的に多くなりますので、ユーザーからの問い合わせから問題への対処まで多くの工数を取られることになります。

 なお(2)Targetedの対象は、なるべくITリテラシーが高くかつIT部門と場所的に近い人を選ぶべきです。リモートでの会話や操作のためのツールが充実してきた時代とはいえ、やはり遠いところよりは、近くの方が何か起こった場合に対処しやすいのは言うまでもありません。

 そして(3)Broadです。(3)Broadでは企業規模に応じて、さらに内部で段階を分けて適用します。(3)Broadの対象PCをどれくらいの単位で分けるべきかは、企業規模や担当者の力量で変わってくると思いますが、おおむね下記の点を考慮して設定してください。

  • なるべくIT部門と場所が近いユーザーからアップデートしていく
  • 問題が起こった時に、対処可能な数をまとめてアップデートを行う
  • ネットワークの負荷を考慮する

 最後に(4)Criticalです。このリングの対象とすべきPCは、2パターンあります。一つは、問題が発生すると影響が広く、大きい部署が丸ごとこの(4)Criticalとなってしてしまい、(3)Broadである程度の期間、運用して問題が出ないことを確認してから最後の最後にアップデートするというパターンです。

 もう一つは、(3)Broadの部署で必ず1台以上は(4)Criticalとして、部署全てが(3)Broadの段階ではバージョンアップしないとするパターンです。ただ、このパターンは、グループ分けを厳密にする必要があり、運用に少々骨が折れます。グループ分けを最初きちんとしても、運用していく中で新しい人が入ったり、人が辞めたりしてグループの構成が崩れてしまうからです。これをいちいち管理して、修正していくのは手間がかかるためあまりお勧めしていませんが、どうしても慎重にやりたいという場合はこのパターンを設定しましょう。

ZDNET Japan 記事を毎朝メールでまとめ読み(登録無料)

ZDNET Japan クイックポール

注目している大規模言語モデル(LLM)を教えてください

NEWSLETTERS

エンタープライズ・コンピューティングの最前線を配信

ZDNET Japanは、CIOとITマネージャーを対象に、ビジネス課題の解決とITを活用した新たな価値創造を支援します。
ITビジネス全般については、CNET Japanをご覧ください。

このサイトでは、利用状況の把握や広告配信などのために、Cookieなどを使用してアクセスデータを取得・利用しています。 これ以降ページを遷移した場合、Cookieなどの設定や使用に同意したことになります。
Cookieなどの設定や使用の詳細、オプトアウトについては詳細をご覧ください。
[ 閉じる ]