第3章：ガバナンスと運用を考慮したCMDBデータモデル設計

3.1 ServiceNow CMDBの基本構造と標準クラスの重要性

ServiceNow CMDBは、ITサービスの構成要素(サーバー、アプリケーション、サービス、ドキュメントなど)を管理するためのデータベースです。CMDBは単なるリレーショナルデータベースではなく、オブジェクト指向アプローチを採用しており、構成アイテム (CI)は階層的なクラス構造で整理されます。

例えば、基本クラスである `cmdb_ci` (ベース構成アイテム)を基盤に、以下のような形で、より特化したクラスが階層的に整理されています。

• `cmdb_ci_hardware` (ハードウェア)
  • `cmdb_ci_server` (サーバー)
    • `cmdb_ci_linux_server` (Linuxサーバー)

各CIクラスには、そのタイプに固有の属性(例: `cmdb_ci_server` のCPU数やメモリ、`cmdb_ci_web_server` のWebサーバーソフトウェア情報など)を持たせることで、共通の要素を親クラスで管理し、特化した要素を子クラスで追加するという効率的なデータモデリングが可能になります。

3.1.1 標準クラスの利用とその重要性

ServiceNowは、一般的なITインフラ、アプリケーション、サービスコンポーネントに対応する豊富な標準CIクラスのセットを提供しています。これらの標準クラスは、以下のような主要なServiceNowプラットフォーム機能と密接に統合されています。

• ServiceNow Discovery (自動検出されたCIの分類)
• Service Mapping (ビジネスサービスとの関連付け)
• ITSMプロセス (特定のフォームやワークフローとの統合)
• CMDB Health (データ品質管理)
• IntegrationHub (外部システムとのデータ連携)

標準クラスを可能な限り活用することで、以下のメリットが得られます。

• CMDB実装の迅速化 (カスタムクラスの設計・調整が不要)
• バージョンアップ時の互換性維持 (標準機能との整合性確保)
• ITOM製品(Discovery, Service Mapping, Event Management等)とのスムーズな連携
• ServiceNowコミュニティの活用 (情報共有・サポートの容易化)

3.1.2 カスタムクラスの追加は慎重に

標準クラスで要件を満たせない場合に限り、カスタムクラスの作成を検討しますが、その判断は慎重に行うべきです。

• 不必要に多くのカスタムクラスを作成すると、標準機能との統合が難しくなるため、拡張は必要最小限に抑え、標準クラスの活用を優先することが推奨されます。
• カスタムクラスの作成は、将来のアップグレード時の互換性問題や、運用保守の複雑化を招く可能性があります。

3.2 主要CIクラスの活用と管理属性の定義

本セクションでは、CMDBスコープに基づき、管理が必要な主要CIクラスを特定し、それに適した標準CIクラスを選択する方法について説明します。

3.2.1 主要なCIクラスの選定

代表的なCIクラスには以下のようなものがあります (括弧内はServiceNowテーブル名例):

• 物理/仮想サーバー (`cmdb_ci_server`, `cmdb_ci_vm_instance`)
• ネットワークデバイス (`cmdb_ci_netgear`, `cmdb_ci_ip_router`, `cmdb_ci_ip_switch`)
• ストレージシステム (`cmdb_ci_storage_device`)
• データベース (`cmdb_ci_database`, `cmdb_ci_db_instance`)
• ミドルウェア (`cmdb_ci_middleware_instance`)
• アプリケーション (`cmdb_ci_appl`)
• クライアント端末 (`cmdb_ci_computer`)
• サービス関連クラス (CSDMで重要、例: `cmdb_ci_service_discovered`, `cmdb_ci_service_business`)

これらの標準クラスを活用することで、ServiceNowの主要機能との互換性を維持し、運用を最適化できます。

[図表プレースホルダー: Bellwood Services社がフェーズ1で選定した主要CIクラス一覧と説明、ServiceNow標準クラス名を示した表]

3.2.2 管理対象属性の選択と定義

各CIクラスでCMDBレコードにどの属性情報を管理するかを明確にすることが重要です。この定義は、以下の観点を考慮して行います。

3.2.2.1 技術的な識別・構成情報

CIを一意に識別し、その技術仕様や構成を示す情報。

例: 名前/ホスト名、IPアドレス、OS種類とバージョン、CPU/メモリ/ディスク容量、シリアル番号、ベンダー、モデル、ハードウェアバージョン、インストール済みソフトウェアリスト

データ収集方法: Discovery(第4章)や他の連携ツール (第5章)を活用し、自動収集が推奨される。

3.2.2.2 運用・管理情報

日々のIT運用やITSMプロセスでの管理に必要な情報。

例: 場所、会社/部門、管理グループ/管理者、サポートグループ/担当者、連絡先情報、運用ステータス、ライフサイクル段階

活用用途: ITSMチケットの自動割り当て、コミュニケーション、物理的な場所の確認。

3.2.2.3 ガバナンス・コンプライアンス・ITAM関連情報

監査コンプライアンス、リスク管理、資産管理に必要な属性。

例: データオーナー、ティア/重要度、機密レベル、SOX統制フラグ、個人データ取扱フラグ

データ入力:手動入力、ITAMツールや契約管理システムとの統合、調達プロセスを通じた投入。

3.2.2.4 外部システム連携用属性

他システムとの連携や、ServiceNow内でのデータ統合に使用される属性。

代表例: Correlation ID (データ識別と整合性確保のために活用)

3.2.3 属性設計の考慮事項

各属性の設計において、以下の要素を慎重に定義することが重要です。

• データ型(文字列、整数、参照、日付/時刻、ブール値など)
• 長さ制限(適切なデータ量の管理)
• 必須属性の設定( 定義しすぎると入力負荷が増加し、運用に悪影響を与える)
• デフォルト値の適用(入力負担の軽減)

必須属性は、CIの識別や運用上不可欠な情報のみに限定し、データ投入や更新の負荷を最小化することが重要です。

3.3 CI関係性設計の重要性

CMDBが単なる構成アイテム (CI)のリストにとどまらず、IT環境の「地図」として機能するためには、CI間の関係性を正確にモデリングすることが不可欠です。関係性を適切に定義することで、ITサービスの依存関係、システムの相互作用、コンポーネントの包含関係を明確化できます。

3.3.1 CI関係性の価値

関係性を適切に定義することで、以下のような実践的なメリットが得られます。

3.3.1.1 影響分析の強化

インシデントが発生し、影響を受けるCIにリンクされると、CMDBの関係性情報を活用して他の関連CIやサービスを迅速に特定できます。

• インシデント対応: 影響範囲を可視化し、優先順位を決定
• 変更管理: 依存関係を考慮し、潜在リスクを評価

3.3.1.2 サービスマッピング

ITインフラのコンポーネントと、それが支えるビジネスサービスとの関連性を視覚化できます。

• サービスの健全性監視: 依存関係の正確な定義がサービスマップの品質を決定

3.3.1.3 根本原因分析

インシデントが繰り返し発生する場合、関係性を活用して共通の問題要因を特定します。

• 問題管理: CIグループ間の関係性を分析し、構成上の問題を特定

3.3.1.4 IT環境の可視化と共通理解

CI関係性は、複雑なIT環境を視覚化するための共通言語として機能し、IT部門内外のコミュニケーションを促進します。

3.3.2 標準関係性タイプの活用

ServiceNowは、一般的なIT接続に対応する標準関係性タイプを提供しています。以下のような関係性タイプを活用することで、より効率的なデータ管理が可能になります。

• Runs on::Runs (ソフトウェアがハードウェア上で動作する)
• Contains::Contained by (物理的な包含関係)
• Connects to::Connected by (ネットワーク接続)
• Used by::Uses (アプリケーションがデータベースを使用する)
• Depends on::Used by (あるCIが別のCIに論理的に依存する)

これらの標準タイプは、Discovery、Service Mapping、影響分析機能に最適化されています。カスタム関係性を作成する前に、標準タイプで要件を満たせるか徹底評価することが推奨されます。

[図表プレースホルダー: 代表的な標準関係性タイプとその意味、利用シナリオ例を示した表]

3.3.3 関係性設計のポイント

CI関係性の設計では、以下の要点を押さえることが重要です。

• 価値駆動型(Value-Driven): 運用の目的に基づいて定義し、技術的に可能なすべての接続を網羅しようとしない。実際にビジネス・運用に価値を提供する関係性のみに集中し、運用負荷を適切に管理。
• 一貫性と明確性(Consistency & Clarity): 同じ種類の接続には、統一された関係性タイプを使用するルールを確立。各関係性タイプが何を表しているかを明確に定義し、関係性の乱立を防ぐ。
• 保守性(Maintainability): CI属性と同様に、関係性も最新かつ正確な状態を維持することが重要。DiscoveryやService Mappingで自動更新できる関係性を優先し、手動管理の負担を軽減。手動での保守が必要な関係性は、運用体制(第2章)の現実的な能力の範囲内であることを確認し、更新ルールを明確化。

3.4 CSDM(共通サービスデータモデル)の概念と適用

ServiceNow CMDBをITILに基づくITSMの実践基盤として活用するには、単にIT資産を管理するだけでなく、ITが提供する「サービス」とそれを実現する「技術コンポーネント」の関係性をモデル化することが不可欠です。
CSDM (Common Service Data Model)は、このサービスと技術の接続を標準化するための業界ベストプラクティスを提供するフレームワークです。これにより、ServiceNowプラットフォームの主要機能(ITSM, ITOM, SPMなど)が統合されたデータモデルを基盤に構築できるようになります。

3.4.1 CSDMの目的

CSDMは、ITがビジネスに提供する「サービス」を明確化し、それを支えるIT要素(アプリケーション・インフラ)との接続を標準化するための共通言語と構造を提供します。これにより、CMDBのデータがサービス単位で整理され、異なるServiceNowモジュール間の統合が促進されます。

CSDMの適用により、以下の能力が実現されます:

• ビジネス視点からITを理解する(どのITコンポーネントがどのビジネスサービスを支えているかを可視化)
• サービス単位で健全性・パフォーマンス・コスト・リスクを管理する
• IT投資の意思決定をビジネス価値に基づいて実施
• プロジェクトの成果物(新規サービス・機能)を運用へ円滑に移行

3.4.2 主要なCSDMレイヤー

CSDMは、ITサービスをいくつかの主要なレイヤーに構造化し、CMDBのCIクラスを標準的な関係性で接続するフレームワークを提供します。

• 設計レイヤー (Design Layer): サービスの定義・計画・ポートフォリオ管理(例: Service Portfolio, Service Offering, Catalog Item)。ITとビジネスが提供するサービスを整理するためのレイヤー。
• サービスレイヤー (Service Layer): 運用中のサービスのランタイム情報(例: Business Service, Application Service)。ビジネスユーザー視点 (Business Service) と提供者視点 (Application Service)からサービスの健全性・パフォーマンス・コストを管理。Service Mapping (第9章)はこのレイヤーから技術レイヤーへの接続を構築。
• アプリケーションレイヤー (Application Layer): アプリケーションとそのコンポーネントの情報(例:Application, Application Component, Application Service)。アプリケーションポートフォリオ・論理コンポーネント・ランタイムインスタンスの管理。
• 技術レイヤー (Technology Layer): サービスやアプリケーションが稼働するインフラの情報(例: Server, Database, Network Device, Storage)。Discovery(第4章)はこのレイヤーのCIを発見・維持。

[図表プレースホルダー: CSDMの4つの主要レイヤーと代表的なCIクラス、関係性を示した概念図]

3.4.3 CSDM適用のアプローチ

CSDMは包括的なフレームワークであり、一度に完全導入するのではなく、段階的に適用していくことが現実的です。

CSDMに準拠したデータモデルは、CMDBがITILやCOBITによるサービスマネジメントのベストプラクティスを支える強力な基盤となります。

3.5 カスタムクラスおよび属性追加に関する考慮事項とガバナンス

ServiceNowの標準CIクラスと属性は広範囲にわたりますが、組織固有のITコンポーネントや、標準定義ではカバーされていない重要な情報を管理するためにカスタムクラスや属性の追加が必要となる場合があります。しかし、カスタム化にはServiceNowのアップグレード、標準機能との互換性、運用負荷などのリスクが伴うため、慎重な検討と厳格なガバナンスが不可欠です。

3.5.1 カスタム化を検討する具体ケース

カスタムクラスや属性を追加する必要がある代表的なケース:

• 標準クラスでカバーされていない独自のITコンポーネントの管理 (例:自社開発システム、特定ベンダーの特殊機器、業界特有の設備)
• 標準属性では表現できない重要なビジネス・運用情報の管理 (例:組織独自の識別子、特殊なライセンスモデル、業界特有の規制要件)

3.5.2 カスタム化に伴うリスク

カスタム要素の追加には以下の潜在的なリスクが伴います。

• アップグレードへの影響: カスタム要素が多いほど、検証作業・修正工数・アップグレードの複雑性が増大します。
• 標準機能との非互換性: カスタム要素を標準機能と連携させるには、追加開発が必要となる場合があります。
• 運用負荷の増大: 専用プロセスの開発・運用、手動更新の負担増、トレーニングの必要性。
• レポート・分析の複雑化: カスタムレポートの開発が必要になることが多いです。

3.5.3 カスタム化のガバナンスプロセス

カスタム要素の追加はCMDBガバナンス委員会(2.3.1参照)による厳格な承認プロセスを経る必要があります。委員会では以下の評価ポイントを徹底確認します:

• 必要性の証明: 標準機能や既存クラス・属性の活用、外部システムとの連携では本当に要件を満たせないか?
• コスト・ベネフィット分析: カスタム化によって得られるビジネス価値は、総コストを上回るか?
• 運用実現可能性: カスタム要素のデータ投入、更新、品質管理の具体的な運用プロセスを確立できるか?
• 影響評価: アップグレード、標準機能統合、CSDM準拠、既存データモデルへの影響は評価済みか?
• 代替案の検討: 既存クラスへのカスタム属性追加や参照フィールドで対応できないか?

カスタム化に関するまとめ

• 標準機能の活用を最優先し、不必要なカスタム化を避ける。
• カスタム化を行う場合は、CMDBガバナンス委員会による厳格な評価と承認プロセスを適用し、影響を十分に評価した上で慎重に進める。
• カスタム化の決定は文書化し、その理由、範囲、影響、管理責任者を明確にする。

3.6 ガバナンスおよび運用指向の属性設計- ステータスと連携キーへの注力

CMDBを適切に運用し、ITSM連携(第8章で詳述)や監査コンプライアンス(第10章で詳述)を円滑に進めるには、ガバナンス、運用、システム統合に関連する属性をデータモデルに組み込むことが不可欠です。これらの属性は、CIの技術的な構成だけでなく、組織内での管理・活用の実態を示します。

3.6.1 ステータス関連属性

CIや資産の管理には、異なる側面を示す複数のステータス属性が存在します。ITSM、ITAM、ガバナンスプロセスと統合するためには、これらのステータスをデータモデルに明確に定義し、それぞれの役割を整理することが重要です。

主に以下の4つのステータスがあります (ServiceNowの標準フィールド名を例示):

• Operational Status (`operational_status`) - 技術的な稼働状態: CIの技術的な運用状況(例:稼働中、停止中、保守中)を示し、IT運用やサービス監視に不可欠。
• Install Status (`install_status`) - 構成管理状態: CIの構成管理上のステータス (例:インストール済み、削除待ち、在庫、廃棄済み)を示し、CMDB管理の基本属性。
• Asset Status / Hardware Status (資産レコードの `install_status` `substatus` など) - 物理的・物流管理状態: 物理資産の物流的な状態(例:在庫、使用中、修理中、リース中、廃棄済み)を示し、ITAM (IT資産管理)で使用。
• Life Cycle Stage (`life_cycle_stage` など、CSDMの概念に基づくフィールド) - サービスライフサイクル管理: CIが属するサービスライフサイクルの段階(例:計画、構築、運用、最適化、廃棄)を示し、CSDMベースのポートフォリオ管理や戦略的意思決定に活用。

これらのステータスは相互に関連し、一貫した更新が求められます。データモデルと運用プロセス設計においては、どのステータスがマスターとして管理されるかを定義し、ステータス間の整合性を確保するルールを策定することが重要です。

3.6.2 責任・割り当て属性

CIの管理やサポートにおける責任者を明確にする属性です。

• Data Owner / Responsible Party (`owned_by` やカスタムフィールドなど)
• Managed by Group / Person (`managed_by_group`, `managed_by`)
• Support Group / Supported by (`support_group`, `supported_by`)

3.6.3 ガバナンス・コンプライアンス・リスク管理属性

ITガバナンスやリスク管理の枠組みに適合させるため、以下の属性を設計します。

• Tier / Criticality (`business_criticality` やカスタムフィールドなど)
• SOX Control Flag / Personal Data Handling Flag (カスタムブール型フィールドなど)
• Confidentiality Level (カスタム選択リストフィールドなど)

3.6.4 外部システム連携 - Correlation ID の設計

Correlation IDは、CIが異なるデータソースから更新される際に、そのCIをシステム間で一意に識別するための重要な属性です。

適切なCorrelation IDの設計とIREの活用によって、データの重複や誤った更新を防ぎ、CMDBのデータ品質を大幅に向上させることができます。

3.7 運用負荷とデータ鮮度を考慮したデータモデル設計

どれほど優れたデータモデルを設計しても、それを継続的に最新かつ正確な状態に維持できなければ、CMDBの信頼性は低下し、最終的には利用されなくなります。そのため、データモデルの設計では、運用負荷と情報の鮮度維持を常に考慮することが不可欠です。

3.7.1 自動化の最大化

Discovery(第4章)や他の自動化された統合(第5章)を活用し、属性や関係性の収集・更新を可能な限り自動化する。自動化により、大規模なデータ管理において鮮度と精度を維持する。自動化は、CMDBのデータを最新の状態に保ち、運用負荷を最小限に抑える最も効果的な手段です。

3.7.2 手動入力の最小化

• 手動入力が必要な属性は、ビジネス・運用・ガバナンス上不可欠な情報に限定する。
• 手動更新の手順や責任者を明確化し、更新頻度を適切に管理する。
• 運用スタッフやCIオーナーに対する徹底的なトレーニングを実施し、運用の失敗を防ぐ。

手動更新の負担が高いデータモデルは、運用ミスやデータの陳腐化を招くリスクが大きくなるため、慎重な設計が必要です。

3.7.3 必要十分な詳細度の確保

• 必要以上に細かい属性を設定すると、運用負荷が増し、データが陳腐化するリスクが高まる。
• 「知っていると便利な情報」と「CMDBで管理する必要がある情報」を区別する。
• 維持する情報の価値と、それにかかるコスト(自動化・手動更新)を評価する。

データモデルの設計では、管理対象の情報が本当に運用上必要かどうかを常に見極めることが重要です。

3.7.4 定期的なレビューと改訂

• IT環境・ビジネス要件・運用プロセスの進化に合わせてデータモデルを更新する。
• CMDBガバナンス構造 (2.3.1参照)内に、CIクラス・属性・関係性の定期的なレビューを実施する仕組みを組み込む。
• 運用チームやCIオーナーのフィードバックを積極的に取り入れ、データモデルが実際の運用ニーズと整合するよう調整する。

データモデルは静的なものではなく、定期的な見直しを行うことで、運用の現状に適した形に維持することが可能になります。

3.8 CMDB Foundation Dashboard-構造的健全性とCSDM採用度の測定

CMDBデータモデルを設計する際は、モデルがCSDM (共通サービスデータモデル)に適合しているかを測定し、その進捗を追跡することが不可欠です。特に、必要なCIクラスと関係性が適切に定義され、データが投入されているか (構造的な完全性)を評価することが重要です。
ServiceNowが提供するCMDB Foundation Dashboardは、この目的のために設計されており、CMDBの構造的な健全性とCSDM採用の進捗状況を測定・可視化します。

3.8.1 CMDB Foundation Dashboardの目的

CMDB Foundation Dashboardの主な目的は、以下の4点です:

• CSDMに適合したデータモデルの実装状況を測定する
• CMDBの構造的な完全性(例:サービスが技術インフラまで正しくリンクされているか)を可視化する
• CSDM採用活動の進捗を追跡し、次のステップを特定する
• CMDBガバナンス委員会 (2.3.1参照) やCMDBプロジェクトチームが進捗を管理できる共通のメトリクスセットを提供する

3.8.2 CMDB Foundation Dashboardで測定される主なメトリクス

CMDB Foundation Dashboardは、CSDMの主要なレイヤー(設計、サービス、アプリケーション、技術)にわたるデータ投入状況と関係性を測定します。具体的なメトリクスはServiceNowのバージョンによって異なりますが、一般的には以下の要素が含まれます:

• Foundation Data: CIの総数、主要なCIクラス (例: サーバー、アプリケーション)の数
• CSDMレイヤーの完全性: Business Serviceの登録数, Application Serviceの登録数, Application Serviceが技術レイヤー(サーバーなど)に正しくリンクされている割合, Business ServiceがApplication Serviceにリンクされている割合, Application ServiceのランタイムCIが技術レイヤーのCIにリンクされている割合
• ServiceNow製品との連携: Event ManagementやService Mappingなどが利用しているCIの数

[図表プレースホルダー: CMDB Foundation Dashboardのサンプルスクリーンショット]

3.8.3 CMDB Health Dashboardとの違い

CMDB Foundation DashboardとCMDB Health Dashboard (第7章で詳述)は異なる側面を測定します。

• CMDB Health Dashboard → 個々のCIレコードと関係性のデータ品質(属性の正確性・完全性・鮮度など)を評価
• CMDB Foundation Dashboard → 構造的な健全性やCSDMのデータモデル準拠度を測定

CMDBの健全な運用には、正しいデータモデル (Foundation)に基づいて高品質なデータ(Health)が維持されることが重要です。両方のダッシュボードを補完的に活用することで、CMDBの最適な運用とデータ品質の向上を実現できます。

3.8.4 CMDB Foundation Dashboardの利用方法

• 主な利用者 → CMDBオーナー、構成マネージャー、CMDBガバナンス委員会、ServiceNow実装プロジェクトチーム
• 用途 → CSDM採用ロードマップの進捗管理・データ投入作業の優先順位付け・Service Mappingの推進

このダッシュボードを活用することで、CMDBの構造的な完全性を維持し、CSDM準拠を効果的に進めることが可能です。

3.9 本章のまとめ

CMDBデータモデルの設計は、ServiceNow CMDBを構築するうえで最も重要な技術的活動の一つであり、その品質がCMDBの価値、ひいてはITサービスマネジメント全体の成熟度に大きな影響を与えます。

本章では、ServiceNow CMDBの基本的な階層構造から始まり、CSDM(共通サービスデータモデル)というサービス中心の考え方、そして日々の運用とガバナンスを支えるための具体的な属性設計に至るまで、多角的にデータモデル設計の要諦を見てきました。

本章で学んだCMDBデータモデル設計の核心:

• 標準クラスとCSDMの活用: ServiceNowが提供する標準CIクラスとCSDMフレームワークを最大限に活用することが、効率的で持続可能なCMDB構築の鍵です。
• ガバナンスと運用の組み込み: データモデルは、技術的な側面だけでなく、第1章で定義したガバナンス要件や第2章で設計した運用体制と密接に連携している必要があります。
• 属性と関係性の戦略的設計: 管理するCIクラス、属性、関係性は、ビジネス価値と運用負荷のバランスを考慮して慎重に選定します。特に、ステータス関連属性やCorrelation IDは実用性を大きく左右します。
• カスタム化の慎重な判断: 標準で対応できない真に重要な要件がある場合に限り、厳格なガバナンスプロセスの下でカスタム化を検討します。
• 運用負荷とデータ鮮度の重視: データモデルは、構築後の運用負荷とデータの鮮度維持の観点から常に評価されるべきです。
• 継続的な評価と改善: CMDB Foundation Dashboardのようなツールを活用し、データモデルの構造的な健全性やCSDM準拠度を定期的に測定・評価し、ビジネスや技術の変化に合わせてデータモデルを継続的に改善していく姿勢が不可欠です。

"CMDBデータモデルは、一度作ったら終わりではありません。組織の成長と共に進化し続ける「生きた設計図」として捉え、育んでいくことが、CMDBプロジェクトを成功に導き、その価値を最大限に引き出すための道筋となるのです。"