連載
» 2013年12月25日 20時00分 UPDATE

実践! IT資産管理の秘訣(2):知らないとパニック必至! ライセンス監査の基礎知識 (1/2)

近年、ソフトウェアライセンス監査の動きも高まり、IT資産管理の重要性が一層増している。今回はIT資産管理のエキスパート、クロスビートの篠田仁太郎氏が、ライセンス監査を基礎から解説する。

[篠田仁太郎,クロスビート]

 IT資産管理を実践的な視点から徹底解説する本連載。前回は、以下の3点について解説しました。

  • IT資産管理とは何か?
  • IT資産管理とSAMの関連
  • さまざまなマネジメントシステムにおけるSAMの重要性

 また、ソフトウェアのライセンス監査が増えつつあることから、それに対する備えを怠らないことの必要性もお伝えしました。今回は、この「ライセンス監査とはどういうものか」について詳しく紹介します。なお、ここでご紹介するライセンス監査はあくまでも一例です。実際にはこのパターンに当てはまらないケースもありますので、一般的な実施例として参考にしてください。

ライセンス監査とは?

 そもそもライセンス監査(以下、監査)とは、ソフトウェアメーカー(著作権者)が、使用許諾条件に基づいて、「自らの著作権が侵害されていないかどうか」を確認するために、当該著作物の使用者(ユーザー)の使用実態を監査するものです。「監査」ではなく「調査」という言葉で使用実態の報告を要求するものもあります(以降、「監査」には「調査」も含むものとしてお読みください)。

 監査はソフトウェアの使用許諾契約に記載された「権利」として実施されます(全ての使用許諾契約に監査条項が入っているわけではありませんが、有償ソフトウェアの大半の使用許諾契約には含まれています)。単独のソフトウェアメーカーによって行われることもあれば、複数のソフトウェアメーカーによって行われることもあります。監査のタイミングは一定ではなく、毎年来ることもあれば、何年も来ないこともあります。

 監査の対象は、一般的に次の3つのパターンで選定されます。

1.ランダム抽出

2.ターゲティング抽出

3.内部通報

 それぞれ対応すべき内容、要求される内容が異なります。以下で個別に解説しましょう。

ランダム抽出

 ランダム抽出は、一般的には「監査」というよりも「調査」という言葉で伝えられることが多いものです。監査対象は取引先データベースから、文字通りランダムに抽出されます。一般企業に限らず、自治体などの公共団体や学校、病院など全ての企業・組織が対象となります。

 このタイプの監査は、ライセンス利用状況調査の実施を要求するレターなどが送られてくることから始まります。特に意図を持って接触してきているわけではないので、無視しても問題が発生しないケースもあります。しかし調査要求がエスカレートすることもありますので、できればこの時点で適切に対応しておいた方が無難です。

 一般的には、報告書の提出をもって監査は終わります。報告書のフォーマットはソフトウェアメーカーごとに異なり、「パッケージソフトウェアやボリュームライセンスごとに、ライセンスの保有数とインストール数を分けて報告するもの」や、「インストールキーを全て調査して報告するもの」などがあります。

 前者の「ライセンスごとに保有数とインストール数を記入する報告書」を作成するためには、以下の2つの知識が必要です。

  • ライセンスを理解し、種別ごとに適切に割り当てる知識
  • ライセンスを保有していることを証明するために必要な部材の知識

 一方、「インストールキーを全て調査する報告書」では、以下の2つの対応が求められます。

  • インストールキーが記載された証書等の情報を正確に転記する
  • インストールされているハードウェアを特定し、1台1台を指定された方法で確認する

 手間は掛かるものの、ごまかしたり隠したりしなければ、大きな問題になることは少ないのがこのランダム抽出です。

ターゲティング抽出

 ターゲティング抽出は、ソフトウェアメーカーの取引先データベースから、例えば「従業員数に比べてボリュームライセンスの購入数が少ない」など、何らかの条件に合致する対象を抽出して調査依頼をするものです。一般的に、どのような抽出条件が適用されるかについては、ここでの公開は控えさせていただきますが、「一般的な条件を知りたい」という方は、筆者に直接お問い合わせください(ただし、お答えさせていただくのは純粋なSAMのユーザーの方に限ります)。

 ターゲティング抽出の場合も、ランダム抽出と同じ調査依頼と報告フォーマットが示されることが一般的です。ただしターゲティング抽出の場合、監査対象をあらかじめ一定の条件でフィルタリングして選定しているため、ソフトウェアメーカーは、ある程度、ライセンス不足の可能性を想定して接触してくることになります。

 従って、報告書の提出はランダム抽出の場合よりも注意が必要です。かなり強い確信を持って当たりを付けて来ている場合もあるため、自社の現状を十分に認識した上で対応することが望まれます。ランダム抽出にしてもターゲティング抽出にしても、最も注意すべきことは、利用数と保有数の整合を取るということです。

 また、報告書をソフトウェアメーカーに提出して、一度で「OK」とされるケースは極めてまれです。提出して「終わった」と気を抜いてしまうのではなく、「まず間違いなく、何度かの再確認要請があり、それに対して見直しを実施することになる」という認識を持っておくことが大切です。

 ライセンスの過不足の調整ばかりに気を使い、結果として整合性が取れない報告書を提出してしまうと、単純な見直しとはならず、場合によっては全面的な再調査を要請され、結果として組織全体に大きな作業負荷を強いる結果になることもあるのでご注意ください。

 なお、インベントリツールは重要なツールではありますが、「インベントリツールで調査した結果だけ提出すれば済む」と考えていたら、それは大きな間違いです。単にインベントリツールの収集情報を提出しても、それだけではライセンスの保有を証明することも、利用数を報告することもできません。なぜなら、詳しくは後述しますが、「利用しているソフトウェアの数」と「保有しているライセンスの数」の整合が取れなければ、信頼に値する報告にはならないからです。基本的に、インベントリツールでは「どんなIT資産があるか」しか把握できませんし、社内ネットワークに接続されないスタンドアロンPCや倉庫内にしまわれたPCなど、ツールだけでは把握できない資産も存在します。

 また、監査の際にはソフトウェアメーカーが独自の調査ツールを用意しており、それを利用した報告が求められることもあります。インベントリツールがない場合には、そのツールの利用が義務付けられるケースが多いのですが、弊社のこれまでの経験では、インベントリツールを持っていても、このソフトウェアメーカー独自のツールの利用を要請される場合もあります。

 なお、ランダム抽出やターゲティング抽出では、ソフトウェアメーカーが直接確認するケースもありますが、ソフトウェアメーカーのパートナー企業や監査法人が代行することが多くなっています。

内部通報

 内部通報には大きく分けて、ソフトウェアメーカーへの通報と著作権団体への通報の2つがあります。中には、ソフトウェアメーカーの法的な事案を取り扱う部門から連絡が行く場合もありますが、代理人(多くは弁護士)から連絡があるケースがほとんどのようです。

 ここで留意すべきは、「ソフトウェアメーカーは、内部通報の全てに対して監査をしているわけではない」ということです。

 通報を受けたソフトウェアメーカーや著作権団体は、その事実を確認するために、通報者にヒアリングをしたり、ソフトウェアメーカーの売り上げ実績と通報された組織の現状を実際に確認したりした上で、ある程度、ライセンス違反の確信を持った企業・組織に接触しています。もちろんその想定が間違っており、違反が全くないというケースもないことはありませんが、ほとんどの場合、大きな違反が見つかっています。従って、ソフトウェアメーカーの法務部門や代理人から連絡があった場合には、ある程度のライセンス不足が発生していることを前提に対応していくことが重要です。

内部通報による監査では“パニック買い”に注意!

 このとき、ライセンスが不足していると思われるソフトウェアをすぐに調達しようとするケース(俗称「パニック買い」)がありますが、パニック買いをしたところでそれは事後の扱いであり、不足していたという事実が消えるわけではありません。

 また、ソフトウェアメーカーとの交渉の結果、「必要なライセンス数を持っていない」と判断されても、部分的にライセンスの保有が認められる場合もありますので、パニック買いはあまりメリットのあるものとはいえません。なお、このとき不足分をアンインストールするという行為は、絶対にしてはいけない行為です。場合によっては「証拠隠滅」と受け取られることがあるためです。

 内部通報に基づく監査の際に、組織の管理不備、統制不備によるコンプライアンス違反が想定されるのであれば、あれこれ小細工することなく粛々と監査を受け入れ、ソフトウェアメーカー、経営層と共に善後策を正々粛々と協議し、進めていくことが最善の対応です。

 内部通報の際には、場合によっては、全組織の全PCやサーバーなどを調査されるケースもあります。また、単に不足分の是正にとどまらず、監査後にSAMの体制構築を約束しなければならないケースもあり、その対応負荷は計り知れないものがあります。ここで求められる管理レベルには非常に高いものが要求されることも多く、その構築負荷も将来の重い課題となります。

 「そうなることのないよう、事前に最低限の管理をしておくことが大切だった」と、実際にソフトウェアの著作権者と和解をした組織の担当の方は口をそろえて言っています。

       1|2 次のページへ

Copyright© 2017 ITmedia, Inc. All Rights Reserved.

@IT Special

- PR -

TechTargetジャパン

この記事に関連するホワイトペーパー

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。