blog

DeNAのエンジニアが考えていることや、担当しているサービスについて情報発信しています

2024.09.17 技術記事

ServiceNowを活用したPC棚卸業務の効率化

by Kazuki Iwasaki

#asset-management #servicenow #saas #情シス

はじめに

皆さんこんにちは。IT本部IT戦略部の岩崎です。
前回のBlog 「DeNAグループの資産管理システムをServiceNowで構築した話」 の後に実施した業務効率化事例として、PC棚卸機能をカスタマイズで実装した事例を紹介します。
現在ServiceNowを使用している方の、より深い活用方法の検討の一助になれば幸いです。
(前回記事はこちら)

この記事の流れ

ServiceNowに構築した資産管理システムにカスタマイズで追加した「PC棚卸機能」について紹介します。

  • PC棚卸の概要
    • DeNAのPCと棚卸方法
    • PC棚卸の課題
  • カスタマイズの検討
    • 実態調査と仮説立て
    • カスタマイズ機能の要件
    • カスタマイズ機能の設計
  • 機能の実装
    • 実装前の準備
    • ワークフロースタジオでのフロー実装
    • Slackからの回答受け入れ設定と「ダッシュボード」の作成
  • PC棚卸機能の動作イメージ
  • 導入効果
  • まとめ
  • 最後に

PC棚卸の概要

DeNAのPCと棚卸方法

DeNAではWindowsとMacの合計で約5,000台のPCを従業員に貸与しています。
PCは業務要件にあわせて複数のスペックから選択が可能です。
また、貸与は1人1台と限定せず、業務上の必要性にあわせて複数台の貸与を実施しています。
PCは原則「リース調達の標準スペックPC」とし、特殊なスペックのPCは購入を行っています。
貸与時は在庫からの払い出しを行うため、入社等の需要予測を実施して在庫が不足しないように運用しています。そのため、需要が多くなる際は在庫が枯渇しないように追加調達を行うことがあります。
また、PCの棚卸は以下の目的で「年に1回」実施していました。

  • 貸与PCの所在確認
  • 貸与PCの継続利用確認
  • OSのサポート切れ等に対する準備

PC棚卸の課題

既存のPC棚卸に対する現場担当者の課題感は以下の通りでした。

  • 年に1回の調査では「即時性」に欠ける。
  • 棚卸の回答率が低い。
  • 開発や検証等の理由で複数台のPC貸与を行っている場合、ログ上で「使用していないPC」が発生していることが判明した。
    • 結果として「使用していないPCにかかっているコストが一定ある」認識である。

ServiceNowでの資産管理システムの稼働後、「貸与しているPCがどれくらい使用されているか」を調査しました。
調査の結果、利用されていないPCの返却勧奨を行うことで、PCの追加調達コストを抑えることができるのではないか?の気づきを得ました。
※上記の調査はServiceNowにカスタマイズで構築した「ActiveDirectory及びデバイス管理システムのログ集約機能」により実施しています。

カスタマイズの検討

カスタマイズの実施判断にあたり、課題に関する実態調査と仮説立てを行いました。

実態調査と仮説立て

  • 実態調査
    • 前回棚卸の未回答率は約20%
    • ログから確認した「直近1か月のログが無いPC」は300台程度
      • 検証用端末もあるため、全台が不要なわけではない。
    • PCリースのコストを平均すると1台7,000円/月程度。
  • 仮説
    • 棚卸回答率の低さについて
      • 棚卸依頼メールに気づいていない可能性が高い。
        • 日常的に使用しているSlackのプッシュ通知なら気づいてもらいやすいのではないか?。
      • メールを読む→システムにログイン→回答の手間が大きい。
        • もっと簡単に回答できると回答率が上がるはず。
          • Slackの受信メッセージから「その場で回答」できれば良いのではないか。
    • 「直近1か月のログが無いPC」の半分が返却されると月に約100万円の効果が生まれる。
      • 毎月発生するコストであり、カスタマイズ工数を考慮しても十分な費用対効果がある。

上記の内容により、「費用対効果が相当に高く、優先的にカスタマイズを行う」ことを決定しました。

カスタマイズ機能の要件

調査結果及び仮説をもとにカスタマイズ機能の要件を固めます。

  • 棚卸は「毎月実施」とする。
    • 毎月手間なく実施できるように「自動的に対象を抽出」できるようにする。
    • 完全自動ではなく、対象をPC管理担当者がチェックできるようにする。
  • 棚卸対象の特定
    • 「1か月以上」PC利用ログが記録されていない端末を対象にする。
    • 複数のログのうち「1種類でも1か月以内のログがある」場合は対象外にする。
    • ログ収集ができないもの(モニタや特殊用途PCなど)は対象外にできるようにする。
  • 棚卸メッセージの送信
    • PC利用者の「Slackアカウント」に対して棚卸メッセージを送信する。
    • 「回答ボタン」をメッセージ内に仕込み、ユーザーは「メッセージ内のボタン」を押して回答できるようにする。
    • 回答ボタンに応じた返信メッセージを自動送信できるようにする。
      • (例)返却すると回答した場合は返却期限や返却方法を送信する。
    • 設定した回答期限までに未回答である場合はリマインダーを送信する。
  • 棚卸結果の記録
    • 回答結果をServiceNowに記録し、PC資産の管理履歴として参照可能にする。

カスタマイズ機能の設計

続いて実装に向けた設計を行います。
設計は「できる限りServiceNowの標準機能を活用する」方針としました。

  • Slack連携には「Slackスポーク」を使用する。
    • 「Slackスポーク」はServiceNowとSlackを連携し、メッセージ送信等を行う機能 です。
    • 機能説明ドキュメント (後述する送信構成と受信決定についても記載されています)
  • Slackメッセージ内の「ボタン」設定はServiceNowの「送信構成」機能を使用する。
  • Slackからの回答は「ワークフロー」及び「受信決定」を使用し、全自動でServiceNowに回答結果を記録する。
  • 回答ログはServiceNowの「カスタムテーブル(PC棚卸履歴テーブル)」に記録する。
    • テーブルには回答結果のほか、メッセージの送信履歴やリマインドの実施履歴を記録する。
  • 作成したテーブルとPC資産のプロパティ情報を連携し、相互参照できるようにする。
  • ダッシュボード機能で「棚卸の回答状況」を把握できるようにする。
    • 特に「返却する」と回答されたPCの返却状況を追跡調査可能にする。

機能の実装

設計に基づき、機能の実装を進めていきます。
PC棚卸機能の全体フローは以下の通りとしました。

PC棚卸のフロー

PC棚卸のフロー

実装前の準備

まずはカスタマイズの事前準備を進めます。
下記の6項目を設定していきます。多いように感じますがGUIから操作できるため、30分程度で完了しました。
1.Slack環境上にメッセージ送信用アプリを作成します。
Slackでのメッセージ送信元として「資産管理システムからのお知らせ」アプリを作成し、利用できるように設定を実施します。
専用ユーザーを作成してメッセージを送信することもできますが、汎用性を考慮して「アプリからの送信」としました。

資産管理システムからのお知らせアプリ

資産管理システムからのお知らせアプリ

2.ServiceNowのSlackスポークを設定します。
ServiceNowの「ワークフロースタジオ」機能から、Slackスポークの設定をします。
SlackとのOAuth認証を実施して連携設定を完了します。
※アクセストークンが切れるとSlackメッセージが送信できなくなるので注意が必要です。

3.PC棚卸履歴の記録用テーブルを作成します。
ServiceNowの「カスタムテーブル」で棚卸回答を記録する「PC棚卸履歴テーブル」を作成します。
テーブル内の「参照フィールド」で「ハードウエアテーブル」と連携することで、自動的にPC資産とのリレーションを設定できます。
テーブルのカラムは以下のように設定しました。

  • 棚卸実施年度
    • (例)2024/08
  • 棚卸方法(選択肢)
    • 随時棚卸や年度棚卸など。今後の拡張性を考慮して設定。
  • ステータス(選択肢)
    • 未回答/回答済/未回答でクローズの3種類を設定。
  • 棚卸メッセージ送信日時(日付時刻形式)
    • 棚卸依頼メッセージの送信日時を記録します。
  • 棚卸メッセージ送信失敗(True/False)
    • Slackメッセージの送信に失敗した場合「True」とします。
  • 棚卸回答期限(日付形式)
    • 棚卸の回答期限をセットします。
  • 棚卸回答(選択肢)
    • 利用を継続する/返却する/問い合わせるの3種類を設定。
  • リマインド回数(数値)
    • 後述するリマインド機能によりリマインドを送った回数を設定します。
  • 管理用コメント
    • 管理者によるメモ用フィールドです

作成した「PC棚卸履歴テーブル」(抜粋)

作成した「PC棚卸履歴テーブル」(抜粋)

4.ServiceNowから送信するSlackメッセージを設定します。
今回のカスタマイズでは「Slackメッセージ上の回答ボタン」で選択された内容を回答結果としてServiceNowに記録します。
まずは「回答ボタンを送信する」設定をServiceNowの「送信構成」機能で作成します。

  • メッセージのタイトル
    • ボタンより前に表示するメッセージを記載します。
  • ターゲットテーブル
    • Slackボタンをどのテーブルに関連付けるか指定します。
    • 今回は先ほど作成した「PC棚卸履歴テーブル」を指定します。
  • ボタン
    • 「ボタンの表記」と「ボタンを押した際の戻り値」を設定します。
  • アクションID
    • 「送信メッセージの識別子」です。この後設定する回答受信時の動作判定に使用します。

Slack送信メッセージ構成

Slack送信メッセージ構成

5.ServiceNowのハードウエア資産テーブルに「除外フラグ」を設定します。
「ハードウエア資産テーブル」にチェックボックス形式で「随時棚卸対象外フラグ」を追加し、対象抽出処理の除外条件として使用します。
随時棚卸対象外フラグの追加

随時棚卸対象外フラグの追加

6.Slackメッセージ送信処理のトリガーを設定します。
ServiceNow標準の「資産タスクテーブル」に「PC随時棚卸Slackメッセージ送信」のタスク種別を作成し、後述するメッセージ送信フローの起動トリガーとして準備します。
タスク種別「PC随時棚卸Slackメッセージ送信」を追加

タスク種別「PC随時棚卸Slackメッセージ送信」を追加

ワークフロースタジオでのフロー実装

続いてServiceNowの「ワークフロースタジオ」で実際の機能を作っていきます。
今回のカスタマイズでは以下の4つの処理フローを作成します。
メッセージ送信処理とリマインド処理は1つのフローに押し込めることもできますが、シンプルな構成にするため別フローとしました。

  • 棚卸対象の抽出処理
  • 棚卸メッセージの送信処理
  • 棚卸メッセージリマインド処理
  • Slackボタンによる回答の受入処理

それぞれの処理フローについて、設定内容を紹介します。

1.棚卸対象の抽出処理

  • 起動タイミング
    • 毎月5日に設定
  • 対象データの抽出
    • PC利用ログが1か月以上存在しないPCを抽出
    • 除外条件として「随時棚卸対象外」フラグを利用
  • PC棚卸履歴テーブルにレコードを作成
    • 抽出結果をもとに、レコードを作成します。
    • レコード作成時に棚卸実施年月や棚卸方法等の項目を設定します。
  • 指定時間まで待機
    • 起動タイミングが土日だった場合、月曜の9時まで待ちます。
    • 日本の祝日設定を入れるか悩みましたが、ロジックが複雑になること、通知対象者は部内特定メンバーとなることを考慮して設定しませんでした。
  • 対象抽出完了メッセージ送信
    • PC管理者へ棚卸対象の抽出が完了した旨をSlackで通知します。
    • 通知は専用の管理者用Slackチャンネルに送信します。
    • Slackメッセージ内のURLから抽出結果を確認できます。

対象抽出完了メッセージ

対象抽出完了メッセージ

2.棚卸メッセージの送信処理

  • 起動タイミング
    • 「棚卸メッセージ送信処理(先ほど作成した処理トリガー)」タスクが作成されたら起動します。
  • 対象データの抽出
    • PC棚卸履歴テーブルから送信対象レコードを抽出します。
    • 「棚卸メッセージ送信日時」が「空」であるもの。(=過去に送信していない。)
    • PCの利用者が在職中かつSlackアカウントを保有しているもの。
  • 送信対象レコードごとにSlackメッセージを送信
    • 参照している「PC資産」をもとに「利用者のSlackID」に対してメッセージを送信します。
    • レコードIDは「PC棚卸履歴」の該当レコードを設定します。
    • 送信構成は事前準備で作成した送信構成「PC棚卸メッセージ送信」を使用します。
  • 送信対象レコードに情報を追加
    • 「棚卸メッセージ送信日時」を現在日時で設定します。
    • 「棚卸期限」を14日後に設定します。
    • 「ステータス」を「未回答」に設定します。
    • 「リマインド回数」を「0」に設定します。
    • Slackメッセージ送信に失敗した場合は「棚卸メッセージ送信失敗」をTrueに設定します。
  • 処理結果の通知
    • 処理結果をPC管理者のSlackチャンネルに通知します。

処理結果通知

処理結果通知

上記の送信処理を行うことでServiceNowに「メッセージの送信ログ」が蓄積されます。
送信ログには「いつ/誰に/どのレコードIDについて送信したか」情報が蓄積され、Slackボタンで回答があると「インバウンドレコード」が作成されるようになります。
Slackメッセージ送信処理フロー(抜粋)

Slackメッセージ送信処理フロー(抜粋)

3.棚卸メッセージリマインド処理

  • 起動タイミング
    • 月曜から金曜の12時に起動します。
  • 対象データの抽出
    • PC棚卸履歴テーブルにおいて以下のレコードを抽出します。
      • ステータスが「未回答」である。
      • 「回答期限日」を超過している。
      • 「棚卸メッセージ送信日時」が「空でない」。
      • 「棚卸メッセージ送信失敗」がFalseである。
  • リマインド回数チェック
    • リマインド回数が「3」である場合はステータスを「未回答でクローズ」に更新します。
    • 毎月実施のため送信+3週間で次回実施前となる計算で設定しています。
  • レコードごとにSlackメッセージを送信
    • 参照している「資産番号」をもとに「利用者のSlackID」に対してメッセージを送信します。
    • 送信設定は事前準備で作成した「PC随時棚卸回答」を使用します。
  • PC棚卸履歴テーブルに情報を追加します。
    • 「リマインド回数」に+1します。
    • 「棚卸期限」を7日後に設定します。
  • 処理結果の通知
    • 処理結果をPC管理者のSlackチャンネルに通知します。

処理結果通知

処理結果通知

4.Slackボタンによる回答の受入処理
PC利用者がSlackボタンから回答した際の処理を作成します。

  • トリガー
    • インバウンドレコード作成時(=Slackで回答ボタンが押されたとき)
  • 対象のPC棚卸履歴テーブル内レコードを検索
    • 回答された対象をインバウンドレコード中の「レコードID」で特定します。
  • 回答結果によるIF分岐
    • 回答ボタンの戻り値により処理を分岐します。
  • レコードの更新
    • 棚卸回答日
      • Slackボタンで回答を行った日時を記録します。
    • 回答内容
      • 回答ボタンの内容により設定します。
  • 返信メッセージ送信
    • 回答者に返信を行います。
    • 回答内容に応じてメッセージの内容を変えています。(継続利用であれば継続利用の注意点を、返却であれば返却手順のWikページを案内します。)
  • レコードの更新
    • インバウンドレコードの「コンテキストID」を「close」にし、処理済みであることを記録します。

Slackボタン回答の受入処理フロー

Slackボタン回答の受入処理フロー

Slackからの回答受入設定と「ダッシュボード」の作成

Slackからの回答受入設定

  • 「受信決定」設定を追加し、Slackボタンによる回答をServiceNowに反映します。
    • 「回答」項目でデータ受信時の動作を指定します。
    • すでに作成した「Slackボタンによる回答の受入処理」ワークフローを指定します。
    • 動作条件として「メッセージ送信設定」で設定したアクションIDを設定します。

上記設定で「PC棚卸機能」のカスタマイズは終了です。

受信決定の設定

受信決定の設定

ダッシュボードの作成
ここまで作成した機能で「棚卸対象の抽出」、「対象へのメッセージ送信」、「リマインド」、「回答結果の反映」が完成しました。
最後にPC管理者あての便利機能として既存の「PC資産管理ダッシュボード」に「随時棚卸状況」メニューを作成し、現在の棚卸状況をモニタリングできるようにしました。

作成したダッシュボード

作成したダッシュボード

PC棚卸機能の動作イメージ

棚卸対象の抽出後、メッセージ送信フローを起動すると棚卸対象PCの利用者に以下のSlackメッセージが届きます。

送信されるSlackメッセージ

送信されるSlackメッセージ

メッセージの受信者は内容を確認し、メッセージ内の各ボタンから回答します。
回答内容に応じて自動返信メッセージが届きます。
例えば「返却する」と回答した場合は、返却期限と返却手順の社内ドキュメントを案内します。
自動返信メッセージの例(返却と回答した場合)

自動返信メッセージの例(返却と回答した場合)

導入効果

カスタマイズ機能により、「回答率の向上・社内ITコストの最適化・担当者の工数削減」それぞれの面で高い効果を発揮しました。

  • 回答率の向上
    • メッセージ送信から3時間以内の回答率65%を達成。
    • 未回答数が90%減少。
      • 未回答で終わるPCもあるが、使用していない場合は翌月も棚卸対象になります。
      • 2か月以上未回答となるケースは全体の2%程度とごく少数で推移しています。
  • 社内ITコストの最適化
    • 初回実施時の記録として、棚卸対象317件のうち106件が返却されました。
    • 仮説通り、在庫の確保によりPC追加購入の抑止に貢献しました。
  • 担当者の工数削減
    • フローの自動化により担当者の棚卸準備作業時間が「ほぼ0」に減少しました。
    • 回答率や回答状況をServiceNow画面上で速やかにチェック可能となり、運用の工数が大幅に改善しました。

まとめ

今回のカスタマイズではServiceNowの機能を活用することで、課題の認識から設計・実装・運用開始まで約3週間で完結しました。
PC管理担当者とServiceNow管理者が対話し、プロトタイプを作りながら開発を進めたことが「高い効果を発揮する機能を迅速に開発」できた最大の要因だと感じています。
今回は「PC棚卸」について紹介しましたが、他にも「リース終了PCの返却確認」や「社内IT費用の社内按分」など多様な機能をServiceNowにカスタマイズで実装しています。
また機会があればBlog記事などで紹介します。

最後に

私の所属するテクニカルオペレーショングループでは新しい仲間を募集しています。
当グループでは、今回紹介した取組のように、DeNAグループ全社IT環境の運用管理にとどまらず「業務改善や効率化・省力化」を目的としたなチャレンジを行っています。
ご興味がある方はぜひ下記リンクから内容をご覧ください。

【社内システム】テクニカルオペレーション 〜社内システムの運用改善でグループ全社へ価値を届けるメンバー募集〜

最後まで読んでいただき、ありがとうございます!
この記事をシェアしていただける方はこちらからお願いします。

recruit

DeNAでは、失敗を恐れず常に挑戦し続けるエンジニアを募集しています。