5,000台のPC管理を自動化！稼働率最適化とコスト削減

はじめに

こんにちは。DeNA IT本部 IT戦略部エンプロイーエクスペリエンスグループの秋葉です。

私たちは、DeNAグループ全体のPCやOSの運用、管理、トラブル対応を担っています。現在DeNAグループで稼働しているPCは、WindowsとMac合わせて5,000台を超えています。その数をいかに効率的に管理するかが私たちの重要なミッションの１つです。

本記事では、DeNAがどのようにして膨大な数のPCと、インストールされているソフトウェアの稼働率を最適化し、コスト削減と資産管理業務の効率化を実現したのか、具体的な仕組みをご紹介します。企業のIT部門でPC管理に課題を感じている方にとって、この情報が一助となれば幸いです。

前提

本取り組みは以下のような環境で実施しました。

PC環境
- OS：Windows / Mac
- 台数：約5,000台（Windows：約2,500台、Mac：約2,500台）
対象PC
- DeNAが貸与する全てのPC
働き方
- オフィス／拠点勤務とリモートワークのハイブリッド
資産管理ツール（台帳）
- ServiceNow
ソフトウェア稼働率を計測するためのデータ（以下「PCログ」とします）
- 全PCに共通してインストールされているEDRのチェックイン日時
- Windows PCとWindows専用MDMのチェックイン日時
- Mac PCとMac専用MDMのチェックイン日時

背景と課題

当時の運用では、ハイブリッドワークや多様な業務特性に対応したPC管理が不十分で、全社的な資産の可視化や最適活用ができていませんでした。具体的には以下の2つの課題がありました。

未使用PCの発生
1人1台に限定せず、業務上の必要性に応じて複数台のPC貸与を許可しているため、未使用状態のPCが一定数発生していました。
- メインPCの故障時に備え、予備機として個人が確保しているケース
- 部署内で共有機として利用しているため、イベント発生時までは長期間未使用になるケース
- 役割変更や異動により利用されなくなったサブPCが、返却されず放置されるケース
棚卸し業務の形骸化
月に一度、PCログが90日以上出ていない端末に対し、自動Slack通知による棚卸しを実施していました。
しかし、回答率の低下や「ただ回答するだけ」といった形式的な運用に陥り、実態把握にはつながっていませんでした。
- 使用継続の回答はあるものの、実際の所在やソフトウェア稼働状況は不明のまま
- 回答のない社員に対して、回収・調査など具体的なアクションが取られていなかった

こうした課題を解決し、PC資産の最適活用とセキュリティ強化を両立させるため、次のセクションでは具体的な目標と評価指標を定義します。

目標と指標定義

前述の課題を踏まえ、PC資産を「持つだけの管理」から「価値を生み出す管理」へと転換するため、取り組みの方向性と達成度を測る指標を明確化しました。

目標
- 稼働率100％の維持
指標（KPI）
- PCログに基づき、直近45日以内に通信実績があるPCを「正常PC」と定義し、対象PCに占める正常PCの割合（%）を稼働率とする。
可視化
- 利用者自身がServiceNowダッシュボードで自分のPC稼働状況を確認できるようにする。
- 上司も必要に応じて状況を把握し、全体フォローアップを支援できる構成にする。
自動化
- 稼働率の集計・通知・管理プロセスの一部を自動化し、週あたりの運用工数を約1時間に抑えるようにする。

アーキテクチャと運用フロー（仕組みの全体像）

全体フロー概要
本仕組みでは、PCログを各ソフトウェアのコンソールからAPIで収集し、TypeScriptによりServiceNowへ送信しています。 ServiceNow側では FlowDesigner を用いて30日超過時のSlack通知やダッシュボード更新を自動化し、5週連続で未対応が続いた場合には上長を含めた自動Slack通知や VPN／証明書失効が段階的に実施されます。

全体のフロー図
ログの収集と連携本システムでは、各種サービスから収集したログをServiceNowに取り込み、棚卸や稼働率の可視化に活用しています。ログ収集と連携は、以下のフローで実行されています。
- 取り込み方式
  - バッチ処理、API連携、スケジュール実行をサービスごとに使い分け
  - APIが提供されている場合は、APIを直接呼び出してログを取得
  - APIがない場合は、SQLによるデータ抽出 → CSV出力 → SCP転送でログを取得
- 処理環境
  - TypeScriptで記述したコードをnode.jsで実行可能なJavaScriptにコンパイル
  - Jenkins上のLinux環境でnode.jsを用いて実行
- データ処理・連携
  - API経由の場合：メモリ上でログを抽出・加工 → ServiceNow APIを呼び出して登録
  - CSV経由の場合：転送されたCSVを抽出・加工 → ServiceNowに登録
  - この仕組みにより、サービスの種類やデータ取得方法に応じて柔軟かつ自動化されたログ収集が可能となっています。
通知・アクションの仕組み
FlowDesignerを用いて、30日超過時にSlackへ自動通知が行われます。当初は、自動Slack通知のみでしたが、返信をアプリ宛に返すユーザも見られ、対応遅延が発生するケースがありました。
そこで、システムアカウントを併用して自動Slackを送る仕組みに改良し、サポートビリティとユーザ体験を向上させました。
さらに、5週連続で未対応の場合は、上長を含めた関係者に遮断予告Slackを送信し、最終的にはVPNの遮断や、社内Wi-Fi接続用802.1X証明書の失効を実施するプロセスとしています。

FlowDesignerと自動Slack通知
可視化と自己確認
ユーザ自身が資産の状態を把握しやすくするため、ServiceNow上で自分にアサインされている資産情報を確認できる仕組みを活用しました。
データは1時間に1回自動連携されるため、ほぼリアルタイムで最新のログ収集状況を確認可能です。これにより、自身の端末がログ収集対象になっているか、期限超過の可能性がないかをダッシュボードから一目で把握でき、事前対応を促す役割も果たしています。
集計
稼働率の集計にはGoogle Apps Script（GAS）を活用しました。 ServiceNowからエクスポートしたデータを取り込むだけで、稼働率が自動で集計される仕組みになっています。これにより、従来の手作業による集計作業を大幅に削減し、定期的な稼働状況の把握とレポーティングを迅速化しました。

成果・今後について

本取り組みを通じて得られた成果と、今後の改善に向けた方向性についてまとめます。実際に運用を開始したことで見えてきた効果と反省点を踏まえ、さらなる改善サイクルの起点としました。

成果

稼働率の向上
通信ログの自動集計と通知の仕組みにより、PC稼働率は約88％から約99％まで改善しました。
100％維持には至らなかったものの、明確な改善効果が確認できました。

施策導入に伴うPC稼働率の推移（2024年10月〜2025年9月の推移）
資産の最適化
過剰または未使用の端末を把握することで、合計200台以上（Windows：約100台、Mac：約100台）の返却を実現しました。 PCリース料やライセンス料を考慮すると、月あたりで約150万円以上のコスト削減が見込まれます。
運用効率の向上
月次棚卸し作業を撤廃でき、施策を通じて資産の所在と正常稼働状況を担保できています。
従業員の意識向上
自動通知やダッシュボードによる可視化により、PC稼働率への意識向上と社内周知が進みました。

今後について

監視項目の拡充
今後は、アンチウイルスソフトの稼働状況や暗号化の有無など、セキュリティ関連項目の監視も強化中です。
遮断プロセスの自動化
現在は人手で対応している端末の遮断処理を自動化し、より迅速かつ効率的な対応を実現します。
また、遮断後の端末に対するフォローアップ体制も整備します。
今後への展望
本施策を基盤として、さらなる運用効率化とセキュリティ強化を推進し、安定した端末管理体制の確立を図ります。

最後に

本記事では、DeNAにおけるPC稼働率の最適化と、それを支える自動化・可視化の取り組みをご紹介しました。今回の施策により、コスト削減や棚卸し業務の撤廃といった運用改善を実現できただけでなく、従業員が自ら資産管理に関わる仕組みを築くことができました。今後も技術や働き方の変化に柔軟に対応しながら、よりセキュアで効率的な端末管理の実現を目指して改善を続けていきます。本記事が、同様の課題を抱える企業の取り組みや検討の一助となれば幸いです。