さて、第5回は、IT資産管理プロセスの自動化要件定義について解説します。まず重要なことは、「IT資産管理はテクノロジーの管理ではない」というポイントです。IT資産管理は、IT部門が主体となり実施するIT資産をコントロールするための業務プロセスの実装であり、「業務プロセスの自動化であるという新しいチャレンジ」であるという理解を全ての関係者が共有することが大切です。ここでは、具体的な例を用いて自動化要件を解説します。

目次

まとめ

まずは、ソフトウェア資産の管理対象であるマイクロソフトライセンス契約を例に考えてみましょう。

ソフトウェア資産管理対象となるマイクロソフトライセンス契約（図１）

組織の規模によって契約形態は異なりますが、代表的なパターンとして図1のようなMBA/MBSA 契約のもとにEA基本契約がその条件とともに契約されます。EA基本契約は条件が変更されなければ無期限ですから、基本契約に3年の加入契約が、それぞれ契約番号が異なる状態で契約されます。そして、加入契約に基づいてライセンスの発注がおこなわれ、使用権がライセンス（License：L）という形で購入されます。さらに、保守契約によりサポートやアップグレードが Service Agreement（SA）という形で発注されます。オリジナルの “L”と、使用権を継続して使用するための”SA”が更新され、年次補正（True-up）により適正なライセンス数を維持していきます。

管理対象としては、現時点での有効ライセンス数を明確に把握するために、まずMBA/MBSAに紐づけてEA基本契約を管理します。そしてEA基本契約に紐づけてEA加入契約を管理し、3年契約の年払いと年次補正情報を管理し、今年度の有効ライセンス数をオリジナルLからSAで更新されたライセンス数として把握する必要があります。最終的に、これらの紐づけ管理された「正台帳」を管理し、発注情報を基に、どのような利用規約（使用許諾条件）によるライセンスをどれだけの数量で、有効ライセンスとして使用可能な状態であるのかを管理します。 さらに、ライセンスの条件がデバイスであれば、デバイスに割り当て処理、ユーザーであれば、ユーザーに割り当て処理ができなければいけません。ライセンスの割り当てが管理できることで、「変更管理」が可能になりますし、割り当て不要となった未使用のライセンスを回収し、在庫化することで「再割り当て」を可能とします。ライセンスの在庫管理能力とは、この一連の紐づけと割り当て処理、再割り当ての処理をもって「在庫管理」と定義されます。

契約の関係性を管理することは、CI（構成アイテム）の関係性を管理することと同義ですので、CMDB（構成管理DB）の要件の範囲です。しかし、汎用的なCMDBでは難しいポイントが、使用許諾条件、つまりライセンスの条件であり、管理メトリクスとなる情報をライブラリ化して、現状の状態をインベントリ収集の情報から把握し、突合するというロジックが必要となることです。これらを汎用CMDBを用いて手組で行うのか、あるいはガートナーが識別しているSLO（Software License Optimization）ツールのような、すでにこれらの要件を考慮したツールを対象に選定するのか選択が必要です。ただし、汎用CMDBでIT資産管理の取り組むことでチャレンジが難しくなると、IT資産管理のCMDBが「塩漬け」コースをたどる、なんてことになりますのでご注意ください。

出典：Gartner ソフトウェアライセンス最適化（SLO）の自動化ツール決定フレームワーク

ガートナーのSLO自動化ツール決定フレームワークからも理解されるように、SLOツールというのは、ソフトウェアライセンス最適化に特化したCMDBで、CMS（構成管理システム）を構成するCMDBの一つであると考えてよいでしょう。ITIL のCMSアーキテクチャをご参照ください。

以下の図２を使って、もう少し詳しくSLOツールのアーキテクチャを解説したいと思います。

SLOツールアーキテクチャ （図２）

SLOツールの重要なポイントは、「正台帳」としての資産コントロール情報の管理です。インベントリ情報は、あくまで、正台帳の情報と現在の環境の状態を突合し、確認するための目的で使用されます。SLOツールの特徴として「インベントリツールに依存しない」ということが挙げられます。つまり、インベントリ収集のツールがSCCMであっても、その他のツールであっても、必要十分なインベントリ情報さえ収集してくれていれば、インベントリツールに依存性がないということです。ここでのポイントは、「必要十分なインベントリ情報」ということです。製品名、メーカー（Publisher）、バージョン、エディションなどライセンスを特定するために必要な情報が取得されていれば良いのです。もちろんインベントリとデバイスを紐づけるために、PCのシリアル番号や、ユーザーとの紐づけを管理するためにADのユーザー情報がLastLoginUserとして取得できれば、ベースラインの構築などの際に開始地点の情報として利用することもできますので有用です。

自動化する上でインベントリ情報のソフトウェアインベントリの名寄せに利用されるライブラリや、発注情報で取得可能な製品SKU番号から利用規約ライブラリを使用する仕組みなどがあれば、ライセンスの発注情報から必要数のライセンス使用権を割り当てるために生成することが自動化できます。ガートナーが識別するSLOセグメントのツールベンダーの多くがこれらのライブラリを用意していますし、これらの正台帳とインベントリ情報を基にしたライセンス突合と整合化の仕組みを提供しています。

マイクロソフトライセンスの管理のポイントは、MBSA－EA基本－EA加入などの関係性を管理することで、オリジナルLとSAの更新を紐づけて有効ライセンス数を自らコントロールすることができるようになるということです。 IT資産管理プロセス自動化ツールの要件について詳細は、以下の国際IT資産管理者協会情報ページでも提供していますので参考にしてください。

次に、Oracleライセンス契約を例に考えてみましょう。 基本的な考え方はマイクロソフトライセンス管理と同じですが、サーバー環境ではそれぞれのソフトウェアメーカーの製品により管理方法が異なり、インベントリ情報の取得方法も異なります。

CMDBとSLOの分界点（図３）

図3では、SLOツールの守備範囲を示しています。Oracleライセンスの場合は、OMA（Oracle Master Agreement）を管理し、保守契約を紐づけます。発注情報からライセンスを生成し、使用権をOracleインスタンスに割り当てます。サブキャパシティモデルのライセンスであれば、VMに割り当てたCPUコアの情報をVMWareなど仮想環境から取得する必要があります。Oracleライセンス管理の場合は、以下のインベントリ情報の取得が必要となります。

• ① VMにデプロイしたインベントリ収集ツールからのインベントリ情報
• ② OracleインスタンスがデプロイされたサーバーのIPアドレスとポート番号へアクセスし、インスタンスの情報を取得（システムアクセス権が必要）
• ③ VMWare にSOAPでアクセスしOracleインスタンスに割り当てられたリソースの情報

SLOでOracleライセンス契約に関する正台帳を作成し、さらにインベントリ情報の取得として前述の3項目の情報を突合することで、実際に割り当てられたライセンスがインスタンスが消費するリソース状態によりライセンス消費の状態とマッチしているのかを確認します。その場合に関係してくるのが、物理サーバーやインスタンスが稼働可能となるCPUの最大キャパシティです。VMWare がvCenter 6.0 によりクラスタをまたいで、物理サーバーをまたいで、データセンターのどこにでも移動が可能であるという場合は「要注意」です。Oracleの定義によると、最大キャパシティとは「インスタンスが稼働可能な範囲」を指していますので、データセンター全体が稼働可能な範囲として解釈されることになります。このような場合の対策としては、以下の3つの対策が考えられます。

• ① すべてのCPUがライセンスされている物理サーバーにOracle製品を集中させる
• ② アクティブなソケット数がライセンス数を左右するため、ソケットをBIOSでオフにする
• ③ プロセッサベースなのでDRS Host Affinity ルールを使用してVMをライセンスされたコアのみの使用に限定する（但し、Oracle社と交渉し契約条件の解釈の相違がないように合意内容を契約書に明文化する必要あり）

このように、Oracleライセンスの１側面を捉えただけでも、自動化要件の考慮は複雑で多岐にわたります。IT資産管理ツールの要件の定義は「エンドツーエンド」で、自社環境で管理が求められる資産スコープを網羅的にカバーするツールが必要です。局所的な対応を繰り返すことは、非効率的で管理システムを不必要に増やし、結果として管理工数があがり、非効率的な管理システムが構築されてしまいます。IT戦略との整合が取れたIT資産管理戦略やロードマップ、スコープの定義を含むIT資産管理プログラムの管理の重要性は、このような背景から生まれてきているのです。

以下に、IT資産管理プロセス自動化のツール要件の重要なポイントをいくつかまとめます。

■自動化ツールの要件ポイント

最後に、サービスデスクツールとの関係について触れたいと思います。最近のサービスデスクツールは「インシデント管理」、「問題管理」、「変更管理」から「サービスカタログ」やCMDB までをカバーするように、その成熟度を増してきています。汎用CMDBはCI（構成アイテム）を設計さえすれば、さまざまな資産を対象に管理が可能です。しかし、商用ソフトウェアライセンスの契約からライセンス消費となると、ユーザーがメトリクスを定義したり、ライブラリを作って参照させたり、インベントリ情報と正台帳を突合させる仕組みを作るのは多大な工数を必要とします。したがって、必要であればCMDBとSLOツールを併用し、補完させて利用する方が効率的であると言えます。

サービスデスクツールとSLOツール（図４）

CMDBはサービスと、サービスを構成するCIをマッピングして網羅的に管理することが可能です。論理的なシステムやサブシステムからサーバー環境の資産管理やOSS製品、社内開発ソフトウェアのコンポーネントまでを対象にすることができます。一方で、SLOツールは、主にクライアント環境のPCや、クライアントおよびサーバーの商用ソフトウェアライセンスの消費をコントロールすることに長けています。将来的な統合を念頭に、管理の重複を避け、段階的に管理成熟度を向上し、一つのマネジメントシステムを設計し実装していきましょう。

まとめ

「IT資産管理」というと「管理」という、やや後ろ向きにも捉えられてしまいがちです。しかし、IT資産のコントロールは、ますます複雑化するIT環境をコントロールするためには必要不可欠であり、「ITサービスをユーザーに提供する」という観点からは、ITサービスを構成する重要な部品の品質管理であり、製造業でいう部品管理：BOM（Bill of Material）の位置づけと言えます。サービスプロバイダとしてユーザーのデジタルビジネスを支援するケイパビリティが求められているIT部門にとっても、IT資産管理のケイパビリティは非常に重要なケイパビリティであるとされています。

5回にわたるコラムにお付き合いいただきありがとうございました。本コラムが皆様の今後のIT資産管理への取り組みにおいて何らかのお役に立てれば幸いです。

国際IT資産管理者協会のメンバーフォーラムサイトでは、IT資産管理の要件定義のリストや、IT資産管理自動化システムRFP案、プロセステンプレートなど様々な情報を提供していますので、是非ご利用ください。