Oracle ULA/PULA更新を「契約更新」にしてはいけない理由

1. 最初に「Renewありき」をやめる

更新プロジェクトで最初に設定すべき選択肢は「どの条件で更新するか」だけではありません。少なくとも次の3つのシナリオを比較する必要があります。

• Renew：現在のULA/PULAを更新する
• Renegotiate：対象製品・条件・価格などを再設計する
• Exit：Unlimited契約から離脱する

ここで重要なのは、Oracleから更新見積を受け取ってから検討を始めないことです。先に自社側で「更新しない場合に何が起こるか」を把握しておかなければ、交渉におけるBATNA（Best Alternative to a Negotiated Agreement：交渉が成立しなかった場合の最善の代替案）が存在しない状態になります。「更新しなければ困る」という状態で価格交渉を始めれば、ユーザー企業側の交渉力は限定されます。ULA/PULA更新プロジェクトの出発点は、Renew vs. Renegotiate vs. Exitの比較であるべきです。

2. Oracle Estateを再構築する

Unlimited契約で注意すべきなのは「Unlimitedだからライセンス管理をしなくてもよい」と考えてしまうことです。むしろ更新・終了を判断する段階では、Oracle Estate、つまりOracle製品が「どこで、何が、どれだけ使われているのか」を正確に把握する必要があります。最低限、次の情報を整理します。

Deployment：Oracle Databaseのインストール先／Database Edition／Options・Management Packs／Oracle Middleware（WebLogic等）／Java／その他ULA/PULA対象製品／本番・開発・テスト・DR環境

Infrastructure：物理サーバ／CPU・Processor情報／仮想化環境（VMware等）／クラウド（OCI・AWS・Azure）／コンテナ環境

Organizational Scope：法人・子会社・海外拠点／M&Aで取得した企業／売却・分社化した企業

この作業で重要なのは、CMDBやSAMツールのデータだけを信用しないことです。複雑なOracle環境では、CMDB × Discovery × Oracle technical data × Contract data × Infrastructure dataなど、複数ソースを照合して実態を再構築する必要があります。

3. 「契約」をもう一度読む

Oracleライセンス管理では、技術データだけを集めてもライセンス・ポジションは確定しません。同じOracle製品を同じ台数使用していても、契約条件によってユーザー企業が保有する権利は異なる可能性があります。したがってULA/PULA更新前には契約の再構築が必要です。確認対象には、たとえば次が含まれます。

• ULA/PULA契約本体、Ordering Document
• OMA / OLSA等の基本契約、Amendment、過去の購入履歴
• Support契約、製品・メトリック、Unlimited対象製品、対象法人・地域
• M&Aに関する条件、Divestitureに関する条件
• Certification / Exitに関する条件、契約固有の特約

ここで重要なのは、Oracleの一般的なライセンスポリシーと、自社がOracleと締結した契約上の権利を混同しないことです。インターネット上の一般的なOracleライセンス情報だけでは、自社のEntitlementは確定できません。最終的には、自社が実際に締結している契約文書を基準として判断する必要があります。

4. Effective License Positionを作る

DeploymentとEntitlementを把握したら、両者を突き合わせます。つまり、Deployment → License Requirement → Entitlement → Gapという構造でEffective License Position（ELP）を作成します。

ただしULA/PULAでは、単純な「不足ライセンス数」の把握だけでは不十分です。重要なのは、Unlimited契約がなくなった場合、この環境をどのようなライセンスで維持する必要があるのかという視点です。たとえば「現在Unlimitedだから100 Processor分使っている」という情報だけでは意思決定できません。必要なのは「Exit後も本当に100 Processor必要なのか」という分析です。

5. 将来需要を予測する

ここが通常のSAMアセスメントとULA/PULA更新アセスメントの大きな違いです。現在のOracle利用量だけで更新判断をしてはいけません。3〜5年程度のITロードマップと重ね合わせます。確認すべき代表的な項目は、Oracle Database増減、Database consolidation、Data Center consolidation、OCI移行、AWS/Azure移行、SaaS化、アプリケーション刷新、ERP刷新、Oracle製品からのMigration、M&A、Divestiture、AI／データ基盤拡張などです。

たとえば現在Oracle Databaseの利用量が非常に大きくても、3年間で半分のシステムをSaaSや他のDBへ移行する計画であれば、現在の利用量を基準としてUnlimited契約を更新することが最適とは限りません。逆に、M&Aや新規システムによってOracle需要が大幅に増えるのであれば、Unlimited契約の経済合理性が高まる可能性があります。したがって、Current Estate × Future Demandで評価する必要があります。

6. 「価格」ではなくTCOで比較する

更新判断でよくある間違いが、「Oracleから提示された更新価格は高いか、安いか」だけを評価することです。比較すべきなのは価格ではなく、各シナリオのTotal Cost of Ownership（3〜5年TCO）です。

つまり判断式は「Renewal Price」ではなく「3〜5年TCO」であるべきです。さらに金額だけでなく、Compliance Risk・Vendor Lock-in・Operational Flexibility・Cloud Strategy・M&A Flexibility・Exit Flexibilityといった定性的な要素も評価します。

7. 更新後・Exit後のSAMを設計しておく

ULA/PULA更新プロジェクトで見落とされやすいのが、契約判断後の運用です。特にUnlimited契約から通常のライセンス管理へ移行する場合、管理モデルは大きく変わります。Unlimited環境では問題にならなかった新規Deploymentが、Exit後には追加ライセンス需要につながる可能性があります。そのため、少なくとも次のような統制を設計しておく必要があります。

• Oracle製品導入時の事前承認、Database Option/Pack利用管理
• 仮想化変更時・Cloud移行時のライセンスレビュー
• M&A／Divestiture時の契約レビュー
• 定期的なOracle Estate Discovery、Entitlement Repositoryの維持
• ELPの定期更新

ULA/PULAからExitできても、その後のSAM統制が弱ければ、数年後に再び大きなライセンスリスクを抱えることになります。

更新12〜18か月前から準備する

ULA/PULA更新は、契約満了の数か月前に始める購買プロジェクトではありません。大規模環境では、Oracle Estateの把握、契約再構築、ELP、将来需要予測、シナリオ分析に相当な時間が必要になります。実務上は、更新期限から逆算して段階的に進めることが重要です。

• 1
  T-18〜12か月

  契約・Entitlement整理／Oracle Estate Discovery／データ品質評価
• 2
  T-12〜9か月

  ELP作成／将来需要予測／ITロードマップとの照合
• 3
  T-9〜6か月

  Renew / Renegotiate / Exitシナリオ作成／3〜5年TCO比較／リスク分析
• 4
  T-6〜3か月

  交渉戦略策定／BATNA確定／Oracleとの交渉
• 5
  T-3〜0か月

  最終契約判断／Certification・Renewal対応／Post-ULA/PULA SAM統制開始

この順序が重要です。Oracleとの交渉を先に始めてしまうと、Oracleから提示された選択肢の中から選ぶプロジェクトになりやすくなります。先に自社のデータと戦略を確立し、その後で交渉に入るべきです。

ITAM/SAMとVendor Managementは分離しない

ULA/PULA更新では、SAMチームだけでも、調達・Vendor Managementチームだけでも十分ではありません。SAMは「何をどれだけ使っているのか」を明らかにします。IT・Enterprise Architectureは「今後何を使うのか」を明らかにします。Financeは「それぞれの選択肢はいくらになるのか」を評価します。Vendor Management / Procurementは「その情報をどのような契約条件と価格に変えるか」を担当します。したがって、SAM × IT Strategy × Finance × Vendor Managementを統合した意思決定プロセスが必要です。

まとめ：Oracleとの交渉より先に、自社の「選択肢」を作る

Oracle ULA/PULA更新で最も重要なのは、値引き率を最大化することではありません。重要なのは「更新しない」という選択肢を含めて、自社が複数の現実的な選択肢を持った状態で交渉に入ることです。そのためには、Contract → Deployment → ELP → Future Demand → Scenario → TCO → Negotiationという順序で準備する必要があります。Oracleとの契約交渉は、このプロセスの最後に位置します。Oracleから更新条件が提示されて初めて検討を始めるのでは遅いのです。

ITAM/SAMとVendor Managementが先行してOracle Estateと契約上の権利を可視化し、将来需要を予測し、Renew / Renegotiate / Exitそれぞれの経済性を把握する。その状態を作ることこそが、Oracle ULA/PULA更新における最も重要な交渉準備と言えるでしょう。

ULA/PULA更新プロジェクトを専門家に相談する

Oracle Estateの再構築、契約レビュー、ELP作成、シナリオ別TCO比較、交渉戦略の策定まで、独立系のOracle専門コンサルタントが更新プロジェクトを一貫して支援します。初回相談は無料です。