さて、第5回は、「Microsoft ライセンス管理のためのベースライン構築 その１」と題して、ベースライン構築の最初のステップであるライセンス契約書のたな卸しとライセンス契約に関係するCI（構成アイテム）とライセンス割り当ての管理を解説します。

目次

確認するべきポイント

ステップ

ライセンスの割り当て

まずはMicrosoft社製品のライセンス体系にあるライセンスの種類（タイプ）を理解しましょう。 タイプとしてはデバイスライセンスとして特定のデバイスに提供されるものと、ユーザーライセンスとして特定のユーザーに提供されるものがあります。 そして、それぞれに永続（パーペチュアル）ライセンスと非永続（サブスクリプション）ライセンスがあります。 その他に、プロセッサやコアライセンスなどがあり、これらを理解し、現時点で自社が採用し契約しているライセンスのタイプにより管理メトリクスを特定し管理システムを構築する必要があります。同じMicrosoft Officeでも、ライセンスタイプの違いにより管理メトリクスが異なり、システムの設定も異なります。これらの異なるライセンスタイプはSKU（Stock Keeping Unit）番号により特定のライセンスタイプの利用規約（ライセンス契約条件）を識別できるようになっています。同じ製品であってもSKU番号が異なる場合があり、SKU番号ごとに管理メトリクスが異なります。例えば、MS Officeデバイスパーペチュアルの場合は、オリジナルライセンス（License：以降、L）とソフトウェアアシュアランス（Software Assurance：以降、SA）をデバイスにひもづけて管理して追跡する必要があります。一方で、ユーザーサブスクリプションであれば、有効なサブスクリプションをユーザーにひもづけて管理するという具合です。 さらに、自社環境内にはOEM版（PIPC：Pre-Install PC/ プレインストールPC）などPCを購入した際にPCのメーカーがMicrosoft社と契約しハードウェアにバンドル（プリインストール）して提供され、Microsoft社との直接契約ではないMicrosoft社製品も存在する場合があります。OEM版の場合は、特定のハードウェアのシリアル番号に特定のライセンス契約番号がひもづき、当該ライセンスはハードウェアメーカーが割り当てた物理コンピュータに限定的にライセンスされます。 さらに、ここで注意するポイントは、デバイスパーペチュアルのSKU番号であっても、契約交渉の結果、ユーザーパーペチュアルのライセンス契約となっている場合も考えられるということです。最終的には契約書のライセンス契約の条件をよく読んで、必要に応じた管理メトリクスにより管理しなければならないということを理解しておきましょう。 そして、契約も必ずしも一本化されていない、つまり、EA基本契約で獲得した契約条件とSelect Plus などでカバーされるライセンス条件が異なる複数のライセンスタイプのMicrosoft Office を使用しているかもしれないということに留意しておきましょう。

多くの組織ではプロジェクトチームやインフラチームが調達部などの協力のもと、あるいは、VMO（Vendor Management Office）が設立されている組織ではプロジェクト、インフラ、VMO と調達が協力して契約や発注を行っている場合があります。残念なことに、運用部がIT資産管理という観点からこれらの契約を管理していることは少ないので、実際の運用担当者がMicrosoft社の契約を見ず条件を把握していない場合も多く考えられます。また、グループ会社で親会社がMicrosoft社との契約（MBA/MBSA）を持っており、傘下の組織は、指定されたグループ内調達機能をもつ商社から購入することと伝達されているものの、なぜ、そのようなことをするのかの説明がなく、必要性を理解できないまま、購入条件のよりよいLSP（Licensing Solution Partner）から購入していることもあるでしょう。あるいは、親会社がすでに10万ライセンスをボリュームでコミットしており、傘下の組織にはライセンス数を割り当てて、年次で必要数の確認をしているというケースも考えられます。 いずれにせよ、契約条件を把握し、条件に基づいて管理メトリクスを設定し、ライセンスを割り当てて管理することが重要です。そのためには、まず現在の自社あるいは自社グループにおけるMicrosoft社との契約体系を理解し、契約条件を理解し、自組織がどのような管理を実行するべきかを理解した上で取り組みを進めていきましょう。

確認するべきポイント

• ① 自組織または親会社は MBA/MBSA 契約をMicrosoft社と締結しているか？
  ・締結している場合、同契約にひもづけることができる契約は、その総数でボリュームディスカウントを受けることができる。
  ・締結している契約傘下にひもづかない契約は、総数でのボリュームディスカウントを受けることができずに割高なライセンス料金となる。
• ② 一つの製品をEA基本契約、Select Plus、Open など複数の条件で契約しているか？
• ③ 一つの製品の契約条件が異なる運用が存在するか？
  ・デバイスパーペチュアル、ユーザーパーペチュアル、ユーザーサブスクリプション、OEM（PIPC）版が混在している。
  ・デバイスパーペチュアルの場合は、Lはいつ購入されたのかを契約とひもづけて管理する。さらにSAで引き継いだ加入契約を3年ごとに更新している履歴を管理しEA基本契約と加入契約および契約条件が変化していれば、そのタイミングなどを管理する。
  ・デバイスライセンスの場合は、ライセンス→デバイス→ユーザー→ロケーションのひもづけが必要。
  ・ユーザーライセンスの場合は、ライセンス→ユーザー→デバイス→ロケーションのひもづけが必要。
  ・OEM（PIPC）版の場合は、OEMライセンス契約番号と個体ハードウェア（PC）シリアル番号とのひもづけが必要。

図：Microsoft社 の契約アーキテクチャを把握する

VMOやライセンス発注担当者などはMicrosoft社から複雑なライセンス購入の教育を定期的に受けています。ライセンスを効果的に管理するためのベースラインを構築するためには、発注するために必要な知識とほぼ同等の知識が求められます。なぜならば、発注時に取得したライセンス数が導入時にライセンスの割り当てに必要なライセンス数であり、どのデバイスまたはユーザーに割り当て、管理の運用開始ポイントを構築するかが決まるからです。 さらにライセンス条件に基づいた運用中の変更管理を実施するためには、ライセンス条件を理解し、必要に応じた管理メトリクスをシステムで設定して管理することが求められます。 自組織が保有する全てのMicrosoft社契約をたな卸しし、関係する契約の親子関係を関係ツリーで表現します。この関係ツリーをSLO（Software License Optimization）ツールにベースライン情報として投入します。この時に注意すべきポイントは、MBSA、EA基本、EA加入、オリジナルL からSA の最も古い情報で開始地点を作成し、今日まで時系列でデータを順番に投入し整合性を確認しながら最終の今日のデータを作成するということです。そうすれば、SKU番号の利用規約の条件が交渉などにより変化した場合は、その変化も記録に残しておくことができます。オリジナルのLと今日のSAがしっかりとひもづいている状態を構築することを念頭にデータ投入をしていきましょう。 いくつかのケースで「SAは10000あるがLが5000しかない？」というような状態が発生することがあります。例えばM&A（企業買収）などで5000人の組織に5000人の組織が合併した時にLの登録を合併先に統合しLを10000、SAを10000として管理していない場合などに発生します。このような事態を回避するためにもLとひもづくSAの整合性を管理する必要があるのです。

ステップ

• ① ベースライン構築のためには、親契約となるMBA/MBSA番号からデータ投入します。
  MBSA（Microsoft Business and Service Agreement）
• ② 最も古いEA基本契約番号とEA加入契約番号を投入します。
• ③ 購入情報/発注情報としてSKUとライセンス数、ライセンス価格を投入します。そして、投入した購入情報／発注情報を加入契約番号とひもづけます。
• ④ SKU と契約条件からシステムのライセンスエンティティ（ライセンス条件/管理メトリクス）を作成します。
• ⑤ ライセンスエンティティにひもづく購入ライセンス数に基づいたエンタイトルメントをライセンス数分作成します。
  ※本来はこのタイミングでライセンスの割り当て処理を行います。
• ⑥ 2番目に古いEA基本契約番号またEA加入契約番号を投入します。
• ⑦ 前ステップと同様に購入情報/発注情報としてSKUとライセンス数、ライセンス価格を投入します。そして、投入した購入情報／発注情報を加入契約番号とひもづけます。
• ⑧ SKU と契約条件に変更がなければライセンスエンティティに変更はありませんが、条件に変更がある場合はライセンスエンティティのライセンス条件を変更します。

ライセンスの割り当て

ベースライン構築の際の課題としてあがるのが、最初のライセンスの割り当てです。今までライセンスを正確にデバイスやユーザーに割り当てて運用していなかった場合、どのようにして管理ツールで運用の開始ポイント、つまりベースラインを構築すればよいのか？と、多くの運用者が困っているのが現状です。 ひとつの方法として、まずは「仮のベースラインを作る」ことが可能です。

「といっても、インベントリ収集で、デバイスにインストールされているソフトウェアは分かるけど、それを使用しているユーザーはわからない。どうすればいい？」

例えば欧米の大手組織では、インベントリ収集とソフトウェア配布には多くの場合Microsoft社 のSCCM（System Center Configuration Manager）が利用されています。SCCM には Last Logged In User の情報を収集する機能があります。この情報を利用することで AD（Active Directory）に登録されたユーザー識別子（社員番号、共通認証IDなど）でインベントリ収集したデバイスにログオンしたユーザー情報を取得することができます。この情報とインベントリ情報のデバイスのシリアル番号をペアにしてエクスポートし、SLOツールに資産登録されたデバイスのシリアル番号に対してユーザー割り当てを行い、最初のデバイスのユーザーを識別するリストを作成することが可能です。デバイスライセンスであれば、デバイスが識別され、デバイスにひもづけるべきユーザーがひもづけられます。次のタイミングの実地たな卸しのユーザー向けの確認リストに、PCのシリアル番号、資産管理番号、ユーザーがひもづいた情報をたな卸しのリストとして提供し、確認を得ることで徐々にユーザーとデバイスの割り当て情報の精度を高めることができます。 ユーザーライセンスの割り当てに関しては、前述の状態からデバイスとユーザーをひもづけ、デバイスにインストールされたソフトウェアでユーザーライセンスであるものを列挙し、デバイスに割り当たったユーザーに対してライセンスのエンタイトルメントを割り当てるという作業が必要です。ユーザー識別子のリストをエクセルなどで作成し、ユーザーに割り当てるエンタイトルメントを割り当てテーブルとします。そのテーブルをSLOツールにインポートすることで、仮のユーザーライセンス割り当てを作成します。後はデバイスとユーザー割り当ての情報精度を上げるのと同様に、次のタイミングでデバイスの利用者ユーザーの精度を上げることでインベントリ情報のソフトウェア割り当ての整合性を確認していきます。 ユーザーライセンスであれば、ほぼこの方法で最初のユーザーライセンス割り当てを作成したな卸しでユーザーとデバイスの割り当てを確認することを繰り返すことで徐々に精度を上げることが可能です。

さて次回は、ライセンス契約、購入情報、ライセンスエンティティ、エンタイトルメント、ライセンス割り当てを管理するSLO（ソフトウェアライセンス最適化）ツールとインベントリ、メータリングを行うインベントリエージェントのポイントを解説します。