サブスクリプションの低迷：誰も歓迎しない緩やかな成長

半導体設計チームがテープアウトの締め切りを守るためにTestMAX DFTモジュールをもう1つ追加するよう依頼した場合、その依頼は些細なものに見え、数分で承認されます。これは、シノプシスのソフトウェア ポートフォリオにおける単一の明細項目に過ぎません。そのフェーズが終了しても、モジュールは引き続き割り当てられたままであり、それを解放するのは誰の具体的な仕事でもありません。 このパターンを、数千人のエンジニアにサービスを提供する数個の共有ライセンスプール全体に拡大すると、設計組織では1年間で24ものフローティングシートが追加されることになる。これらは、個人が承認したわけでもなく、組織として検討されたわけでもないが、更新請求書にその累積額が反映されることになる。

サブスクリプション・ドリフトとは、ソフトウェア のエンタイトルメント・プールにおいて、更新から次の更新までの間に、承認を経ずに徐々に増加していく現象を指します。あちこちでシートやライセンスが追加されていくものの、サブスクリプションやメンテナンスの期間が再び到来するまで、誰もその内容を再評価することはありません。変更はそれぞれ個別に承認されますが、12か月間の合計を確認する人はいません。エンタイトルメント数は1年を通して変動し続け、その合計が初めて明らかになるのは、更新の請求書が届いた時です。

半導体設計分野において、この傾向が最も顕著に表れるのは、2つの共通点を持つツールファミリーです。1つ目は、一般的に更新ベースで販売されているという点です。例えば、シノプシス社の直近の四半期決算によると、同社の製品売上高の約60％は期間制のサブスクリプション型ライセンスによるもので、残りの40％は一括払いによるものです。2つ目は、単一の包括的な製品ではなく、個別にライセンスが供与される多数のモジュールに分かれているという点です。

シノプシスのTestMAXテスト向け設計（DFT）スイートは、DFT、ATPG、診断、およびその他のいくつかのアドオン製品に分かれており、ほぼすべてのデジタル設計チームが毎日使用している単一のコア合成ツールであるDesign Compilerに比べ、何がまだ必要なのかを見失いやすいものです。あるプロジェクトのフェーズのためにTestMAXモジュールをもう1つ導入することは、その都度、些細でありながら正当化できる決定です。 しかし、そのフェーズが終了した後、それを元に戻すことは、誰の担当でもないのです。

数千人のエンジニアが利用する共有プールを運用している設計組織において、月に2席の追加など取るに足らないことのように思えるかもしれない。しかし、これを1年間積み上げると、個々には承認されていない24席分がプールに追加されることになる。そして、このような計算は、ほぼすべてのマルチサイト設計環境の背後で、ひっそりと行われているのである。

ライセンスプールの変動は、いかなる規則にも違反しない

テープアウトの締め切りが迫ると、プロジェクトのフェーズに合わせて早期テスト可能性モジュールが割り当てられ、チームがすでに継続的に運用している基本のDFTツールと併用される。モジュールは締め切りをクリアし、フェーズが終了しても、ライセンスは帳簿上に残ったままになる――それを解放する担当者がいないからだ。2年前にあるプログラムのために拡大されたテスト対応設計（DFT）ライセンスプールは、決して縮小されることがない。各ステップは小規模で、文書化されており、それ単体でも正当化できるものである。

欠けているのは、各段階を俯瞰する視点だ。ほとんどのワークフローでは、今年の追加事項を総合的に見て、昨年の基準線に対して依然として妥当であるかどうかを確認する仕組みは存在しない。ましてや、特定の追加モジュールが現在も実際に起動されているかどうかなど、なおさら確認されていない。記録には承認された内容しか残らない。何が蓄積されてきたのか、また、導入の根拠となった段階が終了した後、いつのまにか使用されなくなってしまったものは何か――そういった情報は記録には表れないのだ。

複数の拠点でEDAライセンスを運用している設計組織――多くの場合、合成、DFT、レイアウト用の共有リソースがわずか数セットしかない中で、数千人のエンジニアが利用している――では、このギャップは急速に拡大します。ある拠点の設計チームは、他の2つの拠点が同四半期にすでに同じDFTモジュールを追加したかどうか、あるいはそれらの拠点のいずれかが昨年のモジュールをまだ利用し続けているかどうかを確認できないまま、追加のDFTモジュールをリクエストしてしまう可能性があります。

なぜ通常の報告書では見逃されてしまうのか

ライセンスに関するレポートの多くは、実際に使用された状況ではなく、チェックアウトされた状況を示しています。この違いは重要です。チェックアウトは、ライセンスが割り当てられたことを示すだけであり、その後の1時間、1日、あるいは四半期の間、誰かがそのツールを使って作業を行ったことを示すものではありません。

ライセンスメータリングの分野において、この問題に対する最も一般的な対処法は、自動回収ルールを設定することです。つまり、ライセンスがチェックアウトされた状態で、設定されたタイムアウト時間を超えてアイドル状態が続いた場合、そのライセンスを自動的に解放する仕組みです。これにより、一晩中開いたまま放置され、何の操作も行われていないような単純なケースは捕捉できます。ただし、これは依然としてチェックアウト時刻から活動を推測しているだけで、実際に測定しているわけではありません。

「権利のドリフト」は、そのギャップを容易にすり抜けてしまいます。3月に追加され、それ以来ほとんど利用されていないライセンスであっても、チェックアウトログやアイドルタイマーのみを基に作成されたレポートでは、依然として通常の「使用中」ライセンスとして表示されます。数字上は良好に見えます。その背後にある実際の利用状況を確認した人は誰もいませんでした。

次回の更新前に確認しておくべきポイント

サイン	通常、それはどういう意味か
合成、DFT、またはレイアウトのライセンスプールは、総数を承認する者がいないまま、数回の更新サイクルにわたって拡大してきた	追加項目は一つずつ審査を通過したが、その合計額自体は一度も審査されなかった
アイドルタイムアウトのレポートでは利用状況は正常と示されていますが、特定のライセンスに対して実際にジョブを実行しているユーザーが誰なのか、誰も特定できません。	「レジ＋タイマー」のビューは実際の利用状況ではない――このレポートは間違った問いに対する答えを出している
更新時には、事前に誰かがベースラインを再設定しなくても、「現在の使用状況」に合わせて調整されます。	更新時の流出――今年の変動幅が翌年の下限となる
各拠点やプログラムのチームは、他の拠点がすでに追加した席数が把握できないまま、追加の席をリクエストしている	オーバープロビジョニングは、目に見えない形でローカルに蓄積されていく

格差を埋める2つの方法

このカテゴリーのほとんどは、最初の問題を同じ方法で解決しています。それらが異なる点、そして特に「サブスクリプション・ドリフト」が見過ごされがちな点は、その後に何が起こるかという点にあります。

一般的なアプローチは、ライセンスサーバーのログを基盤としています。具体的には、現在誰がライセンスを保有しているかを示すリアルタイムの可用性情報、アクセス拒否されたユーザーとその日時を追跡する機能、部門やプロジェクトごとに分割されたコスト配分、および設定されたタイムアウト時間を超えて使用されていないライセンスを自動的に解放する回収ルールなどが含まれます。このカテゴリの一部のプラットフォームでは、クラウドライセンスの再割り当てを行うためのサブスクリプション最適化レイヤーも追加されていますが、これはEDAライセンスの回収とは別の仕組みです。

これらはすべて実際の機能であり、実際の無駄を明らかにします――誰も解放するのを忘れていたライセンス、追加の容量購入を正当化する（あるいは正当化しない）拒否パターン、誰も開いていないライセンスの料金を黙って支払っている拠点などです。しかし、これらの情報からは、現在割り当てられているライセンスが実際に使用されているかどうかはわかりません。そのすべてが、依然として「チェックアウトとアイドルタイマー」のデータに基づいているからです。 20分ごとに2分間だけ操作され、アイドルタイマーをリセットするのにちょうど十分な頻度でアクセスされる合成シートは、その同じログの上にいくつのモジュールが載っていようとも、その間ずっと「アクティブ」と認識されます。

更新前に確認すべき事項	一般的なアプローチ	Open iT （レベル1＋レベル2）
この席は現在、誰によって予約されていますか？	はい	はい
誰かが入場を断られたことはありますか？また、それはいつのことですか？	はい – 否認の追跡	はい –レベル1の否認報告書
この費用は、どのサイトまたは事業部門に計上されるのでしょうか？	はい	はい
この座席は、自動で解放されるほど長い間空いたままだったのでしょうか？	はい、固定のアイドルタイムアウトクロックに対して	はい、単なる時計の表示ではなく、測定された活動不足度と相関させています
この席に座っている人は、今実際にそこで働いているのでしょうか？	いいえ――チェックアウトとアイドルクロックから推測したものであり、測定したものではない	はい。エンドポイントで計測されたキーボード、マウス、CPU、およびI/Oのアクティビティは、「ワークレシオレポート」を通じて確認できます。
今年追加された項目――それらは一つずつ、サイトごとに承認されてきたものだが――は、更新前に誰も確認していなかった何かを構成していたのだろうか？	いいえ――各レポートはリアルタイムまたはサイトごとのものであり、昨年のベースラインに集計されるものはありません	はい。Open iTの実装チームは、更新前に顧客とドリフト数値を確認します。サイトごとに個別に確認するわけではありません。

その最後の行こそが、見解が分かれる点です。リアルタイムの空き状況、利用拒否の追跡、コスト配分、およびアイドルタイムアウトによるリソース回収は、いずれも「ある特定の時点で、ある特定の席」に関する疑問に答えるものです。 しかし、これらはいずれも、単独では、更新時に問われる「今年度の累計総数（全拠点で少しずつ追加されたライセンス数）が、組織が実際に使用している数と依然として一致しているか」という問いには答えられません。これは「このライセンスは現在アイドル状態か」という問いとは異なるものであり、前者の問いに答えるために構築されたツールでは、後者の問いには答えられないのです。

このような更新まであと90日という時点で、真の問題は、プラットフォームに十分なレポートがあるかどうかではなく、その中に重要な疑問に答えるものが含まれているかどうかです。レポートのカテゴリーがいくら多く並んでいても、その作業を省略できるわけではありません。単に、「データはあるか」という推測が、「どのレポートにそのデータが含まれているか」という推測に変わるだけです。

解決策は簡単です。1ユーザーあたり、1アプリケーションごとに、チェックアウト時間のうち実際にそのツールでの作業に費やされた時間を測定し、 契約更新の話し合いを行う前に、その数値を顧客と確認しておくことです。話し合いが終わってからではなく、その前に確認すべきです。

個々のマシンに手を加えることなくとも、ライセンスサーバーのログに記録されている基本的なチェックアウトおよび拒否のデータだけでも、問題の全容がすでに浮かび上がってきます。それは、数回の更新サイクルにわたって拡大し続けたプール、追加購入の是非を判断する根拠となる（あるいはならない）拒否パターン、そして作業が終了してからずっと後にまで開いたままになっているセッションなどです。 これは、「このプール全体がレビューされたか」という問いに対する現実的かつ有用な答えですが、ある特定の曖昧さを解消することはできません。20回に1回、2分間だけ使用されたライセンス席も、一度開かれてから一度も閉じられなかったライセンス席も、システム上では「継続的にアクティブ」と見なされるからです。これら2つを区別できるのは、マシン上で実際に何が起きているかを測定することだけです。

キーボード、マウス、CPU、I/Oといった直接的なアクティビティ測定は、まさにその役割を果たします。つまり、プロビジョニングされたモジュールが、更新前（更新後ではなく）に実際に使用されていたかどうかを示すのです。 この区別が最も重要となるのは、まさに本記事で取り上げているモジュール型製品ファミリーです。シノプシスのTestMAXはDFT、ATPG、Diagnosis、Manager、Advisor、ALEに分かれており、シーメンスEDAのCalibreはnmDRC、nmLVS、PERC、Auto-Waivers、SONR、Fab Insightsに分かれています。これらはそれぞれ独立したライセンス製品であり、チームはプロジェクトの特定のフェーズでプロビジョニングした後、二度と利用することはありません。 Design Compiler、TestMAX、IC Compiler、Calibre、MATLAB、LabVIEWは、この比較がすでに今日でも適用可能なツールです。

データは、専門家がレポートを解釈するのを待たずに、誰かがそのデータに基づいて行動できるようになって初めて、その価値を発揮するのです。

よくある質問

いずれにせよ、次の契約更新はやってくる。唯一の本当の選択は、その金額がチーム側が納得できるものになるか、それとも双方にとって初めて目にする金額になるか、ということだ。