IT資産管理プログラムとは？

「IT資産管理」というカテゴリをツールからみると、この10数年で確立されてきた「クライアント環境（PC環境）管理」と認識される場合が多い。

しかし、実際のIT資産管理の対象は、PCから様々なクライアント デバイスを含み、IT環境を構成するサーバーやストレージ、あるいはクライアント ソフトウェアからサーバーソフトウェアなど、全ての資産を含んでいる。
また、ITサービス管理の観点から考えると、ITサービスを構成するサービス資産に含まれる外部サービスをIT資産として管理する必要もでてくる。

このようにIT資産の管理は、目標をどこに置くかにより、考慮されるべき点が大きく変わる。つまり、スコープや、参照されるべき標準、ベストプラクティス、プロセスなども目標を明確にしなければ、確定することができず、あいまいな目標からスタートしたプログラムや、プロジェクトが失敗に終わることも少なくない。

さらに、IT資産管理プログラムは、ITサービス管理プログラムのプロセスを共有する部分も多く、インターフェースや統合を考慮していないと、独立したマネジメントシステムが構築され、最終的な結果を、効率的に統合できなくなる可能性が高い。（例：要求実現、インシデント管理、問題管理、変更管理、構成管理、サプライヤ管理など）
また、セキュリティ管理プログラムともユーザー顧客における体制構築において共有されるべき部分が多く、インターフェースや統合を考慮していないと、独立した組織構造が構築され、効率的、効果的な運用が妨げられる。

IT戦略における目標を明確にし、その目標を実現するためのロードマップをITサービス管理、IT資産管理、セキュリティ管理という標準やベストプラクティスを参照し、統合された形で実施していくためにそれぞれのプログラムを管理し、プログラムやプロジェクトの整合性を維持していくためのシステムを構築する。

ここでいうシステムとは、マネジメントシステムとして、インプットとアウトプットがあり、一つのアウトプットが、次のプロセスのインプットとなり、新たなアウトプットを生成するというシステムを指している。ロードマップの作成には、「あるべき姿（ToBe）」のモデルが明示されていなければならない。現状である「ありのままの姿（AsIs）」を把握し、そこにある問題を明らかにし、あるべき姿へはどのように、これら問題を解決し、ギャップを埋め、段階的に近づいていくかを計画しなければならない。

したがって、IT資産管理プログラムとは、組織におけるIT資産管理の以下の項目をIT戦略における最終目標や、目標を共有し並列するプログラムとの整合性を考慮しながら定義、網羅し、整合性を維持しながら最終目標を達成するために立ち上げられるプロジェクトを管理すること、と定義することができる。

IT資産管理プログラム
１．ミッション
２．全体戦略
３．目的
４．測定項目
５．優先順位

IT資産管理プログラムは、すべての活動が定義、実装、制御、監視され、中央管理されたプロセスだ。

「全体戦略」と「目的」は、IT資産管理プログラムのミッションを支援するロードマップを定義する。

「測定項目」は、IT資産管理プログラムの有効性を検証するために必要なフィードバックを提供する。

IT資産管理者は、常に主要ビジネスドライバに基づき、IT資産管理プログラムに関係するプロジェクトやタスクの「優先順位」を管理しなければならない。

IT資産管理プログラムが対象とする１２の主要プロセス エリア

IT資産管理プログラムの管理における参照ベストプラクティスとして挙げられるのが、国際IT資産管理者協会（IAITAM）のIBPL （IAITAM ベストプラクティス ライブラリ）だ。

IBPL ではIT資産管理の中央管理プロセスを１２の主要プロセス エリアと定義し、これらのプロセス エリアによる構成をIT資産管理プログラムとしている。

１．調達管理
２．資産識別
３．コンプライアンス管理
４．コミュニケーション管理
５．廃棄管理
６．文書管理
７．教育管理
８．財務管理
９．法務管理
１０．ポリシー管理
１１．プログラム・プロジェクト管理
１２．ベンダー管理

それぞれのプロセス エリアはインターフェースを持ち、他のプロセス エリアと機能的な依存関係とプロセス間の相互関係の管理を提示している。

IBPL ではすべての機能のコントロールに関係する以下の３つのプロセス エリアをコア プロセスとして定義している。

１．プログラム管理
２．ポリシー管理（規程・規則）
３．コミュニケーション・教育管理

プログラム管理については、一般的なプログラム管理フレームワークとしてPMBOK（PMI）、PRINCE2（OGC）、P2M（PMAJ）などが考えられるが、IBPL においても基本的なプログラム管理は標準的なフレームワークに準じており、特にIT資産管理プログラムに不可欠なプログラム管理プロセスについて取り上げている。

コミュニケーション管理については前述のフレームワークと内容は同じで、ステークホルダーの特定や、ステークホルダーとのコミュニケーションの重要性と、要求事項のすりあわせや管理、整合性の維持、といったところにコミュニケーションの重点を置いている。

ポリシー管理については、IT資産管理については特にIT部門に留まらず、使用者責任としてユーザーの役割が大きく占めることから、ポリシー（規程・規則）の内容から、それらをどのように必要な要員に教育やコミュニケーションによって理解を促し、受け入れ、実践してもらうのか、という点に重きが置かれている。

IT資産管理 － プログラム管理

IT資産管理プログラムの管理においてフレームワークを参照すれば、以下のようなプロセス群と、知識エリアにおける管理が考えられる。

プロセス群
１．立上げ
２．計画
３．実行
４．監視・コントロール
５．終結

知識エリア
１．統合管理
２．スコープ管理
３．スケジュール管理
４．コスト管理
５．品質管理
６．コミュニケーション管理
７．リスク管理
８．調達管理
９．財務管理
１０．ステークホルダー管理
１１．ガバナンス

IT資産管理プログラムの管理で最も重要であり、困難なプロセスは「ステークホルダーの特定」や、「スコープ計画」などが考えられる。

何故ならば、ステークホルダーを特定するためには、まず現在のIT資産管理のプロセスを洗い出し、フローチャート化し、すべての関係プロセスを明らかにした後に、それらのプロセスに関係する人物を部門や職務内容に関係なく網羅的に列挙する必要があるし、それは、IT部門に留まらないので、他部門へ問い合わせて他部門における関係プロセスも明らかにする必要があるからだ。

もし、この作業を避けて通れば、IT資産管理の管理システムはIT部門の部分的な最適化を実現しても、部門横断的な全体最適化を実現することは不可能となり、IT資産管理に関係するデータの信頼性や、鮮度の維持、データ利用の効率化と効果的な管理システムの自動化テクノロジーの運用を妨げることとなる。

つまり、IT資産のライフサイクル プロセスの管理は、それに関係するすべての関係者の効率化や効果的な管理システムと自動化テクノロジーの運用なくして、実現はありえないと言える。
そのためには、まず、「ステークホルダーの特定」や「ステークホルダーの期待管理」を「スコープ計画」や「目標と目的」、「要求事項定義」などと合わせて、全体戦略との整合性がとれたロードマップを構成するに足るIT資産管理プログラムの計画を構築することが求められる。

求められるプログラム アーキテクチャ管理

「ステークホルダーの特定」や「スコープ計画」などからも理解できるように、IT資産管理プログラムでは、複数の立場、目的などが折り重なるメッシュ状態の関係を管理することが必要となる。

例えばIBPLなどのフレームワークを参照する場合、それぞれの管理プロセス エリアの依存関係をアーキテクチャとして図示しているが、複雑に関係するプログラム構成要素間の関係を構造化し、統制ルールに準拠させなければならない。また、IT資産管理プログラムのコンポーネントである調達、法務、財務、コンプライアンスなどは、それぞれのインターフェースについて透明性のある管理が重要となる。

プログラム アーキテクチャは、目的が異なるステークホルダー間の関係を明確にし、同じ目標を持ってIT資産管理プログラムに取り組むための共通理解を得るためにも重要な役割を担うのでプログラム チームのメンバーからステークホルダー全てに対してのコミュニケーション計画や教育計画に含むべき内容と言える。

プログラム アーキテクチャには、プログラムを構成する以下のプロセス エリアを含む。

１．ポリシー管理
２．ベンダー管理
３．財務管理
４．調達管理
５．法務管理
６．コンプライアンス管理
７．資産識別管理
８．廃棄管理

これらのプロセス エリア間の依存関係やインターフェースには以下の項目を含むが全てではない。

１．調達ポリシー
２．環境要件
３．購入情報
４．パフォーマンス情報
５．購買情報
６．資産パフォーマンス
７．一意識別子
８．突合・整合化データ
９．要求事項
１０．再配置・変更
１１．法令順守要件
１２．法令・法規
１３．税法
１４．財務記録
１５．課金

IT資産管理プログラムの現状

残念ながら、良く耳にするのは「IT部門内でおさまるIT資産管理をやりたい」とか、「IT部門は、間接部門なので組織横断的な協力を求めるのは難しい」とか、「財務、法務、人事などの部門は、自分たちのシステムで完結しているので協力を得られない」などのIT部門の悲痛な叫びだ。

しかし、今までに少なくとも１回、あるいは２回以上IT資産管理に取り組みながら、その取り組みが成功だった、と認識されていない場合、多くの場合の原因は前述の「ステークホルダー」と「スコープ」の問題であるといっても過言ではない。

ただし、これはIT資産管理を任されたプログラム マネジャーや、プロジェクト マネジャーの責任ではない。

これは、明らかにIT資産管理の重要性と取り組みについてのIT担当役員の認識不足であり、多くの場合、プログラム マネジャーや、プロジェクト マネジャーは、これらの必要性を経営層に訴え続けてきている。

そして、IT担当役員の認識を得られ、IT担当役員が組織横断的な協力を求めるべく各部門長と交渉し、IT部門のプログラム マネジャーに対して責任だけでなく、権限を委譲し、関係各部門からプログラムに参加するメンバーを供出させることができればIT資産管理プログラムの成功率を飛躍的に向上させることができることは、数あるプログラム/プロジェクトの前例から立証されている。

「IT資産管理は所詮、後ろ向きな取り組みだから重要ではない」などという経営者がいたとすれば、それは、「IT部門はいつまでもコストセンターでいい」、つまりは、IT部門はどこまでいっても「技術サービス」を提供するコストセンターに留まらせる、という決断を下したに等しい。

もしも、IT部門をプロフィット センターとして、サービスモデルの実現を目標にIT戦略を構築している、あるいは、しようとしているのであれば、まったく、その動きと相反した矛盾した言動と言える。

組織は、コンソリデーションを行っているだろうか？ 仮想化を行っているだろうか？リソース プールを構築しているだろうか？ビジネス ユーザーのニーズを捉え、迅速に対応するためにサービス指向アーキテクチャへ移行しようとしているだろうか？クラウド サービスの採用などにより、ハイブリッド クラウドの採用を考えているだろうか？ これらの問いへの回答がYESである場合、それは、すなわち、サービス モデルへの移行を意味している。

つまり、ユーザーあるいは経営者の期待は、IT部門が「部品の提供者」で「コストセンター」であったところから、「サービス プロダクトの提供者」で「プロフィット センター（バリューセンター/イノベーションセンタなど呼称は色々変わるが）」として自律する能力を求めている。

これから、ますますサービス プロバイダによるサービス プロダクトの競争が激しくなっていくなか、IT部門は可能であれば1st Tier（ユーザーに直接対応する唯一のプロバイダ）サービス プロバイダのポジションを確保すべきだ。ところが、もちろんのこと選択肢としては、大手ベンダーが虎視眈々そのポジションを狙っている。
IT資産管理プログラムは、サービス プロダクトを提供する上で、メーカー（製造業）にとってはBOM（Bill of Material）管理に等しい。

IT担当役員は認識を改め、IT資産管理プログラムに取り組む必要があると言える。