SLO Japan: ソフトウェアライセンス最適化

エンタープライズ ソフトウェアの進化に合わせたソフトウェア資産の管理する

共有
Randy Littleson

ZDNet に、「The Evolution of Enterprise Software: An Overview  (エンタープライズ ソフトウェアの進化：概観)」というタイトルの面白い記事があった。記事では、これまでエンタープライズ ソフトウェアがどのように進化し、その進化によって、平均的企業に、どのような課題がもたらされたかについて興味深い知見が紹介されている。ことさら目を引いたのは、ソフトウェア ライセンスについてのライターのコメントである。彼曰く：

エンタープライズ  ソフトウェアのライセンス条件は非常に入り組んでいて分かりづらい。特に、大手ベンダーが、幾度かの買収の結果として、買収先ごとに異なるライセンス スキームがスイートに統合されている場合、その複雑さは尋常ではない。不完全なソフトウェア資産の管理ツールを使っている会社では、これ複雑さが、多大なコンプライアンスの違反金を払う原因にもなりかねない。

しかし、ほとんどの大手ベンダーは買収を通じて成長してきているのが現実であり、そうでない場合でも、複数の製品をそれぞれ異なるライセンス モデルで提供することや、顧客が望む利用方法に応えるため、製品ごとに複数のモデルが用意することは全くめずらしいことではない。

しかしながら、これを人の手で管理するというのは、ほぼ不可能だと言っていい。積極的にソフトウェア資産を管理して、ソフトウェア ライセンス契約のコンプライアンスを継続的に維持し、ソフトウェアの支出を最適化する場合、次のようなプログラムが絶対に必要になってくる。

• 明確な役割分担 (オーナーシップ) に基づく 
• 適切なテクノロジーに支えられた 
• ベスト プラクティス ソフトウェアの資産管理 (SAM) プロセス。

ソフトウェアの資産管理とソフトウェア ライセンスの最適化テクノロジーは、ソフトウェア製品およびベンダー固有のライセンス情報が格納されている高価値ライブラリを取り入れることで、企業に多大な恩恵をもたらすことができる。このための専用ツールでは、人の手では管理と有効活用が実質的に不可能な必要不可欠情報を”製品化”することで、これを実現している。ソフトウェア ライセンスの管理 (ライセンスの調整) プロセスでは、データが収集、正規化 (ノーマライズ) された後、インベントリ データとライセンス エンタイトルメント データ （発注と契約データ) が比較され、ライセンスの使用状況が明らかにされる。エンタープライズ側における利点は、ライセンスの調整作業中に、ライブラリ内のビルトイン情報の自動適用によって引き出される洞察という形で得られる。

アプリストア基本講座：ソフトウェア資産データを活用して、ライセンス コンプライアンスを維持する

共有
Laura Noonan

エンタープライズ アプリストアについて聞かれたら、ビジネス ユーザーは何を連想するだろう。簡単に目を通せるオンライン カタログ。アップルの App Store や Google Play のような買い物サイト。手間なく、すぐに入手可能なアプリ。

だが、IT のプロとしては、何が頭に浮かぶだろう。すべてのアプリは、適切にライセンス付与され、ライセンスの契約条件に違反していないか。エンタープライズにおけるソフトウェア投資予算は賢く使われているか。コストの最小に抑えながらソフトウェア支出も最適化されているか。これらの目標は、IT 環境の規模や複雑度、また、ソフトウェア ライセンス モデルの種類や複雑さによっては、いつも簡単に達成できるとは限らない。

幸いなことに、コストを抑制し、ライセンス コンプライアンス リスクを最小限に抑えながら、ユーザーの期待とニーズを満たすエンタープライズ アプリストアの構築することは可能である。データが鍵となる。真の意味で成功と言えるアプリストアでは、すべてのソフトウェア資産に関する包括的かつ詳細な最新データへのアクセスが可能になっている。データにアクセスできることによって、ソフトウェアの要求申請から、承認、配置まで適切かつ自動的に処理することができるようになる。

だが、これらのデータは、一体どこに存在するのだろうか。ガートナー社は、エンタープライズ アプリストアを、組織のソフトウェアの資産管理システムおよび IT 調達システムに統合することを推奨している。(出典:“ガートナー社調査報告書 「Enterprise App Stores Reduce Risk and Improve Business Results (Ian Finley)」 2012月2月1日付)。このように統合することによって、組織のアプリストアを通して、ソフトウェアの支出を抑制しながら、ライセンスのコンプライアンスを維持することができるようになる。

では、自社のソフトウェアの資産管理システムおよび他のエンタープライズ IT システムから、どのようなデータを取り込むべきか。以下は、いくつかの例である：

• 所有するバージョンおよびエディションの数、インストール済み数、インストールされているデバイスと所在地、利用可能なライセンスの数などを含むソフトウェア資産データ。
• 使用中および未使用のソフトウェア インストールを識別する計測データ。
• ユーザー ロールやアクセス権など、アクティブ ディレクトリで定義されている形でのユーザー データ。

この種のデータをエンタープライズ アプリストアで利用できるようになると、単なるアプリケーションへのアクセス以上の機能を提供できるようになり、様々な IT ニーズに対応できる能力をアプリストアに追加することができる。例えば：

• 各デバイスにインストールされているアプリケーションについての正確な情報を使って、アプリストア カタログを作成できる。
• ライセンス申請が発生した時点で、ライセンスの利用状況をリアルタイムで確認し、利用可能なライセンスが存在する場合、それを予約。ライセンスの調達が必要な場合、調達プロセスを開始。これにより、ソフトウェアは、ライセンス エンタイトルメントが付与されてる場合にのみインストールされるようになる。
• ライセンス契約条項の違反リスクを最小限に抑えるために、ベスト プラクティスを活用し、資産およびユーザーデータに基づいて要求申請を承認プロセスに自動ルーティング。
• 使用状況を最適化し、高価な買い過ぎを避けるために、インストールされているが使われていないアプリケーションを判別して回収。

資産データを利用することで、上記だけでなく、沢山のことが可能になる。この「アプリストア基礎講座」シリーズの次のブログ「社内アプリストア、ソフトウェア ライセンスの最適化に役立てる」では、ライセンスの再利用、ソフトウェア リースなどの機能を利用して、ソフトウェアの利用と支出をどう最適化するかについて述べてみたい。

***

ソフトウェア資産の管理およびライセンスの最適化に関する詳しい説明は、当社オンデマンド ウェブセミナー「Software License Optimization 4-Part Webinar Series」をご覧ください。

SAP ランドスケープの最適化が本当に意味するもの

共有
Matt Schaefer

我々は頻繁に、SAP 資産の最適化について、それがあたかもよく理解されているかのように議論をしているが、我々は本当に議論の対象を理解してるのだろうか。 実質的に SAPの最適化には、考察すべき 3つの側面が存在する。

• ライセンス
• プロセス
• ベンダーとの関係

ライセンス」という側面は、購入済みのライセンスと消費されているライセンスの差に基づく、ライセンスの使用状況を考察することを意味する。 組織で消費されている SAP ライセンスの組み合わせ (例、「開発者」、「プロフェッショナル」、「制限付きプロフェッショナル」、「従業員ユーザー」タイプなど) について考えたとき、必ずいくつかの複雑な問題が浮かび上がってくる。組織に必要なライセンス タイプの組み合わせについて検証するには、組織で、SAP ランドスケープがどのように利用されているかを理解する必要がある。 実際の SAP の利用状況に基づいて、ユーザーごとに最も効果的なライセンス タイプを選ぶ場合、最低でも、ユーザーが実行しているトランザクションの種類、システムの利用時間、セッションとセッションの間にユーザーがログインする頻度は、調べる必要がある事実である。 これがなぜ重要かというと、顧客企業は概して、システムにおけるユーザーの役割に関係なく、”ライセンス” でカバーすることを最優先させるため、「プロフェッショナル」レベルのライセンスを割り当てる傾向にあるからである。 このような運用は、高い保険契約につながる可能性があり、マルチシステム SAP 環境全体を対象に自動計算できるソフトウェア ライセンスの最適化ソリューションを利用することで簡単に回避できる。

「プロセス」という側面は、SAP ライセンスの使用状況を繰り返し計算するために必要な一連のタスクを反復する機能について考察することを意味する。 大抵、SAP のオーナー/ユーザー/実行者は、上記のために費やされている時間やリソースの量に無関心なことが多い。 彼らは、ある種のカスタム レポートやスプレッドシートを提出するだけで十分だと思い込んでいる （また、それらが十分でないことが分かっても、それ以上は無理だとも信じ込んでいる）。 問題は、ライセンス データを自分でまとめてしまうと、運用コストが高くつくだけでなく、ライセンスの使用状況を正確に理解して、ライセンスの最適化へ踏み出す機会も失ってしまう。 また、自分の手でデータをまとめると、莫大な労力が必要になり、監査が近づいても、最小限度の準備しかできず、システム ランドスケープからの投資収益率を最大化するというのはほとんど無理な状態になる。適切なソフトウェア ライセンスの最適化ツールを利用してSAP ライセンスの管理の負担を自動化することで、業務プロセスを合理化し、飛躍的に改善を図ることができる。

「プロセス」という側面では、SAP だけでなく、SAP が一部となっているソフトウェア資産全体の最適化を総体的に検討する必要がある。 エンタープライズ全体にわたってソフトウェア資産の管理プロセスの標準化を図ることにより、報告機能の一元化が可能になり、ベンダーの管理においても、幹部、IT、調達、法務間における社内コミュニケーションが、より一層スムースになる （サプライヤーとの取引きにおいて、こちら側の意志を、より戦略的かつ明確に打ち出すことができるようになる!）。 例えば、調達グループは、自分達が必要ないと気が付いていないライセンスに対して割引きを求めるよりは、ライセンスの入れ替えのみに交渉の焦点を向けたほうが良い場合がある （つまり、50% の割引きを受けても、購入したライセンスの半分だけしか使用しなかったら、正規料金を払ったのと結局は同じだということである）。 重要なのは、組織は、どうすれば自分達のシステム、契約、ベンダーから最大の価値を得られるかを知っていなくてはならないということである。 この「プロセス」の考え方では、より多くの情報に基づいたビジネス決定を行うために、効率的かつ反復可能な方法で、適切な人に適切な情報を適切なタイミングで提供することに焦点を当てている。

「ベンダーとの関係」は、前の 2 つの最適化領域を実行して築き上げていくものである。この側面は、ベンダー (ここでは SAP) との関係はどうあるべきかを考察することを意味する。 平たく言うと、これは、ベンダーを分類できる能力 (戦略的パートナーとなりうるかどうか) と、明確かつ正確な方法で、適切な価格条件を受け入れる能力を意味する。 ベンダーとの関係は、曖昧さから敵意が生まれることも稀ではない。 両者において価格条件が一貫的に理解され、かつ、同意されたときはじめて、当事者間の関係は、守りの構えから協力体制へと変化し、焦点が戦略的成長に移っていく (例、「x（機能）が必要」 -> 「y（結果）を達成するために協力者を探している」)。 

一般的な例として、SAP に交渉して、「制限付きプロフェッショナル」ライセンス タイプの “制限付き” の意味を、組織にとってプラスの意味を持つように明確に定義してもらうことが挙げられる。 一旦これが確立すると、会話はしばしば、機能の定義から、それらの機能をどう活かすかということに移っていく。 これは、SAP 社にとっても恩恵がある。これにより、SAP 社の顧客も、これまで自分達が SAP 社 と共に行ってきた価値ベースのビジネスを明確に理解し評価できるようになるからである。 また顧客は、これにより、SAP で節約した経費を、SAP ランドスケープにおける SAP テクノロジーの拡張など、自信を持って再投資できるようになる。

つまり、最適化とは、SAP 資産をどれだけ消費および活用しているかを正確に把握し、その情報に戦略的な方向性を適用するだけでなく、SAP 社との協力体制を確立するためのフレームワークとして、具体的な価値ベースの目標を持った関係を育成するために使用できるようにすることを意味するのである。

SAP ライセンスの最適化についての詳細は、オンデマンド ウェブセミナー「SAP Software Licenses Could be Costing You」をご覧ください。

 

ソフトウェア ライセンスの管理は誰の仕事か

共有
John Emmitt

ソフトウェア ライセンスの管理は誰の仕事か。 これは、Scott & Scott 社のブライアン フォン ハッテン氏によって書かれたブログのタイトルである。 ハッテン氏は、さらに続けて、ここ数年、ソフトウェア ライセンスの監査の数が急激に増えていると書いている。 当社でも、このトピックでブログを掲載している (昨年掲載されたブログ 「New Gartner Report Shows Software Audits Up Again in 2011」を参照)。 しかしながら、この記事の主眼は、ソフトウェア ライセンスの管理とライセンス コンプライアンスの維持は誰の責任かというところにある。

ハッテン氏は、あるプロ向けのネットワーキング サイトでこの質問に返された回答を見る限り、責任の所在に対する見方は、組織ごとに大きな違いがありそうだと報告している。 氏はそして、「実際これらの管理は、全員の責任であるべきだ」と付け加えている。 全体的に見れば、これは本当かもしれないが、通常このタイプの責任は、責任者が誰か分かるように、特定の個人またはチームに割り当てたほうが良策である。 特に多額の予算外の補正発注費が絡む場合、企業の幹部は、責任者の割り当ての必要性を感じるだろう。 一部の企業では、この手の支出は、役員による審査と承認が義務付けられている。

ソフトウェア資産の管理とライセンス コンプライアンスの責任者は、ソフトウェア資産マネージャーから IT 調達担当者までと様々であることは事実である。 時にこの責任は、最高情報責任者の管轄に置かれることもあり、最高財務責任者の管轄に置かれることもある。また、大企業の中には、規制や様々なコンプライアンスに関する問題をはじめ、ライセンスのコンプライアンスにも究極的な責任を担うコンプライアンス総括責任者を置いているところもある。 フレクセラ・ソフトウェアの社員として今まで様々な起業と一緒に仕事をしてきたが、ソフトウェアの資産管理とライセンス コンプライアンスにおいては、様々な肩書きと組織体制を今まで見てきている。

しかしながら、組織としての義務には、責任者の割り当てだけでなく、ソフトウェア資産の管理 (SAM）方法やツールに投資してソフトウェア ライセンスを効率よく管理し、自主的にライセンスのコンプライアンスを維持していくことも含まれる (上記のソフトウェア ライセンスの最適化ブログを参照)。 この問題は極めて複雑なため、単に人を割り当てれば済むという問題ではないのである。 少なくとも、ライセンスの管理が困難なものにしている複雑性には、3 つの領域が存在する。

• ライセンスに関する複雑性 – ベンダーごとに異なる複雑なボリューム ライセンス契約、無数に存在するライセンス モデルとメトリクス、ライセンスの消費量を最小限にするために理解し十分に利用しなければならない複雑なソフトウェア製品の使用権など。
• IT 環境に関する複雑性 -- 多様に存在する仮想技術 (サーバー、デスクトップ (VDI)、アプリケーション、ハードの分割など)、パブリックおよびプライベート クラウド、SaaS、BYOD、ローミングなど。
• 組織に関する複雑性 -- グローバルに分散した組織、合併、買収、売却、分散調達など。

さらに組織は、単なるソフトウェア ライセンスのコンプライアンスの維持を越えて、ライセンスの使用状況を最適化し、継続的にコストを削減する努力もしなくてはならない。 ライセンス コンプライアンスを維持することで、予算外の補正発注費を防ぐことはできるが、ライセンスとメンテナンスに対して過度な支出がなされることを止めることはできない。 この点が、まさしくソフトウェア ライセンスの最適化の大きな利点なのである。組織は、ライセンスのコンプライアンスを維持できるだけでなく、ソフトウェアの支出を、年間 5% から 25% まで減らすことができるという特典がある。

***

ソフトウェア ライセンスの最適化に関する詳細は、当社のホワイトペーパー「Moving Up the Software License Optimization Maturity Curve to Drive Business Value」をご覧ください。

Microsoft の 「ライセンス調整」は MSDN から始める

共有
Mandi Sue Bleau

マイクロソフトのソフトウェア ライセンス調整の件で、新しい顧客と一緒に仕事をするとき、まず最初に、「MSDN （Microsoft Developer Network） はライセンスを、どのように管理しているか」と聞くことにしている。 なぜこのような質問をするかというと、顧客にとって、これが支出を最も大きく削減できる方法だからである。 MSDN ライセンスは非常に高価であるにもかかわらず、ほとんどの企業では、使い捨てティッシュのように取り扱っているのが現状なのである。

分かりやすい例を 1 つ挙げてみる。最近、開発者自身が MSDN ライセンスを管理している顧客企業と一緒に仕事をする機会があった。一見これは理にかなっているように見えるが、ライセンスを効果的に管理しようとする場合、責任者側には、把握かつ留意すべき細かな情報がたくさん存在する。 責任者は、開発者ごとに、最も適した製品バージョン、および、それらの購入先と購入方法についての知識を有しているだけでなく、ボリューム ライセンス サービス センター （VLSC） への登録、転送、更新の管理など、多数の責任を担っている。言うまでもなく、通常、開発者は、このようなライセンス管理に関する問題に対応できるように研修も受けていないし、責任として割り当てられることも稀である。 もちろん、開発者に非があるわけでなく、彼らにとっての優先順位は自分達の仕事を片付けることだというだけの話しである。

この顧客企業では、ほとんどの MSDN ライセンスが登録されていない状態で、管理もされていなかったので、ソフトウェア アシュアランスが更新されていない MSDN ライセンスが大幅に超過していた。 開発者が会社を辞めた場合も、使用されていたソフトウェア ライセンスは、VLSCに再割り当てされていなかったため、新しい開発者は自分で新しいライセンスを購入していた。  ソフトウェア アシュアランス (SA) が更新されなければ、新しいエディションが必要になった場合、新しいライセンス (およびSA) を購入しなければならなくなり、それにより支出が増加するのである。  購入手続きも、正しいプログラムに基づいて行われることは滅多になく、あるときは Select プログラム下で、またあるときは、Enterprise Agreement プログラム下で行われていた。  また、この会社では、実際の MSDN ソフトウェア ライセンスの使用率に気を配っていなかったため、 購入されたライセンスの半分以上が、実際には使用されていないという状態だった。

最終的に、これら全ての要因によって、約 278 の MSDN ライセンスに対して、2 年間超の間に 190 万ドルが浪費されていたのである。

では、今日のポイント。それは、MSDN ライセンスを自主的かつ一元的に管理・最適化する場合、ソフトウェア ライセンスの最適化プログラムをは必ず必要だということである。これを怠った場合、ライセンス管理は悪夢となり、大幅な浪費に繋がる危険性が常につきまとうことになる。

***

成熟したソフトウェア資産の管理およびライセンスの最適化プログラムによる利点については、当社ホワイトペーパー「Moving Up the Software License Optimization Maturity Curve to Drive Business Value」を参照してください。

ウェブセミナー: 新しいモバイル コンピューティング、BYOD を制す

共有
John Emmitt

日々の仕事においてこれまで以上に移動が激しく、高い柔軟性が要求される今日、場所や時間を問わずにデスクトップとアプリケーションを提供することができる仮想化技術を採用する組織が増えてきています。 ユーザーは、会社のノートパソコンだけでなく、個人で使用している携帯電話やタブレットからもアクセスできる必要性を感じています。 本ウェビセミナーでは、オンデマンド BYOD モバイル コンピューティングの導入について学べるだけでなく、複数のデバイス、多様なプラットフォーム、ソフトウェア ライセンス管理などの課題に対処方法についても学ぶことができます。

新しいコンピューティング パラダイムへの移行を計画している企業とって、ソフトウェア ライセンス管理への影響は必須課題です。

本ウェブセミナーでは、フォーカス社の社長兼チーフ アナリストのバーブ ゴールドワーム氏をお迎えして、デスクトップ仮想化の導入、課題、適切に運用された場合の利点を説明していただきます。 また、フレクセラ・ソフトウェア社のビンセント  ブラサールによる、仮想デスクトップの実装にあたって、いかにライセンス コンプライアンスの適合を維持し、ソフトウェア コストを管理していくべきかの説明も見逃せない内容となっています。今すぐ是非ご登録ください。

本ウェブセミナーでは、次を学びます。

• デスクトップ仮想化の導入、課題、ビジネス面における価値。
• Citrix XenDesktop ソリューション
• 仮想デスクトップ環境における、フレクセラ・ソフトウェア社の FLEXnet Manager スイート ソリューションを利用しての効果的なソフトウェア ライセンス管理。

日時

北米：2013年4月9日 火曜日、午前10時 (CT)
EMEA： 2013年4月16日 火曜日 午前 11 時 （英国時間）
アジア太平洋地区：2013年4月18日 木曜日 午前 9時 （豪シドニー時間）

スピーカーについて

フォーカス社の創業者、代表取締役社長兼チーフ アナリスト
バーブ ゴールドワーム氏

www.focusonsystems.com仮想化、クラウド コンピューティング、システム、およびストレージにおける変革技術に焦点を当てた研究、分析、コンサルタント会社。 IBM、StorageTek、Novell、Enterprise Management Associates、およびその他の有名ベンチャー企業で、様々な上級管理職、技術、マーケティング、販売、業界アナリストのポジションを 30 年以上にわたって経験してきたゴールドワーム氏は、仮想化、システム管理、ストレージに関してよく知られた業界の専門家で、基調講演者、著作者、コラムニストとして多忙な日々を送っています。

フレクセラ・ソフトウェア 製品管理ディレクター
ビンセント  ブラサール

フレクセラ・ソフトウェア のビンセント ブラサールは、 ソフトウェア資産管理およびライセンスの最適化の分野において 15 年以上の豊富な経験を積んできています。 ソフトウェア開発から専門サービス、製品管理まで様々な職務を経験してきた後、現在 フレクセラ・ソフトウェアでは、FlexNet Manager Suite for Enterprises シリーズのために、顧客のニーズとビジネス ゴールに基づいた強化点の定義と戦略的方向性の設定を行う責任を担っています。

仮想デスクトップの実装にあたって、どのようにライセンス コンプライアンスの適合を維持し、ソフトウェア コストを管理していくべきかを学ぶことができます。今すぐご登録を!

ベンダー全社、ソフトウェア ライセンスの撤廃を決断！

共有
John Emmitt

ここ数週間ずっと噂で聞いていたことが、ついにニュースで報道された。大手ソフトウェア ベンダー全社が、ソフトウェア ライセンスを撤廃することを決断したらしい。 これが本当だとすると、一旦購入したソフトウェアは、好きなだけ、好きなように使うことが可能になる。 さらに、ソフトウェア監査と予算外補正発注費が終わりになることも意味する。ライセンス契約もソフトウェア ライセンス コンプライアンスに関する問題も全部過去のものになる。なんという朗報だろう。同じソフトウェア ライセンス監査が繰り返されて今年で 4 年目という組織の話を聞いたことがある。 この新転換の一環として、これらのベンダーも、進行中のすべての監査を断念してくれることを願うばかりである。

あるベンダーのスポークスマンは、このように語っていたらしい。 「ソフトウェア ライセンスの仕組みは、あまりにも複雑になりすぎて、自分達でさえもライセンスの契約条件が理解できなくなってしまった。 たとえば、”ファイアウォール内のローミング使用権”の意味など、ほとんどの人間は分かっていない。字面だけ見ても矛盾して意味をなさない。ということで我々は、最善策として、ライセンスを完全に排除することに決めた。 これにより、ベンダーである我々だけじゃなく、顧客もずっと楽になるだろう。」

同じスポークスマンに製品アップグレード権について誰かが質問してみたところ、「新バージョンは、勿論すべて有料。それが唯一、ビジネスとして生き残れる方法だから仕方がない」という回答が返ってきたそうだ。だが、顧客が既にソフトウェアの旧バージョンを購入していると仮定した場合、新バージョンをお金を払って購入するかどうかは、完全に顧客次第ということになる。 そうなると、つまり、ベンダー側に、顧客がお金を払ってでも使いたいと思うソフトウェアを作り続けなくてはならないという大きなプレッシャーがかかるということになる。

これは、ソフトウェア資産管理とライセンスの最適化ツールを開発しているベンダーにとっては深刻な警鐘である （ガートナー社の報告書「ソフトウェア ライセンスの最適化ベンダー概要」を参照）。というのは、ソフトウェア製品の使用権を理解し、適用できる高度なツールの必要性がなくなるからである (このトピックについては、最近ブログを参照)。 二次使用権、障害回復権/フェールオーバー権、仮想使用権など、様々な権利を」有効に活用してライセンスの消費量を最小化する努力も必要なくなる。 仮想マシンも、好きなだけ立ち上げて、それら全マシンでソフトウェアを実行しても問題なし。 ライセンスの移動権も心配することなく、オンプレミス ソフトウェアをクラウドへ自由に移すことができる。考えれば考えるほど正気の沙汰とは思えない。

うん? 今誰かが横で、今日は 2013 年 4 月 1 日だと言っているのが聞こえた。なるほど、どおりで話が上手すぎると思った (笑)。

IT 構成管理によるソフトウェア ライセンスの最適化サポート

共有
Natalie Overstreet Lias/Martin Kurzinski

IT Infrastructure Library （ITIL） などの標準規格に基づいたベストプラクティスを採用する組織が増えていることに伴い、組織の IT 環境のキー属性を監視するために、インフラ チームにからの構成管理データベース （CMDB） やその他の構成管理システムの需要が高まっている。 CMDB には、管理下の構成アイテム （CI） のキー属性が含まれおり、構成アイテムには、コンピューター (物理と仮想の両方） だけでなく、IT資産として監視されているモバイル デバイス、プリンター、ルーター、モニターなどのアイテムも含まれている。

通常、CMDBには、資産の所有者情報 （個人または部門）、製造元とモデル情報、およびデバイスの種類に固有の詳細情報が含まれている。  例えば、モニターには、解像度やコネクター タイプ用のフィールドが用意されていることがある。 コンピューターの場合、マシンの CI には通常、プロセッサとコア数、利用可能なメモリとハードディスク ドライブの容量、IPアドレス （静的な場合​​） と MACアドレス、パッチレベルを含む OS のほか、保証およびサポート情報が含まれている。サーバー用のCI には通常、いくつかの高レベルのアプリケーション情報が含まれている。 このアプリケーション情報は、IT資産の目的や関係についての情報を提供する目的で CMDB 内に存在している。 一般的に、資産がオンライン化されると、この情報は手動でCMDBに入力され、指定された目的は、構成時に理解され、組織の標準サーバー構成プロセスの一部としてCMDBで容易に追跡することが可能になる。

通常の CMDB 内のデータは、間違いなく、ソフトウェアの資産管理 （SAM） とソフトウェア ライセンスの最適化プロセスに役立てることができるが、それだけでは、どちらの目的にも十分ではない。  それは次の 2 つの要素が欠けているからである。

1 つ目は、CMDB では、ソフトウェア ライセンスのエンタイトルメントを目で確認することが不可能であること。 場合によっては、CMDB を構成して、IT資産に購買情報をリンクすることもできるが、一般的に CMDBは、ソフトウェア ライセンスのエンタイトルメント (アップグレードおよび保守エンタイトルメントも含む) のレコードを実際に作成･管理できるようには設計されていない。 また、未加工ののソフトウェア発注 （PO） データも、一般的に記録として保存されない。 さらに、ソフトウェア資産の管理者は通常、CMDB のコアユーザーでも利用者でもないことが多いため、読み取り専用で使用している管理者がいても、ハードウェア資産の管理を兼務している場合を除き、更新を行うことはない。  これらの理由により、CMDB をソフトウェア ライセンス エンタイトルメントを監視するための実効性のあるリソースとして利用することは、通常現実的ではないのである。

２ つ目は、CMDBは、サーバーにインストールされているアプリケーションについて高レベルの情報を保有していることもあるが、組織で使用されている標準イメージのコンテンツを除き、クライアント （デスクトップ、ラップトップ） に関する情報は一般的に保有していないという点である。 サーバー アプリケーションの情報でさえも、通常、ソフトウェア ライセンスの消費量を正しく計算するには十分でないことが多い。 典型的な CMDB のアプリケーションの説明は手動で入力されるため、インストールされているコンポーネントを識別して、関連するライセンスの使用状況を計算する必要があるとき、大抵、情報として不十分である。  主要なアプリケーションに関しては、ほぼ間違いなく正しく文書化された情報を期待できるが、CMDB内で、指定ユーザーの数、別ライセンス オプションやアドイン、その他の詳細情報が保有されていることは稀である。  これらの情報は、CMDB のビジネス上の目的には必要ないからである。 また、IT インフラ　チーム側においても、ソフトウェア　ライセンスの消費量を把握するための適切な情報が目に見える形で提供されていないことが多い。

ソフトウェア ライセンスの最適化ツールを入手すると、スタンドアロン製品、スイート、バージョンおよびエディションを識別することができるアプリケーション認識ライブラリが提供される。  さらに、これらのツールでは、発注プロセスを自動化し、”購入済みとインストール済み” という点からライセンス使用状況を分析するためのSKU ライブラリが常に更新されている。 また、ソフトウェア ライセンスの最適化ツールでは、ソフトウェア ライセンス エンタイトルメント (ライセンスの消費量を最小化し、ソフトウェア支出を削減するための製品使用権) を自動的に適用するための製品使用権ライブラリも提供される。 CMDB では、これらの機能のどれも、提供されていない。

大切なのは、ITIL および SAM /ライセンスの最適化の目標が何であるかを覚えておくことである。つまり、どの点が類似していて、どの点が異なるか。  ITIL の目標は、IT 環境の論理モデルを CMDB 内において管理することであり、それゆえに、インシデント管理、問題管理、変更管理、リリース管理、構成管理などの ITIL プロセスが実現可能になるのである。 ソフトウェア ライセンスの最適化の目標は、戦略的計画、買収や撤去プロセスを含む資産のライフサイクル全体を通して、コスト、リスク、インベントリ、契約およびベンダーの管理プロセスを最適化することである。

CMDB 内にある組織のデータをソフトウェア資の産管理およびライセンスの最適化プログラムに適切に取り込むには、CMDB　のビジネス上の目的とコンテンツだけでなく、それらが SAMデータ セット全体をどのように補完するかを検証する必要がある。  組織のソフトウェア ライセンスの使用状況を効果的に最適化するためには、CMDB が保有する豊富な IT （ハードウェア） 資産に関する情報を、正確なソフトウェア インベントリ情報に融合し、ソフトウェア ライセンス エンタイトルメントを正しく適用する必要がある。

***

ソフトウェア ライセンスの最適化に関する詳細は、当社のホワイトペーパー「Moving Up the Software License Optimization Maturity Curve to Drive Business Value」をご覧ください。

ソフトウェア ライセンスの調達プロセスを一元化すべき 3 つの理由

共有
John Smith

エンジニアリング系および ERP アプリケーションを使用している顧客に対応しているうち、ソフトウェアの供給過剰は、ソフトウェアの調達プロセスがローカル ベースで、かつ、まとまりのない形で行われてる場合に最も起きやすいということが分かってきた。  つまり、エンタープライズ レベルでの管理が抜けてしまっているため、既存のライセンス インベントリやアプリケーションの使用率が事前に確認されずに、ライセンスが新しいスタッフやプロジェクトのために取得されているのである。

さらに、これらのソフトウェアは、追跡機能を持たないまま配置され、配置場所も共有されていない場所であることが多い。これは、特定のユーザー部門またはグループしかアプリケーションやライセンスにアクセスできないということを意味する。 これらのアプリケーションはまた、次善の契約条件で購入されていることが多い。

調達プロセスの一元管理およびソフトウェア ライセンスの管理を確立することによって、ソフトウェア資産は完全に可視化することができる。  一旦可視化が達成されると、未使用または十分に使用されていないライセンスを回収して再割り当てするためのプロセス (ライセンスの再利用とも呼ばれる) を設計して、絶対に必要なソフトウェアの購入のみ許可することができるようになる。

一元管理によるもう一つの大きな利点は、ベンダーとの交渉を、ソフトウェアの購入契約やライセンス契約条件について広い知識を持っている専任の IT調達担当者に任せることができるようになることである。 専任の IT調達担当者は、職務上、最良の取引条件を獲得するために、価格以外の要素も利用できる立場にある。 また、ベンダーを動かすことができるインセンティブ （例、収益認識） を使って、企業顧客にとって大きな意味がある譲歩を引き出だすことができる。  プロの調達担当者は、顧客側にとって高い柔軟性があり、今日のダイナミックな組織にとって大きな関連性があり、潜在的に起こりうる合併、買収、売却などの事態にも対応できる契約を達成することができるのである。

たとえば、ソフトウェアは、大規模な初期投資を伴う永続ライセンスを購入する変わりに、数年間の期間限定でリースすることができる。これにより、技術の進歩によりせっかく投資したソフトウェアが使えなくなるというリスクを回避することができる。  また、ソフトウェア資産の使用率を最大限まで上げるために、(同時接続) ライセンス プールに自由にアクセスできることを条件として加えるように交渉することもできる。

契約に、メンテナンス コストの増加を制限する条項や、将来の製品へのアクセスを保証価格でアクセスできる条件を追加できることもある。  また、従来版の製品および機能を、すべてまたは一部のみ最新バージョンの製品と入れ替えたできるように買い戻しオプションを交渉できることもある。 半導体設計チームによって使用される電子設計自動化 （EDA） ソフトウェアのようなケースでは、入れ替えができることで、組織は、設計サイクルの段階に合わせて、設計および検証ツールで提供されている各アプリケーションで使用可能な同時接続ライセンス数を変更することができるようになる。

まとめると、ソフトウェアの調達とソフトウェア ライセンスの管理を一元化には、次の 3 つの大きな目的 (理由) がある。

• ソフトウェア資産を管理する （何を所有しているか把握し、購入したものを配置して、配置されたものを使用する）。
• ソフトウェア ライフサイクル全体を通しての効果的なライセンス管理、コストの管理、および既存のソフトウェア資産の使用率の増加を実現するためのベスト プラクティス プロセスの実装する。
• より高い柔軟性があり、常に変化している組織のニーズにより適したソフトウェア契約内容を交渉する。

エンジニアリングや技術アプリケーション用などの同時接続ライセンス を管理するためのソフトウェア試算管理 (SAM) プログラムを設定について詳しく学ぶには、当社のオンデマンド ウェブセミナー「Creating a Mature SAM Process for Concurrent License Management」をご覧ください。

トライアド ライセンス サーバー構成を採用すべきか。

共有
Jim Griffin

自分はライセンス サーバーの仕事を 10 年以上してきているが、「今使っているトライアド (３ サーバー冗長ライセンス サーバー） を使い続けるべきか、それとも、同時接続ライセンスの高可用性を実現するために新たなトライアドを設置すべきか」という質問をされなかった週はこれまでほとんどなかった。  長年、このような質問に対して、可用性には、トライアド サーバー構成のことは忘れて、複数サーバーを使用すべきだと答えてきた。 "複数サーバー" とは、2 台または 3 台のサーバー間でライセンスを分割し、それらのサーバーを別々のマシンに配置することを意味する。マシンは、異なる場所に存在することもある。  このシナリオでいくと、1 台のライセンス サーバーがダウンしても、他のサーバーによって、一部のライセンスを提供することができる。

ベンダーごとに複数のライセンス サーバーを用意すべきという提案の背後には、社内全体にライセンスを分散することと、ライセンス サーバー トライアドを実装する際の煩雑さを避けることができるという理由があった。  しかしながら、同時接続ライセンス サーバーを大規模に使用しているユーザー企業と話をしているうち （一緒に仕事をしたことがある顧客の何社かは、数百のライセンス サーバーを所有していた）、トライアドの使用は、多くの企業にとって避けられないことなのだという結論に至った。

確認のため、冗長ライセンサー サーバー トライアドを設定する際、実際に何が起きるのかを思い出してみたい。  FlexNet Publisher に搭載されている 3 サーバー冗長化機能を使用すると、3 台のすべてのライセンス サーバーによって 1 つのトライアドが形成される。  ライセンス サーバーは、定期的にメッセージを送信し合って、常に最低 2 台のサーバーが稼動していることが確認される。  3台のライセンサー サーバーのうち最低 2 台が稼動状態にあり、かつ、交信が問題なく行われいると、クォーラムが形成される。 これにより、ユーザー コミュニティに提供可能なライセンスが存在するということが分かるのである。

ライセンス サーバーは、プライマリ、セカンダリ、またはターシャリのいずれかとして識別される。 そのうち 1 台のライセンス サーバーはマスターとして指定され、次の責任を担う：

• FlexEnabled 対応アプリケーションにライセンスを提供する。
• デバッグ ログに情報を記録する。
• レポート ログに情報を記録する。

マスターに問題が生じたとき、他の 2 台のライセンス サーバーのいずれかがマスターとして機能する。 下記は、プライマリ ライセンス サーバーがマスター [m] として機能している図である。 FlexEnabled 対応アプリケーションからライセンスのチェックアウト要求が送られれてくると、マスター サーバーが応答し、その FlexEnabled 対応アプリケーションにライセンスを提供する。

 

 

トライアドの主な目的は、プライマリまたはマスターサーバーでハードウェアの障害が生じた場合にも、ライセンスが問題なく提供できることである。  この手の問題は、このような戦略方法が登場したばかりの 90 年代初期に多く見られた。 しかしながら、ある日突然サーバーがダウンし、高い報酬を払っている数百人のエンジニアに向けて、その日一日なぜ仕事ができなくなったかを説明しなければならなくなったことがある人なら、トライアドの使用が、エンジニアがプロジェクトの遂行に必要不可欠なソフトウェアに常にアクセスできるようにするため、いかに重要かということにすぐ気が付くだろう。

個人的には、ネットワークの停止や中断のほうが、サーバー ハードウェアやディスクの障害よりも一般的だと思っているが、自分が一緒に仕事をした企業の多くは、自社でトライアドを設置しており、これを読んでいる読者の会社でも必要かもしれない。

もしトライアドを既に採用しているのであれば、私からの提案として、3 台すべてのサーバーをライセンス サーバーとして使用することをお勧めする。 たとえば、サーバーの 1 台を、あるグループのベンダー ライセンス用のマスターとして使用し、その他の 2 台のサーバーを、それ以外のベンダー用のマスターとして使用するようにトライアドを設定すると、3 台すべてのサーバーがライセンス サーバーとして運用されることになる。  ライセンサー サーバーの構成は、ライセンス管理ガイド (http://www.globes.com/support/fnp_utilities_download.htm )を参照してもらいたい。

***

当社のオンデマンド ウェブセミナー 「Creating a Mature SAM Process for Concurrent License Management」もご覧ください。 ゲスト スピーカーのダン グリフィス氏は、Freescale 社で Comprehensive Software Asset Management (CSAM) チームの責任者として従事していた際、複数の個別サーバーを使用する手法を採用しています。