エグゼクティブサマリー
組織が成長し、IT運用が成熟するにつれて、ITサービスマネジメント（ITSM）プラットフォームの基盤アーキテクチャは、長期的な俊敏性、効果的な統合、高水準のサービスを実現するうえで大きな差を生みます。
HaloITSMのような一部のITSMソリューションでは、すべてのサービスレコードを1つの統合テーブルに格納する、簡素化された単一テーブルモデルを使用しています。一方、Ivanti Neurons for ITSMは、より高度なオブジェクト指向アーキテクチャを採用し、個別のITILプロセス（インシデント、問題、変更、リクエスト）を、独立したモジュール型エンティティに分割します。
本ホワイトペーパーでは、特に複雑なエンタープライズ環境における単一テーブルアプローチの欠点を検証し、より構造化されたスケーラブルなITSMアーキテクチャを採用するメリットを明らかにします。
| 機能／能力 | 単一テーブル | モジュール |
|---|---|---|
| ワークフローの柔軟性 | 限定的 | 高い |
| ITILとの整合 | 基本的 | 包括的 |
| カスタマイズの分離性 | 低い | 高い |
| レポートの粒度 | 中程度 | 高度 |
| 統合の複雑性 | 高い | 低い |
| スケーラビリティ | 中程度 | 高い |
| パフォーマンス | 中程度 | 高い |
| セキュリティ | 複雑 | 簡素 |
1. はじめに
ITSMを取り巻く環境は急速に進化しており、自動化、統合、ユーザー中心のサービス提供に対する要求が高まっています。シンプルであることは小規模チームやスタートアップにとって利点になり得ますが、組織が成長するにつれて負担となる場合が少なくありません。本書では、HaloITSMの単一テーブルモデルとIvanti Neuronsのモジュール型設計の間にあるアーキテクチャ上のトレードオフを検証します。
2. 単一テーブル型ITSMモデルの理解
単一テーブルを使用するプラットフォームでは、インシデント、サービスリクエスト、問題、変更のいずれであっても、すべてのサービスレコードが1つの「Tickets」テーブルに格納されます。
以下は、6つのフィールドを持つ単一テーブル型ITSMアーキテクチャの例です。
| レコード番号 | レコードタイプ | 所有者名 | 件名 | 機密 | 優先度 |
|---|---|---|---|---|---|
| 1 | インシデント | Don | VPNエラー | 2 | |
| 2 | 変更 | Jamie | SQL Serverにパッチ適用 | 低 | |
| 3 | HRケース | Harold | 給与が正しくない | はい | 緊急 |
| 4 | インシデント | Don | SAP障害 | 1 | |
| 5 | リクエスト | Patricia | 新しいコンピューター | 低 |
最初に注目すべき点は、「レコードタイプ」というフィールドです。これは、レコードにどのデータが格納されているかを決定し、そのフィールドタイプへのアクセスを制限するための主要フィールドとなります。
セキュリティ
まず、このテーブルのセキュリティフレームワークを確認します。以下の定義は、Haroldのアクセス権限を示しています。
Haroldには、テーブル = “tickets” かつレコードタイプ = “HRケース” へのフルアクセスが許可されます。
このセキュリティルールにより、Haroldはticketsテーブルにアクセスし、HRケースのみを参照できます。
次に、IT部門で働くDonに対するこのルールを見てみましょう。
Donには、テーブル = “tickets” へのフルアクセスが許可されます。
ここで課題が生じます。IT担当者であるDonはテーブル全体に無制限にアクセスできるため、機密性の高いHRケースデータが意図せずDonに開示される可能性があります。
ルールは次のようにすべきです。
Donには、テーブル = “tickets” かつレコードタイプ NOT = “HRケース” へのフルアクセスが許可されます。
Donに「インシデント」へのフルアクセスを付与し、「変更」には読み取り専用アクセスだけを付与する場合、この複雑さはさらに増します。
設定
統合テーブル環境での設定も、同じテーブル内のフィールドがレコードタイプに応じて多様な要件を持つ可能性があるため、複雑になり得ます。
このテーブルを見ると、各レコードタイプに対してさまざまな優先度タイプが存在することが分かります。インシデントはITIL標準に準拠し、数値体系（1、2、3、4）を使用します。一方、変更とリクエストは低、中、高の優先度に分類されます。ただし、HRリクエストは低、高、緊急に分類されます。
この複雑さをどのように実装し、維持すればよいのでしょうか。自由入力フィールドはデータの整合性と標準化を低下させるため、レコードタイプフィルターを備えたルックアップテーブルの方が望ましいと言えます。しかし、それでもデータ型が混在するという課題が残り、レポート作成やフィールド／テーブルの保守が複雑になります。
共有された単一テーブルでの設定は、すべての設定変更においてすべてのレコードタイプを考慮する必要があるため、より複雑になります。たとえば、「機密」フィールドはHRケースでは必須ですが、他のレコードタイプでは必須ではありません。「HRケース」が独自のテーブルであれば、テーブルレベルでそのフィールドを必須にするだけで済みます。単一テーブルでこの変更を行うと、そのフィールドはインシデント、変更、リクエストにも必須となりますが、これらには必要ありません。解決策は、フィールドビジネスルール内で必須フィールドとしてプログラム的に強制することですが、そのためには定義作業と追加の管理が必要になります。
次に、法務チームが法務リクエスト用のカスタムアプリケーションを構築したいとします。単一テーブルアーキテクチャでは、レコードタイプを「法務」にする必要があり、一部のフィールド（例：「件名」、「説明」、「機密」）は再利用できます。しかし、法務では「外部」（はい／いいえ）、「法的手続き」（はい／いいえ）など、追加の必須フィールドも必要です。これらのフィールドは、ticketsテーブル、フォーム、ワークフローに追加する必要があります。追加フィールドは、既存のレコードタイプ、セキュリティ定義、ビジネスルールに影響を与えないよう、慎重に計画する必要があります。
パフォーマンスとスケーラビリティ
単一テーブルアーキテクチャは、レコード数やOOTBフィールドが少ない初期段階では効率的に運用できますが、データベースの健全性維持とインデックス管理を徹底しない限り、レコード量の増加に伴ってパフォーマンスが低下する可能性があります。さらに、カスタムフィールドの追加によって、潜在的なパフォーマンス低下が一層悪化する場合があります。
一般に、データベーステーブルのベストプラクティスは次のとおりです。
- 不要なテーブルフィールドを避ける。
- 可能な場合はデータを正規化し、冗長なフィールドを削減する。
- 必要なフィールドのみをクエリし、返す。
- パフォーマンスを最適化するために、テーブル内のフィールドに適切なインデックスを設定する。
単一テーブルアプローチのITSMシステムは、パフォーマンスとスケーラビリティをどのように確保するのでしょうか。
単一テーブルのデータモデルは、ITサービスマネジメントの一部の側面を簡素化しますが、理解しておくべき制限もあります。
3. モジュール型ITSMアーキテクチャが有効な理由
モジュール型ITSMアーキテクチャとは、各ITSMプロセスを個別のビジネスオブジェクトとしてモデル化し、他のビジネスオブジェクト（プロセス）と関連付けるものです。たとえば、インシデントと問題、または問題と変更を関連付けます。このモジュール型アプローチはITSMプロセスに密接に沿っており、データの分離を確保することで、複数のメリットをもたらします。
プロセス固有のワークフロー
モジュール型テーブル設計のワークフローでは、SLA、承認、ビジネスルールをテーブル（プロセス）ごとに固有にできます。異なるタイプ（ITSMプロセス）のレコードに対してワークフローが実行されるのを防ぐための特別なフィルタリングは不要です。たとえば、SLA違反時に、インシデントに対してエスカレーション条件を実行する場合などです。
このアプローチでは、ITILのベストプラクティスおよびガバナンスとの整合がより円滑になり、ITIL以外のプロセス（HRケースや施設作業指示など）に対する実行を効果的に防止できます。
セキュリティの向上
プロセスごとにテーブルを分離することでセキュリティが強化され、機密データへの意図しないアクセスのリスクを軽減できます。ここでは、明示的に承認されたユーザーにのみアクセスが付与され、特定のデータやレコードを対象とする追加のセキュリティ対策も容易に適用できます。
さらに、テーブルを分離したセキュリティにより、レポート作成やエクスポートは、より複雑な行レベルセキュリティではなく、標準的なテーブルセキュリティルールに従うことが保証されます。
カスタマイズの強化
プロセス固有のテーブルは、より高い設定柔軟性を提供し、あるプロセスでの変更が他のプロセス（または広く使用されるフィールド）に影響しないようにします。テーブルレベルで固有のフィールド設定を行うことで、複雑なビジネスルールが不要になり、変更に対するCAB承認や問題の根本原因分析など、より複雑なシナリオにも対応しやすくなります。
高度なレポート作成と分析
構造化データを保持するプロセスに沿ったテーブルにより、ITIL領域全体での詳細なレポート作成、傾向分析、KPI追跡がより実現しやすくなり、関連データの取り込みも簡素化されます。たとえば、変更によって解決されたすべてのインシデントを示すレポートなどです。
これにより、プロセスまたは企業内のビジネスオブジェクト（例：HRケース、施設作業指示）にまたがるコンプライアンスレポートや経営層向けダッシュボードも容易になります。
統合と拡張性の向上
外部システムとの合理化された統合には、プロセスに沿った個別テーブルが含まれます。この方法はAPI公開を簡素化するだけでなく、セキュリティも強化します（APIにはテーブルのAPIへの明示的なアクセス権が必要なためです）。
これにより、イノベーションを加速するローコード／ノーコードの拡張性と、既存のビジネスオブジェクトを拡張したり新規作成したりする柔軟性が実現します。
4. 確認すべき質問
単一テーブルのデータ構造は、将来の成長を制約する可能性があります。ITSMシステムを評価する際は、その基盤となるデータアーキテクチャを十分に理解することが重要です。
ITSMベンダーには、次の質問をしてください。
- ITSMプロセスごとに別々のテーブルがありますか、それとも同じテーブル内にありますか。
- これを保守し、セキュリティを確保することはどの程度難しいですか。
- 法務リクエストのような新しい機能を追加すると、どのような影響がありますか。
- ツール内でカスタム機能を再現することはどの程度難しいですか。
- カスタムオブジェクトの作成にはどのくらいの時間がかかりますか。
- 不正アクセスからデータを保護することはどの程度難しいですか。
- 新しいフィールドや新しいオブジェクトを追加する方法を見せてもらえますか。
- 何人の担当者が必要ですか。
- 費用はいくらかかりますか。
- アップグレードは可能ですか。
5. 自社に適したITSMアーキテクチャとは
HaloITSMのような単一テーブル型ITSMソリューションは、簡素化されたユーザー体験で迅速に利用を開始したい組織にとって、優れた出発点となります。しかし、成熟したエンタープライズレベルのIT運用では、こうしたソリューションが成長と拡張の課題を生み出す可能性があります。
組織がITILとの整合、複雑なワークフローの自動化、デジタルエコシステム全体での統合を目指す中で、Ivanti Neurons for ITSMのようなモジュール型アーキテクチャは、長期的な成功に必要な柔軟性、スケーラビリティ、制御性を提供します。