さて、第4回は、組織横断的なIT資産管理プロセスの設計について解説します。

目次

まとめ

組織が大きくなると役割と責任が分化し、あちこちで資産に関係する情報を管理することになります。マスター契約、ライセンス契約、保守契約、発注情報、ライセンスの割り当て、システム、システムインベントリ情報など社内から社外のアウトソースパートナーを含めて必要な情報を統合し効率的な管理を設計するにはBPR（ビジネスプロセスリエンジニアリング）に近い作業が求められます。ステークホルダーに説明し、理解を得るためにも自社の企業戦略、IT戦略、情報システム規程などのポリシーに則ったIT資産管理の将来像（ToBeモデル）を共有し、理解を得ながらIT資産管理業務プロセスの改革を進めるための実現可能性の高い Nextモデルを設計する必要があります。

まずは、ToBeモデルですが、これはISO 19770-1 （図１）というソフトウェア資産管理（SAM）の国際的な標準がありますので、こちらを利用すると良いでしょう。ここで重要なのは、独立したIT資産管理のマネジメントシステムではないということを理解することです。

ISO 19770-1 ：ソフトウェア資産管理（SAM）プロセス（図１）

そもそもISO 19770-1 はITIL の Guide to Software Asset Management という別冊からBritish Standard （英国標準）を経て ISO 国際標準へとなりました。（図２）ITIL を補完する内容になっており、インシデント、問題、変更、リリース、展開プロセスはITILのプロセスにITAM/SAM の考慮を追加する形をとるべきです。

（図２）

ISO 19770-1 を参照し、すべてのプロセスのポイントを考慮するべきではありますが、そう簡単にすべてを理解し、取り組み、適用成熟度を高くすることは困難なため、優先順位により段階的に取り組む必要がでてきます。

優先順位を理解するためには、ISO 19770-1 のプロセスで、資産のコントロールという部分に特化したプロセスを理解することが大切です。

運用チームにとって優先順位の高い資産コントロールに関係するプロセスは、以下の７プロセスです。

• ① 取得プロセス
• ② 資産識別
• ③ 在庫管理
• ④ 資産管理
• ⑤ 資産記録の検証
• ⑥ 使用許諾条件の順守
• ⑦ 適合性検証

資産を取得する際には、事前に標準化などが行われ、標準資産をマスター化（後にサービスカタログとなる）して管理し、資産を識別するために、関係する契約などを紐づけて、資産を運用する際に必要となる条件を管理することが求められるため、これら関係する契約書情報の契約条件などをCI（構成アイテム）として識別し、ライセンス資産との関係性を管理することが必要となります。

すでにお気づきの方もいらっしゃると思いますが、そうです、IT資産管理の基本的な考え方はITIL の構成管理なのです。

ITIL を学んだ方は構成管理（SACM：Service Asset and Configuration Management）はどこかで聞かれたことがあると思いますが。残念ながらITIL では数ページしか取り扱われておらず、主にCMS（構成管理システム）のアーキテクチャの解説にとどまっています。ITIL別冊のGuide to Software Asset Management では、この分野を詳しくソフトウェア資産の調達から廃棄にいたるライフサイクル全般を捉えて解説していますが、残念なことに英語版しか存在していません。欧米でも構成管理を成熟させる取り組みは非常に苦労を伴い年月がかかると、過去の経験から学び、構成管理の成熟度をあげるためにITAM/SAM の取り組みの重要性の理解がひろまりました。そして、その最も大きな原因となっているのが、プロセスのサイロ化の要因である多岐にわたるステークホルダー(図3)の存在なのです。

「隣は何をする人ぞ」役割や責任が細分化され、誰が何をしているのかが良くわからない。思い当りますか？

多岐にわたるステークホルダー（図３）

例えば、OracleDB の導入を例に考えてみましょう。システム要件からOracleDBが必要となった場合、システムのプロジェクトチームは共通基盤を考慮し、インフラチームと連携して環境に必要なソフトウェアをリクエストします。この際に調達（およびVMO：Vendor Management Officeが存在すればともに）と、システム構築に必要なライセンスを取得します。この段階では運用チームは関与していません。実際に運用フェーズに入り、ユーザーの要件により運用環境を変更する場合は、運用チームとインフラチームなどが変更管理に取り組みますが、この変更管理の考慮に「性能」というポイントは重要視されていますが、BIA（ビジネス影響分析）の項目としてライセンス コンプライアンスという考慮が欠落している場合が多くあります。そもそも、OracleDB を導入する際に、ライセンスのTerms&Conditions に則った運用を担保するための契約順守メトリクスの監視が設計されていない場合が多く、環境構築が済んだ後で運用チームに「ライセンスの管理もしてくれ」と依頼をしても、「サーバーのメトリクス監視に必要となるエージェントを各VMにデプロイしないと不可能です」ということになります。欧米でも構成管理への取り組み当初はOracleの技術担当者に構成管理情報の更新という役割を当てましたが、Oracle技術担当者は「性能」の優先順位が高いために、構成管理情報の更新が滞り、数か月のタイムラグが発生し、情報の鮮度や精度が維持されない状態となりました。これらのことから、IT資産管理チームにより、標準化、契約交渉、取得（在庫割り当てから新規購買）、実装（ライセンス割り当て）、変更管理（BIA、ライセンス回収・再割り当て）と対象となる資産のライフサイクルを通じて関与し、契約順守に必要となる管理メトリクスを契約交渉の段階から考慮・設計し、運用環境を構築するというIT資産管理の取り組みへと変化したのです。

ToBeモデルでは全体最適化を目標とする組織横断的なプロセスの結果として「構成管理」の実現や、サービスカタログ、コンプライアンスの維持、ソフトウェアライセンス最適化などが可能となります。現時点でのプロセスをたな卸しし、すべてのステークホルダーが関係するプロセスを識別し、発生する情報がどこで、どんなタイミングで発生するのかを把握し、その情報がどのように管理され、あるいは、運用管理のメトリクスとして監視され、レポートされるべきなのかを計画されなければなりません。

そして、ToBeモデルとAsIs（現状）とのギャップを把握し、実現可能性の高いNextモデルを設計します。

（図４）調達プロセス：標準ソフトウェア

例えば、今日の環境においてインフラの実際の運用がアウトソースされている場合もあるでしょう。この場合は、アウトソースしているサービス（SLA：サービスレベル合意書）の定義において、必要十分な管理メトリクスを提供してもらえるような考慮と交渉が不可欠となります。あるいは、対象となる仮想環境がVMWare で構築されたプライベートクラウドで、実際はホステッド プライベートクラウドというアウトソーシングを利用している場合なども、前述の情報や VMWare との連携によりVMに割り当てられているリソース情報などをニアリアルタイムで取得する必要もでてきます。この場合に、共通基盤となるインフラがすでに構築済みで、SLAの改変は次期の共通基盤を定義するタイミングだとなると、既に3-5年先を計画しなければ効率的な管理の自動化に必要なデータすら入手ができない環境といえるのです。

パブリッククラウドを利用している場合も、OracleやIBMなどサーバーソフトウェアのベンダーが「認定」しているパブリッククラウドベンダー（AWS、Azureなど）であれば、まだ、ライセンス消費の計算方法が提供されている場合もありますが、これらの「認定」対象外となると、ほぼ自社環境と同じ管理が必要となります。つまり、パブリッククラウドであっても、VMが存在するサーバーの最大キャパシティや、インフラ全体（VMWare6.0/vCenter6.0で仮想化の場合など）のキャパシティがライセンスの消費量を決定する要素となるのです。

まとめ

どこまでの管理プロセスが必要となるのかは、自社が契約している契約書のライセンス条件次第です。ライセンスの契約自体をインフラ運用ベンダーに転嫁してしまえば、自社の責任を免れることができますが、ライセンスを自社で契約し、アウトソーシングしているインフラ上で運用するのであれば、ライセンスの責任は自社で負うこととなり、契約条件に適した運用管理計画が必須となります。

重要なのは、「運用チームの努力だけではどうにもならない」というポイントを、IT開発部を含む全てのステークホルダーに理解を得ること。そして、責任ある立場の経営層が理解し、支援することです。

「IT資産の管理ぐらい簡単だろ。うちはやってるだろう？調達が管理してるだろ？」 という経営層の理解の欠如が、今日の日本のIT資産管理の遅れの大きな原因となっていることを、今こそ気づくべきなのです。

IT環境がますます複雑化している今日、IT資産のコントロールはデジタルビジネス時代のIT部のケイパビリティとして、市場の変化により変化するユーザーニーズに対応する俊敏なITサービスを実現するための構成管理の成熟のため、そして、ガバナンスやリスクコントロールの源泉として最重要課題であると認識を改める時なのです。

次回は、
第５回「設計したIT資産管理プロセスを自動化するための自動化要件を定義する」

運用管理ツールというとやってしまいがちな失敗が、 「とりあえず5-7社ぐらいツールベンダー呼んで説明聞いてみろ」 という上司のアドバイスを聞いてしまうことです。

IT資産管理の場合、これは失敗のもと。繰り返し失敗してしまう大きな原因がここにあります。IT資産管理はIT部が中心となる組織横断的な「業務」なのです。IT運用部が主管となり組織をまたがる「業務プロセス改善」の結果を自動化するという考えからスタートしなければ、取り組みは失敗を繰り返すことになります。さらに、ますます複雑化するIT環境を効果的、効率的に「構成管理」するために実施するべき「IT資産管理」なので、将来的に一つのマネジメントシステムとなるパスを考慮したロードマップを描いておかなければ、管理システムを拡張できない短命のものとしてしまいます。ITIL のCMS（構成管理システム）、CMDB（構成管理DB）、サービスカタログを考慮したIT資産管理システムの要件について解説します。