（１） ロードマップ策定時の留意点

IT資産管理に関係する自動化テクノロジーの領域は広い。対象はクライアント環境からデータセンター環境まであり、今日までの「IT資産管理（ITAM）」 は、国内では主にクライアント環境のPC管理を意味することが多い。しかし、世界市場ではIT資産管理（ITAM）ツールといえばディスカバリー/インベントリツールにはじまり、IT資産管理レポジトリやCMDB（構成管理DB）、CMS（構成管理システム）へと発展する。

サービスモデルをゴールとする組織にとってIT資産管理は、サービスポートフォリオやサービスカタログの実現のための基礎情報となる非常に重要な情報を管理している。しかし、実際の市場ではIT資産管理ツールは、主にディスカバリーやインベントリ、あるいはPC管理の機能の多さで評価されることが多い。サービスモデルの実現にはIT資産管理の情報を構成管理で再利用する必要があり、IT資産管理とサービス管理における構成管理の連携が不可欠といえるのだが、残念ながら日本国内のIT資産管理ツールベンダーで、それを理解しているベンダーが少ないのが現実だ。

例えば、ソフトウェア資産管理においては、その対象がPCのアプリケーションソフ トウェアであっても、サーバーやデータセンターにおけるサーバー上のミドルウェアやサーバーアプリケーションであっても、ソフトウェアの構成管理によりライセンスを構成する属性情報などの関係性が管理されている必要がある。

IT資産管理レポジトリにおいてそれが管理されており、部分的な情報が管理され、構成管理DBへ受け渡すことになっていたとしても、何らかのレベルで必要となる全ての情報が管理されていなければ、最終的にライセンスの所有状態と、実際の使用状態を 照合し、突合結果により必要に応じて整合化する作業は実施できない。

そして、最終的には全ての情報が提供するサービスの構成要素として認識され、あるいはそのコストが積算され、課金できるようにしなければならない。顧客であるユーザーに提示するサービスカタログは、これらの構成要素を隠ぺいして分かりやすく提示されていてもよいが、それを実現するテクノロジーグループには詳細が提示されていなければ、サービスの提供を困難、あるいは不可能にする。

IT資産管理情報がIT資産管理レポジトリ、CMDB、CMSで管理される際、情報をマネジメントシステム（ツール）、あるいはデータベースレベルで連携するにはXML ベースのWebサービス連携が可能なシステムが求められる。つまり、IT資産管理レポジトリであっても、最終目標がサービスモデルの実現を標榜する組織であれば、Webサービス連携を実装したIT資産管理レポジトリでなければ、いずれ連携可能な機能を実装する製品を再導入する必要がでてくる。

これを念頭に、IT資産管理チームはサービス管理チームとコミュニケーションを取り、全体戦略との整合を考慮したうえで、IT資産管理のロードマップを策定しなければならない。

（２）ディスカバリー／インベントリツール選定の留意点

IT資産管理ツールは大きく分けて、機能的に 「ディスカバリー／インベントリツール」と「IT資産管理リポジトリ」の2つのツールに分けられる。ディスカバリー／インベントリツールとは、デバイスの検出、インベントリ情報の収集に用いられるツールであり、IT資産管理リポジトリとは、収集したデバイス情報、インベントリ情報を含めて、IT資産を管理するツールである。それぞれについて、選定時の注意点をみてみよう。

対象とするデバイスのOSにもよるが、Windows であれば、WMI/DMI を使用しているので、取得できる情報に差異はない。大きな情報取得能力の違いは現れないとしても、必要な情報を収集しているのか、あるいは、必要な情報を指定して収集できるのか、などの機能はツールによって異なるので充分に注意が必要だ。要件には 「どの情報を取得する」 のかを明確にしたほうがよい。

また、インベントリ情報をサーバーなどにアップロードする方法がツールにより異なる。データの転送技術にも、ローカルなのか、セグメントを超えられるのか、あるいはデータサイズを指定できるのかといった違いがある。対象となる拠点数が多く、セグメント数が多い場合、これらの条件によりコストが大幅に上がったりする場合があるので注意が必要だ。

また、PCやネットワーク機器などであれば、デバイスを物理的に一意に特定できるMACアドレス（またはシリアル番号）を取得し、IT資産管理レポジトリにある所有資産レコードとの自動的な紐付や、突合が行えた方がよい。

インベントリ情報の収集先のレポジトリが、単なるデータベースなのか、MDR（マネジメントデータレポジトリ）/ CMDB （構成管理データベース）を意識したデータベースなのかもチェックポイントだ。ディスカバリー／インベントリ収集ツールは10年以上の市場形成を経てきているのである程度の成熟度があるといっていいが、IT資産管理レポジトリに関しては、ITマネジメントスイート製品のベンダーや構成管理を意識したベンダーを除くと、サービス管理を考慮しているツールベンダーが非常に少ないので、要注意だ。

（３） IT資産管理 レポジトリ選定の留意点

IT資産管理レポジトリについては、CMDB（構成管理データベース） が持つ、リレーションの管理を機能として持っているツールがよい。また、IT資産と契約、財務、あるいはソフトウェア資産におけるライセンスのエンタイトルメントや、インベントリ情報との突合および整合化の機能があるのがよい。

IT資産管理レポジトリは、台帳の機能であり、様々な資産の登録、および資産の属性情報、契約、財務、ソフトウェアライセンス契約の条件管理およびエンタイトルメント（使用権の付与）、購入証明などの機能が求められる。これらは、組織の規模、目的、成熟度により、簡易型のIT資産管理レポジトリなのか、あるいは、将来のITSMS、サービス管理との整合性を考慮したCMDB型による、CMS（構成管理システム）における連合（フェデレーション）を実現する製品であるべきなのかを検討する必要がある。

IT資産管理レポジトリには「ステータス」フィールドが必要

資産の状態を把握するためには、ステータスフィールドに、使用中・稼働中、遊休在庫、納品待ち、受領処理待ち、受領処理中、キッティング待ち、キッティン グ、修理返却中、修理中、ベンダー修理中、コールドスタンバイなど、組織の管理の状況に応じた資産の状態を示す「ステータス」が管理される必要がある。ライフサイクルを通じて、資産の状態を把握し、要求実現の際に、遊休在庫を参照し、標準化されたリクエストにおいて、再配置が可能な資産があれば、利用を促す、ということも資産をライフサイクルで管理し、効率化を図る一助となる。

個体識別番号と管理番号
デバイスが持つ、グローバルユニークな情報をもって個体の一意識別をする必要がある。例えば、MAC アドレスやシリアル番号などは個体ユニークであるので利用可能だ。

MAC アドレスは、イーサネットカードなどのメーカー番号が、各メーカーにより異なり、各メーカーはすべてのイーサネットチップにグローバルユニークな番号を割り当てているため、グローバルユニークなデバイスを特定する情報として利用が可能だ。但し、マザーボード上のイーサネットチップが持つMACアドレスは、マザーボードの交換などにより変更される場合もあるので、変更管理プロセスにマザーボード交換の変更管理対応プロセスによるMACアドレスの変更プロセスを考慮しなければならない。

シリアル番号は、メーカーにより個体ユニークに割り当てられていると信頼できる場合においてグローバルユニークな情報となり得る。但し、BIOS に保存された情報は、BIOS フラッシュなど実施された場合、メーカー修理プロセスにおいてBIOS に記載があったオリジナルなシリアル番号情報の復旧を行うという合意の形成が必要だ。修理返品などでBIOSに記載されているシリアル番号が変化していないかなど、受領におけるプロセスでの確認も必要となる。

コンピューター名やホスト名など、部門内で体系化され一意に割り当てられた管理コードを利用することもできるが、組織の統合があった場合、異なる組織における管理コードの体系が類似している場合などは管理コードが重複してしまう可能性がある。また、コンピューター名などはユーザーが変更可能なため、人為的ミスによる重複名の存在の可能性も高くなり、名寄せや修正など管理工数の増加も考えられるのであまりお勧めではない。

資産管理番号は、デバイスを識別するための一意識別子とは別に、当該資産を管理するために割り当てられる組織内でユニークな管理番号である。デバイス個体の一意識別子と合わせて資産管理番号を管理することで、資産管理番号によるデバイスの識別の信頼性の向上を図ることができる。MACアドレスやシリアル番号の登録プロセスは、受領プロセス（または、延長にあるキッティングにおける構成プロセス）に含まれるべきで、受領プロセスにおける情報の紐付と、追加情報の登録による紐付で（具体的には所有レポジトリで登録済み資産レコードに欠落する個体識別情報としてMACアドレスなどを追加入力し資産レコードを更新する）、以降のインベントリ情報との紐付を自動化することが可能となる。

これらは、インベントリツールと、IT資産管理レポジトリにおけるMACアドレスまたは、シリアル番号によるインベントリデータと資産レコードの紐付を可能としていなければならない。

また、デバイスに資産管理番号を埋め込む場合は、受領プロセスにおいて（またはキッティングプロセス）資産管理番号を埋め込み、ユーザーによる変更ができないように管理する必要がある。

（４）重要なサービス戦略との整合性

「サービスモデルへの転換」をゴールにしているのかどうか、はっきりわからない場合、「クラウドを使うのか？」、あるいは、「ユーザーは、IT資産を所有することにこだわりはなく、必要な時に結果を提供してくれる柔軟性、迅速性の高いITを求めているか？」という質問に変えてみればよい。

中堅・大手企業でITのサービスモデルへの転換を考えていない組織はない

クラウドを使う気は全くないという組織はないだろう。それは、すなわち「サービスモデルへの変化の兆候」といえる。もちろん、サービスモデルへの転換が一朝一夕で成しえないことは明らかだ。それは、一つにはサービスプロバイダとしての文化や風土を育てるには時間が掛かるからだ。しかし、成熟度の高い業界がすべからくサービス指向なモデルへ進化することから考えれば、IT業界のサービスモデルへの転換は必然といってよいだろう。

サービスモデルへの転換には、ユーザーとなる組織にとって、唯一無二となるサービスプロバイダ（1st Tier ： 一次サービスプロバイダとしてのIT部門）が必要となる。このサービスプロバイダが、様々なサービスを提供し、それらサービスの構成要素を管理し、ユーザーが期待するサービス内容と、サービスレベルを保証しなければならない。

もし、一次サービスプロバイダが乱立し、ユーザーが複数のサービスプロバイダを相手にしなければならない状況になれば、テクノロジーのサイロが乱立したテクノロジー駆動型におけるユーザーが所有し、ITがテクノロジーサービスを提供するというモデルから、サービスのサイロが乱立し、ユーザーは利用モデルへは移行するが、結局は乱立するサービスの管理に労力を奪われる結果となる。

したがって、IT部門やIT子会社は、ユーザーにとっての唯一無二のサービスプロバイダとしてふるまうのが、あるべき姿である。具体的には、企業内で構築されるプライベート クラウドやパブリック クラウドなど、ユーザーにとってはサービスの構成要素でしかないテクノロジーに関しては、サービスカタログにおいて隠ぺいしてしまい、ユーザーはサービス プロバイダが提供するサービスカタログから求めるサービスを選択するという形だ。

IT部門やIT子会社が、サービスプロバイダとして存在できなければ、結局はコストセンターとして見られてしまう。サービスモデルにおけるサービスプロバイダ間の競争が激化するのは、火を見るより明らかであり、今後、サービスプロバイダとしてユーザーのパートナーになるか、ユーザーのサービスプロバイダにサービスコンポーネントを提供する立場のサプライヤになるのか、サービスプロバイダとしての能力が求められ、試される時が来る。

IT資産管理レポジトリは、IT戦略がサービスモデルをベースとしているのであれば、サービス管理戦略との整合が取れる製品でなければ意味がない。つまり、MDR （マネジメント データ レポジトリ）であろうと、CMDB （構成管理データベース）であろうと、CMS (構成管理システム）の構成コンポーネントであることには違いないので、CMS を構成するための考慮やインターフェース、具体的にはXML を使用した Webサービス インターフェースによる連合をサポートし、連合の中で複数存在するデータの重みづけにより、データの整合化を図るシステムに参加できる能力が求められる。