第7章：CMDB Healthとデータ品質管理

7.1 なぜ継続的なデータ品質管理が必要なのか

IRE（第6章）はデータ入力時の品質維持に貢献しますが、それだけでは不十分です。

📌 CMDBデータは、環境変化（CIの追加・変更・廃止）、自動化プロセスのエラーや設定ミス、外部システム連携時の不整合、手作業による誤入力や更新漏れ、定義されたプロセスの不遵守など、様々な要因により、常に劣化のリスクに晒されています。

⚠️ データ品質が劣化すると、CMDBの信頼性が著しく損なわれます。その結果、以下のような問題が発生し、ビジネスに悪影響を与える可能性があります。

• ITSMプロセスの非効率化: インシデント解決の遅延、変更失敗リスクの増大、問題の根本原因特定困難など。
• 誤った意思決定: 不正確なデータに基づくIT投資判断、リソース割り当てのミスなど。
• 監査対応の困難化: 統制対象資産の正確な把握ができず、監査指摘を受けるリスク。
• ユーザーの不信感増大: CMDBが信頼できない情報源と見なされ、活用されなくなる。

したがって、CMDBを構築・運用する上で、継続的なデータ品質管理は極めて重要な活動となります。

7.2 CMDBデータ品質の定義：KPIとサブメトリクス

CMDBのデータ品質を客観的に評価し、改善活動を推進するためには、まず「何をもって品質が良いとするか」という基準を定義する必要があります。ServiceNowのCMDB Health機能は、データ品質をいくつかの主要な側面（KPI：Key Performance Indicator）で評価し、それぞれのKPIを具体的なチェック項目である「サブメトリクス」に基づいてスコアリングします。

📌 CMDB Healthは、データ品質を以下の主要な側面（KPI）で評価します。 各KPIは、具体的なチェック項目である「サブメトリクス」に基づいてスコアリングされます。

完全性 (Completeness)

CIレコードに必要な属性情報が漏れなく入力されているかを評価します。
代表的なサブメトリクス:

• 必須属性の欠落 (Required): CIクラスごとに定義された必須属性に値が入力されていないCIの割合。
• 推奨属性の欠落 (Recommended): CIクラスごとに定義された推奨属性に値が入力されていないCIの割合。

正確性 (Correctness)

CMDB内のデータが定義されたルールに準拠し、不整合や矛盾がないかを評価します。
代表的なサブメトリクス:

• 陳腐化したCI (Stale): 一定期間更新されていないCIの割合（例：サーバーCIが90日間更新なし）。
• 孤立したCI (Orphan): 他のCIとの間に期待される関係性を持たないCIの割合（例：アプリケーションサーバーがどのアプリケーションサービスにも属していない）。
• 重複CI (Duplicate): 同一のIT資産が複数のCIレコードとして登録されている割合。📌 重複排除はCMDBの信頼性において特に重要です。
• 無効な関係性 (Invalid Relationships): 定義された関係性ルールに違反する関係性（例：廃止されたCIへの参照）。

コンプライアンス (Compliance)

CMDBデータが組織のポリシー、標準（例：命名規則、資産タグのフォーマット）、および監査要件に準拠しているかを評価します。ServiceNowの監査機能（Audit）と連携し、特定のフィールド値が期待されるパターンに合致しているかなどをチェックします。
代表的なサブメトリクス:

• 監査ルール違反 (Audit): 定義された監査ルール（例：サーバー名が命名規則に準拠しているか）に違反するCIの割合。

関係性 (Relationships)

CI間の関係性が構造的に健全であり、期待される依存関係が正しく表現されているかを評価します。
代表的なサブメトリクス:

• 必須関係性の欠落 (Missing Required Relationships): CIクラスごとに定義された必須の関係性が存在しないCIの割合（例：アプリケーションCIがどのサーバーにも関連付けられていない）。
• 重複した関係性 (Duplicate Relationships): 同じCI間に同じタイプの関係性が複数存在する。
• 循環した関係性 (Circular Relationships): 関係性が循環参照を形成しており、論理的に矛盾している。

[図表プレースホルダー: CMDB Healthの主要KPI（完全性、正確性、コンプライアンス、関係性）と、それぞれの代表的なサブメトリクスをまとめた表]

7.3 ServiceNow CMDB Healthダッシュボードの活用

📌 CMDB Healthダッシュボードは、データ品質状況を可視化し、改善活動を支援する中心的なツールです。

CMDB管理者や運用スタッフは、このダッシュボードを定期的に確認することで、CMDB全体の健全性を把握し、問題のある領域を特定し、修正活動の優先順位付けを行うことができます。

💡 主な機能と活用法:

• 品質スコアの可視化:
  • CMDB全体、およびCIクラスごとの健全性スコアが、KPI（完全性、正確性、コンプライアンス、関係性）別にパーセンテージで表示されます。
  • スコアは通常、健全（緑）、要注意（黄）、不健全（赤）といった色分けで表示され、問題のある領域を一目で把握できます。
• 問題リストへのドリルダウン:
  • ダッシュボード上のスコアやグラフをクリックすることで、そのKPIやサブメトリクスで問題があると判定されたCIや関係性のリストにドリルダウンできます。
  • 👍 これにより、具体的な修正対象を迅速に特定し、修正作業を開始することができます。
• 履歴トレンドの確認:
  • 各KPIのスコアの推移がグラフで表示され、過去からのデータ品質の改善状況や悪化傾向を把握できます。
  • 👍 これにより、実施した改善活動の効果を測定したり、新たな品質問題の兆候を早期に発見したりするのに役立ちます。
• 日々の監視と計画:
  • CMDB管理者や運用スタッフは、このダッシュボードを日常的に確認し、CMDB全体の品質状況を把握します。
  • 特定された問題点やスコアの低いKPIに基づき、修正作業の優先順位付けや、データ品質改善のための具体的なアクションプランを策定します。

[図表プレースホルダー: ServiceNow CMDB Healthダッシュボードの主要なウィジェット（KPIスコア、CIクラス別スコア、トレンドグラフなど）を示したサンプルスクリーンショット]

7.4 CMDB Healthの設定とカスタマイズ

📌 CMDB Healthの効果的な活用には、組織の基準に合わせた適切な設定とカスタマイズが必要です。

ServiceNowのCMDB Healthは、多くの標準的な品質チェックルールを提供していますが、それらをそのまま利用するだけでなく、自社のCMDBデータモデル、運用プロセス、ガバナンス要件に合わせて調整することで、より実効性の高いデータ品質管理が可能になります。

💡 主な設定項目:

• 健全性計算スケジュールジョブ (Health Calculation Scheduled Jobs):
  • CMDB Healthのスコアは、バックグラウンドで実行されるスケジュールジョブによって定期的に計算・更新されます。
  • 通常、CMDB Health Metrics Calculation といった名前のジョブが日次で実行されるように設定されています。（「System Scheduler」>「Scheduled Jobs」で確認・設定可能）
  • 📌 このジョブが正しく設定され、定期的に実行されていることが、ダッシュボードに最新の品質状況を反映させるための大前提です。
• 全体設定 (CMDB Health General Settings):
  • KPIの重み付け（どのKPIをより重視するか）、スコア履歴の保持期間、特定のCIクラスを健全性計算から除外する設定などを構成できます。
  • （「CMDB Health」>「Administration」>「Properties」や、バージョンによっては「CMDB Health Preferences」などで設定）
• データ品質ルール設定 (Health Metrics and Submetrics):
  • 各KPIを構成するサブメトリクス（具体的なチェックルール）は、主に CI Class Manager を通じてCIクラスごとに設定・調整します。
  • 完全性 (Completeness): どの属性を必須 (Required) または推奨 (Recommended) とするかを設定。
  • 正確性 (Correctness):
    • 陳腐化 (Staleness): CIが更新されない場合に陳腐と見なす期間（日数）を設定。
    • 孤立 (Orphan): 期待される関係性がない場合に孤立と見なすルールを設定。
    • 重複 (Duplicate): 重複を検出するための基準（通常はIREの識別ルールと連動）を設定。
  • コンプライアンス (Compliance): ServiceNowの監査機能（Audit）と連携し、特定の属性値が定義されたパターン（例：命名規則）に準拠しているか、あるいは特定のスクリプトによる検証結果に基づいて準拠状況を判定するルールを設定。
  • 関係性 (Relationships): 必須の関係性が存在するか、循環参照がないかなどをチェックするルールを設定。
  • これらのルールごとに、測定対象とするCI、具体的なチェック内容、健全と見なすための閾値などを定義します。

💡 詳細な手順: 具体的な設定画面や手順はServiceNowのバージョンによって異なります。必ず、ご利用のバージョンのServiceNow公式ドキュメント（Product Documentation）で「CMDB Health」や「CI Class Manager Health」といったキーワードで検索し、最新の情報を参照してください。

7.5 データ品質問題の特定と修正プロセス

📌 データ品質問題の特定から修正、そして根本原因の解決までを体系的なプロセスとして実行することが、CMDBの健全性を継続的に維持・向上させるためには不可欠です。

CMDB Healthダッシュボードは問題点を「特定」するための強力なツールですが、それだけでは品質は改善しません。特定された問題に優先順位を付け、効率的に修正し、さらに再発を防ぐための取り組みが必要です。

💡 修正プロセスのステップ:

1. 特定と分析 (Identification & Analysis):
   • CMDB Healthダッシュボードや関連レポートを利用して、データ品質が低いKPI、サブメトリクス、および影響を受けている具体的なCIや関係性を特定します。
   • 特定された問題について、その根本原因を分析します。例：Discoveryの設定ミス、外部システム連携のエラー、手動入力の誤り、IREの識別・調整ルールの不備、プロセスの欠陥など。
2. 優先順位付け (Prioritization):
   • 特定された全ての品質問題を一度に解決するのは現実的ではありません。
   • 問題の深刻度（ビジネスへの影響度）、影響範囲（関連するCIやサービスの数）、修正の容易性、修正にかかる時間などを考慮し、対応の優先順位を決定します。
   • 📌 特にクリティカルなビジネスサービスに影響を与える可能性のある品質問題や、広範囲に影響する重複CIなどは、最優先で対応すべきです。
3. 修正実行 (Remediation):
   • 優先順位に基づき、具体的な修正作業を実施します。
   • 修正内容は問題の種類によって異なります。例：属性値の修正、重複CIのマージ、孤立CIへの関係性追加、陳腐化CIのステータス更新または廃止処理、不正な関係性の削除など。
   • 📌 修正作業を行う際には、必ず関連するマスターデータソース（情報の原本を持つシステム）を確認し、必要であればマスターソース側も修正することが重要です。CMDBだけを修正しても、根本が解決していなければ再度同じ問題が発生する可能性があります。
4. 根本原因解決 (Root Cause Resolution):
   • 📌 個々のデータエラーを修正する（対症療法）と並行して、そのエラーが発生した根本原因を解決する（根本療法）ことが、持続的なデータ品質維持の鍵です。
   • 根本原因が特定できたら、再発防止策を講じます。例：Discoveryパターンの修正、連携設定の見直し、IREルールの調整、手動入力プロセスの改善、運用担当者への再教育など。
   • ⚠️ 根本原因を放置したまま対症療法だけを繰り返していると、運用負荷が増大し、データ品質もなかなか向上しません。
5. 修正タスク管理と追跡 (Remediation Task Management):
   • ServiceNow CMDB Healthは、特定された品質問題に対して、修正作業を管理するための「修正タスク (Remediation Task)」を自動的に生成し、担当者や担当グループに割り当てる機能を提供しています。
   • 💡 この機能を活用することで、修正作業の進捗状況を追跡し、対応漏れを防ぎ、プロセス全体を効率的に管理することができます。
   • 👍 特にCMDB Workplaceなどの機能を利用すると、よりユーザーフレンドリーなインターフェースでこれらのタスクを管理できます。

[図表プレースホルダー: データ品質問題の特定から根本原因解決までの修正プロセスフロー図。各ステップの主要な活動を示す。]

7.6 データ品質管理における役割と責任

📌 データ品質管理は、特定の担当者だけが行うものではなく、組織全体の取り組みとして推進する必要があります。CMDBに関わる各役割が、データ品質に対するそれぞれの責任を認識し、連携して活動することが成功の鍵となります。（詳細は第2.4章「CMDBを活かす仕組み：構成管理の運用体制デザイン」も参照してください）。

💡 主な役割と責任の概要:

• CMDBオーナー / 構成マネージャー (CMDB Owner / Configuration Manager): CMDBデータ品質戦略全体の責任者。品質目標の設定、改善活動の優先順位付け、リソース確保、ガバナンス委員会への報告。
• CMDBガバナンス委員会 (CMDB Governance Board): データ品質ポリシー・標準・KPI・目標値の承認。重大な品質問題の意思決定、部門間調整、改善活動の監督。
• CMDB管理者 / 運用スタッフ (CMDB Administrator / Operations Staff): CMDB Healthダッシュボード運用、品質スコア監視、レポート作成、問題分析、軽微な修正、修正タスク管理、CIオーナー等へのエスカレーション。
• CIオーナー / CIオーナーグループ (CI Owner / CI Owner Group): 担当CIのデータ正確性・完全性・最新性の維持責任。担当CIに関する品質問題の修正タスク実行、原因分析協力。
• ITSMプロセスオーナー (ITSM Process Owners): 各ITSMプロセスでのCMDBデータ適切な利用推進。品質問題のCMDB運用チームへのフィードバック、担当プロセスのCMDB関連ルール遵守状況監督。
• データソース責任者 (Data Source Owners / Stewards): 各データソースから提供されるデータの品質責任。データソース側での品質問題調査協力・修正。

[図表プレースホルダー: データ品質管理に関わる主要な役割と、それぞれの具体的な責任範囲をまとめたRACIチャート（またはそれに類する責任分担表）]

7.7 データ品質評価と監査準備

📌 CMDB Healthのレポートとメトリクスは、データ品質評価と監査対応における客観的な証拠となります。

組織内部でのデータ品質の継続的な評価だけでなく、外部監査や内部監査への対応においても、CMDB Healthで管理されているデータ品質指標は非常に有効です。

💡 主な活用例:

• データ品質状況の定量的報告:
  • CMDB Healthダッシュボードで示されるKPIスコアやトレンドグラフは、経営層や監査部門へのデータ品質状況報告の基礎資料となります。
  • 👍 これにより、データ品質改善の進捗や課題を具体的に示すことができます。
• 監査証跡としての提供:
  • 資産リストの網羅性: 「完全性」スコアなどが指標となります。
  • 情報の正確性・鮮度・一貫性: 「正確性」スコア（陳腐化CIや重複CIの少なさ）が証拠となります。
  • 変更の追跡可能性: ServiceNowプラットフォームの監査ログ機能とCIの変更履歴で示せます。
  • 統制対象資産の管理状況: 「コンプライアンス」スコアや特定の監査ルール遵守状況が証拠となります。
  • データ品質管理プロセスの有効性: CMDB Healthスコアの改善傾向や修正タスク記録が証拠となり得ます。
• 内部監査・自己評価への活用:
  • IT部門自身がCMDB Healthの運用状況やスコアを定期的にレビューし、自己評価を行うことで、継続的な改善活動を促進し、外部監査に備えることができます。
  • CMDB Healthのスコア自体が、内部監査における評価項目の一つとなることも考えられます。

7.8 本章のまとめ

📌 CMDBの価値維持には、構築後の継続的なデータ品質管理が不可欠です。

本章では、CMDBデータを常に健全な状態に保つための守護神とも言える ServiceNow CMDB Health 機能に焦点を当ててきました。

データ品質は常に劣化のリスクに晒されている ことを認識し、その対策としてCMDB Healthのような仕組みを導入・運用することが、CMDBを「信頼できる唯一の情報源」として維持するための鍵となります。

CMDB Healthは、「完全性」「正確性」「コンプライアンス」「関係性」という主要なKPIと、それらを構成する具体的なサブメトリクスを通じて、CMDBのデータ品質を多角的に測定・可視化します。

CMDB Healthダッシュボード は、品質状況の監視、問題点の特定、改善活動の優先順位付け、そしてその効果測定を行うための中心的なツールです。

効果的なCMDB Healthの運用には、組織の基準に合わせた 適切な設定とカスタマイズ 、日々の 監視と分析 、特定された問題に対する 体系的な修正プロセス （対症療法と根本原因解決の両立）、そして 明確な役割と責任分担 が不可欠です。

👍 高品質なCMDBは、ITSMプロセスの効率化、ITガバナンスの強化、リスク管理の精度向上、そして監査対応の容易化など、組織に多大なメリットをもたらします。

第6章で学んだIREはデータ入力時の品質ゲートキーパーとして機能しますが、それだけでは防ぎきれない品質問題や、時間経過とともに発生するデータの陳腐化などに対応するためには、CMDB Healthによる 継続的な監視と改善活動 が不可欠です。

CMDB Healthを効果的に活用し、データ品質への意識を組織全体で高めていくことが、CMDBプロジェクトの長期的な成功と、ServiceNowプラットフォーム全体の価値最大化に繋がるのです。