1年～5年 の ULA 契約は、そもそも期間満了で終了する想定の契約だった
Oracle の契約は OMA（Oracle Master Agreement）/TOMA（Transactional Oracle Master Agreement） から Online TOMA へと変化し、Ordering Document で定義される ULA（Unlimited License Agreement）で利益を享受できるユーザーとそうでないユーザーの差は大きくなる一方です。
「なんだか損している気がする・・・」と思われている組織の問題は、「交渉力が不足している」ということにつきます。
しかも、自ら求めるわけではなくULA を持つ組織にとって、「満期の際に終了してコスト削減はできないのか？」という疑問がULA契約期間中、ずーっと、もやもやとわだかまった状態のユーザーが増えているようです。
そんな皆さまに朗報です。そもそも ULA は満期で終了するのがデザインです！
では、なぜ終了できない組織が多いのか？
実は問題は、なぜ、ULA になったのか？にあるのです。
Oracle ライセンスの契約や使用許諾条件を理解していない、あるいは、その使用許諾条件の解釈を理解していない組織において、Soft-partitioning の仮想環境、共有ストレージ、スタンダード版における OEM（Oracle Enterprise Manager）の エンタープライズ版 有償オプションの無意識での利用は、コンプライアンス違反の致命傷です。これらの場合において ULA によってコンプライアンス違反で発生する違約金や遡及（そきゅう）など含めた監査補正請求に対する「猶予期間」を買う、というのが昨今の実際の適用なのです。（Oracle営業さんにそのような説明を受けた方も少なくないのでは？）もちろん、ULA を望むユーザーにとっては、これから数年間にわたって20％以上のデプロイメントの増加が見込めるので、ULA で交渉して満了時に必要なパーペチュアルライセンスを持って終了し、通常の保守契約に戻すのであればユーザーにとっての利益となります。
しかし、残念ながら多くの組織が「猶予期間」を買うために ULA を余儀なくされています。しかも、本当に必要なライセンスボリュームをよく理解しないままさらに、ライセンスの運用状態が理解できていない状態が継続され、満期でULAを終了できずにULAを更新し続けるケースが多いのです。そして、その原因は、そもそものULA を余儀なくされた原因と全く同じである、「コンプライアンス違反」なのです。
そして、なぜコンプライアンス違反になりULAを終了できないのか？ の理由は、至って単純で、「使用許諾条件とその解釈を理解できていない」という理由にほかならないのです。

包括契約、Unlimited は「無制限」という意味ではない！
ULA には様々な制限があり、これらを交渉して解除や必要な定義をしておかないと、永遠にコンプライアンス違反の呪縛から逃れることはできません。

① 使用国：日本
本当に日本だけでいいのですか？パブリッククラウドでバックアップのため２ndリージョンを使いませんか？グローバル組織で他国からの利用はありませんか？拡大する予定はありませんか？
② 使用許諾組織：ライセンシーとサブライセンシーの定義
交渉して定義しておかないと、購入者として登録された組織の社内利用でしか利用できません。
③ Unlimited の対象製品
どの製品がUnlimited なのかを把握して運用していますか？対象製品は仮想環境での消費や、共有ストレージ、承認されたパブリッククラウドなどで利用されますか？
④ オプション：OEM （Oracle Enterprise Manager）は無償だと思い込んでいませんか？

IT部門は契約書に弱い
そもそもITテクノロジーの専門家であるエンジニアは、契約や法律の専門家ではありません。
使用許諾条件が付されたライセンス製品を組織の契約により異なる条件を管理して運用することは、非常に困難なタスクなのです。
複雑化したIT環境に対応したOracleライセンス契約書などはライセンスベンダーの中でも最も複雑です。
エディションの違い、オプションの条件、仮想化（物理/論理）、クラウド（パブリック/プライベート）、本番/開発/テスト/DR 環境の違い、ライセンスモデルなどの要素から、前述の使用許諾組織の範囲、ホスティングライセンス、自社アプリケーションホスティング登録、などなど、専門的な知識が要求されます。
しかし、これらの情報を把握し専門的知識をもとに解釈や判断ができれば、ULA を終了することは難しいことではないのです。そもそもが満期で終了するデザインなのですから。

ULA 終了の準備ステップ
① 現状のライセンス利用状況を正確に把握する
ライセンス違反やULA を違反している項目があると、3年後に遡及（そきゅう）の対象となり終了するためには莫大（ばくだい）な監査補正請求書の支払いが求められます。デジャブですか？
ULA の契約条件を正しく理解し、遵守状態を構築します。→ これができていない組織が多いのです。これが終了できない最大の原因です！
そもそもライセンスの消費状態を正確に把握するのはライセンス契約書をもつビジネス組織としてあたりまえのコンプライアンス確認の行為です。代理店やパートナーがやってくれない！というのは言い訳になりません。ガバナンスは自らがコントロールしなければならない、今こそ自らがコンプライアンスをコントロールできるように体制を構築しましょう。
② 必要な是正を講じる
ライセンス違反、コンプライアンス違反がULAの終了を妨げる最大の原因であれば、是正してコンプライアンスを維持さえすれば、終了できるのです。
③ 証明プロセスの準備をする
ULA を終了する際の 証明プロセスを理解し、実際には監査がきても正しくコンプライアンス情報（監査スクリプトデータなど）を提供し、違反がなく問題がないことが証明できる状態を維持します。
④ 必要なパーペチュアルライセンスを維持して保守費用を支払う

これら①～③ は、Oracleライセンス契約の専門家と一緒に対応することで確かな情報をもとに解釈を理解し、対策を講じることが可能となります。そのようなニーズに対応したライセンス分析サービスやアドバイザリサービスなどは欧米では一般的で、日本でも利用可能なサービスがありますので、ぜひご相談ください。

Oracle ライセンス監査で要求されるデータ
① 契約、購買情報
② インスタンスが稼働する物理サーバー情報
③ Oracle DB インスタンスで実行するスクリプト出力
④ vCenter による仮想環境の情報
⑤ その他（システム概要、対象ユーザー、連携システムなど）

LMS（License Management Service）/GLAS（Global License Advisory Service）監査チームにより監査において要求される情報は、前述のとおりですが、分かりにくいのは ③ の「Oracle DB インスタンスで実行するスクリプト出力」で、何がどこまで監査されるのか、というポイントがあげられます。
簡単にまとめると以下のような情報が出力されます。

① Oracle DB のエディション情報（SE/ EE）を含むインストールソフトウェアの情報
② Oracle DB の使用オプション情報
（オプションを構成する機能ごとの使用開始日、使用回数を含む）
③ インスタンスが稼働中の物理サーバーのモデルや使用CPU数、物理サーバーではなく仮想環境で稼働しているという情報

これらの情報をユーザーからの提供により、LMSチームはデータ分析を実施し、監査報告書をまとめます。監査報告書のポイントを以下にまとめます。

SE を割り当てているインスタンスが、SEの2ソケット以下（SEOne、SE2 の場合）の物理サーバーで稼働しているかどうか。

SE を割り当てているインスタンスが、オプションを使用してないかどうか。
※オプションは使用不可です。オプションを使用しているとEE＋オプションで請求されます。
通常オプションはインストールされませんが、トラブルシューティングでマネジメントパックをインストールすると、すべてのオプションがインストールされてしまいます。オプションを使用すると記録が残り、使用開始日、使用回数などがスクリプトの実行出力として監査チームに渡ります。

SE を割り当てているインスタンスが、vCenter 下の管理VMになっていないかどうか。
※vCenter など Soft Partitioning は、ライセンス消費を制限する技術としてOracleは認めていません。vCenter で管理しているすべてのCPUでSEライセンスを割り当てなければなりません。ただし、2ソケット以下の物理サーバーで構成されている場合。
それ以外は、すべてEEでCPUコア総数にライセンスが求められます。

EE を割り当てているインスタンスが、オプションを使用していないかどうか。
※オプションはすべてインストールされており、使用が可能な状態です。
しかし、購入していないオプションもすべてインストールされ、使用が可能になっているため、購入していないオプションを使用してしまうケースが多発しています。

EE を割り当てているインスタンスが、vCenter 下の管理VM になっていないかどうか。
※vCenter の環境では、同一ネットワークセグメントすべての vCenter 下にある管理対象サーバーのCPUコア総数にEEをライセンスする必要があります。

EE が vCenter 下で使用されている場合のオプションの利用は、vCenter 下の管理対象CPUコア総数にEEおよび使用しているオプションのすべてをライセンスしているかどうか。

対象環境において使用されているライセンスに関係する契約数

共有ストレージと接続している物理サーバー

一般的には、これらの監査項目を前述のすべての情報を用いて最大のライセンス違反の可能性として評価するのがLMS監査報告書と言えます。LMS監査チームは、監査報告書とともにOracle社のライセンス使用許諾条件の解釈を解説しますが、あくまで、解釈を説明するにとどまっており、ユーザーの解釈とのすり合わせはしません。また、他社の監査チームが過去には監査請求などまで実施していたのとは異なり、監査結果に基づいた監査請求の見積もりや交渉などは行いません。監査請求の見積もりや交渉はOracle社の担当営業が行います。

このように監査プロセスは分業化されており、データ取得/顧客説明チーム、データ分析チーム、交渉（営業）チームの分業体制で効率的に監査プロセスを実施しています。これらの状況から、今日の「ライセンス監査」は、営業活動に直結した活動であることは明らかと言えます。そもそも1990年代に言われていたのは、「経済が悪化すると、ライセンス監査が増加する」でした。2010年代に入ってからは、多くのソフトウェアベンダーで「ライセンス監査活動は最も効率の良い営業活動である」との認識が高まったことから、「ライセンス監査」を実施するベンダーは増加する傾向にあります。そして、その活動プロセスは効率的な営業プロセスへと進化しているのです。

ライセンス監査、ULA（包括契約）交渉への備え
「Oracle DBライセンスたな卸し分析」は、スクリプトを使用して、LMSが使用するデータとまったく同じデータを取得します。LMSが使用するデータを使用することで、監査が入る前に正確なライセンスポジションを把握し、プロアクティブに是正すべき点は是正し、ベースラインを正しくコントロールすることを可能とし、監査や契約交渉で不可欠となる「情報力」を獲得し、交渉を可能とします。自らのライセンスポジションの理解やコントロールなしに監査へ臨めば、主導権は著作権者へ渡り、交渉のパワーバランスは著作権者の圧倒的な優位からの交渉となります。その場合は、ユーザーにとっては「交渉にならない」という状況になることは火を見るよりも明らかです。
「交渉力」は、「情報力」です。まずは、自らプロアクティブにライセンスポジションを把握し、プロアクティブな是正に取り組み、正確なベースライン情報をもって交渉の準備を怠らないようにしましょう。

LMS監査からのULA は、高すぎる？！
そもそも、3億円以上のULA は無駄なコストが含まれている可能性があると欧米では言われています。しかし、そう言われている欧米でも3億円以上の高額なULA を保有する組織はすくなくありません。その理由については、Oracle監査請求額が100倍に！？ウソ！？ホント！？の記事を参照ください。主な理由はシステム毎のサイロ化されたIT環境と、人とプロセスのサイロにより、システム横断的に、契約・ベンダー横断的にライセンスの使用状況を把握できていないからです。

ケイパビリティとしてはベンダーマネージャ、プロセスとしてはVMO（Vendor Management Office）の一元的な管理プロセスの実装がライセンス契約のガバナンス向上には不可欠な要素です。
ところが複雑化したIT環境と、複雑化したライセンス契約と、サイロ化した組織とシステムの環境とを横断的にコントロールを利かせるというのは、着手を任命された担当者にとっては、とても大きな災害級の困難に少人数で取り組むようなものなのです。

ULA は、コンプライアンスのコントロールができないと Exit できない！
システム単位で調達してきたライセンスは、様々なSIパートナーから購入され、ベンダーが提供するOEM版や、Oracle製品代理店からの再販製品や、異なるエディション、ライセンスタイプが混在した状態で、「お客様」定義が不明確な状態で、仮想環境に移行されている環境ができています。
一言で言えば「カオス」な状態です。このような状態を可視化し、現時点でのEffective License Position（ELP:有効ライセンス状態）を把握することは非常に困難です。カオスな状態のままULAの満了日を迎えると、Certification Process においてコンプライアンスを担保して Exit する、ということが難しくなります。つまり、ライセンス違反があれば、遡及となるため、さらに3年間のULA を更新しなければならない、という沼にはまるわけです。この現象は欧米においても顕著で、これを繰り返して、最終的には PULA（Perpetual ULA：永年ULA）にロックインされてしまいます。それが組織の望む、メリットのある契約条件であれば問題はありません。一方で、組織にとってメリットが感じられない契約条件であれば、改善すべき問題となります。
「カオスな状態から可視化し、コントロールし、交渉してExit するなんて私には不可能だ！」担当者なら、誰しもが一度は叫びたくなるでしょう。
しかし、不可能ではありません。ELPを求めるには、自主監査が最も効果的、効率的です。具体的に何をするべきかは、「Oracleライセンス監査の実態！？」の「Oracleライセンス監査で要求されるデータ」の項をご参照ください。さらに、これらを実施するためのサービスなどもありますので、ベンダーマネージャサービスを提供するパートナーと共に実施することができます。詳しくは協会までお問い合わせください。
なぜ、ULA が終了できないのかの原因については、「Oracle ULA（包括契約）は、なぜ終了できない？」をご参照ください。

パートナー選びが重要だ！
サイロ化したシステムに多数の契約と異なる契約条件はカオスの原因ですが、それだけではありません。本来であればユーザーを支援するべきベンダーが、実は機能していない、ということも大きな原因の一つとなっているのです。
ご相談をいただくユーザーが「なんだ、相談相手を間違ってたのか！」という反応をされることも少なくありません。ライセンスの使用許諾条件は非常に複雑で専門性が要求されます。それが故に、「誰に聞くのか？」は最も重要なポイントの一つなのです。尋ねる相手を間違えると「藪蛇」にもなるので十分に注意しましょう。

経営上位層の理解が不可欠！
「資産管理ぐらいやっている！」と経営陣は一蹴されます。私は15年ほどIT資産管理に関わってきましたが、過去にそのようなリアクションの経営層の皆さんの大手組織は、結果として多大なコンプライアンス違反金を支払ったりしている組織であったりします。なぜ、やっているはずなのに、そのような結果になってしまうのか？それは、組織的な情報やコントロールの分断、分散が大きな原因となっています。資産管理は、調達が頑張ればできるとか、IT運用部が頑張ればできるとか、という「誰かが頑張れば何とかなる」というたぐいの取り組みではないのです。
調達も、法務も、ユーザー部門も、IT開発も、IT運用も、経営層もすべての関係するステークホルダーが共有するビジョンと明確な戦略をもって取り組まなければ、そのガバナンスを継続的に維持、向上することは不可能なのです。
つまり、経営層がその重要性を認識し、中長期的な視点から、組織横断的にグローバルな取り組みを、体制を持ち、明確なポリシーとロードマップを持って、信頼できるパートナーと共に歩むといった取り組み方が求められるのです。
「喉元過ぎれば熱さを忘れる」にならないように小さな一歩でもその歩みを止めることなく、継続的改善に取り組んでください。ご利用ください。

ベンダーマネージャの社内育成とアウトソーシング
グローバル市場では、特定のベンダーに特化したベンダーマネージャのアウトソーシングサービスやコンサルテーションなどが多数存在しています。特にOracle社の契約は複雑で、専門的知識が要求されますので、この分野の専門コンサルティング会社の増加が顕著です。しかし、サービスの品質はまちまちですので注意も必要です。

VMWare のすべてのサーバーCPUコアでOracleDBのEnterprise版がライセンス要求される
基本的にStandard版（SE/SE1/SE2）利用は、ソケット単位でのライセンスで物理サーバーで2ソケット（SE除く）を最大とするという制限が設けられています。また、NUPは、基本的には小規模でユーザーリストを管理して主に開発環境用途に用いられます。ところが、SEのNUPやProcessorライセンスが気付けばVMWareの環境にお引っ越ししていた、なんてことがよくあるのが今日です。しかも、Oracle Enterprise Manager のオプションはその大部分が有償でEnterprise版専用オプションとなっているため、厳密な管理をしていないと有償オプションを気が付かないうちに使用してしまっている、なんてことが発生します。少なくとも私がご相談を受けた案件の90％のユーザーさんが、これらのケースにあてはまります。ある程度の規模のユーザーさんであれば、ほぼ100％これらのケースにあてはまるシステムが存在します。
恐ろしいのは、仮想環境において一カ所でもこのケースが発生していると、その影響は全仮想環境のサーバーのCPUコアでのライセンス要求へと、爆発的にリスクが高くなることです。これが、Soft Partitioning ポリシーの非常に恐ろしいところなのです。つまり、「Oracle と VMWare を混ぜると危険、爆発します！」ということなのです。何年も注意喚起はしてきたのですがなかなか浸透しないので、今一度忠告致しますが、コンプライアンス上のリスクは災害級です。是非、十分に注意して対策、コントロールしてください。対応方法については過去のコラムでも言及していますが、ポイントを以下にまとめます。

① 物理サーバーに閉じ込める
② 共有ストレージを使用しない。VMWare同様、爆発します（またはLUNで制限する）
③ VMWare 環境においてはSE2 Proc をすべてのソケットに充足し、オプションを使用しない
（だいたい気が付かないでオプション利用しています）
④ L3スイッチでVLAN構成をとり物理的ネットワークセグメントで分母を制限する
⑤ NUPは開発のみで利用（小規模組織で利用者名簿管理できる場合を除く）
混ぜると爆発します

上記の対策が不十分であるとどうなるのか？「爆発します」つまり、仮想環境のすべてのサーバーのCPUコアでライセンスが要求される可能性が高くなり、数百ライセンスのEnterprise版が要求される論拠となってしまいます。
例え、それが1システムでも？「はい」たとえそれが大規模な仮想環境上の1システムでも、です。
「そんなバカな、大げさに言ってるんでしょ？脅かして、もっと真剣に管理しないとダメですよって言いたいから」とよく言われますが、とても控えめに言っています。
実際にユーザーさんが経験されると「武内さんが言ってたことはホントなんですね！」となるのですが、そうなってからでは遅いので、できればそうなる前に対策してください。

コロナ禍でも監査は減らない
コロナ禍の影響で税務署の監査は対面でのやり取りがあるので感染リスクを考慮し減少している、と言われていますが、Oracle社の監査は逆に増加していると言われています。その原因の一つが監査パートナーを増やしていることや、リモートでの監査を実施し、データをポータルにアップロードする形態をとっていることなどがあげられます。
欧米では大手組織に限らず中小規模の組織にも監査レターが来ていると言われています。日本国内においても上場企業であれば、ほぼ確実に監査対象となることは間違いありません。手遅れになる前に、「自主監査」を実施し、「自主的な是正」によりコンプライアンス対策を万全にしておきましょう。

ソフトウェアベンダーによるライセンス監査は、以下のような様々な形態で実施されてきました。

① ソフトウェアベンダーの監査部門または指定監査法人によるハードアプローチ
② ソフトウェアベンダーのアドバイザー部門（監査部門のブランチ）によるソフトアプローチ
③ ソフトウェアベンダーの営業によるソフトアプローチ
④ ソフトウェアベンダーのパートナー（販売代理店）によるソフトアプローチ
⑤ ソフトウェアベンダーのライセンス最適化/最適化管理認定パートナーによるソフトアプローチ

これらがすべてではありませんが、今後も「監査」は、ハードアプローチ、ソフトアプローチで実施されると考えられます。
ハードアプローチが「監査」という明確な著作権者、知的財産権者の権利の行使であることをうたったアプローチである一方で、ソフトアプローチは、「ライセンスの棚卸しのサポート」、「ライセンス最適化の支援プログラム」、「ライセンスサーベイ」など「監査」をうたわないアプローチとなっています。そして、これらの「提案」は、やんわりとお断りすることができるのです。
アプローチがソフトであろうとなかろうと、実際には「監査部門」が関与することが多く、情報はソフトウェアベンダーの売り上げ増の目的で利用されることが多いのが事実です。
このようなソフトアプローチは、常に存在し、「監査」であるとは知らないうちに「監査データ」を提供しているユーザーは少なくありません。
なぜ、お断りできるソフトアプローチの監査に応じてしまうのか？（そもそも監査という認識がないケースも多々ありますが）
その原因は、自組織による「自己監査能力の不足」にほかなりません。
結果として、「無償でライセンス最適化のアドバイスをしてくれるので、ライセンス棚卸しをしてもらおう」ということになりやすいのです。あるいは、「サーベイ調査にはすべてのユーザーさまにご回答いただいています」などの説明から、情報提供は義務であると誤解される場合もあるでしょう。この「無償でライセンス最適化のアドバイス」を提供してライセンスコストを削減してくれるサービスが成立するのか？と考えると、サービス提供の結果として追加のライセンス販売など売り上げがなければ、このような活動を営利目的で活動している組織が実施するはずがないということに気が付くと思います。もちろん中にはベンダーからパートナーへの補助金が提供されている場合もありますが。
しかし、それでも、ついユーザーがソフトアプローチに応じてしまうのには、ライセンス契約やライセンス使用許諾条件を理解している人がユーザーの社内にいない、という台所事情から、常にライセンスについての不安がある、というユーザーの心理があります。
そして、それを誰よりも知っているベンダーは、そのようなユーザー心理を狙ってソフトアプローチをしてくるのです。
「ただより高いものはない」は、真理ですし、「販売している人を100％信じてはいけない」も真理です。
お断りできることは、やんわりと、しかし、しっかりとお断りする。そして、自らの力でライセンスの状態を把握し、コントロールすることが、「監査を受け身で受けてコスト増大を甘んじて受け入れる」という状態を回避する唯一の方法です。
購入者としては、自らの力でライセンス契約を理解し、交渉し、組織のニーズにマッチしたライセンス契約を獲得し、契約で定義された使用許諾条件に基づいて運用し、継続的に交渉して改善する、を怠ってはいけません。

リセッションがやってきたとした場合は、10年サイクルで考えると、これから数年間は様々な形でのソフトウェアベンダーのソフトアプローチおよびハードアプローチの監査が実施されると考えられます。今こそ、その対策と「自己監査」の準備に取り掛かることをお勧めします。

ベンダーマネージャの社内育成とアウトソーシング
グローバル市場では、特定のベンダーに特化したベンダーマネージャのアウトソーシングサービスやコンサルテーションなどが多数存在しています。特にOracle社の契約は複雑で、専門的知識が要求されますので、この分野の専門コンサルティング会社の増加が顕著です。しかし、サービスの品質はまちまちですので注意も必要です。

ULA終了準備最初の一歩
ULA の Exit （満了時のタイミングの契約終了）においては、「契約内容をよく理解する」ということにつきます。これが簡単なようで、実際は非常に困難なのです。なぜならば、契約内容とはOMA（Oracle Master Agreement）や、ULA のOrdering Document の使用許諾条件を網羅的に理解する、ということだからなのですが。これが実現されている組織が非常に少ないのです。OMA の難しさは、URL や関係文書において定義される使用許諾条件の複雑さであることは以前のコラムでも解説しています。OMA は、ユーザー毎に違いはないのですが、使用許諾条件の解釈はユーザー環境によって異なるので注意が必要です。さらに、ULA の Ordering Document における使用許諾条件はユーザー毎に異なるので、これらの使用許諾条件を正確に理解し、遵守する必要があります。欧米では、このULA の使用許諾条件への遵守で失敗してExit できないユーザーが少なくないと言われています。そのような場面で欧米でよく言われるのが「The devil is in the details.」（細かいところに落とし穴）です。

契約書のレビュー
特に重要なのは、ULA の Ordering Document をしっかりとレビューして理解し、チーム全体で共通の認識を確立することです。使用許諾先国、使用許諾先組織、製品、エディション、ライセンスタイプなどから、Ordering Document で定義されるすべての条項をしっかりと理解し、コンプライアンスの条件や証明プロセスの条件などを正確に理解した上で、Exit に関係するチーム全員の共通の理解を確立し、役割と責任を定義して終了計画を設計することです。
本来は、VMO（Vendor Management Office）やベンダーマネージャがこれらの責任を持ちますが、それらの役割と責任が定義され、体制が構築されていない場合は、役割と責任や体制から定義し、「契約書の理解の責任」は誰にあるのか、「能力」は担保されているのか、からしっかりと見極めることが大切です。
ULA の Ordering Document の使用許諾条件を網羅的に理解していないチームが「なんとなく」でExit の準備を行い、役割と責任だけを負わされるのはデスマーチへの一歩と言わざるを得ません。必要であれば「専門家」に相談してください。
レビューに必要なメンバーは以下の通りです：

① ULA のOrdering Document におけるライセンス定義および使用許諾条件定義がどのような経緯でなされたのかを把握している人
② ULA で定義されたライセンスの自組織のライセンスニーズを理解している人
③ ULA で定義されたライセンスの自組織の実装状態、運用環境、ライセンスの消費状態を理解している人
④ OMA/ULA の条項を読んで内容を正確に説明し、共通の理解を確立することができる人

多くの場合、①から③までは自組織内部にいる誰かが責任を負わなければなりません。一方で④ については自組織にはベンダーマネージャがいない、という場合は外部の「専門家」を利用します。④ はベンダーマネージャの役割と責任であり、④ の「能力」を担保することで、①から③の現状からコンプライアンスの状態やExit の戦略を設計することが可能となります。
どのベンダーのライセンス契約も複雑化が進んでいるので、理解することは難しいことではありますが、不可能なことではありません。体制、役割と責任、能力を担保し、正しいアプローチによりプロセスを設計しコントロールすることで、しっかりとライセンス契約などのガバナンスコントロールを得ることが可能です。

2019年 OMA（Oracle Master Agreement）の変更
Oracle 製品 のライセンス契約の条件は、OMA や Ordering Document といわれている発注情報で定義されていますが、2019年のOMA には監査項目において「Oracle社が提供するLMSスクリプトを使用してデータを提供すること」と条件が追加されています。今までもLMSという監査チームが提供するLMSスクリプトを使用して「インベントリ情報を提供してください」という依頼はあったものの、OMA には明確に定義されていなかったので、任意で協力するというものでした。

しかし、2019年のOMA にはLMSスクリプトを使用したデータ提供が義務付けられる条件が記載されるので、この条件を交渉して削除しない限り、ユーザーはLMSスクリプトを使用してデータを提供し、その他の情報も要求に応じて提供しなければならなくなります。

LMSスクリプトとは？
Oracle社にはLMS（License Management Service）という監査チームがあります。このチームが監査の際に使用するデータコレクションツールに「LMSスクリプト」というOracle社の製品情報を取得するためのスクリプト群があります。これらのツールを使用することで、インストールされたOracle製品のバージョン、エディション、使用しているオプションなどの設定情報が収集されます。

これらのツールで収集された情報と、ヒアリングなどをもとにユーザー環境で運用されているOracle製品のライセンス消費状態を把握して、コンプライアンスの状態を把握し、不足するライセンスについて監査レポートを提供する活動をしているのがLMSというチームです。

LMSレポートは正確か？
Oracle社はVMWare などのSoft-partitioning 技術を、ライセンス消費を決定する技術として認めていません。つまり、VMWare などの環境では、Oracleライセンスの消費は環境にあるすべてのプロセッサを対象にパーペチュアルライセンス[永久ライセンス]が要求される可能性があります。そしてLMSレポートは、そのような環境においてのライセンス消費の最大値が調査結果として報告される可能性が高いということです。

これに対してユーザーは、実際の保有ライセンスを契約のたな卸し・Ordering Document のたな卸し・実装環境の整理などの情報をもとに、自社環境とOracleライセンスの運用状態・Oracleライセンスの稼働によるメリットなどを考慮して、請求される監査ライセンスや提案を検討して交渉し、妥当と考えられる条件や金額で折り合いをつける努力をしなければなりません。

交渉のステップ
自社のOracleライセンス契約およびOrdering Documentすべてをたな卸しし、レビューする。
LMSスクリプトと同等レベルのたな卸し情報を用いてたな卸しする。または、すでにLMSスクリプトによるLMSのたな卸しが進行している場合は、結果データのレビューを自社で実施する。
LMSによるライセンスポジションのレポート報告と自社の見解の差分を把握し、交渉に備える。
Oracleベンダーマネージャまたは外部の専門家と相談し、LMSスクリプトデータのレビューおよび交渉戦略を検討する。
戦略とデータ、仮想環境における制御計画をもとにLMSチームとLMSレポートを最終化するための交渉を実施する。

ベンダーマネージャの社内育成とアウトソーシング
グローバル市場では、特定のベンダーに特化したベンダーマネージャのアウトソーシングサービスやコンサルテーションなどが多数存在しています。特にOracle社の契約は複雑で、専門的知識が要求されますので、この分野の専門コンサルティング会社の増加が顕著です。しかし、サービスの品質はまちまちですので注意も必要です。

Oracle Java ８ は、2019年4月以降が有償？
BCL（Binary Code License for Java SE） から OTN （Oracle Technology Network License Agreement for Oracle Java SE）へ変更されたのが2019年4月なので、OTN から有償という誤解をされているケースが多いのですが、BCL では、OTN と同じく開発や個人利用に加えて「General Purpose」という特定の用途のみが無償でした。したがって、一般的な企業が利用する社内開発したアプリケーションなどはBCL から有償の可能性が高いのです。つまりGeneral Purpose の定義（General email, general purpose Internet browsing, and office suite productivity tools）に当てはまらない場合は、有償なのです。

Oracle Java SE のライセンスが不要なケースとは？
① Oracle Java は開発でしか使用しない
８や11を使用している場合でも開発でしか使用しない場合はライセンスは不要です。
② Oracle WebLogic や Oracle社のJavaアプリケーションでしか使用しない
以下のアプリケーション製品はJavaのライセンスが付与されています。
Schedule A Products:
● Oracle SQL Developer
Schedule B Products:
● Oracle Forms, and applications that contain Oracle Forms
● Oracle E-Business Suite, and applications that contain Oracle E-Business Suite
● Oracle WebLogic Server Product
● Oracle Coherence Product
● JD Edwards
● Oracle AutoVue products
● Oracle Secure Global Desktop
● Oracle Demantra products
③ Oracle Cloud Infrastructure（OCI）でしか使用しない
④ Java 17 または OpenJDK しか使用しない
⑤ 他社のJava ディストリビューションしか使用しない
⑥ Java で開発したアプリケーションベンダーがJavaライセンス契約をしている

Javaのライセンス契約が必要な対象は？
前述のライセンスが不要なケースを識別して除外した後に、Oracle JDK８または11を使用してアプリケーション開発をして運用しているのでライセンスが必要であると識別した対象の以下の環境でのライセンスが必要です。

① サーバー Java： プロセッサライセンス
② クライアント Java（JRE）：Named User

そして、注意するべきポイントとして、① サーバーJava は、Soft Partitioning においては「分離」がされていないとDatabase のライセンス使用許諾条件 同様、仮想環境のリソース全体にライセンス消費がされますので十分な制御が求められます。

本当に必要なライセンス数を見極めるためには、「ライセンスが不要な対象をしっかりと識別して除外する」ことです。さらに、Soft Partitioning を制御してライセンス消費をコントロールすることです。
これらを管理することでJavaライセンスの最適化と契約交渉をしっかりとしていきましょう。

ベンダーマネージャの社内育成とアウトソーシング
グローバル市場では、特定のベンダーに特化したベンダーマネージャのアウトソーシングサービスやコンサルテーションなどが多数存在しています。特にOracle社の契約は複雑で、専門的知識が要求されますので、この分野の専門コンサルティング会社の増加が顕著です。しかし、サービスの品質はまちまちですので注意も必要です。

仮想環境で使用不可能なOracle スタンダード版
典型的な100倍請求の原因は、「スタンダード版をVMWare で構成した仮想環境で運用している」というケースです。そもそも、スタンダード版は、さまざまな制限があります。スタンダード版を運用可能な物理サーバーのスペックは、2ソケット（２CPU最大搭載）のサーバーです。そして、仮想環境は一切認められていません。Oracleは、ソフトパーティショニング技術（Soft Partitioning ）を、ライセンス消費を左右するテクノロジーとして一切認めないという文書も発行しています。ただし、契約書中には明文化されていません。しかし、Oracle社の監査では、スタンダード版が２CPU以上の物理サーバー上や、仮想環境で運用されている場合は、すべてエンタープライズ版を買い直さなければなりません。
さて、以下の単純なシナリオで考えてみましょう。

スタンダード版2ライセンスを、2CPU に割り当てて運用しているつもりでした。
ところがスタンダード版を運用している物理サーバーには4CPU搭載されていました。
さらに、環境はすでにVMWare6.0 で仮想化されていました。

購入したスタンダード版をStandard Edition ONE （SEO）と仮定し、約70万円＋サポートを支払っているとします。2ライセンスですので×2 で、140万円＋サポート（約22%）。
スタンダード版は、１CPUに対して1ライセンスを消費します。
エンタープライズ版は、１コアに対して1ライセンスを消費します。
使用しているCPUは、クアッドコア（4コア）とします。
エンタープライズ版は、570万円＋サポートとします。単純にライセンス価格だけでSEOの約8倍。
さらに、4コアのCPUであれば×4で、32倍。
そしてクラスタ構成が4CPU ×5サーバーで、20CPU を32倍すると、640倍。
ところが、VMWare 6.0 は、複数クラスタを構成する、複数vCenter をまたいでインスタンスが移動可能なことから、対象はすべてのCPU となります。御社のCPU数×32倍で考えてみてください。

簡単に数百倍に膨れ上がる監査請求額
「スタンダード版の制限をよく理解できていなかった・・・」
原因は、「プロジェクト―調達―VMO:ベンダーマネージャ―インフラ―Oracle技術者―運用」という組織横断の取り組みやプロセス、契約における責任の所在や役割が「あいまい」なことです。
Oracle監査に苦しむ多くの組織で、契約におけるライセンスの条件や制限を理解し、運用環境でライセンスコンプライアンスをコントロールする仕組みが「欠落」しています。
「契約」を交渉するためには、契約条件を正確に理解し、自社の運用環境におけるライセンス運用の実態を把握しなければなりません。

「どのような契約をしたのか、運用現場では具体的に理解できていません」
「どのようなライセンスに仮想環境における制限があるのか、仮想環境の運用者には理解できていません」
このような状況では、監査請求の妥当性検証ができるわけもありません。

複雑化した今日の環境では、契約で与えられた条件や制限を適用してライセンスをコントロールするケイパビリティが求められます。そして、それは組織横断的に取り組まれなければならないのです。
そのためには、まずは「Oracleライセンスたな卸し」（契約、Ordering Document （発注情報）のたな卸し、運用インスタンスのインベントリたな卸し）の実施が必要です。
そして、たな卸しした結果を分析し、コンプライアンスと運用計画を見直し、運用環境の是正をし、契約の継続的改善を実施することが大切です。

いつ取り組みを開始するべきでしょうか？「今です！」

ベンダーマネージャの社内育成とアウトソーシング
グローバル市場では、特定のベンダーに特化したベンダーマネージャのアウトソーシングサービスやコンサルテーションなどが多数存在しています。特にOracle社の契約は複雑で、専門的知識が要求されますので、この分野の専門コンサルティング会社の増加が顕著です。しかし、サービスの品質はまちまちですので注意も必要です。

組織横断で取り組むIT資産運用プロセス構築 ～クラウド・仮想化環境の全体最適化、ガバナンスの獲得～

第8回：VMOが機能していない組織の課題～海外大手ITベンダーとの関係構築にはベンダーマネージャの専門的知見が不可欠！～

VMOは確立したがVMOへの期待値ばかりが高まり、実情がおぼつかない
「ベンダーマネジメントは重要である」と、経営者が理解を示していてVMOを確立していたとしても、VMOの「役割と責任」が明確に定義されていないと「IT資産管理」や「構成管理」を成功に導くための十分なベンダーマネジメントの能力がVMOにないというケースが少なくありません。なぜならば、経営者がVMOへ要求する「役割と責任」や「機能」について、理解できる情報が提供されていないことが多いからです。

今までのVMOへの期待は、主に対象がSIerや開発パートナーなど、役務を提供するベンダーとの「調達」、「契約」、「パフォーマンス」に関係する管理を目的として定義されていました。しかし、ソフトウェアを提供してきた海外ベンダーのソフトウェアライセンス契約などは、同じレベルの経験だけでは対応が難しいことを理解してもらう必要があるのです。

これらのソフトウェアベンダーの製品はリセラーや代理店から購入されてきましたが、多くのソフトウェアベンダーがクラウドへと移行するなか、ソフトウェアベンダーはサービスベンダーへと性質を変化させています。ソフトウェアライセンス契約なども複雑なマルチクラウド環境において運用され、製品群も幅広く、ライセンスモデルやクラウドサービスの提供形態も、環境の変化に伴い劇的に変化し続けています。これらを的確に管理するためには、「契約」を理解し、管理することが不可欠です。そして海外では、この「契約」を理解するための利用規約が複雑化していることから、特定のソフトウェアメーカーに特化したベンダーマネージャという専門職が一般的になってきました。

ベンダーマネジメントにおける「契約の交渉と締結」には、特定のベンダーに特化したベンダーマネージャの能力として「当該ベンダーの製品やサービスを網羅的に理解し、自社の既存契約や過去の契約履歴を把握したうえで、契約を統合し、シンプル化しながら戦略的なWin-Winの関係性を継続的に向上していくことができる」という専門職ならではの知識や戦略が必要とされるのです。

複雑な利用規約は、単一の契約だけでは定義されていない
海外ではMicrosoft、Oracle、IBMなど大手ITベンダーが提供する製品やサービスのライセンス契約やクラウドサービス契約を理解するための教育プログラムを提供する専門ベンダーがあります。また、当該ベンダーとの戦略的パートナーシップを実現するためのベンダーマネジメントのコンサルテーションサービスを提供する専門ベンダーもあります。ベンダーマネージャに必要な能力を獲得するためにはそれなりの教育や時間がかかります。

デジタルビジネスや IoT など、エコシステムが不可欠となる次世代IT環境においてサービスを構成するベンダーの契約は最も重要な管理対象です。そのため、海外の組織は投資を惜しまずにベンダーマネージャという専門職を社内で育成したり、アウトソースしたりするという対策を講じています。残念ながら、国内ではゼネラリストに頑張ってもらい、片手間に勉強してなんとか対応しようとしたり、ゼネラリストで構成されたVMOにベンダーマネージャという専門職を置かずに「根性」で対応させたりしようという、旧態依然とした精神論で押そうという悲しい風潮が相変わらず大勢を占めているのが現状といえるでしょう。

現場でできることの一つは、経営者の理解を向上するために「新たな時代に備えたベンダーマネージャ要件の啓蒙と教育」が考えられます。海外ではこのようなエグゼクティブブリーフィングを支援する前述のようなベンダーが数多くありますが、国内でもそのようなサービスが立ち上がりを見せているので、専門家に相談することをお勧めします。