火消し対応を減らせ：アップデートの失敗と手作業によるトラブル対応を削減する

Macの導入に際してIT部門が火消しに追われる理由（とその対策）

macOSデバイスが導入され、エンドユーザの元に届きました。一部のデバイスにはベースラインの設定が適用されているものの、そうでないデバイスもあります。このような状態は、ビジネス運営の妨げになるほか、ユーザにとってもストレスです。

また、同じ状況はIT部門にとっても問題です。トラブルの解決に際し、毎回トリアージ作業（ログを収集・解析し、デバイスのコンプライアンス違反の原因を突き止める）を経る必要が出てくるからです。

このような状況が皆様の組織でもよく起こっているようなら、それはもう偶然の不運ではありません。IT部門が事後対応的になっている証です。アップデートやアプリなどが展開された時点で、トラブル対応の作業が始まり、多大な労力を費やすことになっているというわけです。

中堅企業のIT部門でこのような状況が見られる場合、その原因はスキル不足や計画の不備ではありません。組織としての仕組み・体制です。この点をしっかり理解することこそ、事後的修復の悪循環を脱し、予防的・積極的体制を作り上げる第一歩です。

事後的修復の悪循環

中堅企業のIT部門で問題への対応が「日常業務の一種」になっているとしても、余分な手作業を引き起こす問題が何度も発生する原因を追究するのをやめる理由にはなりません。

そこで、ここではアップデートの展開のよくある流れを見てみましょう。

1. 重大なアップデートが失敗する

デバイスの85％がアップデートを完了したものの、残り15％については完了を確認できないとします。

2. 根本的な問題を特定する

IT部門がレポートを収集のうえデータを分析し、アップデートに失敗したデバイスとその原因を特定します。

3. 展開をやり直す

原因を除去し、展開をやり直した後もなおアップデートの完了が確認できなければ、手作業による介入が必要になります。

4. 手作業による対応を実施する

アップデートの完了が確認できなければ、エンドポイントがリスクにさらされた状態が続くので、手作業によるインストールを実施して対応します。

以上は、デバイスのライフサイクルの最初から最後まで、各種のアップデートを展開するたびに発生します。そのため、展開の回数が多いほど事後対応的な作業に追われ、他の作業に割ける時間が失われていきます。

積み上がる隠れたコスト

トラブル対応のコストとしては時間が最もわかりやすいのですが、コストはそれだけではありません。以下では、時間を含めた様々なコストを確認します。

時間：けっして戻らないもの

IT部門の規模にもよりますが、展開後に問題の修復作業を優先した結果、管理関連の作業が遅れることがあります。

問題の火消しは事後対応であり、それに時間を費やすことは予防的・積極的な体制の構築とは正反対です。事後対応が中心の状態では、IT部門がトラブルの対応に追われます。これに対して、予防的・積極的な体制を構築できていれば、IT部門が自らのスキルを戦略的な取り組みに振り向けることが可能になります。例えば、自動化です。自動化の目的は「日常的な作業の手間や面倒を解消することにより、IT部門が人手を増やすことなく業務拡大に効率的に対応できるようにすること」であり、まさに予防的・積極的アプローチです。

リスク：放置は、窓を開けっぱなしにするようなもの

アップデートに失敗した状態のデバイス、アップデートが一部完了していないデバイス、IT部門がステータスを確認できないデバイス。これらはいずれも、コンプライアンス違反のエンドポイントとして扱う必要があります。

リスクを放置することによる影響は、時間とともに大きくなっていきます。既知の脆弱性が対策されずにいる時間が長ければ長いほど、攻撃の窓口（リスクにさらされる範囲）が大きくなるほか、攻撃者が脆弱性を悪用するチャンス（時間）も拡大していくからです。コマンドベースの管理でコマンドを送信してから、デバイスのステータスが返ってくるまでのタイムラグはその好例です。

士気：レポートには現れないコスト

定量化はほぼ不可能であるものの、IT部門のメンバーが確実に実感しているであろう影響が、士気の低下です。火消し対応に追われることは、精神的にも肉体的にも大きな負担になることが少なくありません。具体的な症状は以下のとおりです。

• 圧倒される：あらゆる出来事にただ反応するだけになります。
• 不満：前に進んでいる感覚がまったくない状態になります。
• 疲労困憊：次々と問題の対応に追われ、肉体も精神もすり減っていきます。
• 退屈：同じ作業を何度も繰り返すことに不毛さを感じます。
• 無気力：作業をやり遂げようという意欲が失われます。

このような症状が長く続けば、一時的に後手に回っているだけだったはずの状態が、トラブルの対応に時間の大半を費やすことが企業文化と言えるレベルまで常態化し、IT部門が有意義な仕事にスキルを発揮することが困難になります。

そうなれば、従業員の定着率にも悪影響が及びます。もっとも、この種の影響は大部分を予防できます。また、予防できなかったとしても、一時的なものにとどめることは十分可能です。

コマンドベースの手法が問題の原因なのか？

違います。IT部門が考えなければならないのは、「従来のMDMのフローで、現代の環境のニーズに対応できているか？」という点です。

この問いに答えるにあたり、従来のMDMで使われているコマンドベース（プッシュ型）の手法の流れを見てみましょう。

1. 管理サーバからデバイスにコマンドをプッシュする。
2. デバイスが、定期的なチェックインのタイミングでコマンドを受信する。
3. デバイスが、データペイロードの処理を開始する。
4. コマンドの処理の完了後に、エンドポイントがMDMにステータスのレポートを返す。
5. デバイスのレコードが、ステータスのアップデートのタイムスタンプとともにサーバに記録される。

以上のMDMのプロセスは、IPネットワークを介してベストエフォートで行われるため、以下のような事態が発生し、展開が失敗に終わることがあります。

• チェックインの時点でデバイスがオフライン：コマンドが受信されなくなります。
• ネットワーク接続が不安定：コマンドがタイムアウトになります。
• ユーザがアップデートのプロンプトを無視：ワークフローが実行されなくなります。
• リソースの競合が発生：コマンドがキューに溜まり、ボトルネックを引き起こします。

このような事態が日々発生することこそ、旧式のMDMが想定していない現代の実情なのです。

状態ベースの管理モデルでトラブルを減らす

状態ベースで管理するという宣言型デバイス管理（DDM）のアプローチは、現代の導入・展開のニーズを念頭に置いたものです。具体的には、まずデバイスのコンプライアンス状態の要件をIT部門が定義します。次に、その定義（ブループリント）を管理対象デバイスに直接配布します。すると、あとはデバイスが自律的にタスクを処理し、組織のニーズに応じたコンプライアンス状態を維持できるようになります。

DDMと旧式のMDMの違い

• 自動による再試行：以下のような事態が起きた場合でも、デバイスが展開を自動で再試行します。
  • デバイスがオフライン
  • ネットワーク接続が不安定
  • ユーザがアップデートプロンプトをキャンセル
• 事前のステータスレポート：次回のチェックインを待つことなくコンプライアンスが検証されます。
• デバイスレベルのポリシー適用：デバイス側で一貫した管理を確保します。

IT部門にとっての効果

中堅企業に関しては、効率的な展開管理プログラムにより頻度の高い問題を予防し、火消し対応を減らすことができるという点が特筆に値します。

失敗が減れば、展開後のトラブル対応も少なくなります。そして、トラブル対応（事後対応）が少なくなれば、IT部門に時間の余裕が生まれ、戦略的（予防的・積極的）取り組みに注力できる体制が実現します。