ここから本文です

ソフトウェア資産管理システム、信じられないような「本当の話」~失敗しない製品選定・導入のツボ~

6/27(火) 7:55配信

@IT

 今回はSAMシステム選定の指標となる「SAM BIBLE SAM支援システム構築推奨機能Ver.2.10」のうち、以下の3つの重要ポイントについて詳説します。

「SAMシステム構築推奨機能」において「部署やユーザーの変更対応」の機能についての説明

1.バージョンアップ・問い合わせへの対応
2.管理可能なライセンス
3.その他

 今回お伝えする3つのうち、「1.バージョンアップ・問い合わせへの対応」については、システムの機能以前のポイントであるため、「SAMシステム構築推奨機能」には記載していません。しかし、まずはこの点からお伝えします。

 「バージョンアップや問い合わせ対応など、当たり前のことになぜ注意喚起を?」と思われる方は多いかもしれませんが、台帳ツールを調達する際は、事前に確認しておくべき重要ポイントの1つになりますので、お目通しください。

●「1.バージョンアップ・問い合わせへの対応」での注意点

○バージョンアップについて

 台帳ツールはいくつものベンダーから提供されており、そのほとんどは「パッケージソフト」として紹介されています。しかし、実際の導入はカスタマイズが前提となっているものが少なくありません。そのため、製品パンフレット上では、保守の項目において「バージョンアップが含まれる」と記載されていたとしても、バージョンアップの適用が不可能となるケースが多くあるのです。

 もちろん、バージョンアップ対応のためにカスタマイズ開発を都度行えば、新しい機能を利用できるようにはなります。しかし、そのコストはユーザー負担となるため、実際には、よほどのことがない限り、カスタマイズした場合には製品版のバージョンアップ機能を享受することはできないのが実情です。

 従って、パンフレット上の保守料金にバージョンアップが含まれているにもかかわらず、「カスタマイズによっては、バージョンアップの権利が実質的に行使できない」ことが明確であれば、バージョンアップに相当する部分については保守料金の減額を要求しておくことが望まれます。

 ただ、仮想化やクラウドなどテクノロジーの進化に伴い変わっていくIT資産を管理していくためには、カスタマイズなどせずに、パッケージ版をそのまま導入し、バージョンアップされた新機能を享受していくことが最も望ましい形です。

 そもそも、この連載で何度も触れてきたように、IT資産管理には国際規格(ISO/IEC19770-1:2012)があり、また、この国際規格をベースとしてSAMACが提供しているソフトウェア資産管理基準もあります。管理対象とするハードウェアや利用しているソフトウェアの使用許諾条件についても、ユーザーによって異なるようなものはほとんどありません。つまり、管理プロセスのひな形ともいえるべきものが存在しており、管理対象もほとんど共通なのです。

 にもかかわらず、多くの企業でカスタマイズが前提となっているのは一体なぜなのでしょうか?

○「なぜカスタマイズしなければならないのか?」

 これは大きく分けて2つの原因があります。1つは製品の開発側の問題であり、もう1つはユーザー側の問題です。

 開発側の問題とは、台帳ツールを開発しているベンダー自身が、規格や基準のプロセス、要求事項を十分に理解していないために、機能が不十分であったり、実用に耐えないものになっていたりするというものです。これはベンダー自身が、規格や基準を基にしたIT資産管理を、実際には導入していないケースで多く見られるものです。

 例えば、単にインベントリーツールだけ、あるいは台帳ツールを組み合わせたSAMシステムだけを社内に展開し、運用ルールの周知も、運用状態の検証や是正プロセスも十分に行っていない場合、当然、実際の運用イメージはつかめないことになります。従って、開発する製品の実装機能も限定的なものになり、その結果、運用負荷への配慮が不足した仕組みになってしまうのです。そもそも、十分な機能の実装を初めから放棄して、カスタマイズ作業自体を売り上げとして見込んで販売しているケースもあるようです。

 ユーザー側の問題は、実は、こうした開発側の問題が影響しているケースが多くあります。

 一般に、ベンダー側が考える“カスタマイズの表向きの理由”は、「ユーザーが、これまでの管理方法を変えたがらないから」「ユーザーが、規格に応じた管理方法ではなく、『何となくこうあるべき』といった独自の管理方法を求めるから」といったものです。しかし、その根っこにあるのは、前述のように、そもそも必要なプロセスや機能をベンダー側が理解していないため、実装機能が不足しているケースが多いというものです。また、ユーザーから「こうあるべき」と言われたときに、提供側の知見が不足しているために、ユーザーが納得する代替案を出すことができないケースも少なくありません。

 「それぞれ管理プロセスが異なるので、カスタマイズして導入するお客さまが多いです」とか、そもそも代替案の提示すらなく、言われたことをそのままカスタマイズで対応しようとするベンダーは、IT資産管理に関する本当の知見は持っていないものと判断してまず間違いないと、筆者は思います。

 いずれにせよSAMシステムのカスタマイズは、よほど特殊な組織を除いては、百害あって一利なしと考え、カスタマイズありきでシステムを考えないことが大切です。

○「問い合わせ対応」の注意点

 そしてもう1つ、確認しておかなければならないのが、問い合わせ対応です。問い合わせ対応は、SLAに盛り込むべき重要ポイントの1つです。これは、台帳ツールのベンダーによって大きく異なるばかりか、ユーザーによって対応が異なるケースもあります。

 ここで確認すべき問い合わせ対応とは、以下の2点です。

【1.問い合わせ方法】

 問い合わせ方法には、メール、電話、オンサイト訪問などがあります。問い合わせ先についても、指定されたヘルプデスクのみの場合や、担当営業経由の場合、あるいはそのどちらも可といったものがあります。

【2.問い合わせ対応の期間】

 問い合わせ対応の期間とは、「受付時間+回答期間」です。受付時間については、メールなら24時間対応となりますが、緊急時の電話やオンサイト保守が入っている場合には、「受付時間+回答期間」を事前に確認しておくことが大切です。ここで最も重要な確認ポイントは、「いつ回答をもらえるか」という原則としての回答期限と、それを過ぎる場合、あるいは回答期限までの間の検討状況の報告の有無についてです。

 こうした問い合わせ対応についても「当たり前のことだろう?」と疑問に思われるかもしれません。しかし、現実にこれらに関するトラブルは決して少なくないのです。

 そのトラブルとは次のようなものです。

・問い合わせ対応はメール以外では受け付けない(実際に画面を確認しながら説明しないと伝えることが難しいケースが少なくないが、全て画面キャプチャーと説明を付けるように要求される)。

・営業担当は、問い合わせ対応は受け付けない(全てメールで、かつ、問い合わせを受け付けるのはサポート窓口のみ)。

・問い合わせ対応に対する回答期限は特に設けておらず、進捗状況についても、ユーザー側から問い合わせなければ連絡がない(営業に電話をしても、「確認します」という返答しか来ず、そのうち諦めることになる)。

 信じられないような話かもしれませんが、全て実際にある話です。過去には、従業員数500名程度の組織で、電話対応を追加してもらおうとしただけで、年間数百万円増となる保守見積もりが届いたこともあります。調達してからでは遅いので、こういったことについても仕様書と契約書に記載しておくことが必須です。

●「2.管理可能なライセンス」についての留意点

 次は、ライセンスの管理機能についてです。「SAMシステム構築推奨機能」では以下の2点にまとめています。

 ここについては、ライセンス利用数のカウント方法について重要なポイントを紹介します。

 インベントリーツールや台帳ツールのパンフレットには、「管理可能なライセンス」として、「デバイスライセンス」「ユーザーライセンス」「CPUライセンス」「CAL」など、さまざまな種類が記載されています。

 しかし、実際に管理機能を確認してみると、本稿の執筆時点(2017年5月現在)では、デバイスライセンス以外、過不足を確認できないものが多いのが実情です。中には「ユーザーライセンスもカウントできる」としている製品もありますが、実際には、例えばボリュームライセンスで開発用ライセンスを50本調達した場合に、それを1本ずつ登録させ、それぞれにユーザーを割り当てる手続きを要求するようなものがあります。

 「開発用ライセンスを使用するユーザーが変わるたびに、台帳を更新する」という運用は、使用許諾条件上は登録義務があるとしても、「台帳上も同じように更新する必要がある」とした場合、頻繁に利用者の変わる開発部門にとっては現実的な運用とは言えません。

 セカンドライセンスについては、現時点では管理対象に含んでいるものは少ないようですが、これからは管理することが望まれるライセンスだと考えています。

 筆者は以前、「システムの対応負荷と管理負荷から費用対効果を考えれば、セカンドライセンスの権利は放棄することも1つの手段である」とお伝えしてきたこともあります。しかしこの考え方が通用したのは、せいぜい3年ほど前までです。

 今では1人1台以上のハードウェアを持つことが当たり前になり、セカンドライセンスの権利行使は、コスト最適化の面からも無視できないものになっています。また、「Adobe Creative Cloud」や「Office 365」などのように、ID1つで複数利用できる権利が与えられるクラウドライセンスの一種では、IDの利用状況についても履歴を管理することが求められています。これらのことから、セカンドライセンスの管理は必要不可欠な機能の1つになっています。

 ライセンスのカウント方法や使用許諾条件は、年々変わっていくものですので、旧態依然としたデバイスライセンスしかカウントできないような仕組みでは、今後の管理はおぼつかないものとなります。新しいライセンスへの対応方針も含め、それに対応できるか否か、機能を確認することが必要です。

 単に「登録可能」なだけの仕組みを「管理可能」な仕組みと言い換えられていないかどうかを十分に確認すること、また、現時点での実装がないとしても、ロードマップを確認し、どの時点でどのような対応を予定しているか確認しておくことが必要です。

 管理可能なライセンスについては、「自組織において、ライセンスの保有を重点的に管理すべきソフトウェアは何か」「その利用状況を把握するために、どのような分類やカウントが必要か」を十分に検討した上で、それが実装されている、あるいは実装される予定が明確にあることを確認することが大切です。

●「3.その他」の留意点

 最後に、その他の留意すべきポイントとして、次の3つを解説します。


1.部署マスター・ユーザーマスター変更時の処理について
2.ユーザー権限について
3.ライセンスのひも付けについて

○1.部署マスター・ユーザーマスター変更時の処理について

 部署やユーザーの変更対応については、「SAMシステム構築推奨機能」では以下の2点にまとめています。

 ここで注意していただきたいのは、どちらも青字で記載している部分です。

 SAMシステムでは、全ての申請履歴や資産に、部署やユーザーの情報がひも付けられます。そしてこれらの情報は、部署マスターやユーザーマスターから参照されるのが一般的です。

 部署マスターの情報は改廃によって何度も変更されることがあり、ユーザーマスターの情報も、部署の移動や退職などによって変更されることがあります。このとき、例えば申請履歴なら、部署マスターやユーザーマスターが変更された際、過去に承認されたレコードも影響を受けて変更されてしまっては、申請履歴としての意味がありません。資産なら、資産がひも付いている部署を廃止した際に何の手当てもなければ、資産が宙に浮いてしまうことになってしまいます。利用者が異動したときに、そのまま資産も全て移動してしまった場合には、(それが利用者と共に移動することで問題ない資産ではない限り)所在不明となってしまいます。そういった事象が起きない仕組みを備えていることを要求しているのが、この青字の部分なのです。

 この部分が適切に設計されていない場合、部署を削除した際に「どの部署にもひも付かない資産」が存在してしまうことに気付かない、という状況も発生することになります。システムに登録されているにもかかわらず、表示されない、あるいは「部署にひも付いていない資産の検索」といった、非現実的な検索をしなければ見つからない資産が存在してしまうような仕組みでは、IT資産管理としての目的を果たせるとは言えないでしょう。

○2.ユーザー権限について

 前回もお伝えした通り、日本の場合は完全な集中管理でIT資産管理を行っている組織は少なく、分散管理、あるいは一部に集中管理の仕組みを持ったハイブリッド管理が一般的です。そのため筆者は、IT資産管理の運用においては、全体を管理する権限を持つ、いわゆる「統括管理者」と、指定された部署のみを管理する、いわゆる「部署管理者」がいることが望ましいと推奨しています。

 ただし、統括管理者や部署管理者といったロールのみをシステムに登録するのは、望ましい仕組みとは言えません。「ユーザーマスターに登録した個々のユーザーにロールを割り当てる」仕組みであれば問題はありませんが、ユーザーマスターに「統括管理者」や「部署管理者」といったロールのみを登録した場合、承認者や申請者がユーザー名ではなく、「統括管理者」「部署管理者」といった特定できない名称になってしまい、実施者を特定できなくなるからです。

 ロールを持つユーザーをシステム外で管理するといったことも考えられますが、それでは“屋上屋を重ねる”ようなシステムになってしまうことから、望ましくありません。

 また場合によっては、1人の管理者が複数の部署を管理する仕組みを持つことも必要になります。例えば、「営業部と総務部があるが、管理者は両方の部で1人しか置かない」といったような場合です。

 分散管理に対応しているということは、一般的には、それぞれの部の情報はそれぞれの部で閉じた形となっているはずです。その場合、両方を管理範囲とするユーザーを作れなければ、管理する部署ごとにログインするユーザーIDを作成し、それぞれにログインし直して管理することになり、現実的な運用とは言えないからです。

 従って、ユーザー権限については自組織の管理体制に照らした上で、

・ログインユーザーは、「ロール」ではなく「ユーザー」として登録できるか?
・ユーザー権限にはどのような権限があるのか?
・1つのユーザーIDに複数の管理範囲を割り当てられるのか?

 以上について、十分に確認しておくことが必要です。

○3.ライセンスのひも付けについて

 「ライセンスのひも付けがどのように行われるか」も、重要な検討事項の1つです。ライセンスについては、利用しているソフトウェアではなくハードウェアにひも付ける仕組みになっている製品があります。

 それは一見問題ないように思われるかもしれませんが、それではライセンスの過剰利用を把握することが難しくなります。

 そのような仕組みの場合、「実際にインストールされていないソフトウェアのライセンスが無駄に消費されている」ことを検知することが難しくなります。

 これを避けるためには、「SAMシステム構築推奨機能」に記載している通り、ライセンスを、ハードウェアではなく、インストールされているソフトウェアにひも付ける仕組みを持つことが必要です。

 また、ライセンスとライセンス媒体をひも付ける際、それが1対1か多対多かを確認しておくことも大切です。例えばダウングレード可能なライセンスの場合、当該ライセンスには複数のダウングレード用の媒体と最新バージョンの媒体をひも付けられることが望まれます。ダウングレードして上位バージョンのライセンスにひも付けたライセンス媒体は、同バージョンのライセンスにもひも付けられることが望まれます。

 1対1のひも付けしかできない場合、ライセンスごとにライセンス媒体が必要となり、媒体を無駄にコピーする必要が生じます。

 「MSDN(Microsoft Developer Network)」や「JUST Office」などのスイート製品についても、1ライセンスに複数の媒体をひも付ける必要が生じる場合があります。インストールしているソフトウェアによって、利用する媒体が異なることもあるため、インストールしているソフトウェアに合わせて、ライセンス媒体をひも付けることも望まれるからです。

――◇――

 以上、SAMシステムの重要ポイントについて、特に必要と思われる機能について説明してきましたが、考えていただきたい順番は以下の通りです。

1.必要な機能を考える

2.必要な機能が実装されているか、実用可能な機能かを確認する

3.機能がない場合、今後の製品ロードマップで、必要な機能が実装されるかを確認する

4.3が受け入れ可能な場合は、それまでの代替手段を考える、あるいは(カスタマイズ以外の)代替手段を提案してもらう

 そもそもロードマップもないようであれば、カスタマイズはやむなしですが、まずはカスタマイズしないでどこまでできるかを考えることが重要です。


●著者プロフィール

篠田 仁太郎(しのだ じんたろう)

日本におけるIT資産管理、ソフトウエア資産管理のトップコンサルタント。株式会社クロスビート代表取締役/(財)日本情報経済社会推進協会 IT資産管理評価検討委員会 委員長/(社)ソフトウェア資産管理評価認定協会(SAMAC)事務局長/情報規格調査会 SC7 Class Cリエゾン SAMAC代表

最終更新:6/27(火) 7:55
@IT