なぜ「ベンダー別」の専門知識が必要なのか
Microsoft・Oracle・IBM・VMware（Broadcom）に共通するのは「複雑なライセンス体系」という一点だけです。それぞれのビジネスモデル・商慣行・監査方針・価格交渉の論理は根本的に異なります。
たとえば、Oracleは仮想化環境においてハイパーバイザー全体を1つのサーバーとみなすPolicy（LIUM）を持ち、適切な構成管理なしに仮想マシンを動かすだけでライセンス違反になるリスクがあります。一方MicrosoftのEAは毎年のTrue-Up（実績申告）が義務付けられており、契約期間中に増加した使用ライセンスを事後追加する仕組みです。IBMはILMT（IBM License Metric Tool）の導入なしにサブキャパシティライセンスが認められないという独自ルールを持ちます。
このような「ベンダー固有の知識」なしに交渉に臨めば、常にベンダー側が優位に立ちます。VMAJの教育領域09は、この非対称な情報格差を縮めることを目的としています。
各ベンダーページには無料の実務ガイド（PDF）を用意しています。ライセンス管理担当者・VMO・IT調達チームの実務参照資料としてご活用ください。
対象ベンダー
Microsoft
EA / MCA-E / CSP 等の契約モデル選択から、True-Up・SA・FVB・ライセンスモビリティの実務、さらにM365・Azure・Copilotの包括的ライセンス管理まで。Microsoft製品群を横断した実務知識を解説します。
Oracle Database
Processor・NUP・Named Userの各メトリクスの違い、仮想化環境での適用ルール（LIUM）、ACE（Authorized Cloud Environments）を活用したクラウド移行戦略、DR/フェイルオーバー時のライセンス扱いを解説します。
VMware（Broadcom）
2024年のBroadcom買収後のライセンスモデル転換（VCF / VVF）、16コア最小単位とSPDの実務、KB313548が示す旧バージョン扱い、Compliance Reporting（180日ルール）、既存環境の移行戦略を解説します。
IBM
IPAA / IPLA / LIの契約階層、PVU・VPC・RVU・MSU等19種のライセンスメトリクス体系、ILMTによるサブキャパシティ管理、コンテナ環境でのIBM License Service運用、パスポートアドバンテージの台帳管理を解説します。
Demand-to-Contract-to-Service Controlの視点
VMAJが定義する「Demand-to-Contract-to-Service Control（需要・契約・サービス供給のマッチング統制）」において、ベンダー別の専門知識は「契約」フェーズの核心を担います。
需要（組織が必要とするソフトウェア・クラウドサービス）は現場から発生しますが、その需要をベンダーの契約条件・ライセンスメトリクス・価格モデルに正確にマッピングできるかどうかが、コスト最適化と監査リスクゼロの両立を決定します。Microsoft EAのTrue-Upで後払いになる仕組みを知らなければ予算計画が崩れます。Oracle LIUMを理解せずに仮想化環境を設計すれば、翌年の監査で数千万円規模のバックペイを求められるリスクがあります。
各ベンダーページでは、需要→契約→実績管理→更新交渉という一連のサイクルを通じて、ベンダー固有の知識がどこでどのように活きるかを具体的に示します。