Uncategorized

これまでの議論で、「グローバルなエンジニアリング」と「ローカルなライセンス条件」がいかに衝突しやすいかを見てきました。 では、もしベンダーにその違反を“見つけられたら”、何が起こるのでしょうか。 ソフトウェア資産管理（SAM）の世界で、最も高額な請求につながる手紙は、たいてい次の一文から始まります。 「貴社を通常のライセンスコンプライアンスレビューの対象として選定しました。」 Ansys、Autodesk、Dassault Systèmes などのハイエンドCAE／CADベンダーがグローバル企業を監査する際、単に「ライセンス数が足りているか」を見ているわけではありません。彼らが本当に狙っているのは 「地理的リーク（Geographic Leakage）」 です。 つまり、 低価格な「ローカルライセンス」が 本来許可されていない高コスト地域で使用されていないか 出張中・海外拠点からアクセスされていないか という点です。 以下は、なぜ地理的監査が“多層的な財務災害”になるのかを分解したものです。 目次 「MSRPペナルティ」（割引リセット） バックメンテナンス（“時間をさかのぼる税金”） 「サブスクリプションという銃を突きつけられる」 見えにくいコスト：利用場所の証明 なぜ「グローバルライセンス」は保険だったのか 結論：可視化こそ唯一の防御策 「MSRPペナルティ」（割引リセット） 大企業の多くは、ボリュームや長期取引を理由に、定価（MSRP）から30〜50％の割引を受けています。 しかし、地理的違反（例：インド向けに購入したライセンスをドイツで使用）が見つかった瞬間、ベンダーはその使用を 「有効なライセンスゼロ」 とみなすのが一般的です。 その結果、 最も高額な「グローバルライセンス」 しかも 割引なしのMSRP価格 で「是正購入（Remediation）」を要求されます。 例： 本来の想定価格（ローカル） 20ライセンス × 25,000ドル = 500,000ドル 監査後に要求される価格（グローバル・MSRP） 20ライセンス × 50,000ドル = 1,000,000ドル ➡ 差額（実質ペナルティ）：500,000ドル バックメンテナンス （“タイムトラベル税”） ベンダーは「今」グローバルライセンスを買え、とは言いません。 「過去に失われた保守費用」 も請求してきます。 通常、監査和解では 過去2〜3年分

私がこれまで関わってきた会議室や開発現場では、いつも2つの考え方の対立を目にしてきました。 それを私は次のように呼んでいます。 「完成してから見せる」考え方 「一緒に作りながら改善する」考え方 完璧主義の落とし穴（完成してから公開） この考え方は、 「完璧になるまで外に出さない」というものです。 エンジニアリングの現場では、まだユーザーに使われてもいない機能やUIを、何週間もかけて細かく作り込むことがあります。これは一見、安全で正しいように感じます。 しかし、変化の早い環境では大きなリスクになります。 リスク例 6か月かけて「完璧な橋」を作ったのに、 ユーザーが本当に必要としていたのは「船」だった、ということが起こります。 完成した頃には、 要件が変わっている ユーザーの使い方が想定と違う ということは珍しくありません。 段階的に進める開発（反復・改善型） もう一つの考え方が、OpenLMが大切にしている方法です。 早く出す・何度も改善する まずは「動くけれど、まだ完璧ではない」状態でリリースします。 そして実際の現場でどう使われるかを見ます。 これは「未完成」なのではなく、「状況にすぐ対応できる」開発です。 戦略の考え方：「2-way ドア」 Amazonのジェフ・ベゾスは、意思決定を2種類に分けています。 ① One-Way ドア（後戻りできない決定） 基本アーキテクチャ 基幹システムの技術選定 これは慎重に、時間をかけるべき ② Two-Way ドア（やり直せる決定） 機能追加 UI変更 API設計 など 間違えたら戻せばいい 日本の現場では、この 「Two-Way ドア」まで完璧を求めてしまい、スピードが落ちることがよくあります。 リーナス・トーバルズに学ぶ Linuxの開発者、リーナス・トーバルズはこう考えました。 「早く出す。何度も出す。そしてユーザーの声を聞く」 Linuxは、完成形になる前に公開されました。 それによって、世界中のエンジニアからフィードバックが集まり、品質が急速に向上しました。 一人で完璧を目指すより、多くの目で早く改善する方が強い、という考え方です。 研究でも証明されている マシュマロ・チャレンジ 子どもたちは「とりあえず作って、壊して、直す」。大人は「完璧な計画を立ててから作る」。結果は、子どもの方が成功率が高い。 Pixarの方法 Pixarでは「最初の映画は必ずダメ」と考え、早い段階で厳しいフィードバックをもらいます。 モノリス開発 vs 小さなリリース 完璧主義型 数か月こもって開発 一気にリリース ユーザーが使いにくいと気づくのが遅い 反復型

現在のエンジニアリング業務は、国境を越えて行われています。例えば、ドイツで設計し、インドでレビューし、アメリカのクラウドで解析するといったことは珍しくありません。 しかし一方で、ソフトウェアライセンスの契約条件は今も「国・地域」に縛られたままです。 ソフトウェア資産管理（SAM）担当者やIT責任者にとって、この「地域制限ライセンスのギャップ」を理解しているかどうかは、 無駄なコストで済むか、高額な監査リスクになるかの分かれ目になります。 目次 「見えないグローバル税」 ライセンス違反が起きる2つの典型パターン 賢いエンジニアによる回避 出張エンジニアの落とし穴 コンプライアンス対策：事前防止か、事後検知か A. 事前に防ぐ方法（自動制御） B. 事後に把握する方法（可視化・監視） まとめ：これからは「データ」で管理する時代 「見えないグローバル税」 多くのソフトウェアベンダー（Autodesk、Dassault、ANSYSなど）は、 ライセンスの使用地域を以下のように分けています。 シングルサイト 特定のオフィス、または半径50マイル以内のみ使用可 地域限定（大陸単位） EMEA、APAC など特定地域内のみ使用可 グローバル 世界中どこでも使用可 問題は価格です。 グローバルライセンスは、シングルサイトの2～4倍の価格になることもあります。 以前は、人件費の低い国向けに安い価格設定（LCE）がありましたが、現在はグローバル価格へ移行しています。 しかし、価格が同じでも「使用地域の制限」は契約上、依然として有効です。 つまり、 「ドイツ向けライセンスを中国で使う」ことは、今でも契約違反になります。 ライセンス違反が起きる2つの典型パターン ① 賢いエンジニアによる回避 エンジニアは問題解決が得意です。 もし自分の拠点のライセンスサーバーが満杯だった場合、別の国・地域にあるライセンスサーバーのIPアドレスを指定してライセンスを取得することがあります。 技術的には使えてしまいますが、契約上は明確な違反です。 ② 出張エンジニアの落とし穴 例えば、 インド拠点のエンジニアが、英国に出張したケースを考えてみましょう。 英国オフィスのWi-Fiに接続 インドのライセンスサーバーからライセンスを取得 多くの契約では、 「実際に使われた場所（英国）」が使用地域とみなされます。 グローバルまたは出張対応ライセンスがなければ、知らないうちにライセンス違反になってしまいます。 コンプライアンス対策：事前防止か、事後検知か 事前に防ぐ方法（自動制御） 違反が起きる前に、そもそも使えないようにする方法です。従来は、ライセンスのOptions Fileを手作業で管理していましたが、運用が複雑で、ミスが起きやすいのが現実です。 OpenLMでは「LAC（License Access Control）」でこれを自動化します。 Active Directory

長年にわたり、GIS ライセンスは「柔軟」であることが当たり前でした。企業は永続ライセンス（買い切り）を購入し、比較的安価な保守費用を支払い、「同時使用（フローティング）」モデルで高価なライセンスを多くの技術者で共有してきました。 しかし、その時代は終わりを迎えています。 Esri ライセンスを管理している企業にとって、2025年後半から2026年にかけて起きる変更は、過去20年で最大の転換点です。 私たちはこれを **「Esri ライセンス移行（サイレント・マイグレーション）」**と呼びます。 なぜ「サイレント」なのか。それは、1回の大きな契約変更ではなく、管理上のデフォルト設定変更や技術的なサポート終了によって、静かに進行するからです。 ここでは、2026年の Esri ライセンス変更で何が起きるのか、そしてどう対応すべきかを解説します。 目次 ArcGIS 永続ライセンスの変更 同時使用ライセンスの終了（コストの問題） 2026年のタイムライン：技術的な「ロックアウト」 大規模組織向け Esri ライセンス戦略：最適化 まとめ ArcGIS 永続ライセンスの変更 最初の変化は「管理面」です。これまでソフトウェアを使い続けるためには、毎年「保守（Maintenance）」を支払うだけで十分でした。 しかし 2025年後半以降、状況は大きく変わります。 新しい Esri の方針では、ArcGIS Desktop の永続ライセンス更新見積は「保守」ではなく、自動的に「ユーザータイプ（年額サブスクリプション）」に変換されます。 これはつまり、 資産として所有する CapEx（資本支出）モデル から 毎年支払う OpEx（運用支出）モデル への移行 を意味します。 これまで「所有している」と考えていた永続ライセンスは、実質的にレンタル契約へ移行することになります。 参考記事：2026年に向けたソフトウェア資産管理（SAM）のベストプラクティス 同時使用ライセンスの終了（コストの問題） 最も大きなコスト影響を与えるのが、同時使用（コンカレント）ライセンスの廃止です。 従来モデルでは、例えば以下のような運用が可能でした。 土木・建設エンジニア：100名 実際のライセンス保有数：20本 同時に使う人が限られるため、1:5 の共有比率でコストを抑制 しかし、新モデルは 「指名ユーザー（Named User）」 です。 このモデルでは、 100名の技術者 ＝

ソフトウェア資産管理（SAM）は、コスト削減・コンプライアンス対応・業務効率化のために欠かせません。管理が不十分だと、使われていないソフトへの無駄な支出や、ベンダー監査時のリスクが高まります。 ここでは、2026年に向けた実践的で分かりやすいSAMのポイントを紹介します。 ソフトウェア資産を正しく把握する まずは「何を使っているか」を可視化することが重要です。 PC、サーバー、クラウド、SaaSを含めて自動で検出 社員が無断で使っているWebサービス（シャドーIT）も把握 ハード・ソフト情報を1か所で管理 SAMライフサイクルを標準化する ソフトウェアは購入から廃棄まで一貫して管理する必要があります。 購入：契約内容・費用・ベンダー情報を一元管理 導入：必要なユーザーのみにライセンスを付与 廃棄：不要なソフトは削除し、コストとリスクを削減 利用状況を最適化する コンプライアンス対応だけでなく、実際の利用状況を見ることが重要です。 使われていないライセンスを回収 利用されていないSaaS契約を削減 「誰が持っているか」ではなく「誰が使っているか」を確認 管理を自動化する 手作業の管理には限界があります。 権限のない利用を自動で制御 ライセンス期限切れなどを事前に通知 レポート作成を自動化 ソフトウェア監査に備える 監査対応は日頃の準備が重要です。 操作履歴・利用ログを保存 契約で定められた地域で使われているか確認 購入証明・契約情報をすぐ提示できる状態にする OpenLMによるライセンス管理の強化 CAD / CAE など高額なエンジニアリングソフトには、専門的な管理が必要です。 OpenLMは、リアルタイムでライセンス利用を可視化し、無駄なコストを削減します。 ServiceNowなどと連携することで、SAMとIT資産管理を一元化できます。 よくある質問（FAQ） SAMのベストプラクティスとは？ 可視化、標準化、最適化、自動化、専門ツールの活用です。 なぜSAMが重要なのですか？ コスト削減、監査対応、セキュリティ強化につながるためです。 ITAMとSAMの違いは？ ITAMはIT資産全体、SAMはソフトウェア管理に特化しています。 SAMは自動化できますか？ はい。ライセンス回収やアラート、レポート作成は自動化可能です。 フリーバージョンダウンロードの後は？ ライセンスパーサー 紹介ビデオ よくある質問  

License Access Control（LAC）は、OpenLMプラットフォームの中核機能です。 「誰が・いつ・どのソフトウェアを使えるか」という業務ルールを、IT環境で自動的に実行する仕組みです。 以前は、この機能は「Options File Management」と呼ばれていました。当時は、サーバーにログインし、複雑なオプションファイルを手作業で編集する必要があり、ミスが許されない運用でした。 OpenLMは最初にUIベースのOptions File Managerを提供しましたが、それでも本質は設定ファイル作成ツールでした。 現在のLACは、考え方そのものが変わっています。 LACの進化ポイント ベンダー非依存のライセンス制御 LACはFlexLMだけでなく、OpenLMが対応するすべてのベンダーを対象にします。 FlexLM / RLM：オプションファイルを自動生成 Autodesk / Adobe / SaaS：APIや管理画面と直接連携 管理者は「ルール」を定義するだけで、配信方法はOpenLMが自動処理します。 細かいライセンス制御 LACでは、業務ルールをそのままライセンス制御に反映できます。 操作：許可（INCLUDE）／禁止（EXCLUDE）／専用確保（RESERVE） 対象：ユーザー、ADグループ、端末、IP 単位：製品だけでなく機能（Feature）単位も可能 例：MATLABは全員、Simulinkは上位エンジニアのみ。 Namedライセンス (名前付きの個人席)管理の3つの方法 LACは、以下の方法でNamedライセンスを管理します。 ① 疑似Named フローティングライセンスを特定ユーザー用に予約し、常に使える状態を確保。 ② Network Named User（NNU） 安価なNamedプールへ自動振り分けし、高価なフローティング利用を防止。 ③ クラウド（SaaS） AD連携により、ライセンスの付与・回収を自動化。 ディレクトリ連携による自動化 Active Directory / Azure AD と連携し、人事変更に合わせてライセンスを自動更新します。 例： 社員が 「インターン」から「エンジニア」 に変わった場合、 →

はじめに 2000年代初頭、IT業界は大きな転換点を迎えました。それが サーバー仮想化 です。 当時は、「1つのアプリケーション＝1台の大きな物理サーバー」という考え方が主流でした。 しかしこれは、 無駄が多い 柔軟性がない 管理が難しいという問題を抱えていました。そこで登場したのが仮想化です。1台の大きな物理サーバーを、複数の 仮想マシン（VM） に分割し、用途や担当ごとに自由に割り当てられるようになりました。 今、同じ問題が「ライセンス管理」で起きている 現在の ソフトウェア資産管理（SAM） は、まさに「仮想化前のハードウェア時代」と同じ課題を抱えています。 特に 指名ユーザー（Named User）ライセンス です。 多くの企業では、 Adobe Creative Cloud：1,000ライセンス Microsoft 365：1,000ユーザー Autodesk：数百〜数千ライセンス といった 巨大なライセンスプール を保有しています。 ベンダーから見ると、これは「1,000個のメールアドレスの一覧」にすぎません。 しかし、IT管理者にとっては管理不能に近い巨大な塊 です。 ライセンスにも「仮想化」の考え方を そこで必要なのが、ライセンスを仮想化する という考え方です。 OpenLM Virtual License Manager（VLM）の役割 VLMは、 ベンダーの管理ポータル 実際のエンドユーザー の 間に立つ仕組み です。 巨大な1つのライセンスプールを、組織構造に合わせて、論理的に分割（仮想化） します。 コンセプト：原子を分けるように 750人、1,000人分のライセンスを1つの塊で管理するのは現実的ではありません。 VLMでは、次のように分割できます。 仮想プールA（プロジェクト「Falcon」）：50ライセンス → プロジェクトマネージャーに委任 仮想プールB（シミュレーション部門）：200ライセンス →

Autodesk（Revit など）のライセンス管理では、ITマネージャーやBIMマネージャーがとても気にする数字があります。 それが 「損益分岐点（ブレークイーブンポイント）」 です。 考え方はとてもシンプルです。 Revit 年間サブスクリプション 約 2,835ドル / 年 → 約 236ドル / 月 Revit Flex（トークン） 1日 10トークン → 約 30ドル / 日 計算すると： 236ドル ÷ 30ドル ≒ 約7.8日 ここから、業界ではこんなルールが生まれました。 「月に8日以上Revitを使う人はサブスク、それ以下ならFlex（トークン）」 一見、正しい計算に見えます。しかし、大きな落とし穴があります。 それが 「季節変動（シーズナリティ）」 です。 平均値の落とし穴 「月8日ルール」は、人が毎月同じように働くことを前提にしています。 でも、現実は違います。 12月：年末休暇、会社の休業、作業停止 8月：夏休み、長期休暇 プロジェクトの空白期間： 設計完了から次フェーズまでの数週間 年間サブスクリプションは、12か月ずっと使う前提の料金です。使っていない日が増えるほど、1日あたりの実際のコストは高くなります。ケーススタディ：使用が不安定なプロジェクトマネージャー 例えば、こんな人を想像してください。 利用者のタイプ シニアアーキテクト / プロジェクトマネージャー 普段は毎日Revitを使わない でも締切前は一気に使う 利用パターン 春（3〜4月）：締切で多く使用

設計・エンジニアリング用ソフトウェアの管理は、とても重要で難しい業務です。これらのソフトウェアを管理している方の多くは、FlexLM（FlexNet Publisher）を使ってライセンス管理を行っていると思います。 FlexLMは、Autodesk、MATLAB、Siemens などの主要ベンダーで使われている、業界標準の同時利用（コンカレント）ライセンス管理システムです。 しかし、FlexLMの標準機能だけでは、見えない問題（無駄）が多く残ります。 ライセンスコストを本当に削減するためには、「何ができて、何ができないのか」を正しく理解する必要があります。 目次 FlexLMの標準ライセンス管理とは？ 基本的なFlexLM監視の課題 本当の利用状況が見えない ライセンス不足への後追い対応 ライセンスの買いすぎによる高コスト OpenLMによる高度な最適化 起動しているだけでなく「実際の利用」を監視 リアルタイムで判断できるデータ ディレクトリ連携による利用状況の見える化 グローバル環境でのライセンス最適化 エンジニアリングライセンスを本当に管理するために よくある質問（FAQ） FlexLMの標準ライセンス管理とは？ FlexLMは、社内ネットワーク内でソフトウェアライセンスを配布・管理する仕組みです。 多くの場合、「フローティング（共有）ライセンス」が使われます。 中央のライセンスサーバーにライセンスが保管される ユーザーがソフトを起動するとライセンスを取得 ソフトを閉じるとライセンスが戻る FlexLMの標準レポートで分かることは、主に以下です。 現在、何本のライセンスが使われているか 誰がライセンスを使用しているか ライセンスサーバーが正常に動いているか また、ノードロックライセンス（特定PC専用） とフローティングライセンス（共有） の違いもあります。 ノードロック：管理は簡単だが柔軟性が低い フローティング：効率的だが、しっかりした監視が必要 基本的なFlexLM監視の課題 標準機能では、コストに直結する重要な質問に答えられません。本当の利用状況が見えない FlexLMは「ライセンスが取得された」時点で「使用中」と判断します。 しかし実際には、 ソフトを起動したまま会議に行っている バックグラウンドで開きっぱなし といったケースも多くあります。本当に使われているのか、放置されているのかが分かりません。 ライセンス不足への後追い対応 ライセンスが足りないと「ライセンス拒否（Denial）」が発生します。 標準ログでは記録されますが、 本当にライセンスが足りないのか サーバー障害なのか 特定ユーザーが占有しているのか といった原因までは分かりません。 ライセンスの買いすぎによる高コスト 状況が見えないため、多くの企業は「足りなくなると困るから多めに購入」します。 その結果、 使われていない高価なライセンスに多額の費用を払うことになります。 OpenLMによる高度な最適化 OpenLMは、FlexLMの情報を活用しながら、 より深い分析と自動化でコスト削減を実現します。

ソフトウェアライセンスを正しく管理することは、現在のIT部門やエンジニアリング部門にとって非常に重要です。エンジニアが必要なツールを使えないと、生産性はすぐに低下します。一方で、「念のため」にライセンスを多く購入しすぎると、コストが無駄に増えてしまいます。 FlexNet Publisher がよく知られていますが、多くの重要なエンジニアリングソフトは Reprise License Manager（RLM） を使っています。Maxon、RWS、Foundry などのベンダー製品を利用している場合、日常的に RLM を管理している可能性があります。 このガイドでは、RLM とは何か、なぜ重要なのか、そして効率化とコスト削減のためにどのように管理すべきかを解説します。 目次 Reprise License Manager（RLM）とは なぜエンジニアリングチームはRLMを使うのか 課題：可視化と管理の難しさ 集中管理によるRLMの最適化 リアルタイム利用状況の確認 ライセンス拒否の把握 コスト最適化 まとめ Reprise License Manager（RLM）とは？ Reprise License Manager（RLM）は、多くのソフトウェアベンダー（ISV）が利用しているライセンス管理ツールです。FLEXlm（現在の FlexNet）の開発者によって作られ、従来のライセンス管理の複雑さを改善するために設計されました。 RLMの考え方は「シンプルで分かりやすい」ことです。ライセンスのルールはアプリ内部ではなく、ライセンスファイルに明確に記載されています。 そのため、管理者はテキストファイルを見るだけで、 フローティング（共有）ライセンス ノードロックライセンス メータードライセンス などの内容を簡単に確認できます。 ※ 参考記事：DSLS ライセンス管理の解説（監視と最適化） なぜエンジニアリングチームはRLMを使うのか RLMは、変化の多いエンジニアリング環境に柔軟に対応できるため、多く利用されています。 ライセンス借用（Roaming） オフライン環境でもライセンスを利用でき、出張先やVPNなしのリモート作業に便利です。 フェイルオーバー機能 メインサーバーが停止しても、自動でバックアップサーバーに切り替わり、作業を止めません。 マルチOS対応 Windows、Linux、macOS に対応しており、研究開発部門の多様な環境に適しています。 課題：可視化と管理の難しさ RLM自体はシンプルですが、大規模な環境では管理が難しくなります。 複数のRLMサーバーや、FlexNet、DSLSなど他のライセンス管理ツールが混在することもあります。 よくある課題： 利用状況が分かりにくい 複数のログや管理画面を確認する必要があります。