さて、最終回となる第12回は「CMDB、AMDB、SLO とインベントリツールの連携」と題して、IT資産管理の対象となるクライアント環境からデータセンターをエンドツーエンドで網羅的に、ハードウェアからソフトウェア、ライセンス契約、また、これらの購買情報や利用のための契約などさまざまな形態で使用するIT資産のすべてをコントロールするために不可欠となる複数システムの統合について解説します。

目次

① CMDB （Configuration Management Data Base：構成管理DB）

② AMDB（Asset Management Data Base：資産管理DB）

③ SLO（Software License Optimization：ソフトウェアライセンス最適化）

戦略と設計

「IT資産を管理するという目的で導入するツールなのだから、対象となる資産をすべて網羅的に管理するツールを導入したい！」 至極当然な要望だと思います。しかし、残念ながら今日の複雑化したIT環境に存在するすべてのIT資産を一つのツールで網羅的に管理コントロールすることは不可能です。

そこで最も重要となるのが、IT環境全体を見渡し、管理対象と目的を明確にする全体設計と、設計に基づいて管理システムを自動化する統合設計となります。つまり、さまざまな対象や目的によって使用するツールが異なるため、最終的な目標を前提にCI（構成アイテム）の分担領域を設定し、システムが統合された後にこれらの複数のシステムから集約された情報を活かせる統合管理システムを構築することが、無駄のない効率的なIT資産管理を可能にし、構成管理の業務システムを構築することができるのです。これが実現できないと、結局はExcelでバラバラに管理していたデータがツールに収まるだけで、一見、自動化されたように見えますが、結局、最後は手作業が求められてしまい、運用者の作業効率化は進まないこととなります。

IT資産管理の最終的な目標が、デジタルビジネスで市場競争を勝ち抜くために必要となるIT （サービス）をユーザー事業部門が迅速に提供することを目的としてIT資産のガバナンスとコントロールを獲得する、ということであれば、IT資産管理はCMS（構成管理システム）を構成する要素として考えられていなければなりません。つまり、CMDB､AMDB､SLOはCMSを構成するという点では、同列に存在するシステムということになります。

以下に、CMDB、AMDB、SLOツール市場における一般的な違いのポイントを挙げます。

① CMDB （Configuration Management Data Base：構成管理DB）

• CMDB
• コアCMDB
• サービスとの関係性を管理
• CI全般
• システム/サブシステム

② AMDB（Asset Management Data Base：資産管理DB）

• IT資産 全般
• 物理サーバー
• 契約管理テンプレート
• システム/サブシステム
• サーバーハードウェア資産の発注書
• 資産管理ロジック

③ SLO（Software License Optimization：ソフトウェアライセンス最適化）

• ソフトウェアライセンスに特化した特化型CMDB
• CMDB／コアCMDBと連携し補完
• 契約／ライセンス契約を管理
• 親契約（例：MPSA）子契約の関係を管理
• リース契約、売買契約、発注書
• PC資産
• 専用ライブラリ

• ARL（Application Recognition Library）
• PURL（Product Use Rights Library）
• SKU（Stock Keeping Unit）

これらを目的ごとに使い分けて効率的にシステムを構築することが求められるのですが、CIの設計段階から管理メトリクスを考慮して自動化要件を正確に捉え、必要となるシステムの全体設計をしないと戻り工数の発生や連携ができずに結果的に手作業を増やすことになります。

以下に、CIの設計の際に必要となる考慮ポイントを挙げます。

• 1. 管理対象
• 2. 管理目的
• 3. 管理粒度
• 4.管理メトリクス
• 5. 管理責任（役割と責任）
• 6. 自動化

CIの設計段階で重要なことは、全てのIT資産を識別するということです。

• 1. 物理ハードウェア
• 2. ソフトウェア、ライセンス（ライセンス契約）
• 3.ハードウェアリソース（クラウドサービス）
• 4.ソフトウェアリソース（クラウドサービス）

ソフトウェアといっても自社開発のソフトウェアもあれば、商用ソフトウェアもあります。商用ソフトウェアといっても、クライアント環境のアプリケーションからサーバーOSやミドルウェア、SaaS などのクラウドサービスもあるでしょう。さらには、BYOSL（Bring Your Own Software License）のように、ライセンス契約したソフトウェアをパブリッククラウド上で利用することなども出てくるでしょう。これらを漏れなく対象として捉え、どのような組み合わせを、どのように管理することが求められているのかを把握して管理システムの設計に着手することが大切です。

IT資産管理の取り組みの難しさは、複数のシステムを統合して構成管理システム（CMS）を構築するということだけではありません。これらの情報の発生や、資産情報をコントロールするために協力が必要なステークホルダーが多岐にわたり、組織横断的な取り組みなしでは対象となるIT資産管理業務プロセスの自動化がままならないという、IT部門としての組織横断的な業務プロセスの再構築を伴う取り組みであるからです。

そのためには、取り組みにおける戦略と設計がどうしても必須となります。

戦略と設計

• 1. 明確なマネジメント戦略
• 2. 役割と責任
• 3. 情報集約のための業務プロセス
• 4. スコープと優先順位

全体設計においてはITIL（IT Infrastructure Library） などサービス管理の設計を参照してIT環境全体の管理プロセスの整合性を維持する必要があります。 多くの場合、前述のツールはサービス管理の標準に準拠し、CMSを構成する前提で設計されています。

そのため、サービス管理のマネジメント思想を理解した上で統合システムの設計や計画を立てることが最も効率的です。

CI の設計なども構成管理システム（CMS）からIT環境全体を網羅し、対象や目的ごとにドリルダウンしていくことで自動化要件も明確に定まります。

CI：構成アイテム（例）
• システム
• サブシステム
• 物理サーバー
• 仮想サーバー
• ソフトウェア
• ハードウェア契約
• ソフトウェアライセンス契約
• クラウドサービス契約
• 購買情報

CIを管理する上で必要な管理メトリクスが明確になると、インベントリ情報として突合に必要な要件が明らかになります。

対象が明確になり、管理メトリクスが明確になると、それぞれに適切な自動化ツールが明らかになります。

SLOツールの機能

市場にはさまざまなIT資産管理に関係する自動化ツールが存在しています。しかし、いずれのツールも「データさえ突っ込めば、後は、自動的にIT資産管理をしてくれる」という機能は実装していません。それぞれのツールの特性や対応範囲を把握し、自らの組織が求めている管理対象と目的に合致したツールを連携し、統合することでしか、複雑なIT環境全体を網羅的にIT資産という観点からコントロールするマネジメントシステムの構築は不可能であるということをSMO（Service Management Office）など戦略部門に理解してもらうことがとても重要なのです。

今回で、本シリーズ「複雑化するデータセンターのIT資産管理システム構築への挑戦」は最終回となります。これからIT資産管理システムを構築される方や、構築済みのシステムに課題を抱えている方など、システム管理者のみなさんの業務改善の一助となれれば幸いです。