ソフトウェアライセンス管理のコツ｜更新漏れとコンプライアンス違反を防ぐ方法

資産の種類別に管理のコツを見ていくシリーズ、前回はPC・端末管理のコツとしてハードウェアの管理を扱いました。ハードウェアの管理は1台ずつに資産番号を振り、ステータスで状態を持ち、現物と台帳を突き合わせる、「動くモノ」を追いかける話でした。

今回はソフトウェアライセンス管理の話です。ハードウェアが「目に見えて、机の上にあるモノ」だとすれば、ライセンスは「目に見えない契約」です。形がないぶん、契約上「何ライセンス持っているか」と、現場で「実際に何人が使っているか」が、知らないうちにズレていきます。しかもライセンスの多くは更新が1年単位で回ってくるので、サイクルのどこかで気を抜くと、払いすぎ（余り）や更新忘れ（不足）につながりやすい。今回は、この1年の流れに沿ってライセンス管理のコツを整理したいと思います。

なぜソフトウェアライセンスの管理は難しいのか

前回、ハードウェアの管理は難しいという話もしましたが、ソフトウェアも別の理由で難しい点があります。それは、形がないこと、インストールが現場任せになりがちなこと、そして契約と更新が年単位で回ることの３つです。

ハードウェアなら、棚卸しのときに「現物が何台あるか」を目で数えられます。ところがライセンスは数えられません。契約書には「50ライセンス」と書いてあっても、実際に何台のPCにインストールされ、何人が使っているのかは、台帳を見ないと分からない。そしてインストールは現場の判断で進むことが多いので、情シスが把握しないまま使われている、逆に契約だけ残って誰も使っていない、という状態が生まれます。

ここがハードウェアとの大きな違いだと思います。PCは「ある／ない」がはっきりしていますが、ライセンスは「契約の数」と「使っている数」という2つの数字がいつもセットで存在し、その2つがズレていく。台帳に契約を載せるだけでは足りず、「使う数」のほうを追い続けないと意味がないです。では、この見えにくいライセンスを、どう管理すればいいのでしょうか。

ライセンス管理は「1年のサイクル」で考える

ライセンス管理の際は「1年のサイクルで回るもの」という前提で管理するのがやりやすいです。前回のハードウェアは入荷から廃棄までの一直線のライフサイクルでしたが、ライセンス、とくにサブスクリプション型は、契約・更新を毎年くり返すというサイクルになります。

ライセンス管理の場合は最初に契約する「導入時」、日々使われていく「運用中」、契約が切れる前の「更新前」、そして年に一度くらい点検する「監査・点検」。この4つを毎年くり返していきます。それぞれの局面でやるべきことが違いますので順番に見ていきましょう。

① 導入時 ── 契約数と「使う数」を最初に揃える

最初の局面は、新しいソフトを導入するときです。ここで決まるのが「何ライセンス買って、誰に割り当てるか」という記録です。地味ですが、ここでの過不足が、あとの3局面すべてに尾を引いてきます。例えば、あるツールを「とりあえず50ライセンス」で契約したとします。でも実際に使うのは営業部の30人だけだった。すると20ライセンスは誰も使わないまま、毎月お金だけが出ていきます。逆に、30ライセンスしか契約していないのに、いつのまにか40台にインストールされていたら、これは契約数を超えた利用、つまりライセンス違反となってしまいます。

ライセンス管理は過不足のどちらに振れてもよくないです。不足（過少契約）はコンプライアンス違反となりますが、余り（過剰契約）はコストの無駄となります。この両方を同時に避けるには、契約数と「実際に使う人数」を最初の時点で揃えておくことが出発点になります。最初からぴったり割り当てるとは限らないです。少し余裕を持って契約することもあるでしょう。それでも、「50契約・30利用」という2つの数字を最初から台帳に並べて持っておけば、「20ライセンス余っている」という事実が見える状態になります。見えていれば、次の更新のときに減らす判断ができる。導入時は、この2つの数字を並べて持つ準備をする局面だと考えるといいと思います。

② 運用中 ── 「誰が使っているか」を割り当てで追い続ける

契約したら、次は日々の運用に入ります。この局面でいちばん大事なのは、「誰がそのライセンスを使っているか」を割り当てとして追い続けることです。導入時に「30人に割り当てる」と決めても、組織は動き続けます。新しい人が入って割り当てが増える、退職した人のぶんが宙に浮く、異動で部署が変わる。これを追わずに放っておくと、契約数は変わらないのに、実際の利用者が誰なのか分からなくなっていきます。

想定ケースで考えてみます。50名規模のBtoB SaaS企業で、デザインチームがAdobe Creative Cloudを10ライセンス契約していたとします。当初は10人で使っていたのですが、2人が退職し、1人がマーケ部門へ異動した。けれど割り当ての見直しをしていなかったため、退職者2人ぶんのライセンスがそのまま「空き」として放置され、新しく入ったデザイナーには「足りないから追加で買おう」と、本来は空きがあるのに買い足してしまった——こうした話は、よくお伺いします。退職者のぶんを回収して再配分していれば、追加購入は要らなかったはずです。

この問題を防ぐコツは、ライセンスと利用者を一対一で紐づけ、人が動いたらその紐づけも一緒に更新することです。とくに退職・異動のタイミングは要注意で、人事の手続きと「ライセンスの割り当て解除」をセットにしておくと、空きが宙に浮きにくくなります。台帳と現実を合わせ続ける、地道ですがいちばん効く作業だと感じます。

③ 更新前 ── 期限を「先に」つかみ、棚卸しで見直す

3つ目の局面は、契約が切れる前です。サブスクリプション型のライセンスには更新期限があり、ここを見落とすと一気に事故につながってしまいます。更新前にやることは2つあります。1つは、更新月と自動更新の有無を「先に」つかんでおくこと。もう1つは、更新の前に「本当にこの数のまま続けるか」を棚卸しで見直すことです。

期限の把握が大事なのは、気づくのが遅れると選択肢が消えるからです。自動更新の契約だと、何もしなければ勝手に1年延びてしまいます。「来月で切れる」と1か月前に気づければ、減らすか・やめるか・続けるかを落ち着いて選べますが、更新されたあとに気づいても、もう1年ぶんの費用は確定しています。期限は、過ぎてから気づくのではなく、近づく前に教えてもらう仕組みにしておきたいところです。

そして更新の直前は、②の運用中で追ってきた「契約数と利用数のズレ」を清算する絶好のタイミングでもあります。「50契約しているけれど、ここ半年ずっと利用は35人前後」なら、更新時に40へ減らせるかもしれません。逆に「ぎりぎり足りていない」なら、このタイミングで増やす。更新は、ただ自動で延長する作業ではなく、1年に一度の見直しの機会だと捉えると、コストの最適化につながります。直前になって慌てて判断するのではなく、更新月の少し前に棚卸しを挟む。それだけで、払いすぎも不足もかなり減らせるはずです。

④ 監査・点検 ── 証跡を出せる状態にしておく

最後の局面は、点検です。年に一度くらい、あるいは外部の監査が入るタイミングで、「ライセンスが契約の範囲内で正しく使われているか」を確認し、それを説明できる状態にしておく必要があります。ここで関わってくるのが、ソフトウェア資産管理の考え方です。SAM（Software Asset Management、ソフトウェア資産管理）という言葉があって、ソフトウェアの調達・配布・利用・廃棄までを管理し、ライセンスを適正に保つ取り組みを指します。難しく聞こえますが、要は「契約した数の範囲で、ちゃんと使っていますよ」と証拠を持って言える状態にしておくということです。

ソフトウェアは、誰かが気軽にコピーしたり、契約外のPCに無断でインストールしたりしやすいです。悪意がなくても、「とりあえず入れておこう」が積み重なると、いつのまにか契約数を超えてしまう。そしてメーカーによるライセンス監査が入ったとき、「誰に・いつ・何ライセンスを割り当てたか」を示せないと、過剰利用を疑われても反論できません。そのため、この証跡は必ず残すようにしましょう。

Assetiveでできること（ライセンス管理）

ここまで、ライセンス管理を導入時・運用中・更新前・監査という4つの局面で見てきました。「考え方は分かったけれど、Excelで契約数と利用数を追い続けるのは大変そう」と感じた方もいるかもしれません。そこで、私たちが運営しているIT資産管理SaaS「Assetive」では、この4つの局面をどう実現できるのかを、局面に対応づけて見ていきます。機能を並べるというより、「さっきの①〜④は、Assetiveだとこうなる」という形で読んでいただければと思います。

ライセンス台帳の入力項目（① 導入時）

ライセンス1件ごとに、ライセンス名・契約番号・種別（永続型／サブスク型）・保有数（契約数）を持ち、サブスク型なら契約開始日・契約終了日・契約金額・契約会社まで登録できます。管理部門と管理者（社員）も紐づけられます。導入時に「何ライセンス買い、どこの部署が責任を持つか」をこの1レコードに収めておく、というのが①の局面に対応します。

契約数と割当数の管理（①②）

保有数（契約数）に対して、実際に何人へ割り当てているか（使用数）は、社員への割り当て実績から自動で集計します。契約50に対して割り当て35なら、その差の15が「余っている数」として見える、という具合です。ここは「契約と利用という2つの数字がいつもズレる」という、ライセンス管理いちばんの難所に正面から効く部分なので、一覧で過不足が一目で分かるようにしました。割り当ては契約数を超えてはできないので、知らないうちに契約違反になることも防げます。

期限アラート通知（③ 更新前）

更新期限は、アラート通知でカバーします。契約終了日を期限として持ち、30日前・7日前・当日の3段階で通知メールを自動で送ります。これは「期限切れに気づいた時にはもう遅い」という失敗を避けるために、あえて3段階にした部分です。ひとつ注意点をお伝えすると、更新日（契約終了日）を入力していないライセンスには、当然ながらアラートは飛びません。③の局面でまず期限を「先に」入れておくことが、この通知を活かす前提になります。

社員への割り当てと退職時の整理（②運用中／④証跡）

②で触れた「人が動いたら紐づけも更新する」は、社員管理の側から扱えます。ライセンスを社員に割り当て、社員モーダルの「資産」タブからは、その人が今どのライセンスを持っているかを一覧で確認できます。社員を退職処理する際に後任者を指定すれば、管理者を後任者へ切り替えつつ、退職者ぶんの割り当ては解除されます。退職者のライセンスが「空き」のまま宙に浮く、あの放置を防ぎたい、という意図です。そして、いつ誰に割り当て・解除したかの操作は監査ログとして残るので、④の「証跡を出せる状態」にもそのままつながります。

このように、デバイス・ライセンス・SaaSを同じ画面の流儀で一元管理できるようにしているのは、「ツールを行き来する手間が、管理のモチベーション低下に直結する」という現場感覚からです。ライセンスだけ別のExcelで管理していると、結局そこだけ更新が止まる。最初からひとつにまとめておきたかった、というのが設計の出発点でした。

まとめ

ソフトウェアライセンスの管理を、1年のサイクルとして4つの局面に分けて見てきました。導入時に契約数と使う数を揃え、運用中は割り当てで利用者を追い続け、更新前に期限を先につかんで棚卸しで見直し、監査・点検では証跡を出せる状態にしておく。形のないライセンスは、この円環を毎年ていねいに回していくことで、払いすぎと更新漏れの両方を防げると思います。

ハードウェアの「ある／ない」とは違い、ライセンスは「契約の数」と「使う数」を追い続ける管理でした。資産管理全体の位置づけをあらためて確認したい方は、IT資産管理とは｜基礎知識もあわせてご覧ください。

次回は、種類別シリーズの3本目として、SaaS管理のコツを扱う予定です。ライセンスが「契約した数の範囲で使う」管理だとすれば、SaaSはアカウント単位で増えやすく、情シスの知らないところで契約が広がる「シャドーIT」の問題が絡んできます。性質がまた少し変わるので、別のコツが必要になります。

ここで挙げた「契約数と利用数のズレ」「更新期限の見落とし」に心当たりがある方は、契約と利用を1か所で追える仕組みが選択肢のひとつになるかもしれません。