はじめに

皆さんこんにちは。IT本部IT戦略部の岩崎です。
前回のBlog 「DeNAグループの資産管理システムをServiceNowで構築した話」 に続く、ServiceNow記事第2弾です。
今回はServiceNow上で実現した「資産管理オペレーションの効率化」について、カスタマイズを行った機能とともに紹介します。

この記事では2023年3月に開催したDeNA TechCon 2023で好評を頂いた「より便利を届ける社内IT部門のチャレンジ」から、DeNAグループのIT資産管理システムをSaaSプラットフォームであるServiceNow上に構築した内容についてより詳細に記載します。
TechCon 2023の動画はYouTubeで配信していますので、ご興味ある方はぜひご覧ください。

この記事の流れ

今回はServiceNowの導入で実現した「PC資産管理オペレーションの効率化」について紹介します

• オペレーション効率化の必要性
  • PC資産管理業務の課題
  • 新システムの目指す姿
• 効率的なPC資産運用のための追加機能
  • バーコード読取によるPC操作
  • 返却記録保存機能
  • 効率的な在庫PCの棚卸及び「保管場所」の設定
• 次回予告

オペレーション効率化の必要性

資産管理システムの再構築にあたり、現状の課題感や困りごとを資産管理担当者にヒアリングしたところ、「システム」と「運用」それぞれの課題が明らかになりました。

PC資産管理業務の課題

• 旧システムは「システム開発時点のオペレーション」に合わせて機能が作り込まれているため、現在のオペレーションと合わない箇所がある。
  • システムリリース後に発生した運用変更が反映されていない内容があり、実際の運用とシステムの操作にズレが生じていました。
• 機能拡張や改善に向けた工数捻出が難しい。
  • 旧システムは内製開発であり、運用担当者と開発担当者が異なります。それぞれの担当者は別チームに属しており、開発担当者は資産管理システム以外にも多くの開発案件を抱えています。
  • 機能拡張や改善に向けたシステム改修の際は開発担当者への依頼が必要ですが、日々多くの業務を行う運用担当者にとって「開発依頼」の負担が重い状態でした。
  • 負担が重い理由として、資産資産システムの改修には専門的な業務内容の理解が必要な場合が多く、担当者間で要件ヒアリングや内容調整を丁寧に実施する必要があることが挙げられます。
  • 結果として開発依頼を行うハードルが上がり、なかなか開発依頼を出しにくい状況となっていました。
• 改修完了後に新たな運用変更が生じることも多く、いたちごっこになってしまう。
  • システム外の「スプレッドシート形式の台帳」など、少ない工数で反映できる仕組みや「運用でのカバー」が増える傾向がありました。
  • 結果として「システム外での運用」が増加し続け、全体のオペレーションが複雑かつ効率が悪くなっていました。

新システムの目指す姿

新システムでは、「SaaSのメリットを十分に活かして業務課題を解決するシステム」の実現を目指しました。
また、現状課題を将来繰り返さないことも重要と考え、開発にあたり以下のポリシーを定めました。

• 業務をシステムに合わせる
  • システムを業務にあわせてカスタマイズしない。
  • システム更新をきっかけにオペレーションを見直す。
• 自動化できる箇所は自動化する
  • 工数削減＆オペレーションミス防止のため手作業は最小限にする。
• 不要なことはしない
  • あとで使用するかも。程度のものは実装しない。
  • UIはシステム標準のものを使用する。
• ユーザーによるカスタマイズを可能にする
  • 見た目の変更、項目の追加/変更は担当者自身が実施できるようにする。
• 既存の仕組みやツールを活用する
  • Slack/Google Workspace/Oktaなど、今あるものを有効活用する。
  • ServiceNowの標準機能をフル活用する

上記のうち「業務をシステムに合わせる」点に最も力を入れて取り組みました。業務システムでは「業務に合わせてシステムを作る」ことが一般的ですが、今回の開発では「SaaSであるServiceNowのメリットを活かす」ため、以下を念頭に置いています。
ServiceNowにはPC管理の基本的な機能が備わっており、「世間一般で行われている管理」であればカスタマイズ不要で実現できるはずです。
旧システムで実現していたDeNA独自の管理プロセスひとつひとつについて、「ServiceNow標準機能で実現できるか」をひとつの拠り所にしながら、丁寧に業務を見直します。

効率的なPCの資産運用のための追加機能

この章ではServiceNow上にカスタマイズ開発を行った3つの機能を紹介します。
前述の通り、新システムは原則としてServiceNowの標準機能を活用する方針としています。しかしプロトタイプでのレビューを実施する中で「確かに必要だが、標準機能では不足する機能」が明らかになりました。
機能の不足が運用に及ぼす影響、ServiceNow標準での代替機能有無、運用変更の可否などを考慮した結果、複数の機能について「必要な機能のカスタマイズ開発を行う」決定をしました。

複数PCのバーコード一括読取機能

PC貸出や納品、棚卸などの処理はPCに設定された「12桁の資産番号」をもとに行います。
資産番号の手入力は作業効率と正確性に悪影響を与えるため、PCには資産番号バーコードが必ず貼付されています。
ServiceNowにはスマートフォン用モバイルアプリにおいて「カメラでバーコードを読み取り、PCの特定及び操作を行う機能」が存在します。しかし、DeNAのPC運用では1回に数十台、多いときには100台程度のPCを処理する必要があり、スマートフォンのカメラを用いて「1台ずつバーコードを読み取る」ことは作業速度や効率の観点から要件に合致しません。
一方で旧システムでは「バーコードリーダー」を使用し、効率的にバーコードの読み取りを行っていました。旧システムはスクラッチ開発であったため、バーコード読取画面や後続の処理を自由に設計できます。しかし、ServiceNowには「バーコードリーダーによる複数台一括でのバーコード読み取り」機能が標準搭載されていません。
しかしながら、システム移行により機能が失われると運用工数の増大を招くことが明らかであるため、以下のポイントを定めて開発を行うことを決定しました。
開発のポイントは以下のとおりです。

• 「バーコードリーダーによる一括登録」を共通業務として開発し、PCの納品/貸出/返却受付/リース会社返却/在庫の棚卸など複数の業務で利用できるようにする。
• ServiceNow標準の各業務ワークフロー（貸出/返却等）では「PCを1台ずつ処理」するロジックとなるため、「一括登録」されたデータを分割する必要がある。
• 開発を行うのは「バーコードリーダーによる一括登録」と「登録されたデータの分割」までとし、各業務ワークフローはServiceNow標準のプロセスを使用する。（ServiceNowの標準機能をフル活用する）

それでは機能について見ていきましょう。
各機能は業務プロセスごとに区分したメニューを作成し、作業時の迷いを防止しました。

返却記録保存機能

PCがいつ、どのように返却されたか記録する機能です。
ServiceNowの標準機能では「アサイン先」の設定でPC利用者を特定します。過去のアサイン先の変更や返却日の更新は、「レコードの履歴」機能によりデータベースの更新履歴として記録されています。

DeNAのPC運用では返却時のチェックにおいてPCに故障や不具合がある場合、過去の利用者へ問い合わせを実施しています。 また、PCが再利用され、新たなユーザーが使用を開始した後に「動作が安定しない」などの不具合が報告された場合も「以前の利用者」に同様の事象があったか確認します。 上記の確認タイミングは不定期かつ、しばしば発生します。
当初はServiceNow標準機能で運用する想定でしたが、プロトタイプを用いたレビューの中で「レコードの履歴表示を1件ずつ調べる作業は効率が悪い」、「旧システムで管理できなかった返却記録の管理や問題のあるPCの一覧表示を実現してほしい」との要望が寄せられたため、以下のサブ機能2つとともに「返却記録保存機能」を開発しました。

（サブ機能1）返却記録への郵送伝票情報追加

この数年でリモート勤務が増加したことから、PCの返却及び交換を郵送で実施できるように制度を変更しました。
対面返却では返却PCを返却者本人同席のもとで確認し、「いつ・誰から受け取ったか、PCに破損や汚損は無いか」をその場で記録しています。
郵送返却では大量のPCが一度に到着することがあり、到着の数日後にまとめて実機確認をすることがあります。また「輸送中の事故」の可能性も考慮する必要があります。輸送事故の発生時は運送会社と連携を行う必要があり、到着日や伝票番号の記録が必要になります。
これまでの運用では「郵送返却台帳」スプレッドシートを作成し、各PCの返却日や伝票番号をシステム外で記録していました。この運用を新システム内で実現するため、郵送返却である場合は伝票番号を返却記録に追加する機能を実装しました。
返却時の破損や故障が発生した際、記録された伝票番号をもとに「いつ・どこで発送され、いつ到着したか」、「運送会社はどこであるか」の確認が可能になります。
※伝票番号のインターネット検索期間は3か月程度ですが、PC返却処理は遅くても数日～1週間程度で完了するため、運用上の問題にはなりません。

（サブ機能2）返却時問題の記録

PC返却時によく起こる問題を記録し、状況を管理するための機能です。
返却時の問題として「ACアダプタやケーブルなど付属品の返却漏れ」や「外装の汚損や破損」があります。
これらの問題が発生したPCを放置しておくと、再利用する際に「貸出をしようとしたがACアダプタが欠品していて貸し出せない」「破損品を貸し出してしまう」といった事態が発生しかねないため、問題は適切に記録し、正常なPCと区別しておく必要があります。
旧システムには問題を記録する機能が存在せず、スプレッドシートによる管理を行っていましたが、新システムではスプレッドシートを廃止し、「付属品紛失/外装破損/故障」などの問題を直接記録できるようにしました。
新システム上に問題が記録されたPCは「使用不可」のステータスが自動設定され、再利用ができなくなります。
あわせて、問題の残件数は「資産管理ダッシュボード（後述）」に表示され、例えば足りない付属品が手元に残っていないかを元の利用者に問い合わせる、紛失しているようであれば追加購入するなど、担当者に解消を促します。
【機能の効果】
PC返却履歴の記録によりPCに関する問題が発覚した際、素早く元の利用者を特定し連絡できるようになりました。特に付属品の返却漏れはPC再利用に影響があるため、素早い対応はPCの利用効率向上に繋がります。また、PCの問題を担当者間で共有できる仕組みとしたことで、漏れなく集中して作業できるようになりました。

効率的な在庫PCの棚卸及び「保管場所」の設定

「PC保管庫」の在庫棚卸時に使用する機能です。
これまでは「スプレッドシート形式の在庫リスト」をもとにPCの有無を点検していました。
在庫管理に関する課題として「PC保管庫にはキャビネットが多数あるが、PCの保管場所が記録されていないため、探す手間が大きい」ことが明らかになりました。
在庫PCは故障時の代替機や新入社員への貸与に使用するため、在庫品の提供時間が短縮されることは全社従業員のメリットになります。
上記を考慮し、開発のポイントは以下を設定しました。

• 棚卸業務における担当者の工数をできる限り減らす
• これまで使用していた「スプレッドシート形式の在庫リスト」は使用せず、システム内で完結させる
• 在庫PCの保管場所をシステム上で記録し、PCを速やかに発見できるようにする。

結果として以下2つの機能をカスタマイズにて開発しました。

• 月次棚卸リスト表示機能
  • システム上のステータスから「在庫として存在しているPC」を一覧化し、「スプレッドシート形式の在庫リスト」を置き換えます。
• 実機確認機能
  • 保管庫の棚ごとにPCのバーコードを読み取る方式に変更します。

棚卸作業にて「棚ごとにPCのバーコードを読み取る」ことで、棚情報を「PC保管場所」に反映させる仕組みとしています。

また、対応が必要なPCの残件数と一覧は「資産管理ダッシュボード」に表示するようにしました。「ダッシュボード」を構築することで担当者は「いま・何をすべきか」が明らかになりますし、専用の台帳やリストを別途用意する必要もないため作業そのものに集中できるようになります。
ダッシュボードはあらかじめ用意されたパーツの組み合わせによって自由に構成できるため、要件に応じた画面を簡単に作成可能です。

このように新システムでは「ServiceNow標準機能」をフル活用しながら、必要に応じたカスタマイズを行うことで業務の効率化を実現しています。
ServiceNow上での開発は前回記事で紹介した「FlowDesigner」により、8割以上をGUIによるノーコード環境で開発しています。

次回予告

今回取り上げなかった「コスト管理に関する課題」についてカスタマイズした主要機能を中心に解説します。

この記事の最後に

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