さて、第3回はデバイスライセンス、ユーザーライセンス、同時ライセンス、フルキャパシティ/サブキャパシティライセンスの管理ポイント、マスター契約と子契約、保守契約の関係性を管理してグローバル契約統合によるメリットを享受するための取り組み方を詳しく解説します。

目次

OMA（Oracle Master Agreement）

まとめ

自社のIT環境で運用されているIT資産を管理しようとしても、どのような契約なのかがわからなければ管理メトリクスさえわかりませんので、どこからどこまでの情報を管理するべきなのかすらわかりません。というわけで、まず管理対象となる資産に関係するすべての契約書を棚卸しして、契約書で定義される諸条件を理解し、管理メトリクスを把握することから着手します。

ところが、IT資産管理の役割を任命された担当者は、ここで最初の難関に直面します。

「誰が契約書を持っていて、理解して運用しているのだろう？」

ひょっとするとOracle担当者に「契約書を提供してください。契約書の条件はなんですか？」と問い合わせても「契約書なんかない」という回答が返ってくる可能性があります。

一般的にインフラ系の技術担当者の責任範囲は「性能」に限定されている場合が多く、契約については調達やVMO（Vendor Management Office）または開発系のシステムプロジェクトチームと調達により導入時に契約が管理されています。 例えば、Oracle の場合は、以下のようなMaster Agreement があり、第2回で説明したライセンスカウント方法を解説する価格表と、サブキャパシティであれば Core Factor Table などを組み合わせシステムに必要となるライセンス消費を計算して、ライセンスの割り当てを管理する必要があります。

OMA（Oracle Master Agreement）

（以下、OMAから抜粋） 第１０条（定義及び規則(ライセンス定義)） お客様に許諾された使用権を完全に理解するために、お客様は以下に掲載されている価格単位（License Metrics）の定義、期間指定ライセンス及びライセンス規則を閲読する必要があります

前掲の契約書は33ページありすべての内容を理解することは非常に困難です。それでも、契約書に署名、押印してしまうと当然ながら契約順守の義務が発生します。契約を交渉する段階から内容を把握し、管理計画を立てておかないと運用開始してから管理メトリクスを洗い出し契約で規定されている報告義務に従い、ライセンス消費を管理し、消費量に応じた報告や追加の発注をして契約を順守することはとても難しいのです。契約書内の法的文言は社内の法務チームと、技術的内容は技術担当者をチームに迎え、内容を理解し、管理メトリクスを定義し、管理プロセスを実装し、そのプロセスを自動化するというアプローチが無ければ、契約順守は不可能なのです。

管理するうえで、ここで重要なのは、まずは、親契約となる Master Agreementや、Microsoft社であれば MPSA （Microsoft Products and Services Agreement）を把握し、その親契約をもとに契約される保守契約やライセンス契約を子契約として、紐づけて関係性を管理することです。ベースライン構築の基礎部分となりますので、これができないと精度の高い管理基盤を構築することが不可能となります。

最近のトレンドとしては、ソフトウェアベンダーにとっても契約統合は顧客管理のコスト削減や来年度予算の見える化などのメリットとなっており、クラウド環境も拍車をかける形で顧客との距離が短くなったことでベンダー自身が契約統合を推進しています。MPSAなどもグローバル契約統合の親契約としての機能を持っており、MPSA に全ての契約を紐づけることで１顧客が複数のグループ企業で構成され世界各地に分散していても、統合された契約によるディスカウントのメリットや、ソフトウェアベンダーがサービスプロバイダとして顧客に提供するサービスレベル向上を図るため、あるいは、顧客ユーザー側にとっての契約交渉力の向上を可能としています。

さらに、契約書に記載されている条件を理解し、適用する環境が当該条件を順守しているのかを判断する必要があります。

（以下、OMAから抜粋） お客様は次の制限に違反しないことを保証する責任を負うものとします： 1. Oracle Database Standard Edition 2は、最大搭載可能プロセッサ数が2ソケットのサーバーに対してのみ、使用権許諾されます。Oracle Real Application Clustersと共に使用する場合、Oracle Database Standard Edition 2は、最大で2台の1ソケットサーバーに対してのみ、使用権許諾されます。さらに、お客様のOracleライセンス契約のいかなる条項にも関わらず、各Oracle Database Standard Edition 2データベースは、常時最大16CPUスレッドを使用することができます。Oracle Real Application Clustersと共に使用する場合、各Oracle Database Standard Edition 2データベースは、常時1インスタンスあたり最大8CPUスレッドを使用することができます。お客様がNamed User Plus（NUP）ライセンスを注文する場合、お客様は、サーバー毎に最少でも10NUPを維持する必要があります。

前述の条件は稼働環境の物理的な制約を定義しています。最大搭載可能プロセッサ数が2ソケットとなっていますので、例えば１６ソケットのサーバー上で仮想環境を構築し、「１CPUしか使っていないから大丈夫だろう」は物理的な制約に違反していることになりライセンス違反となります。これはデータベース製品に限られた条件ではなく、様々なサーバーソフトウェア製品に適用されている条件ですので、十分に使用環境とライセンス条件を理解しておかないと全てのシステムでライセンスを割り当てている物理サーバーの全ソケット数に対して課金されますので十分な注意が求められます。

このように、契約書の諸条件をしっかりと理解し、運用する環境を把握し、ライセンスの消費計算ができるような仕組みを構築していくことが不可欠ですので、ライセンス契約のレビューはとても重要な作業なのです。できる限り工数を削減するためには、契約を統合し、一本化し、ライセンスの条件をまとめて管理ができるようにしましょう。 もちろん、これらの複雑な管理はCMDBやライセンス管理に特化したSLO（Software License Optimization）ツールなどに親契約と子契約の関係性管理機能、子契約と保守契約、さらに発注情報（SKU：流通型番）からライセンス資産を生成して、ライセンスの管理メトリクスをライブラリ化し参照して自動化するツールが市場にはでてきていますので、これらを利用して人的工数を削減し、効率的な管理プロセスの自動化を計画しましょう。

自動化ツールの検討の注意点： 汎用CMDB と SLO（Software License Optimization） ツールの守備範囲に注意！ 双方とも環境にあるCI（構成アイテム）を管理します。双方ともCMS（構成管理システム）を構成する１CMDB です。違いは、SLO が商用ソフトウェアライセンスに特化し、ソフトウェア名の名寄せライブラリ、SKU（Stock Keeping Unit）ライブラリ、PUR（製品使用権：ライセンス利用規約条件）ライブラリなどを提供していることです。CMDBでサーバーのハードウェア構成や開発ソフトウェアの構成管理は可能ですが、ライセンス契約や利用規約をメトリクス化して自動化するとなると、相当なカスタマイズが必要となり塩漬けされることも少なくありません。用途に応じて自動化要件を定義し、CMDBとSLOを連携させ、データ統合が可能なCMSの設計が必要となります。

次に、クライアントPCのソフトウェアによくあるデバイスライセンスとユーザーライセンスですが、これらも以下の注意が必要です。

• ① デバイスライセンス：
  　・ライセンスされたソフトウェアのバージョンとエディション
  　・一次使用権と二次使用権
• ② ユーザーライセンス：
  　・ユーザーライセンスが付与される対象OS
  　・１ユーザーライセンスで使用可能な最大デバイス数と利用可能OS

基本的にデバイスライセンスを運用する場合は、ライセンスの割り当てがデバイスに、ユーザーライセンスを運用する場合は、割り当てがユーザーにされなければなりません。さらに、デバイスライセンスで二次使用権がある場合は、２つのデバイスが一人のユーザーに紐づいて、1ユーザーにより２デバイスで一次と二次使用権を消費していることが管理されなければなりません。ユーザーライセンスであれば、ユーザーに割り当てした1ライセンスが、例えば５デバイスのWindows上でライセンスが付与されているのであれば、ユーザーが使用している５デバイスが紐づいて1ライセンスの消費として管理できなければなりません。

デバイスライセンスの運用例としては、例えば１PCを共有パソコンとして5ユーザーが使用する場合であれば、５ユーザーライセンスを割り当てて運用するよりも、１デバイスライセンスを割り当てて、使用者が5名であるという管理をした方がコストを削減できます。

また、ユーザーサブスクリプションライセンスのような期間が限られているものに対しては、ライセンスの期間を管理し、更新作業を円滑に行えるような考慮が必要となります。

最後にSAPのようなユーザーの利用形態や利用ボリュームにより異なるユーザー使用量ライセンスについてです。SAPのようなユーザー使用量モデルのライセンスは、しっかりとユーザーの定義を理解し、どのようにユーザーの使用量を特定し最適化できるのかを把握することが重要です。多くの場合、ユーザーのアクティビティにより定義され、アクセスボリュームでライセンス料が異なります。これらを管理項目としてどのように管理し、最適化を図るのかを計画することが重要です。SAPの場合は、LAW を使用して状態を把握することができますが、すべてのデータを人的に分析することは多くの人的工数を消費します。これらのデータを処理し、分析結果を提示し、推奨構成などを提示してくれるSLOツールなどが増えているようですので、そういったツールも検討対象として計画しましょう。

ライセンス契約のレビューから理解できるように、今日の仮想化、クラウド化による複雑なIT環境に対応してライセンス体系は複雑になっています。関係するステークホルダーも調達、法務、開発プロジェクトチーム、VMO、インフラチームと多様で、これら関係者をまたぐ組織横断的なプロセスが管理に求められるようになっています。ソフトウェアの導入は、これらの管理プロセスの構築や管理プロセスの自動化、契約の順守に必要となるコストを含めて TCOやROI が検討されるべきでしょう。規模によっては管理コストを考慮した場合、製品を乗り換える方が将来的にコストを抑制することが可能な場合もあるかもしれません。本当にここまで複雑な管理をしてでもその製品が必要なのか？それとも、他社製品に乗り換えた方が全体コストを抑制し最適化を図ることが可能となるのか？そのような意思決定を可能とするためにも、現時点での契約をレビューし、管理工数などを含めたTCO、ROI を試算して検討することが重要です。

まとめ

最初にするべきことは、誰がどの契約を持っているのか、そして、どのような契約条件の契約があるのかを把握することです。さらに、契約に関係するサーバー環境の情報はだれが持っているのか、契約のライセンスとサーバー環境の情報から現在の契約条件の順守状態がわかるのかを把握することです。しかし、それを行おうとすると組織に分散するステークホルダーから必要な情報を収集して集約し、関係性をマッピングするというベースライン構築の作業へと入っていきます。管理のためのベースラインを構築するために乗り越えなければならない組織の壁が立ちはだかります。

次回は、
第4回「組織に分散するステークホルダーを横断的に把握しIT資産管理プロセスを設計する」

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