IT資産管理（ITAM）、ソフトウェア資産管理（SAM）、ソフトウェアライセンス契約管理（SLAM）、FinOps は、なぜ失敗するのか？

単純な回答は、「経営が現場に責任を押し付けるから」だ。これらはツールを用いて実現するITテクノロジーの管理とはわけが違う、という理解が乏しい経営の責任であるといって間違いない。

それでは、どのように取り組めば成功するのだろうか？　以下に取り組みを成功に導くためのポイントをあげる。

① 当該分野の重要性、特にコンプライアンスについてはガバナンス、コントロールというデジタルトランスフォメーションにおいても最重要課題の取り組みであるということを経営が理解し、必要となるリソースを後援する。

② 組織全体（グループ企業など）で、ポリシー（規程）、体制（役割と責任の定義）、業務プロセスを組織横断的に見直すBPR（ビジネスプロセスリエンジニアリング）であるという理解を共有する。

③ ツールからの着手は失敗への最短距離であることを理解する。

契約は交渉力の無さがコストを100倍にする

ソフトウェアライセンス契約およびサブスクリプション契約は、ビジネスニーズに基づいて使用許諾条件を交渉した結果を運用環境において、その契約した使用許諾条件に照らし合わせて管理するからコンプライアンスの管理が可能となる。
何を持ってコンプライアンスとするのかは、ソフトウェアベンダーの担当営業が理解できていないことが多いということを理解した上でコンプライアンスを把握し、コントロールするための管理設計が必要となる。
契約交渉は交渉プロセスを設計し、ビジネスニーズに基づいた諸条件の獲得を目標として交渉チームが交渉する。

以下に代表的な重要ポイントをあげる。

① ビジネスニーズに基づいて使用許諾条件を交渉するためにビジネスニーズを正確に把握する
② 使用許諾先組織のスコープ
③ システム要件を満たす使用許諾条件の把握
④ ディスカウントレートの適用範囲
⑤ 年次上昇率の交渉
⑥ 契約条件はすべて交渉が可能であると理解する。問題は自社に交渉力があるかどうかを見定めること
⑦ ベンダーが提示する「すべてのお客様にこの条件でやってもらっています」という言葉を鵜呑みにしないこと

ビジネスニーズに基づいた使用許諾条件が獲得できていない場合、後に高額な追加費用を求められる状況に陥ることが多い。

使用許諾先組織の定義ひとつとっても、ビジネスニーズに基づいて、誰が、どのタイミングで使用権を必要としているのかを想定し、想定されるロードマップに則って最終形の組織スコープを最初に交渉して獲得することで多額の追加コストを回避することが可能だ。また、どのような実装環境での運用が考えられるのかも物理、仮想、クラウドなどの利用環境形態のロードマップなどを検討し、これらの可能性に対して備えた使用許諾条件を獲得しておくことも後の高額な追加請求を回避することを可能とする。
物価上昇率を考慮した年次上昇率は、基本的には標準的なインフレを考慮した物価上昇率をベースに交渉するべきで、それ以上の上昇率は実質的な値上げを含んでいることを理解し交渉するべきであり、ベンダーの提示をそのまま受け入れる必要はない。
契約は、”Agreement” の名の通り、双方の合意形成を意味している。提示された条件はあくまでベンダー優位な提示であり、すべての条件は交渉が可能であると理解し、交渉力を上げるためのボリューム、その他の総合的なパワーバランスの調整（BATNAの戦略）により交渉力を獲得して交渉することが大前提であると理解し、交渉チームが交渉プロセスをコントロールすることが重要だ。

ベンダーの監査戦略

契約交渉が管理されていない、コンプライアンスのガバナンス、コントロールが無い組織は特にベンダーの監査戦略に注意する必要がある。これはコストを急激に上昇させる大きな要因となる。「包括契約」という聞こえの良い選択肢は、多額の一時金と継続的な多額の保守費用を余儀なくされる。また、顧客のための最適化支援と称するサービスなども実際にはサービス費用を前払いで支払う監査サービスにほかならない。これらの無駄なコストを回避するためには、ユーザーがプロアクティブに契約をコントロールする必要がある。

ソフトウェアライセンス契約もクラウドサブスクリプション契約も全ては、「ビジネス契約」であることから、企業のガバナンス、コントロールの一環としてコンプライアンスを正確に把握し、最適化のための契約交渉が継続的に実施できるようなポリシー、体制（役割と責任）、業務プロセスが求められる。これはツールを導入すればどうにかなるという話ではないことを経営がしっかりと理解し、「とりあえずツールで運用チームがどうにかせよ」という悪しき習慣から脱却することが最も重要である。

IT業界全体が「テクノロジーモデル」から「サービスモデル」へ大きく変化しようとしている。このモデル変化は、ITの利用者である「顧客視点」であり、ITサービスを提供する側にとっては、リスクの増加、コスト管理の責任、サービス能力の育成など、今までとは比べ物にならないくらいの負担増となるのは火を見るより明らかだ。
しかし、現実は、これらの能力を備えたサービスプロバイダだけが進化の中での生き残り競争を勝ち抜くことができるのであり、IT業界での生き残りをかけた進化の競争は、今後、ますます激化していくだろう。
ここでは、そんな大きな変化の最終ゴールともいえる「サービスモデル」のあり方を考察し、ITサービス管理にとってのIT資産管理についてまとめてみる。

ITサービスとは？
そもそもサービスモデルで言われている「ITサービス」とは何か？
意外なことに、この共通認識が明確でないままIT業界は「サービスモデル」へと進んでいるように思える。もちろん、大手ベンダーはリサーチ会社との提携や買収などにより着実にサービスモデルへの変革を睨みながら垂直統合を行い、サービスの提供能力を強化してきているのだが、多くの水平分業のパートを担っていたベンダーが取り残され気味にバズワードに振り回されながら大手ベンダーの影を追いかけているように見える。
まずは、「サービス」の定義を明確にしたいと思う。
マーケティング マネジメントではバイブルとも称される「コトラー＆ケラーのマーケティング マネジメント」では、
「サービスとは、一方が他方に対して提供する行為や行動で、本質的に無形で何の所有権ももたらさないものをいう。サービスの生産には有形製品が関わる場合もあれば、関わらない場合もある。」と定義されている。
つまり、マーケティングにおいて、対象となる製品は有形製品を含み、無形のサービス（サービス プロダクト）をも含む。
それでは、ITサービス マネジメントのフレームワークである ITIL （IT Infrastructure Library）の「サービス」の定義はどうだろう。
「サービスとは、顧客が特定のコストやリスクを負わずに達成することを望む成果を促進することによって、顧客に価値を提供する手段である。」と定義されている。
これらを踏まえて、今までのITの利用者である「顧客」、つまり、ユーザー部門はITとどのように付き合ってきたのかを考えると、その大きな違いが見えてくる。

＜ユーザーとITの付き合い方＞
・ユーザー部門が必要とするITの処理、能力、期待する結果を要件としてまとめる（IT部門はそれを支援する）
・IT部門が支援し、まとまった要件を実現するためのテクノロジーと、その導入・運用コストを試算する
・ユーザー部門が、試算にもとづいた予算を確保し、発注する
・IT部門が、調達し、または、開発し、システム統合を行い利用可能な状態を構築し、ユーザー部門へ提供し、システム運用のサービスを提供する

簡単に上記にまとめたポイントを含めて現状を解釈すると、ユーザーが所有するITテクノロジーがリスクやコスト管理など、本来ユーザーが求めているITによる処理能力と、期待される処理結果を大きく超える負担となることが容易に推察できる。これは、一極集中型におけるITでは存在しなかった負担だ。一極集中型では実現が困難だった市場の変化に対応するニーズ「迅速性」を獲得した「分散処理型」は、複雑なネットワーク環境と構成に起因する所有リスクとコストの上昇によりユーザーの負担を大きく増加させる結果となった。
言い換えれば、ユーザーが変化対応力や迅速性を求めた結果、リスクが増加し、コスト管理が困難になったと言える。変化対応力や迅速性は損ないたくない、できれば向上したい、さらに、特定のコストやリスクは負いたくない、という結果、サービスを志向するようになる。
そんな要求への解として、ユーザーの負担を軽減しつつ、迅速性を維持・向上させるために登場したのが、「サービス指向アーキテクチャ」であり、その実現のために「コンソリデーション（統合）」や「バーチャリゼーション（仮想化）」が進化してきた。
ユーザーが必要とするのは、ITがもたらす処理能力と処理結果であり、ITテクノロジーを所有することで発生するリスクの増加や、コスト管理の能力は、そもそもユーザーが欲するところではない。
つまり、ユーザーが求めるITのサービスとは、「所有権をもたらさずに、特定のコストやリスクを負わずに成果を得る」ことを期待していると言える。
したがって、ITサービスを提供するということは、サービスプロバイダが所有する資産で、リスクを背負い、コスト管理能力を発揮して、ユーザーに成果を提供し、その提供した価値にみあったコストを課金して回収する、と言い換えることができる。

サービスモデルにおけるIT資産管理とは？
サービスモデルにおけるIT資産管理の前提条件として、前述のITサービスの定義からスタートすると、
・IT資産はサービスプロバイダが所有する
・顧客に提供するITサービスを構成する資産はサービス資産である
・顧客に提供するITサービスを実現するために必要となるサービス 能力を支援するに必要なIT資産を含む
IT資産の定義として上記のポイントを考慮すると、
IT資産とは、サービスプロバイダが所有するIT資産（有形・無形）全般を指し、サービス資産を含み、顧客に提供するサービスを構成しないサービスプロバイダの資産をも含む
と、考えることができる。
しかし、テクノロジーモデルからサービスモデルへの変化には、それ相応の時間がかかる。その間、所有がユーザーであるIT資産や、所有がサービスプロバイダであるIT資産もあり、一方でコストの全体最適化を実現するためにプールされる資産は、そのどちらをも含むというトランジション フェーズが何年か続くだろう。
つまり、サービスモデルへのトランジションは、複雑に入り組んだ所有権とプールされる資産を、誰が（所有と利用）、何のために（紐づくサービス）、どのように利用される（リスク・コンプライアンスの管理）のかを明確に管理することが重要となる。

サービスカタログ、要求実現でおさえるべきIT資産管理プロセス
サービスモデルを標榜する組織では、IT資産管理のプロセスはサービスカタログ、要求実現のプロセスにおいて開始される。
サービスカタログはユーザーに分かりやすいカタログ化という一面と、そのサービス提供を可能とする裏方が利用するテクノロジーの詳細という一面が存在する。
例えばユーザーの端末機器は、サービスを提供する上でエンドポイントとなり、エンドポイントの機器、環境の提供や管理などサービスカタログにおいて標準化されたパッケージサービスがユーザーに分かりやすく、詳細の構成情報などはサービスプロバイダに分かりやすく設計されている必要がある。
IT資産管理のプロセスは、要求実現のプロセスにも大きく関与する。ユーザーまたはサービスプロバイダが所有する資産を、サービス実現のために提供するにはIT資産の在庫管理が正確に実施されていることが前提条件となる。これは有形のハードウェア資産、無形のソフトウェア資産（契約）の在庫管理の能力、つまり、資産プールの管理や、再利用のために必要な処理という能力が求められる。
IT資産管理においては、標準化、調達、IMAC（インストール、移動、追加、変更）、ソフトウェア ライセンス（使用権）の最適化などのプロセスがこれらに関係し、サービス管理のプロセスとの統合が求められる。サービス管理との統合を念頭に考慮されていないIT資産管理は、独立したマネジメント システムを複数構築し、無駄が発生し、管理コストを上昇させるだけでなく、リスク増加の原因ともなるので十分な注意が必要だ。

サービス資産、構成管理でおさえるべきIT資産管理プロセス
ユーザーの端末はエンドツーエンドのサービスのエンドポイントであり、ユーザーの端末環境を含むエンドポイント プラットフォームの提供をサービスと捉えれば、「ユーザーにPCを提供する」というサービスを構成するサービス資産であるPCハードウェアやOS、アプリケーションおよび、それらの設定を含む構成情報は、サービス資産および構成管理の範疇であり、IT資産管理プロセスと重複するので、統合を念頭に考慮されなければ前述の無駄やリスクが発生する。
もちろん、サービス管理におけるサービス資産とは、能力や人材などサービスを提供する上で必要となる構成要素すべてを含み、IT資産管理が対象とする資産は、サービスを構成する資産に限らず、サービスを提供するために必要なサービス管理インフラの資産をも含む。
サービスプロバイダとしては、これら重複するプロセスを共有しながらも、独立した固有の目的をも対応しつつ、二つのマネジメント システムの統合と共存を図ることが求められる。

クラウドコンピューティングを理解する

ユーティリティコンピューティング

1990年代の後半に、ユーティリティ コンピューティングは再度、市場に現れる。

ITベンダーにとってユーティリティモデルは、ハードやソフトウェア を毎回販売して利益を得る「フロー型ビジネス」から、電気、ガス、水道、電話のように毎月ほぼ固定的に利用料を徴収できる「ストック型ビジネス」への、よ り安定性の高いビジネスモデルへの転換だから歓迎だ。むしろ、ユーティリティモデルのようなストック型ビジネスの方が年間の予算は見えるしビジネスは安定 する。しかも、顧客を囲い込むことができるので、毎回激しい競合との価格競争により利益率が悪化する一方の、それまでのビジネス形態から脱却することがで きる。ユーザにとっても、日々業務に追われながら複雑に進化するIT技術を追いかけるより、従量課金制のサービスとして利用し、月々のコストとして処理するほうがはるかに楽になるはずだった。

しかし、個人情報や機密情報、ビジネス優位性を有するビジネスプロセスなどを完全に企業の外に出してしまい、ITベンダーに預けてサービスとして利用するITには、現時点では様々なリスクを伴う。これらリスクの課題が完全に解決されるまでは、機密情報や企業優位性を有するビジネスプロセスを、完全に企業の外に出した時のリスクに懸念を抱く企業にとって、完全なユーティリティモデルへの移行は不可能だ。もちろん、IT技術がさらに進化し、機密性、安全性が完全に確保され、ユーティリティモデルによるコストメリットを享受できるのであれば、最終的には完全にユーティリティモデルへ移行することが考えられる。この場合は、ユーティリティ データセンターにはサービスを提供する先の複数の企業の変化に対応するための、非常に高い変化対応力が求められる。それだけではなく、提供するサービスの ビジネスにおける重要性に応じてサービス料金もいくつかのレベルを持つ必要がある。可用性、堅牢性が高く求められるミッションクリティカルなサービスと、 そうでないサービスの料金はユーザからすれば当然同じ金額を払うことはできないからだ。もちろん、ユーティリティモデルへの移行時期には例外もある。前述のケースは中堅・大手企業で既に自前のデータセンターを 持っている場合のことで、中小企業などで「サーバを自社購入して、運用管理はサービスを提供しているデータセンターへ実機を置いてお任せしている」、とい う場合は早急にパブリッククラウドへ移行し、全てをコスト化してしまった方が良いケースもある。

中小企業にとってはパブリッククラウド環境が一日も早く安定提供され、最大限の活用による無駄なコストの削減と、IT運用の効率化が競争力の鍵となるだろう。これらのユーティリティモデルへの動きはIT業界における、ITベンダーの垂直統合やグローバル化の動きを見ても、最終形としてのユーティリティモデルによるサービス化をゴールとしていることが伺える。既に飽和状態のIT市場においてフロー型ビジネスではこれ以上の成長は望めない、垂直統合を行い、ユーティリティデータセンターをグローバルに展開し、サービスとしてグローバル企業を取り込むことで30%しか手を出すことができなかったIT市場の100%を視野に入れて成長路線を歩むことができるからだ。

クラウド コンピューティングの登場

現時点でのユーティリティモデルの課題を解決する方法として、提案されたのがクラウドコンピューティングだ。
クラウドには、パブリック クラウドとプライベート クラウドがある。
パブリッククラウドは、SaaS、PaaS、XaaSな どソフトウェア、プラットフォーム、ハードウェアなどをサービスとしてベンダーにより提供され、対してプライベート クラウドは、企業内のユーティリティモデルといえる。企業内ユーティリティモデルでは仮想化された一つのプラットフォーム上で、複数業務に対して組織横断 的にサービスを提供する。仮想化されたリソースプールを効率的に利用することで稼働率90%を実現し、可変的に必要となるリソースは企業外のサービスをパブリック クラウドという形で柔軟に利用する。 また、企業内では優先度や稼働率が低いサービスなどもパブリッククラウドを利用することで無駄な投資を避け、従量課金で最もコスト効率の良いサービスを利用することが可能だ。さらに、企業内にはない優良なシステム（例：SalesForceなど）をサービスとして利用することで、あえて社内でシステム開発をしないで無駄な開発コストや管理コストを抑制することができる。

クラウドにおいては物理的な異機種混合環境を、論理的なリソースプールとして統合し、仮想化することでハードウェアの稼働率の最大化を図る。さらに、管理層により再利用性の高いサービス指向アーキテクチャ(SOA)のアプリケーション層の変更管理を行い、迅速な変更を可能とし、変化対応力を向上する。業務アプリケーションでも、管理アプリケーションでも粒度の粗い、疎結合のシステムにすることで連携や統合を容易にし、サービスとサービスの連携の仕方や、新たなサービスを加えて連携させることで、変化への対応力を高めている。その実装技術としてWebサービスによるHTTPなどを利用したファイアウォール越えの連携がある。今まではAPIを使い、ローカルポートを利用した密結合の連携でしか実現できなかったアプリケーションの連携が、Webサービス技術により、アプリケーションの違いや、開発言語の違いを乗り越えて疎結合の連携を可能とし、比較的簡単に短時間で連携を実現し変化に対して迅速に対応することを可能とした。

そんな疎結合で柔軟性、変化対応力の高いクラウドでより一層明確になったのは管理層の重要性だ。

今までシステムの監視と管理は、開発にくらべ後ろ向きなコストとされ、開発などの投資が30%に対して、運用コストが70%という、後ろ向きなコストを削減するべきだと言われ続けてきた。ところが、異機種混合のハードウェア環境において開発されたアプリケーションを最大限に生かし変化に対応するためには、管理 層の機能は開発同様に戦略的で迅速な対応が求められる。監視と管理という運用における役割は、「再利用性の高いサービスコンポーネントや、仮想化されたプ ラットフォームの変化対応力を最大化する管理層を構築し運用する」という形で、今まで川下と考えられていた運用とは全く異なり、IT戦略の中枢で非常に重要な役割を担うことになる。

クラウド実現の鍵は、「変化対応力を備えた管理層の構築だ」といっても過言ではない。

そして、クラウドの管理層の構築で最も重要なのは、決して管理ツールで自動化すれば解決する問題ではないということだ。管理 ツールは、標準化された運用管理のプロセスをサポートし、自動化、効率化を実現する重要な役割を持っていることは確かだが、ツールの導入で運用管理プロセ スが構築されることはない。変化へ対応するための変更を全てツールにより自動化することは不可能なので、迅速な変化対応を実現するためにはツールを生かすための人によるポリシーベースの変更プロセスが機能しなければならない。

クラウド環境の進化

企業のITのあり方として今日のクラウドコンピューティングに至るまで、「ユーティリティ コンピューティング」や「グリッド コンピューティング」などが提案されている。これらは変化対応力やコストの最適化、投資効率の最大化などを課題として取り組まれてきたもので、今日のクラウド コンピューティングへの進化の過程であり、クラウド コンピューティングとも混同しやすい。

以下にそれぞれの定義を簡単にまとめてみる：

１． グリッド コンピューティング

スーパーコンピュータ、仮想コンピュータがネットワーク化され、疎結合されたコンピュータのクラスターを構成し、膨大なタスクに対して複数のコンピュータが協力して処理する分散処理コンピューティングの形態。

２． ユーティリティ コンピューティング

電気など、公共ユーティリティサービスのように従量課金サービスとして、演算処理やストレージなどのコンピュータリソースを提供するサービスをパッケージ化したもの。

３． クラウド コンピューティング

動的な拡張性があり、仮想化リソースがインターネット上で提供されている。クラウドを利用するユーザは、クラウドをサポートするインフラ技術の制御、専門知識、いかなる知識も必要としない。

クラウドの概念は以下の組み合わせにより構成される：

①IaaS (infrastrucrure as a service)

②PaaS (platform as a service)

③SaaS (software as a service)

④XaaS (everything as a service) その他、最新のインターネット上でユーザのニーズに対応するテクノロジなど。

特にユーティリティ コンピューティングは、クラウド コンピューティングのデリバリ モデルとしての従量課金サービスという共通項があるので混同しやすいが、クラウドはユーティリティ コンピューティングを現在のインターネット時代に合わせて具現化したものと考えた方が良いのかもしれない。

ユーティリティ コンピューティング

コンピュータの演算処理やストレージのようなリソースを必要な時に、必要なだけ利用でき、使用量に応じてサービス料金を支払えたらユーザ企業にとってどんなにかコストの最適化が楽だろうか。

「電気、ガス、水道、電話のような公共サービス(public utility)と同じようにコンピュータも公共インフラサービスのような利用形態を将来とることができる」

1961年当時 MIT で教鞭をとっていたJohn McCarthy が MIT 100年際 で初めてユーティリティ コンピューティングにについてこのように公言した。以来、20年に渡ってIBMなど大型汎用機ベンダーは銀行や大手企業に対して世界規模のデータセンターでユーティリティ コンピューティング モデルを「タイムシェアリング」というサービスで提供した。しかし、ミニコンやオープン系の進化により、ほぼ全ての企業がコンピュータを導入できるようになり、このユーティリティモデルのサービスは廃れていった。

オープン系の進化により、分散処理型のクライアント/サーバ システムによる業務ごとに必要なサーバを立てるという柔軟性の高いシステム構築の方法が紹介されると、必要に応じていくらでもサーバを構築して新たな業務システムを追加できる柔軟性に、次々とサーバが立てられ、新たな業務へと対応が行われた。しかし、あまりに次々とサーバが追加され、そもそもは最終的に80%ぐらいの稼働率を予定して20～30％稼働率で構築されたサーバは、いつまでたっても30%ぐらいの稼働率のまま、ともすると何の業務アプリケーションが使用されているサーバかを管理することすら不可能な状態になっていった。同時期に研究が行われていた技術として、平行/分散処理システムを実現しようとしたのがグリッドコンピューティングだ。グリッド コンピューティングが実現され、 70%もある余剰CPUリソースを集めて分散処理のCPUリソースとして再利用できれば、ユーザは安心して次々とサーバをたて、余剰CPUリソースは新たな業務に仮想的に割り当てることができる。ところが、残念なことにグリッドの技術では余剰CPUを適宜、動的に利用して新たな業務に割り当てるという目的を果たすことは実現されなかった。

なぜ、変更管理が重要か？

今までは「川上の開発」、「川下の運用管理」というイメージで運用管理は捉えられてきた。しかし、その構図こそが全体最適化によるコスト削減の妨げの一因となってきた。

「運用管理のコストがIT投資全体の70%を 占めているからコストを削減しなければならない」長い間、運用管理部門にはこの命題が与えられていた。しかし、そもそも運用コストは上昇する構造だったと したら…川下で帳尻を合わせるということが不可能だったとしたら…

非稼動資産＝余剰資産
業務システムの使用度が成長し、導入後に徐々に稼働率が向上することを考慮して、当初導入時は稼働率30%ぐらいで設計し、将来予想されるピーク時を80%ぐらいと考えて構築されたシステムは、結果として稼働率が予定どおりに向上せずに、70%ぐらいの余剰資産が次々に投入されるという事態を招くことになった。

変化に対応する手段として登場した分散システムは、安定稼動のために業務システム毎にCPUを追加し、１OS上に１業務アプリケーションを配置し、必要に応じて次々とサーバを投入するという状態へと導いた。その結果、運用管理部門は増殖するサーバにより複雑化するサーバネットワークの死活監視と管理に追われることとなった。

分散処理の１OS・１業務アプリケーションという構造を見る限り、コストが上昇する結果は明らかだ。

これら課題の解決策として「サーバ統合」によるネットワークの整理と、「仮想化」による稼働率向上が提案されることになる。

一方、業務アプリケーションの開発も、開発効率と変化対応力の向上のために「サービス」という粒度が高く、「再利用性」の高いサービス指向アーキテクチャ（SOA）へと進化していき、稼働率向上をめざす統合されたサーバ環境の仮想化環境上にSOAシステムが構築されていくこととなる。

もちろん、CPU使用率のピークの波を上手く合わせながら稼働率の向 上を図り、変化する市場にたいしてサービスのキャパシティや、システムも変化させていくとなると所有している資産だけでは収まらなくなるケースも出てく る。そうなるとプライベートクラウドが構築されたデータセンターでは必要性に応じて所有しない資産を「利用する」パブリッククラウドのリソースの有効利用 までも念頭においてサービスの提供を構築することが求められる。

クラウド化のけん引役「サーバ統合（コンソリデーション）」と「仮想化（バーチャリゼーション）」は複雑化を進める

サーバ統合と仮想化により稼働率と変化対応力の向上をしながらコスト削減を実現するクラウド環境へ一歩近づいたといえる。

しかし、変化対応力が向上すると期待されるクラウドは、一方では、頻繁に変化する環境をしっかりと管理しないとサービスの品 質の低下や、可用性の問題を発生する可能性が増大するというリスクを抱える。つまり、クラウドの実現にはリソースプールを利用し、必要に応じて構成変更を 行い変化に対応するシステムの管理が鍵となる。

クラウド実現のための仮想化環境における管理対象例

１． １サーバ上に複数のアプリケーションが動作する環境で、共有するリソースの競合の可能性が大きくなるため、共有されるリソースの管理が必要となる

２． サーバ上のレイヤーが多くなり、アプリケーションが依存する複数のレイヤーとCPUなどのサーバリソースの依存関係が変化し続けるため、ハードウェア・ソフトウェアを含めた全ての構成要素のリレーション管理が必要となる

３． 構成変更が頻繁に行われるので複雑なレイヤーを含めた依存関係の遷移を管理する必要がでてくるため、変更前・変更後などのタイミングでの全ての構成要素のリレーションのスナップショットの管理が必要となる

仮想化環境では変化対応力が向上し構成変更が容易に行えるようになる。しかし、このメリットを生かすためには、運用管理のポリシーにおける変更プロセスを変更の頻度が高くなっても対応可能にしなければならない。具体的には変更に関わる影響分析が複雑なレイヤーや関係するハード ウェア全域、さらにはサービスを構成する全てのアプリケーションと、そのアプリケーションに関係する全てのソフトウェアレイヤーとハードウェアの構成が管理されていなければならない。

複雑化に対応する運用管理

変化対応力やコストの最適化を実現するとして期待されているクラウドだが、前述のように、その実現には複雑化する環境を運用する管理層の充実が不可欠なことがわかる。

管理層の充実は、すでに運用管理のポリシー策定にとどまらず、「戦略」、「設計」、「導入」、「運用」、「変更」といった全てのフェーズに関わっているといっても過言ではない。

そんな変化対応力を実現する企業ITを実現する一助として注目されているのが「Information Technology Infrastructure Library （ITIL）」なのだ。

ITIL Version 3 への期待

ITIL V2 の当時は運用管理の部分だけが注目を集めたが、実はITIL は運用管理に特化したガイドラインではない。ITをサービスととらえ、あたかもユーティリティサービスを提供する際に必要となるサービス提供の全域に渡ってサービスの品質向上を実現するためのガイドラインとして策定されたのだ。

ITIL V3 ITサービスの５つのライフサイクル

１． サービスストラテジ（戦略）

２． サービスデザイン（設計）

３． サービストランジション（導入・変更）

４． サービスオペレーション（運用）

５． 継続的なサービス改善

ここで重要なことは、管理層の充実は５つのライフサイクル全てに関係しているということだ。すなわち、運用管理部門の関与も 管理層の充実という観点から考えるとライフサイクル全般を意味する。「運用管理が戦略的な役割を担う」というのもクラウド環境において運用管理層を考慮せ ずに前述の5つのフェーズのどれも語れないからだ。

クラウド時代における運用管理は川下ではなく、「運用管理こそがクラウド戦略の要」であるといえる。

変化対応力を実現するための変更管理

迅速な対応が求められる変化への対応。それには変更管理のポリシーやプロセスが機能しなければならない。特に組織横断的に利用されるリソースプールを基礎としたプライベートクラウド環境では、組織横断的にサービスの優先順位が明確化されていなければならない。具体的には、「いざとなった時に、どのサービスから犠牲にするか」ということも管理されていなければならない。全てのサービスが可用性100%を求められるわけではない。時間帯や曜日、季節によっても可用性の要件はことなるはず。

「いやいや、うちのサービスは常に利用可能な状態でなければ困ります」という部門毎の主張を受け入れてしまうと、せっかくの全体最適化実現の可能性を失ってしまう。

つまり、組織横断的にSLAを検討し、サービスの優先順位を明確にしなければ全体最適化によるコスト最適化は不可能だといってもよい。重要な社内システムとはいえ、社員が利用する時間外は可用性が高い必要性はない。一方で、一般のユーザが利用するサービスは特定の曜日、時間帯に平日昼間の数十倍、数百倍のキャパシティを必要とする場合もあるだろう。なんらかの時事的要因で例外的に急激なキャパシティ要求の増加に対応しなければならないことも考えられる。それぞれのサービスが必要とされる時間帯や曜日、季節などを特定し、さらに影響される金額に換算して、実際に企業活動の目的 といえる営業利益にどのような影響を及ぼすのかの金額の大きさを基礎に優先順位を明らかにする必要がある。そもそも企業活動の目的とは利益を生むというこ とであることを営業部門のみならず、全ての部門において理解し、IT戦略においても利益創出活動の優先順位によって明確な優先度を持つべきである。また、稼働の計画性が低いサービスや、使用頻度が低かったりというサービスは、同等のサービスがパブリッククラウドで同等コ ストで提供されていないかを検討する必要もある。この場合は会計的観点から「所有＝資産」であるから、当然「総資産回転率」といった経営指標に影響を及ぼ すことを考慮し、資産回転率に悪影響をおよぼすような要因は排除し、費用計上が可能な「利用」形態をとることを検討する必要があることをIT部門も考慮する必要がある。このように変更管理のポリシーの策定には、企業ITの戦略や方針の策定の成功が大きく関与する。

戦略や方針の策定がしっかりしていないと、サービスの優先順位が明確化されず、変更管理のポリシーが策定できず、変更プロセ スが作られていても機能しなくなる。組織横断的に管理されるサービスの優先順位は、企業戦略の変化や経済の変化により変化し続けるので、これらの変化に合 わせて随時アップデートされ管理されて変更管理のポリシーに反映されなければならない。SLAや優先順位の管理は、変更管理ポリシーの策定では一つの要素にすぎないが、これらを踏まえて、変更管理のプロセスが機能するように策定、運用されなければ変化対応力の向上にはならず、全体最適化の実現もできない。これは変更管理プロセスに限ったことではない、情報セキュリティ管理（ISMS）やソフトウェア資産管理（SAM）などもISO化されコンプライアンスが要求され、形ばかりは遵守しているようにつくろっていても戦略や方針が徹底していなければいずれは綻びが生じ問題が発生する。

最も重要な前提条件は、企業戦略に則ったITの戦略や方針が経営者により明示、徹底され、それに基づいて現場のポリシーが策定され、設計されたプロセスにより運用されることだ。

こればかりは、運用管理ツールを導入すれば何とかなるという問題ではない。もちろん、運用管理ツールが不要だということではない。複雑化が進むクラウド環境を効率よく運用するには様々な重要な項目を抑えているITIL のようなガイドラインを参照することは有効だ。また、ITIL に 準拠した統合管理ツールベンダーの製品を利用して管理対象の全てを可視化し、制御し、可能な限り自動化しながら、人的プロセスの一助として利用することも 効率的な運用管理には不可欠といっていい。膨大な管理対象や項目を人手だけで管理することは不可能だし、ポリシーに則って自動化できる運用は、自動化し、 空いた工数はポリシーのアップデートや、組織横断的な優先順位の管理や調整などに充てるなどすべきだ。常に最新にアップデートされた優先順位を含むポリ シーや、有効な危機対応プロセスを維持することで、危機レベルの比較的低いエラー一つで無駄に数多くの人員を夜中にたたき起こすなどということは回避され るはずだ。プロセス自体が可視化され、制御可能な状態で、可能な限り自動化されていることも重要だ。「ツールを導入したが、プロセスは属人的」では有効な ポリシーベースのプロセスは機能しない。

資産管理を効率的、効果的に実施するためには ポリシー（社内規程）/体制（役割と責任の定義）/ライフサイクル業務プロセス/ガイドライン-手順の策定と、中長期的なロードマップを持った IT資産管理プログラムの運営が必須となる。

プロセスを効率化するには、どのような自動化テクノロジーを使用するかの選択が重要となるが、テクノロジー（管理ツール）を導入しただけでは失敗するケースが多い。

多くの場合、資産管理の自動化の成功には欠かせない CI（構成アイテム）の定義と、CI の関係性の定義が明確でないことに起因する。

残念ながら CI の関係性は全ての組織で同じというわけではない、契約やソフトウェアライセンスの買い方などにより CI の関係性が異なることから、ツールを導入すればテンプレートで自動化してやってくれるというわけではないところが失敗を導く要因となっている。

対策としては、具体的には、ハードウェア、ソフトウェア毎に関係する CI を洗い出し、その関係性をトポロジーマップにして効率的な管理が評価対象のツールで可能かを評価することが大切だ。

CI は、 ハードウェアに関係するリース契約、保守契約などから、ソフトウェア契約、ライセンス、使用条件などあるが、ソフトウェアの購入形態により、その関係性は異なる。

同じソフトウェアでも異なるライセンス形態の契約を複数保有している場合などは、親 CI となる 「ソフトウェア名称」 に、「ソフトウェア契約」 の子 CI が複数存在し、それぞれの子 CI には付与されたライセンス数の孫 CI となる「ライセンス（使用権）」が存在する。

このライセンス CI は、その条件により割り当てられるデバイス（またはユーザー）紐付られる。

具体的には、MS Office 2010 のボリュームライセンスを各部門で保有し、パッケージやOEM版なども、ある部門では保有している場合などは前述のCI の関係性を管理し、それぞれの契約に紐づき割り当てられたデバイスが特定できなければならない。

これらは、ソフトウェア契約の内容や保有するライセンスの形態により管理するために必要なCI が異なるため、まずは現在の状態を把握し、求められる管理対象となる CI の粒度を定義し、CI 間の関係性を可視化することが必要となる。

サーバー アプリケーションの契約で、コア単位のキャパシティ ライセンスという形態であれば、サーバー ハードウェアの CI は、サーバーの親 CI に、CPU という子 CI、コアという 孫 CI が紐づき、これら孫 CI に割り当てられた「ライセンス CI」 を追跡し、管理する必要がある。

CI を定義し、CI の関係性を定義した上でツール（CMDB やITAM リポジトリ）のテーブル設計と比較し、もとめているレベルの管理が可能かどうかを評価することが重要だ。ツールベンダーの言う「安心してください、自動化できますから」は決して信用して鵜呑みにしてはいけない。「何を」、「どこまで」自動化するのか、はすべて、ユーザがツールをどのように運用するのかに依存しているということをお忘れなく。自動化されるのは定義され正しく投入されたデータを処理するための機能が備わっている時に初めて実現される。

ベースライン： Baseline
ソフトウェアライセンスの最適化をも視野に入れたIT資産管理システムを構築する際に、システムを運用開始するために必要となるデータを入力し、ベースラインを構築します。
この際のベースラインには以下のデータが必要になります。

チェックリストのポイント：

①　組織
ライセンシーの定義、終了・移行期間、ジョイントベンチャー、関係組織・内部組織間所有移転、廃棄・ランセンス分割

②　ライセンス付与
業務目的、関係組織へのサブライセンシング、ライセンス条件、外部利用

③　契約期間
保守契約開始日、受領期間、保証期間

④　ユーザーベース・ライセンス
地理的制限、実利用、一人・一ライセンス、ユーザー・ライセンスの再割り当て、権利の定義、利用の定義、システム・ユーザー、人ベースの価格

⑤　デバイス・ベース・ライセンス
デバイス種別、仮想デスクトップ、IoT

⑥　サーバー・ベース・ライセンス
仮想化サーバー、ホスティング／パブリック・クラウド、ライセンスの再割り当て、バックアップ／DR、開発および試験、マルチコア・プロセッサ、コア：プロセッサ・ファクター、ハードウェア・マイグレーション、プラットフォームの変更、メモリ量

⑦　その他のメトリックス
ビジネス・メトリックス、インデックス、対象外組織、トランザクション・メトリックス、例外ピーク

⑧　製品リスト
パッケージ変更、後継製品、トレード・イン権利、追加製品、未使用ライセンスの保守契約、ライセンス数の削減

⑨　コンプライアンス検証
不当なさぐり、予期せぬ違反、訂正、妥当な告知、SAMプロセス、監査コストの法的責任

⑩　関係管理
守秘義務、補償、保険、インセンティブ、サポート・サービス・レベル、完全な契約、一方的な変更、許可のない変更、保守費の増額

IT資産管理プログラムの策定には、ガイドラインとなるポリシー（規程）が必要だ。
ポリシー（規程）に対して全社的な合意がなされ、経営者層の理解と承認、支援が行われれば、IT資産管理者の仕事もよりどころができて、よりスムーズに前進できる。

ポリシーが、できるだけ全容をとらえ、複雑すぎず、明確に目的や、責任の所在、役割などをおさえることで、それらを手順におとすことができる。

以下に規程で網羅すべき内容の例をあげる：

 IT 資産管理の範囲と権限
このポリシーは、IT 資産管理者の権限を明らかにし、IT 資産業務部の重要性を明示する。

 エンドユーザーによるデスクトップ、ラップトップ、PDA を含むコンピューターデバイスの
使用についての ポリシー
このポリシーは、コンピューターデバイスを使う個人が、できること、また許可されていないことを示す。エンドユーザーの行動に最終的に責任を負う組織を保護することを目的とし、エンドユーザーのポリシー違反の際の処罰の概要を説明する。

 契約とコンプライアンス権限
契約とコンプライアンス権限に関するポリシーは、契約承認とコンプライアンス関連文書の承認に関する要件と階層的な権限を、明確かつ整合的に定義する。このポリシーは、対象範囲内の文書を種別毎に、簡潔に取り扱わなければならない。ベストプラクティスは、すべての文書化された権限執行と承認を記録する集中型プロセスを維持することである。

 コンピューターハードウェアの調達
このポリシーは、組織がハードウェア調達プロセスを統制できるよう、組織全体の調達プロセスを標準化する。

 ソフトウェアの調達とインストール
このポリシーは、組織がソフトウェアの調達とインストールのプロセスを統制できるよう、組織全体の調達プロセスを標準化する。

 ソフトウェア 倫理規定
ソフトウェア倫理規定は、組織的なソフトウェア購入のユーザーに求められることの要点を明確に説明する。

 違法コピー防止と著作権
違法コピー防止と著作権のポリシーは、著作権保護された物品についての法規制についてユーザーを教育し、違反に対する罰則を概説する。

 サポートされているハードウェア とソフトウェアの 基準、認められた代替物と例外管理
このポリシーは、組織内で基準が用いられること、認められた代替物などの例外の場合の基準の取り扱いを決定する。

 メンテナンス基準
このポリシーは、メンテナンスに含まれるものは何か、どのようにメンテナンスが行われるか、問題が生じた際には誰に連絡すべきか、という組織のメンテナンス基準を概説し、メンテナンス問題発生の対処方法をエンドユーザーに通知する。

 ベンダーコミュニケーションポリシー
ベンダーコミュニケーションポリシーは、ベンダーとのやりとりにおける役割と責務を定義する。具体的には、組織でベンダーとやりとりを許される者がだれで、何をベンダーと協議する権限が与えられているのか、説明する。

 インターネットや他の電子コミュニケーション設備の使用
このポリシーは、組織内でのエンドユーザーによるインターネット使用を決定する。また、ユーザーがアクセスできるサイト、チャットルーム、ショッピングカートや、認められるその他の個人的な使用を規定する。E メールも、このポリシーで規定される。

 外部監査の要求への対応
このポリシーは、外部監査について「何を」「いつ」「誰が」「どのように」対応するのかを概説する。
このポリシーは、監査対応の資格を有し訓練を受けた者（監査対応チーム）に対する対応の統制を制限するため、監査の際にきわめて重要である。

 違法ソフトウェアの排除
このポリシーは、基準を満たさないソフトウェア製品や合法的に購入したことが証明できないソフトウェア製品を排除するという組織の権限について、ユーザーを教育する。

 内部監査
内部監査ポリシーは、内部監査の目的、プロセス、担当者の権限について従業員を教育する。

 損失防止
このポリシーは、組織内のあらゆる損失に関するプロセスを概説する。このポリシーは、また、ハードウェアとソフトウェアが「いかにして」「どこで」「いつ」「誰によって」使用され、組織外に持ち出されるかを、規定する。

 資産廃棄
このポリシーは、「どのように」「いつ」「誰によって」資産が廃棄されるのかを概説する。このポリ
シーは、さらに、廃棄プロセスの際の情報セキュリティを規定する。また、文書要件と組織全体での文書の流れについても概説する。

 在宅勤務ポリシー
このポリシーは、組織のソフトウェアIT 資産とハードウェア IT 資産を使っての在宅勤務を従業員に認める、あるいは要求する、「在宅勤務規定」をカバーする。このポリシーは、ロードできるソフトウェアと認められるハードウェアの変更を明確に規定し、そのような変更を要求、承認、報告する権限を明確に設定すべきである。

 データ管理、バックアップと リカバリー
このポリシーは、エンドユーザーによるデータ管理、バックアップとリカバリーの要件を概説する。このポリシーは、「どのように」「どのくらいの頻度で」「どこに」データをバックアップするのかを規
定し、データのリカバリーが必要な際の措置についてエンドユーザーに説明すべきである。

 リムーバブルストレージデバイスの使用に関するポリシー
このポリシーは、組織内外のリムーバブルストレージデバイスの利用を規定する。このポリシーは、 エンドユーザー向けの情報セキュリティと損失防止情報を含むべきである。

 ポリシーの通知と受諾
これは、エンドユーザーへの新しいポリシーの通知、エンドユーザーによる新しいポリシーの受諾、既存ポリシーのレビューを概説する。

 ベンダー管理 – 交渉ポリシー
このポリシーは、「誰が」「どこで」「いつ」「何を」「どのように」交渉プロセスを執行するのかな
ど、組織の交渉基準を概説する。

 試用ソフトウェア、プロモーションソフトウェアおよび寄贈ソフトウェアの使用
このポリシーは、「無料」ソフトウェアの組織内への導入方法と「無料」ソフトウェアの排除基準を規定する。また、エンドユーザーがアクセスして組織の機器にロードできる修正ソフトウェアについても、規定する。

 貸与機器ポリシー
このポリシーは、「いつ」「どこで」「どのように」「いかなる状況において」貸与機器の使用が認め
られるのか、規定する。

 文書管理保存ポリシー
このポリシーは、保存基準、文書の保存方法と保存場所、全てのIT 資産文書の取り扱いのフロー図など、IT 資産文書の保存を規定し、文書の検索を概説する。

 ワイヤレスデバイス ポリシー
このポリシーは、組織の内外で「誰が」「いつ」「どこで」ワイヤレスデバイスを使用すべきかについて、またそのようなデバイスのセキュリティを概説する。

 情報のプライバシー
このポリシーは、組織の機器のプライバシー保護を概説する。組織は、このポリシーを活用して、所有機器への完全なアクセスを担保し、プライバシーを設定しない。このポリシーは、インターネット使用のプライバシー、遠隔からのプライバシー、プライバシー監査権も規定する場合がある。

目標1:必要なIT資産管理ポリシー が効果的に実装される
既存ガイドラインおよび今後実装される全てのポリシーについて、
● 従業員が自らの責任を理解する（ライフサイクルプロセスに関係するステークホルダーが識別され、当該ステークホルダーの役割と責任が体制において明確に明文化する）
● これらが、なぜ組織にメリットをもたらすものであるのかを、従業員が理解する（ポリシーの「何を」するべきかだけではなく、「なぜ」それをすべきなのかを明確に明文化する）
● ポリシーが可視化される（ステークホルダーが明確に自らの役割と責任を理解し、執行する）
ことが必須である。
何が期待されているのかを全面的に知ることで、
● 従業員は自らの違反行為を最小限にとどめることができる。
● 従業員は、他者のポリシー違反を認識できる。
● 従業員は、ポリシーの違反の報告・対処方法を理解する。

目標2:ポリシーが執行される
ポリシーは、命令系統を通じて執行されなければならないが、その際、
● 組織全体を通じて一律に
● 一貫し目に見える形でコンプライアンス違反に対応し、明確な記録を残す
ことが重要である。
全てのポリシーを執行することで、
● コンプライアンス違反のリスクを低減する。
● コンプライアンス違反事項について、また他の法的状況における組織の立場が強化される。
● 組織も個々の従業員も守られる。

目標3: ポリシーが、定期的にレビューされ更新される
目的があってポリシーが策定されるように、ポリシー更新も、常に、不可避である。良く練られたポリシーが廃棄されることはほとんどないが、ポリシーを修正して組織のニーズに合わせることが時として必要となる。特に、ポリシーが現場の状況を正確に捉えられずに、執行不可能なポリシーが明らかになった場合は、迅速な更新が求められる。それぞれのポリシー更新は、特定の理由によって実施される。ポリシー更新のニーズとして、以下が挙げられる。すなわち：
● 業界の動向と変化を反映する
● 技術進歩と法規制改正への対応
● 組織環境の変化への対応
ポリシー更新は、組織の全体的な改善につながると理解されている。それぞれの更新は、関連プロセスの一部の機能に特定の影響をもたらす。IT管理チームにとって、ポリシー更新とは、
● 新しいコンプライアンス要因のより良い理解と、それによるコンプライアンス違反のリスクの更なる削減と、ほぼ同意語である。

ソフトウェア資産管理を効率的、効果的にソフトウェアライセンス最適化ツール用いてベースラインを作成するための４つのステップ

メーカー監査への対応

・メーカー監査のために各ソフトウェアメーカー毎に対応するのはコスト高になる。

ソフトウェアのメーカーとの契約条件により測定項目（管理が必要となる情報）が異なるため、メーカー監査の対応を行うと結果として当該メーカーのためだけにソフトウェア資産の棚卸作業となる。その結果、メーカー監査が来るたびに同じような作業を繰り返し行うこととなりコスト高な作業となる。対象となるソフトウェア製品の優先順位に基づき、当該ライセンス契約書と使用許諾条件から管理メトリックを識別し、それぞれのメーカー毎、製品毎の管理メトリックを管理するための統合的なライフサイクル管理プロセスが求められる。

１）保有情報の収集と管理

・購入ライセンス（責任：財務部門、購買、部門購買）

まず一番最初にすべきは、組織で既に購入済のソフトウェアライセンス資産の棚卸だ。購入が会社として行われているか、部門で行われているかに関わらず、すべての購入済みのソフトウェアライセンスの情報を収集しリスト化する。

メーカー毎、製品毎、そしてバージョンアップ版であれば、そのオリジナルに辿れるすべてのバージョンアップの支払履歴情報を収集する。（現時点での使用ライセンスがバージョンアップ版の場合、オリジナルの購入証明まで遡って情報を要求される。オリジナルの正規版からバージョンアップ規程に則って現在使用中のバージョンアップ版までの履歴が辿れない場合、オリジナルの正規版を新たに購入させられる場合がある）競合（コンペティティブ）アップグレードキャンペーンなどを利用した場合は、対象となる競合製品のライセンスまで辿る必要がある場合もあるので注意が必要。

EA（包括契約）やボリュームライセンス、パッケージ、OEM版などの種別毎に分別し、過去に購入、支払済みのソフトウェアライセンスの全ての情報を網羅するリストを作成する。

・ライセンス契約書

購入済のライセンスの契約書の棚卸。購入ライセンスのライセンス契約書をすべて集め、保管庫で管理する。デジタル版の場合はデジタル版を保存、またはオンラインであればオンラインのアクセス情報を保存。

・EULA（使用許諾契約書）

それぞれのソフトウェアにはEULA（End User License Agreement: 使用許諾契約書）が付属する。ライセンス契約書またはEULA に定められたライセンスの使用条件を洗い出し、それぞれのライセンスの運用状況を監視するための測定項目を策定するための情報として管理する。

例：デバイスライセンス、ユーザーライセンス、キャパシティライセンス。具体的な条件をリスト化し、測定項目の策定情報とする。

・購入証明

支払った請求書の情報または支払の日付や口座情報などから、それぞれのメーカー毎に必要とされる購入証明に必要な情報。（組織の規模、成熟度およびメーカーとの関係により必要性の度合いが異なる。2012年現在で厳しく追及されるケースは少ない。多くの場合、メーカー監査ではユーザーの購入情報を基に監査活動を行っているため。）

・デバイスライセンス管理に必要なデバイス資産管理

デバイスライセンスはデバイスに割り当てられるために、割り当てられるデバイスを管理する必要がある。（デスクトップパソコン、ノートパソコンなど）

・ユーザーライセンス管理に必要なデバイスのユーザー管理、ユーザーのアクセス権管理

ユーザーライセンスはユーザーに割り当てられるために、割り当てられるユーザーとユーザーが使用するデバイスを管理する必要がある。

２）インストール（配置・デプロイ）の現状の把握（インベントリ情報の収集）

・オン ネットワーク

ネットワークに接続されたデバイスにインストールされているソフトウェアであれば、インベントリ収集ツールを使用してインストール情報を収集する。

・オフ ネットワーク

ネットワークに接続されていないデバイスにインストールされているソフトウェアであれば、手動でインベントリ収集ツールをローカルで使用し、インストール情報を収集する。

・デバイスライセンス

デバイスライセンスであれば、割り当てられたデバイスおよびデバイスの使用者（ユーザー）とロケーション（使用場所）を特定する情報が必要となる。（但し、EULA などで特定の条件の指定があれば EULAに則る）

・ユーザーライセンス

ユーザーライセンスであれば、割り当てられたユーザーおよびユーザーが使用するデバイスとロケーション（使用場所）を特定する情報が必要となる。（但し、EULA などで特定の条件の指定があれば EULAに則る）

・データー クレンジング（スクラビング）

インベントリ情報をインベントリツールを使用して収集した場合で、インベントリ情報が集約されていない場合は、データークレンジングが必要となる。

インベントリ情報を特定するためのデバイスの特定には、資産管理番号（論理的一意識別子）や個体を識別するための個体の物理的一意識別子（MACアドレスやシリアル番号）などで個体を特定し、デバイス個体ごとのソフトウェアインベントリ情報を集約し、最新のソフトウェアインストール状況を把握する。この場合、ソフトウェアによっては、「ソフトウェアの追加と削除」で取得できる情報で十分な場合もあるが、特定のレジストリキーにあるシリアル番号が必要となる場合もあるため、EULA やメーカーに確認し、ベースラインの策定や内部ライセンス監査報告書に必要な項目を確認する必要がある。

３）保有情報（資産“正”台帳）と、インベントリ（現状）の突合および整合化

ベースラインを確定する前の作業として、保有情報とインベントリ情報の突合がある。保有情報として把握しているライセンスと、実際に現場にインストールされ使用されているソフトウェアの情報を突合し、そこに齟齬がないかどうかを確認する。保有情報には存在しないが、インストールされているソフトウェアや、保有情報に存在するが、実際にインストールされていないソフトウェアなどの存在を確認する。

・保有情報に存在しないが、インストールされている

なぜ、保有情報に存在しないが、インベントリ収集で情報があがってきたのか？本当にインストールされていて、使用されているのかを確認する。

インストールされて使用されているのが確認された場合、本当に購入していないのに使用しているのかどうかを確認する。

インストールされ、使用されているが、購入されていない場合、本当に必要かどうかを確認し、必要であれば購入する。誤ってインストールされたのであれば、アンインストールする。

・保有情報に存在するが、実際にインストールされていない

なぜ、購入したのにインストールされていないのか？本当にインストールされず、使用されていないのかを確認する。

購入した経緯を確認し、現時点で使用を希望している人や部門がないかを確認する。

本当に現時点での使用者がいない場合は、使用を希望している人や部門へ割り当てて問題ないかを確認の上、割り当てし配置する。

４）ベースラインの確定

保有情報とインベントリの整合性が取れた情報を最初のベースラインとしたいところだが、必ずしも最初から100% の整合性を確保できるわけではない。できる限り100% の整合性を目指し、維持・改善を継続的に活動に盛り込み、高い整合性を確保できるように継続的改善計画の活動を実施する。

最初のベースラインとして、ある程度満足できるレベルまで突合・整合化が進めば、その情報をベースラインとして管理の自動化ツールへインポートする。

管理の自動化テクノロジー

・エンタイトルメント：ライセンスの紐付

IT資産管理レポジトリ

資産台帳としてデバイス資産およびソフトウェア資産の情報を管理する。

デバイス管理項目として論理的一意識別子や物理的一意識別子、スペックなど、ソフトウェアの管理項目としては、ライセンス数、ライセンス契約の内容（使用条件）、EULA（使用許諾契約書に定められた使用条件）、ライセンスキー、ライセンス証書、メディア、ビルドなどデジタルファイルの保存場所などがあげられる。

属性情報として、デバイスに関わる様々な契約（レンタル・リース契約、保守契約など）、マニュアルなど関係文書など、どこまでの範囲を管理対象とするかを定義しIT資産管理レポジトリで管理する。

組織によっては、目標としてサービスモデル実現のためのサービスマネジメントシステムとの連携・統合を念頭に置いている場合は、構成管理データベース（CMDB）や 構成管理システム（CMS）とのインターフェースを考慮する。

インベントリツール

インベントリツールで注意すべきは、使用条件に基づいた運用状態を確認するに十分な情報をデバイスを特定し、あるいはユーザーを特定した情報として収集し、IT資産管理レポジトリにある保有情報との突合を自動化することが可能な機能を提供しているか否かだ。

多くのツールは「できる」と謳っているが、デフォルトの設定では不可能で、測定項目を理解した上で対象となる情報を指定し、収集する設定が必要となることに十分に注意する。