PC資産管理で必要な機能~Redmineとフィットギャップ分析する
PCやソフトウェア、サーバーなどのハードウェア資産管理について、調べた内容をメモ書き。
【参考】
ソフトウェア資産管理
時代は「PC資産管理」から「IT統合資産管理」へ - @IT情報マネジメント
勉強会リポート:クラウド時代のIT資産管理(2):なぜ、PC資産管理は失敗するのか? (1/2) - ITmedia エンタープライズ
勉強会リポート:クラウド時代のIT資産管理(2):なぜ、PC資産管理は失敗するのか? (2/2) - ITmedia エンタープライズ
特集:自社の命運を左右するIT資産管理(2):IT資産管理ツール、失敗しない選択基準 (1/2) - ITmedia エンタープライズ
特集:自社の命運を左右するIT資産管理(2):IT資産管理ツール、失敗しない選択基準 (2/2) - ITmedia エンタープライズ
【1】PC資産管理の背景と問題点
PCが業務で必要不可欠となった今、内部統制やISMSという観点で、PCやサーバーの資産管理が重要になってきている。
例えば、個人情報や顧客情報の流出、ウイルスによるPC汚染、著作権を無視したソフトウェアライセンスの不正利用、セキュリティパッチが当てられていないサーバーへのDoS攻撃など、下手をすれば会社は社会的信用をなくしてしまう。
そのために、PCやハードウェア、ソフトウェアの資産管理がどの会社でも必須になってきている。
だが、その資産管理はとてつもなく大変なのが実態だろう。
会社で保持しているPC・SW・サーバーをそもそもどれくらい保持しているのか、という内容をまとめるだけでも大変。
現代ではPCやサーバーは消耗品であり、3年も経てば陳腐化してしまい、買い替えが必要。
ハードが変われば、OSもソフトも変わってしまう。
OSやミドルウェアがバージョンアップすれば、それに付随するソフトウェアも一括更新が必要。
情報を収集した時点は最新の情報だが、1ヶ月も経てば、その情報は古くなる。
ハードウェアの資産情報の収集も大変だが、ソフトウェアライセンスの情報収集はもっと大変だ。
特に、WindowsOSやWindowsサーバーはセキュリティパッチがどの状態まで当たっていて、何が不足しているのか、を把握する必要がある。
そうでなければ、IEやWindowsサーバーのセキュリティホールを狙われてしまい、業務の障害や顧客情報の流出などの危険が出てくる。
ソフトウェアライセンスの不正利用がないかをチェックすることも重要だ。
MSOffice製品はもちろん、他のソフトウェアでもライセンス数が足りないのに、水増しして使っていないか。
ソフトウェアライセンスの管理で重要なのは、倉庫に保管されて未使用なPCにあるソフトウェアライセンスの棚卸しだろう。
使われていないソフトウェアライセンスは回収して、別の人に割り当てるなどして、できるだけ有効利用するようにしたいものだ。
だから、PCなどのハードウェア情報だけでなく、ソフトウェアライセンスの情報も定期的に収集する機能が欲しくなる。
また、派遣要員が社内の大半を占める場合、資産ではなくリースの概念も必要になってくる。
全てのPCが資産とは限らない。
特に、会計の観点では、PCやサーバーは資産として計上し、年度ごとに減価償却していくために、年度末には台数をきちんと棚卸し(インベントリ)して確定しておかねばならない。
つまり、PC資産管理では、最終的には会計システムへの連動機能も考慮する必要はある。
【2】資産管理の基本的な機能
資産管理の基本的な機能は3つあると思う。
(1)構成管理データベース(CMDB)の構築による台帳機能
ITサービス管理のガイドラインであるITILでは、構成管理データベース(CMDB)で、PCなどの資産情報を一括管理する。
CMDBに資産情報というマスタが一元管理されていれば、常に最新の情報が取得できるし、いくらでも欲しい情報を集計して出力もできる。
CMDBには、あるべきPCやハードウェアの状態の情報であるToBeと、インベントリ機能で現在の資産情報を収集した状態の情報であるAsIsが明確に区別されて保持する必要がある。
ToBeの情報が、あるべきIT資産台帳に相当する。
資産台帳には、ハードウェア、ソフトウェア、ライセンスの情報が全て入っている。
また、資産台帳とは別に、ソフトウェア辞書もあるとありがたいだろう。
例えば、ソフトウェア辞書を使えば、一つのPCやサーバーに必要なソフトウェア情報をテンプレートとしてまとめておけば、他のPCにも流用できる。
ISMSのセキュリティポリシーを元に、現在の資産の状態が是正すべき状況であるか判断するためには、ToBeの情報とAsIsの情報は明確に区別すべき。
(2)資産情報を自動収集するインベントリ機能
全社規模でPCやサーバーの資産情報を定期的に、社員にアナウンスして情報収集して管理するのは、派遣社員を含む社員数が増えるほど煩雑になる。
自己申告制のため、報告された情報の正確性も内部統制上、問題になるかもしれない。
だから、PCやサーバーの資産情報をツールで自動収集するツールが必須になってくる。
この機能はインベントリ機能と言われるらしい。
つまり、インベントリ=資産の棚卸しだ。
インベントリ機能で、PCやサーバーのスペック情報だけでなく、OS・ソフトウェアのバージョンやパッチの状態、ライセンス情報まで取得できるとありがたい。
そのレベルまで実現できれば、セキュリティポリシーやライセンスポリシーによる判定がかなり楽になる。
実現方法としては、サーバー上でCMDBに資産情報(AsIs)を記録する機能があり、クライアントには別途インストールしたアプリで資産情報を収集してサーバーへ送付する機能の2つが必須。
(3)ワークフロー管理と資産管理の連携
PCやサーバーを新規購入する場合、普通は、上司に申請して承認されて、購入され、OSやソフトをインストールして構築して、データセンターや社内に移動されて、初めて使えるようになる。
すると、資産のライフサイクルに合わせたワークフロー管理機能が資産情報を連携できると運用しやすくなる。
承認フローがワークフロー管理として実装されていれば、証跡として記録することで、内部統制の運用もやりやすくなる。
【3】運用のコツ
PC資産管理は、情報システム部門や管理部門が担当しているだろうが、その業務は結構面倒だ。
そして、管理業務ゆえに細かい所まで頑張るほど、売上に直接関わらないし、単に管理コストが増すだけだ。
だから、できるだけツールを使って、少人数で運用できる方が望ましいだろう。
実際の運用は、ツールと一体化した業務フローを手順としてまとめる必要があるだろう。
PC・サーバーの購入は購買調達部門、PC構築は情報システム部門、実際の使用は各部門のように、ハードウェアの状態によって、担当者が変わる。
従って、資産のワークフロー管理は必須機能だろう。
特に、インベントリ機能は、各担当者のPCやサーバーにアクセスするために、頻度が多いと、彼らの業務に支障が出る。
それ故に、インベントリ機能の頻度や調査範囲をバランスさせる必要があるだろう。
そして、資産管理から会計システムへの連動も考慮が必要。
例えば、購入したハードウェアやソフトウェアは資産として計上され、年度ごとに減価償却されるから、台数やライセンス数を常に厳密に把握しておかないと、会計監査でNGを食らう時がある。
普通は、ハードウェアは有形資産、ソフトウェアは無形資産で計上される場合が多いだろう。
そして、PCが除却されれば、PCの資産はゼロとなり、廃棄費用が計上される。
会計上面倒なのは、リースないしレンタルされているPCやサーバー。
リース故に負債として計上される場合もあるから。
つまり、会計部門と年1回は資産管理の情報を連携する必要があるだろう。
【4】Redmineを適用できる範囲と限界
Redmineのチケット管理をPC・サーバーの資産管理に使う事例は、既にあるようだ。
適用方法や運用方法について、下記で既にまとめた。
RedmineはPC・サーバ資産管理に適用できるか?: プログラマの思索
Redmineのチケットとハードウェア資産を1対1に対応づけることで、チケットに最新の資産情報が表示されるし、その後の変更履歴も記録される。
チケットのカスタムフィールドにIPアドレスや設置場所を追加しておけば、クエリで欲しい情報を簡単に出力できる。
また、PCの状態(購入前、構築中、使用中、廃棄、倉庫に保管中)をチケットのステータスに対応づけることで、定期チェック時にどの資産を的に絞ればよいか、分かりやすくなる。
そして、Redmineの優れたワークフロー機能によって、申請や承認フローも運用可能だ。
しかし、Redmine単独では実現できない機能もある。
上記の資産管理の機能をフィットギャップ分析してみよう。
(1)構成管理データベース(CMDB)の構築による台帳機能
チケットには、登録された資産の最新の情報を記録するだけ。
つまり、AsIsの情報は記録できるが、ToBeの情報を保持する機能は別の実現方法が必要。
また、カスタムフィールドで資産情報を追加していくと、かなりの数のカスタムフィールドが必要になってくる。
例えば、インストールされるソフトウェアとそのライセンスやバージョンの数は数百以上に上るだろう。
すると、チケットの属性が多くなるほど、チケット更新の手間がかかる。
つまり、ソフトウェア辞書のような機能が、チケットのデフォルト機能に存在しないのが弱点の一つ。
(2)資産情報を自動収集するインベントリ機能
Redmineにはもちろん存在しない。
現状は、各担当者にメールで通知して、自己申告で資産情報をチケット更新する運用になる。
すると、自己申告された情報をチェックする運用フローも別途必要となるから、何らかの業務マニュアルやチェックリストが必要になってくる。
(3)ワークフロー管理と資産管理の連携
Redmineのワークフロー機能で実現可能。
但し、もちろん、会計システムと連動する機能はない。
会計システムと連動したい場合、月次・年次のバッチ処理で資産状態を一括集計する機能を実装する必要があるだろう。
以上を比較すると、Redmineでは手運用でカバーする業務が多い。
だから、現状の業務の問題点に対し、Redmineで解決できる業務はどれか、そして、解決できない問題点は手運用でどのようのカバーするか、をあらかじめ事前に分析しておく必要があるだろう。
つまり、我々SIの受託開発の要件定義で、顧客の問題点を洗い出し、開発するシステムが何をどこまで解決するのか、というITソリューション事業の作業内容と何ら変わりない。
【5】オープンソースの資産管理ツールの機能
オープンソースの資産管理ツールはいくつかある。
日本製では、SARMSユーザ会 ≫ マニュアルがあるらしい。
ドイツ語製品だが、i-doITはデモ画面でその機能を確認することができる。
画面をキャプチャしておく。
ちなみに、i-doITは、(1)構成管理データベース(CMDB)の構築による台帳機能、(3)ワークフロー管理と資産管理の連携は実装されているが、(2)資産情報を自動収集するインベントリ機能はないようだ。
| 固定リンク
「Redmine」カテゴリの記事
- 「RedmineのUbuntu+Docker構築への移行」の感想 #redmineT(2024.11.24)
- 第27回redmine.tokyo勉強会の感想 #redmineT(2024.11.10)
- Redmineのバージョン設定でプロジェクトの設定方法が違う(2024.06.23)
- ウクライナのRedmine開発者が作ったRedmineテーマやプラグイン(2024.06.18)
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
「ソフトウェア工学」カテゴリの記事
- アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか?~Software Processes are Software, Too(ソフトウェアプロセスもまたソフトウェアである)(2024.09.22)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「システムアーキテクチャ構築の原理」の感想(2024.05.06)
- ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる(2024.03.03)
- マイクロサービス設計は従来のアーキテクチャ設計と何が違うのか(2024.01.02)
コメント