全部集めようとして、集まらなかった ― 2011年、CMDBの始まり

第1回で予告した通り、時間を戻します。行き先は2011年です。

手元に置いたのは、私のサイトにある「ServiceNow知見データベース」の2011年の行と、後になって教材として整理した「CMDB Assessment Kit」の第1章・第2章です。当時の記録と、後からの整理を並べて読むと、同じ時期の話でも見えるものが違います。その違いも含めて、読み返すのはなかなか楽しい作業でした。

2011年の記録

知見データベースの2011年の行は、「企画・計画（CMMIレベル1）」というフェーズで、概要は一行です。

「ServiceNowを中核にITILプロセスをグローバル環境で運用開始」

対象の規模は、グループ400社、PC 38,000台、サーバー2,000台、ネットワーク機器400台など。いま読み返しても、最初から大きな話だったのだと思います。

当時の現場の空気は、後から教材（第1章）に整理した方に残っています。各国・各拠点でバラバラに最適化されたIT部門を統合しようという時期で、資産管理はExcelが中心、不正確で手間がかかり、監査対応は常に大きな負担でした。情報がサイロ化して全体像が見えない、というのが出発点です。そこに「信頼できる唯一の情報源」を作ろう、というのがCMDB構築の動機でした。

やること自体は、とても素直でした。まず、モノの一覧を正しく集める。サーバーは何台あって、どこにあって、誰のものか。その一覧表を作ることが、仕事の中心だったと思います。

全部集めようとして、集まらなかった

知見データベースの2011年の行に、「直面した課題」として最初に書かれているのは「初期CMDBデータ収集の困難」です。

教材の第2章には、スコープを決める場面の話を残しています。各部門・各拠点から「あれも管理したい」「これも把握したい」という要望が殺到する。「すべてを一度に管理する」という誘惑との戦い、と書きました。全てを最初からやろうとしたら、データ収集だけで数年かかり、その間に情報は古くなってしまう。

実際、集める作業は難航しました。課題のもう一つは「標準化の抵抗」です。各国でやり方が違うのですから、集め方を一つに揃えること自体に抵抗がある。データ以前に、人の問題でした。

この時期の学びとして、知見データベースには2つ並んでいます。

• チェンジマネジメントの重要性
• 初期データ精度より主要CIに焦点

2つ目が、この回の肝だと思っています。全部を、正確に、集めようとするのをやめる。主要なCIに絞って、まず使える一覧にする。成功要因の欄には「経営層のリーダーシップ、段階的な機能展開」とあります。教材の方では、心構えとして「小さく始めて大きく育てる」と書きました。最初から完璧な一覧表は、作れなかったのです。

グラフの視点で読み直すと

ここで、第1回から続けている「グラフ」の視点を持ち込んでみます。

一覧表というのは、グラフの言葉で言えば「ノード（点）」のリストです。サーバー、PC、データベースといったモノの一覧。でも、グラフがグラフであるためには、点と点をつなぐ「関係（線）」が要ります。一覧表だけでは、まだグラフにはなっていません。

面白いのは、2011年の時点で、関係のことが頭になかったわけではない、という点です。教材第2章のスコープ設計には、最初から「CI関係性の定義」という項目があります。どのモノとどのモノの依存関係を管理するかは、計画段階で考えていた。知見データベースの2011年の行の対象範囲にも、「Relationships」という単語が入っています。第1回で自分のデータベースを検索したとき、「Relationships」が2件だけ出てきたのですが、そのうち1件はこの2011年の行でした。

つまり、頭の中では「関係も含めて設計するもの」だったのに、実務の力点は圧倒的に「まずモノを集めること」に寄っていた。そのズレが、2011年の正直な姿なのだと思います。設計図の上ではグラフでも、現場の作業は一覧表作りだった、ということです。

いまの自分の言葉で言い直すと

現時点での言い直しを置いておきます。

一覧表から始まったのは、間違いではなかったと思います。点がなければ、線は引けません。ただ、一覧表はゴールではなく、グラフを作るための部品集めでした。当時の私たちは、部品集めの苦労で手一杯で、「集めた部品で何の地図を描くのか」は、まだぼんやりしていたように思います。

そして、一覧表作りで一番効いた学びが「全部ではなく主要なものから」という絞り込みだったことも、グラフの視点では意味が変わって見えます。点の数を競うのではなく、意味のある点から始める。それは、グラフの設計でも同じはずです。これは予感の段階なので、後の回で確かめます。

まだ分からないことと、次回の予告

2011年の記録を読み返して残った疑問は、これです。

• 「主要CIに焦点」と絞った判断は、当時どういう基準で下していたのか。記録には結果しか残っていない
• 関係の設計は計画にあったのに、実務で後回しになったのはなぜか。手が回らなかったのか、必要性が現場で実感できていなかったのか

次回は2014年の記録です。苦労して集めた一覧表が、今度は「更新されない」という問題に直面します。手作業での更新の限界と、CIクラスごとにCI Ownerを置く体制づくりの話です。集める話から、育てる話へ進みます。

（ご相談について：ServiceNowの導入・運用や、CMDBの構築・立て直しに関するスポット相談を受け付けています。詳しくはBellwood Servicesのサイトをご覧ください。）

主な出典

• オントロジーの語源と歴史（ontologiaの初出は1606年、Jacob Lorhard『Ogdoas Scholastica』。1613年のGoclenius『Lexicon Philosophicum』で定義され、Wolffを通じて広まった）：Wikipedia「Ontology」Etymologyほか（2026-11-10確認）
• Tom Gruber「A Translation Approach to Portable Ontology Specifications」（Knowledge Acquisition, 1993）― オントロジーの定義「概念化の明示的な仕様」
• ServiceNow知見データベース（Bellwood Services）https://bellwoodservices.com/insights/index.html
• Bellwood CMDB Assessment Kit 第1章「CMDB構築の根拠」https://academy.bellwoodservices.com/cmdb-assessment/chapters/chapter1.html
• Bellwood CMDB Assessment Kit 第2章「CMDBの計画と体制」https://academy.bellwoodservices.com/cmdb-assessment/chapters/chapter2.html
• Knowledge Graph学習ノート 第1回 https://blog.bellwoodservices.com/zeek/servicenow/2026/11/10/knowledge-graph-learning-notes-01/