- ライセンスの拒否には3つの原因が考えられます――真の不足、貸し出されたまま放置されているシート、あるいはサーバーがライセンスを割り当てられなかった場合――そして、そのうちの1つだけが「購入」を意味します。
- ライセンス担当チームは、この区分を「真の拒否」と「偽の拒否」と呼んでいます。これらを見分けるには、同じ瞬間を2つの視点から捉える必要があり、ライセンスプールを拡大することではありません。
- Mitta Oyでのライセンス拒否は、ライセンスサーバーの不具合や、場合によってはライセンスファイル内のサーバー行やホスト名の欠落に起因していたため、前任のチームはサーバーの不具合を修正するためにライセンスを購入し続けていた。
月曜日の午前9時前に届いた4通の拒否メール：Petrelへのアクセスが拒否された2人の地球科学者、nAvigatorのライセンス枠がない理由を尋ねるリザーバー担当責任者、そして10時42分に理由の説明もなく失敗したリクエスト。ログには拒否されたことが記録されている。しかし、その理由は記録されておらず、その理由こそがすべてを決定づける――適切な対応が発注書なのかサービスチケットなのか、そして今年費やされた資金が容量の確保につながるのか、それとも不具合の隠蔽に充てられるのか。
ライセンスの申請が次々と却下されたため、チームはさらにライセンスを購入した。利用データがない状況では、購入こそが彼らにできる唯一の手段だった。
サーバーに不具合が生じていた。フィンランドの建設業界向けコンサルティング会社であるミッタ社は、ライセンスサーバーを交換し、その背後に利用状況の監視システムを導入した結果、この事実を突き止めた。アクセス拒否の原因は、需要の急増によるものではなかった。ライセンスを割り当てることができない不具合のあるサーバーが原因であり、場合によってはライセンスファイル内のサーバー行やホスト名が欠落していたことも原因となっていた。同社は、サーバーの不具合を修正するためにライセンスを購入し続けていたのだ。
業界は違っても、犯すミスは同じです。しかも、石油技術分野では、そのミスが1席あたりはるかに大きなコストを招きます。次に購入するツールが、あなたがどのようなミスを犯しているかを指摘してくれるかどうかを判断するには、5つの質問が鍵となります。
1. これは不足なのか、保留中のモジュールなのか、それともサーバーの故障なのか？
拒否の通知には、10時42分にリクエストが失敗したと記載されています。その理由は明記されていません。回答は3つあり、それぞれ異なるアクションにつながりますが、そのうち購入につながるものは1つだけです。
業界では、これを「真の拒否」と「偽の拒否」と呼ぶ。真の拒否とは、座席が実際に満席だったためにリクエストが失敗したケースを指す。一方、偽の拒否とは、割り当て枠にまだ空きがあったにもかかわらずリクエストが失敗したケースであり、空きが遊休状態のまま放置されていたか、あるいはそもそも割り当てられなかった場合である。ライセンスデスクが扱う拒否のほぼすべては、前者の種類として記録される。というのも、ログからは両者を区別する手がかりが得られないからだ。
| データが示すこと | その意味 | どうすればいいか |
|---|---|---|
| 利用を否定するケース、および実際に使用されているすべてのライセンス | 深刻な容量不足――完全な否認 | 購入 |
| 使用拒否、ライセンスは取得済みだが未使用のまま | プールは問題ない。模様が気に入らない | 無駄な時間を有効活用しよう |
| 免許が放置されている間の否認 | 容量の問題など全くない――サーバーかライセンスファイルかの問題だ | インフラを整備し、購入は控える |
3行目は、一目で把握できない部分です。「拒否レポート」では、リクエストが失敗したことや、誰がブロックされたかがわかります。一方、「リアルタイムライセンスモニターポータル」では、その時点で空きライセンスがあったことがわかります。この2つの情報の不一致こそが、重要なシグナルとなります。Mittaは、メールによるアラートではなく、このリアルタイムのビューに基づいて動作します。なぜなら、その処理量であれば、ダッシュボードだけで十分だからです。
次に、修正方法についてですが、これはサーバー側の作業であり、購入を必要としません。 CLIMS これにより、サーバーごとにRDPセッションを開く代わりに、ブラウザ上でベンダーデーモンのステータス、コンソール出力、デバッグログを確認できるほか、ライセンスファイルの表示・編集、欠落した行を特定するためのセマンティック比較、3台のサーバーで構成される高可用性セット向けのトリアド検出機能も利用できます。
Mittaが実際の利用状況を把握すると、あるアプリケーションでは、観測されたピークユーザー数約30人に対して130ライセンス分の同時利用が想定されていたことが判明し、この適正化だけで年間3万～4万ユーロのコスト削減が見込まれました。Autodeskのライセンス数は生産性に何の影響も及ぼすことなく、最大で半減しました。 ライセンスプールが小さいと、診断は容易になるどころかむしろ困難になります。4人で2つの高価なライセンスを共有している場合、1つのライセンスが占有されているということは、誰かが利用できない状態にあることを意味するからです。当時ミッタのITディレクターを務めていたマルコ・ウッコラ氏は、まさにこの理由から利用状況の監視を推奨しています。彼の言葉を借りれば、それは「不安定なライセンスサーバーを特定する」のに役立つからです。
中間のケース、つまりライセンスがチェックアウトされたまま遊休状態にある場合を考えてみましょう。Petrelでは、この状況を構造的な問題として捉えています。70以上の個別にライセンスが必要なモジュール、起動の遅さ、そして過去に利用を拒否された経験を持つ従業員たち――こうした要因により、人々は「今すぐ使うもの」ではなく「必要になりそうなもの」を予約してしまうのです。モジュールの買い占めは、それが行われる現場の立場からすれば合理的な行動なのです。 エンジニアリング部門全体で見ると、チェックアウト時間のうちアイドル状態の割合は通常20％から40％に上り、これだけでも購入の決定を左右するのに十分な要因となります。
これを把握するには2種類の測定が必要であり、Open iT ではこれらを「ティア」として販売しています。1つ目は、ライセンスサーバーのログを読み取ります。具体的には、誰がいつ利用を拒否されたか、キーボード操作がない状態でどのライセンスがチェックアウトされていたか、作業終了後もどの借用ライセンスがチェックアウトされたままだったかといった情報を把握します。この機能は、1時間ごとにライセンスマネージャーにポーリングを行い、5分ごとにサンプリングを行います。2つ目の測定方法は、マシン本体に直接アクセスし、チェックアウトされたシートが実際に使用されているかどうかを測定するものです。これにより、「作業比率レポート」が生成されます。これは、各アプリケーションおよび各モジュールごとに、総チェックアウト時間に対するアクティブ時間を示したものです。
最初のケース、つまり真の品薄状態の場合のみ、購入に至ります。また、誰もが自分が直面しているのはこのケースだと想定しています。
2. 実際には、どのライセンスマネージャーが表示されるのでしょうか？
FlexNetが真っ先に重要なのは、Petrelがこれ上で動作するからです。80のアプリケーションと7種類のサーバーは、石油技術分野の環境としては標準的な規模であり、そのポートフォリオは通常、共有スプレッドシートにまとめられています。
Open iTLicenseAnalyzer™は、ライセンスを割り当てるマネージャーから情報を読み取ることで、90以上のマネージャーにまたがる6,000以上のアプリケーションをカバーしています。FlexNetやPetrelもこれに含まれます。
| 得られるもの | どのマネージャーがそれを提供しているか |
|---|---|
| 同時利用状況、経過時間、および誰が何を保有しているかのリアルタイム表示 | tNavigator、Petroleum Experts (PetEx)、DUG Insight、Seequent、Itasca、Geoactive、Esri Cloud |
| 拒否事例：誰が、いつ拒否されたか | FlexNet、ひいてはPetrelに加え、Encom、Fekete、Peloton、Zetaware |
| ログファイルからの履歴のみ。リアルタイム表示はなし | Zetaware |
| 空席を単に報告するだけでなく、自動的にプールに返却する | FlexLM、LM-X、LUM、RLM |
| 起動、停止、オプションファイル、有効期限を一元管理できるコンソール | CLIMS が管理する12のLMのうち、PetExやtNavigatorなどが含まれる |
3. 本番稼働の前後、作業は誰が担当するのですか？
本番稼働が始まると、ツールは誰かの「副次的なプロジェクト」になってしまう。研修は手薄になり、レポートの責任者がいなくなり、ダッシュボードは1年経ってもまだロードマップ上のまま、利用状況データの取得は再び数日かかる依頼事項に戻ってしまう。
ですから、どのベンダーにも、最初の1ヶ月がどのような流れになるのか、また各ステップの終了時にどのような書面が送られてくるのかを確認してみてください。当社の場合は5つのステップで進みます。
- キックオフと計画策定。ハードウェア、ソフトウェア 、ネットワークの前提条件を準備リストと照らし合わせて確認し、ステークホルダーと範囲およびスケジュールを合意し、議事録とアクションアイテムを記録してから、いかなる導入も開始します。この段階で、以下のフットプリントがお客様にとって問題となるかどうかが判明します。発注後に問題が発覚するのではなく、当社と共にこの段階で確認できるのです。
- 技術的なセットアップと統合。コアサーバーおよび分析サーバーのインストールと設定を行い、接続性とデータ収集を確認した上で、インストールレポートを作成します。指定されたワークステーションにクライアントをデプロイし、要件に合わせて設定した後、クライアントとサーバー間の通信を確認し、概要報告書を提出します。重要なのはこの検証の段階です。なぜなら、意思決定の根拠となる数値が確実に取得できているかどうかを確認できるのは、この段階だからです。
- トレーニングと知識の伝達。システムを運用する担当者とレポートを閲覧する担当者向けのセッションを用意しており、マニュアルやガイドも提供されます。また、出席状況を記録することで、実際にトレーニングを受けた人物を把握できます。より深く学びたい場合は、別途4日間の公開コースも用意されています。「Engineeringソフトウェア Reporting & Analysis」（2026年9月1日～4日）および「Engineeringソフトウェア Administration & Optimization」（2026年9月8日～11日）のいずれもオンライン開催です。
- 最適化とユースケースの開発。デモで示されている内容ではなく、自社の課題に即したレポートを作成すること――どのレポートを財務部門に提出するか、どの閾値でアラートを発行すべきか、70のアプリケーションのうち、まずどの10のアプリケーションを測定すべきか、といった点です。
- 継続的なサポートとパートナーシップ。完了報告書、関連資料、および担当者の引き継ぎを行い、得られた教訓をまとめました。そして、ここからが数年にもわたる取り組みの始まりです。
実行するのはごく一般的な環境です。Windows Server 2016以降、Analysis Servicesを搭載したSQL Server、IIS、.NET、サービスアカウント、アプリケーションプールに加え、ホストマシンにはCore Clientがインストールされており、そのインストールには管理者権限が必要です。クラスターではありません。これは、WindowsやSQLを担当する担当者がすでに運用しているスタックそのものであり、そこが重要な点です。また、v10.2ではAzure SQL Serverの完全なサポートが追加されたため、他のIT環境が移行する際に、これもうまく移行できます。
それ以降の年については、重要なのはサポートのレベルではありません。重要なのは、マッピングがどこにあるかということです。
ベンダーは機能の名称を変更したり再パッケージ化したりしますが、ライセンス対象の機能と実際に購入した製品との対応関係を管理する役割が必要です。これは、1つのアプリケーションに商用コード、サードパーティ製コード、社内開発コードを含む70ものモジュールが組み込まれている場合、特に深刻な問題となります。Open iT は、メンテナンスおよびサポートの一環としてその対応関係を設定し、各顧客の環境で個別に再コーディングするのではなく、SSADに一元的に管理します。お客様側でこれを維持管理する必要は一切ありません。
さらに、人員を確保できない場合でも、業務を当社に委託することができます。この表に記載されているものはすべて、パッケージとして、あるいは品目ごとに個別に購入可能です。
| 移行可能なライセンス関連業務Open iT | 対象範囲 |
|---|---|
| 初期導入後の継続的なインストールおよび設定 | マネージドサービス |
| 誰も作る時間がなかったカスタムダッシュボード | カスタムレポートおよびダッシュボードの開発 |
| 契約更新前に、契約内容と実際の利用状況を照らし合わせる | ベンダー分析および交渉支援 |
| インシデントに発展する前にドリフトに気づく | 四半期ごとの健康診断 |
| 時差にまつわる日常的な問題 | グローバル技術サポート |
レポートはExcel、Power BI、Tableau、およびネイティブのSSRSを通じて出力され、LicensePlanner™は従業員数ではなく実際の使用量に基づいてコストを配分します。
この状況における「サポート」とは、誰かが電話に出てくれるという意味ではありません。それは、その仕事がそもそも担当者のデスクに届くことがないという意味です。
4. 午前3時のセッションはどうなるのでしょうか？
これは「ウェルオペレーション」に関する問題であり、この話題で会話が途切れてしまうこともあります。反対意見が「作業の損失」に関するものはほとんどありません。自動保存機能があれば、その点は問題にならないからです。問題は「再アクセス」にあります。つまり、決定を待つその瞬間に、再度ログインし、モジュールを選択し直し、データを読み込み、ビューを再構築しなければならないという点です。
状況に応じて対処法が決まります。Mittaでは、席が占有されている場合の対処法は電話一本です。誰がどこでその席を使っているかがわかるので、数時間だけ空けてもらうよう依頼するだけです。しかし、3つのタイムゾーンにまたがる数百人のPetrelユーザーがいる状況では、電話一本では対応しきれないでしょう。
Open iT を使用すると、4つのルール優先度レベルにわたり、「ログ」「スタンバイ」「サスペンド」「終了」という4つの方法でアイドル状態のセッションを解放できます。これには時刻や曜日の条件も設定できるため、例えば午前3時の井戸作業時間帯は、信頼関係に基づくのではなく、ルールによって除外されます。 中でも重要なのが「一時停止」です。ライセンスはプールに戻され、作業内容は画面上に残ります。Petrel用にあらかじめ作成された自動保存スクリプトも同梱されています。Petrelを再起動するにはエンジニアが20～30分を要するため、一時停止が終了よりも優れているのです。
「Terminate」という機能は存在します。これを有効にするかどうかは、当社ではなく、お客様ご自身で判断してください。
5. 従業員代表委員会とセキュリティチームには、どのような情報を伝える必要がありますか？
これは、システムに送信される測定データによって決定されます。アイドル状態のセッションとアクティブなセッションを区別するために、ホストマシンに軽量なコレクターが配置され、それらのコレクターがCPU、I/O、キーストローク、およびマウスの操作を測定します。ほとんどのエネルギー関連組織では、この記述は従業員代表委員会や倫理方針、あるいはその両方の審査を通過しなければならず、そうあるべきです。
つまり、これらの制御機能はデータシートのためではなく、その会議のために構築されているのです。ユーザー名は、可逆的または不可逆的に匿名化することができます。アクセスはロールごとに制御されるほか、OLAPキューブ独自のデータレベルでも個別に制御されるため、レポートに何が表示されるかは、それを開いたユーザーによって異なります。個人名を一切明かさない傾向分析が、このシステムを運用する一般的な方法であり、これが、測定プログラムが順調に開始されるか、それとも審査の段階で停滞してしまうかの分かれ目となります。
拒否に対する3つの対応策があり、そのうちの1つだけが「購入」です。これらを区別するのはデータです。サポートがあれば、設定した担当者が休暇中であっても、そのデータが確実に届き続けます。
入手するOpen iT
まず、役割の割り振りを確認してください。どのライセンスマネージャーが「管理対象」、どのマネージャーが「監視対象」、どのマネージャーが「履歴のみ」、どのマネージャーが「いずれも該当しない」となるかを確認してください。
