--- Title: "エンタープライズサービスマネジメント：共有されたツールだけでなく、共有された理解を求める理由" Url: "https://devrev.ai/blog/enterprise-service-management" Published: "2026-08-25" Last Updated: "2026-08-25" Author: "Neelabja Adkuloo" Excerpt: "エンタープライズサービスマネジメントは、すべての部門に1つのインボックスを与えましたが、1つの理解は与えませんでした。ESMの価値を左右する、レコードとグラフの違いをここで解説します。" Reading Time: 4 --- # エンタープライズサービスマネジメント：共有されたツールだけでなく、共有された理解を求める理由 ほとんどの企業はすでにITSM（IT Service Management）を導入しています。彼らに欠けているのは、ITがプロフェッショナルなサービス提供の観点で評価される一方で、人事、財務、ファシリティ、法務がメール、スプレッドシート、その場しのぎのSlackスレッドで業務を回している状態を止める手段です。 そのギャップこそが、Enterprise Service Management（ESM）の存在する領域です。「他部門向けのITSM」としてではなく、企業全体で業務がどのように流れるかについてのリーダーシップの意思決定として存在します。 > [!INFO] > ## エンタープライズサービスマネジメント（ESM）とは何か？ > > エンタープライズサービスマネジメントは、ITSMの構造を、たとえば人事、法務、財務などを含むあらゆる部門に適用します。その目的は、組織のあらゆる側面にわたって、合理化され統一されたサービスマネジメントのアプローチを生み出すことです。 > > しかし、1つのプラットフォームは通常、1つのキューを意味します。つまり、同じ場所に集めること（co-location）であって、理解（comprehension）ではありません。 真のESMとは、1つのシステム内のチケットに関するものというより、エンタープライズサービスとその連関についての共有されたモデルに関するものです。 ## TLDR：共有されたツールは、共有された理解ではない - ESMは、ITSMの構造化されたワークフロー、SLA、サービスカタログを、人事、法務、財務、そしてその先へと拡張します。 - 1つのプラットフォームはしばしば、複数のチームに対する1つのキューを意味します。つまり、チケットを同じ場所に集めること（co-location）であって、業務がどうつながっているかの理解（comprehension）ではありません。システムオブレコードは物事がどこに保管されているかを覚えていますが、ナレッジグラフはそれらがどう関係し合っているかを理解します。 - 部門横断的なリクエストがスムーズに解決されるのは、システムがそれらを孤立したチケットとしてではなく、1つのエンドツーエンドのストーリーとして扱う場合のみです。 - 本当の勝利は、単に共有されたツールではなく、エンタープライズの業務についての共有された理解です。 - **Computer, by DevRev**は、システムオブレコードではなく、ナレッジグラフの上に構築されています。 ## ITSMとESMの違いは何か？ ESMはしばしば、ITSMのプロセスを非IT部門へ持ち込むこととして枠づけられます。それはストーリーの一部ではありますが、不完全です。 ツールを拡張すること、すなわち同じチケッティングシステムにより多くのチームを追加することは、理解を拡張すること、すなわち業務・人・システムがビジネス全体で実際にどうつながっているかを意図的にモデル化することと同じではありません。前者はより多くのキューをもたらします。後者は、計測し、改善し、スケールできるオペレーティングモデルをもたらします。 | 観点 | ITSM | ESM | | --- | --- | --- | | スコープ | ITサービスのみ（ハードウェア、ソフトウェア、ネットワーク、インシデント、変更）。 | すべての社内サービス（人事オンボーディング、財務承認、ファシリティリクエスト、法務インテーク、およびIT）。 | | プロセス | インシデント、リクエスト、変更、問題、資産管理（多くの場合ITILに準拠）。 | ITSMのパターンの上に構築された部門ワークフロー（オンボーディング、アクセスリクエスト、調達、ケース管理）。 | | サービスポータル | IT中心のカタログとセルフサービス。 | すべての社内サービスのための統一されたエンタープライズポータル。 | | オーナーシップ | IT部門。 | ITと事業部門（人事、財務、オペレーションなど）の間で共有。 | ## 標準的なESMの約束 グローバルなEnterprise Service Management（ESM）市場規模は、[予測](https://www.businessresearchinsights.com/market-reports/enterprise-service-management-esm-market-117866)では、2025年の約133.8億米ドルから、2035年までに約396.7億米ドルへ、CAGR 11.5%で成長すると見込まれています。この成長は、買い手が売り込まれた成熟のストーリーを反映しています。あらゆる部門のリクエストを1つのプラットフォームで扱うというのは、正しく聞こえます。 ESMソフトウェアは、ビジネス部門横断的にサービスオペレーションを統合する統一システムを提供します。これにより、エンドユーザーは単一のコンソールからサービスを発見してアクセスでき、サービスプロバイダーは、業務・情報・インサイトが部門をまたいで流れる単一のワークスペースの恩恵を受けられます。 ## 共有インボックスが隠す失敗 1つのプラットフォームは、静かに1つのキューへと変わり得ます。人事、法務、IT、財務のリクエストはすべて同じツールに届くかもしれませんが、そのツールは依然として各リクエストを孤立したレコードとして扱い得ます。リクエストをまとめて記録することは、同じ場所に集めること（co-location）であって、理解（comprehension）ではありません。 従来のESMは、共有されたシステムオブレコードにワークフローを集中させます。それは部門横断的にリクエストを整理できますが、それらのリクエストがどう関係し合っているかを自動的に理解するわけではありません。 月曜日から働き始める新入社員を考えてみましょう。そのオンボーディングは次のようなものを生み出すかもしれません： - 人事のオンボーディングリクエスト。 - ノートPCの配備とシステムアクセスのためのITチケット。 - 給与と経費のセットアップのための財務リクエスト。 共有ESMインボックスは、これら3つのリクエストすべてを保存できます。しかし、それらを人・開始日・ビジネス上のコンテキストで結びつけない限り、それらが同じオンボーディングの旅の一部であることを認識できません。 そのギャップは、何かがうまくいかないときに顕在化します。ノートPCの遅延、給与の問題、初日のアクセス欠落は、異なる部門にまたがる別々のチケットとして現れるかもしれません。各チームは自分のリクエストのステータスを見ることはできますが、従業員の体験の全体像や、タスク間の依存関係を把握している人は誰もいません。 ESMは、人事、法務、財務、ファシリティがワークフローを標準化し、定型業務を自動化し、リクエストをルーティングし、可視性を高めるのを助けることで、ITSMの実践をITの外へ拡張できます。こうしたケイパビリティは業務をより一貫したものにし、従業員が次に何が起こるかを理解する助けになります。しかし、共有されたキューだけでは、共有された理解は生まれません。 したがって、買い手の問いは、単にESMプラットフォームがリクエストを集中管理できるかどうかではありません。それは、プラットフォームがリクエスト間の関係を理解し、管理できるかどうかです。 > [!INFO] > **RFPテスト**：ESMベンダーに尋ねましょう。新入社員がオンボーディングされるとき、システムは人事リクエスト、IT配備チケット、財務セットアップを1つのフローとして自動的に結びつけますか？　**PASS＝はい、関係性によって。FAIL＝手動／レポーティングのみ。** ## システムオブレコードは覚える。関係性を認識するメモリレイヤーは理解する。 システムオブレコードは、リクエストがどこに保管されているかを覚えています。 関係性を認識するメモリレイヤーは、どのリクエスト・人・ポリシー・成果が互いに結びつくかを理解します。この違いはESMにおいて重要です。ESMでは、単一のビジネスイベントがしばしば複数の部門にまたがるからです。 従業員のオンボーディングを考えてみましょう： | リクエスト | システムオブレコードが覚えていること | 理解レイヤーが認識すること | | --- | --- | --- | | 人事リクエスト | リクエストがどこに提出されたか | 従業員の開始日と役割 | | IT配備 | どのチケットが開かれたか | 従業員が必要とするアクセス、デバイス、システム | | 財務セットアップ | どのワークフローが進行中か | 採用に結びついた給与と経費の要件 | | 開始日 | レコードに保存された日付 | すべての関連リクエストにコンテキストを与える期限 | 重要な問いはこうです：**システムは、人事リクエスト、IT配備チケット、財務セットアップ、開始日が1つのストーリーであることを知っていますか？** システムがそれを知っているとき、遅延したデバイスは単なるITチケットではありません。それは、従業員の初日、給与の準備状況、マネージャーの計画、そしてオンボーディング体験全体に対するリスクです。チームはその依存関係を見て、それを軸に連携し、正しい問題を解決できます。単に自分の個別リクエストをクローズするのではありません。 Computer, by DevRevは、チームがすでに使っているシステム全体にわたって、この関係性を認識するメモリレイヤーを追加します。Computer Memoryは権限を認識するナレッジグラフの上に構築されており、関連するコンテキストが、それらのチームが依存するシステムオブレコードを置き換えることなく、人事、IT、財務、その他の接続されたシステムをまたいでリクエストに付随して移動できます。 > [!INFO] > **Computer Memory、DevRevの特許取得済みの権限を認識するナレッジグラフは、**人 ↔ 人事リクエスト ↔ IT配備 ↔ 財務セットアップ ↔ 開始日を、つながったノードとしてマッピングします。そのため、ある部門で開かれたリクエストは、それが触れるすべての部門のコンテキストを携えて届きます。ここが、システムオブレコード → システムオブアンダースタンディングが着地する地点です。 ### これは単に言葉を足しただけのServiceNowではないのか？ そうとも言い切れません。ServiceNowや類似のプラットフォームは**システムオブレコード**です。つまり、リクエストを保存し、ルーティングし、レポーティングします。Computerはそうしたシステムと並んで動作し、あなたのチームがすでに使っているHRIS、CRM、ITSM、財務ツール全体にわたって、関係性を認識する[メモリレイヤー](https://devrev.ai/blog/what-is-enterprise-ai-memory)を追加します。 システムオブレコードは、あらゆる部門のリクエストを保存できます。メモリレイヤーは、人とエージェントが、どのリクエストが同じビジネスイベントに結びついているか、そしてそれらのつながりが何を意味するかを理解する助けになります。 より大きなファイルキャビネットも、やはりファイルキャビネットです。レコードをまとめて保存することは、それらをまとめて理解することと同じではありません。 | 観点 | システムオブレコード | 関係性を認識するメモリレイヤー | | --- | --- | --- | | 中核的な役割 | レコードを保存し、取り出す | システムをまたいでエンティティ、イベント、関係をつなぐ | | 何をするか | 情報がどこに保管されているかを覚える | 情報がどう関係し合うかの説明を助ける | | 部門横断的なリクエスト | 共有キューを、多くの場合は孤立したまま移動する | それが触れる部門とシステムをまたいでコンテキストを携える | | 新入社員のオンボーディング | 人事、IT、財務が別々のレコードを保持し、誰かが手動で調整する | 従業員の開始日を軸に人事 ↔ IT ↔ 財務をつなぐ | | ESMの成果 | より大きなファイルキャビネット | つながった組織のメモリ | **要するに**：ServiceNowはシステムオブレコードのままです。Computerは、チームとエージェントがそれらのレコードがどうつながっているかを理解する助けとなる、関係性を認識するメモリレイヤーを追加します。ESMには両方が必要です。 ## 1つの理解、多くのスキル 関係性を認識するメモリレイヤーは、すべてのチームに同じコンテキストを与えます。[Computer Agent Studio](https://devrev.ai/agent-studio)は、チームがそのコンテキストを、特定のサービスワークフロー向けにカスタムAIエージェントを構築・デプロイすることで活用する場です。 スキルは、各エージェントに部門固有のケイパビリティを与えます。人事エージェントはオンボーディングを支援でき、財務エージェントは承認を管理でき、法務エージェントはポリシー主導のリクエストをガイドできます。それぞれが個別の機能を担いながら、同じComputer Memory、すなわち組織全体で共有され、最新で、権限を認識するコンテキストから動作します。 これは、業務が部門をまたぐときに重要になります。 人事のオンボーディングがITの配備と財務の承認をトリガーするとき、各チームは同じ従業員・役割・ポリシー・開始日のコンテキストから動作します。その結果は、従業員・マネージャー・サービスデスクが手動で調整しなければならない3つの引き継ぎではなく、1つのつながったフローになります。 これは、あらゆる部門を1つの汎用エージェントで置き換えることではありません。1つの首尾一貫した従業員体験を提供するために必要な共有された理解を失うことなく、各チームが自分のサービスワークフローを運用する自律性を与えることです。 ## ファイルキャビネットから組織の頭脳へ その結果、ESMはより大きなファイルキャビネットであることをやめ、組織の頭脳になります。部門横断的なリクエストが解決されるのは、誰かが3つのツールを手動で追いかけたからではなく、システムがそれらがどうつながっているかを理解しているからです。業務はより滑らかになります。ITのステップと財務の承認に依存する人事リクエストは、システムがそれを1つのストーリーとして捉えるため、1つのつながったフローとして解決されます。 ESMはすべての部門に同じインボックスを与えました。しかし、同じ理解は与えませんでした。 システムオブレコードは覚える。ナレッジグラフは理解する。 > [!INFO] > **1つの共有された理解が、いかにしてあらゆる部門のエージェントを動かすかをご覧ください。** > > [デモを予約する](https://devrev.ai/request-a-demo)、または > > こちらをお読みください：[エンタープライズAIメモリプラットフォームで評価すべきこと](https://devrev.ai/blog/enterprise-ai-memory-platforms-what-to-evaluate)。 ## FAQ ### エンタープライズサービスマネジメントはどのように導入するのか？ ほとんどのチームは、すべての部門を一度に展開するのではなく、従業員のオンボーディングのような、量の多い部門横断的なワークフローを1つ選んで始めます。そのリクエストをエンドツーエンドでマッピングし、引き継ぎがどこで破綻するかを特定し、関係するシステムをつなぎ、最初のワークフローがきれいに連携するようになったら、隣接するワークフローへと拡大します。 ### どの部門がエンタープライズサービスマネジメントを使うのか？ ITを超えて、ESMは一般的に人事、財務、法務、ファシリティ、調達へと拡張されます。構造化されたリクエストを受け取り、繰り返し可能なワークフローに従い、業務を完了するために他部門に依存するチームはいずれも候補となります。ESMの価値が最も強く現れるのは、単一のリクエストがこれらのチームの複数に一度に触れる場合です。