IT業界全体が「テクノロジーモデル」から「サービスモデル」へ大きく変化しようとしている。このモデル変化は、ITの利用者である「顧客視点」であり、ITサービスを提供する側にとっては、リスクの増加、コスト管理の責任、サービス能力の育成など、今までとは比べ物にならないくらいの負担増となるのは火を見るより明らかだ。
しかし、現実は、これらの能力を備えたサービスプロバイダだけが進化の中での生き残り競争を勝ち抜くことができるのであり、IT業界での生き残りをかけた進化の競争は、今後、ますます激化していくだろう。
ここでは、そんな大きな変化の最終ゴールともいえる「サービスモデル」のあり方を考察し、ITサービス管理にとってのIT資産管理についてまとめてみる。
ITサービスとは？
そもそもサービスモデルで言われている「ITサービス」とは何か？
意外なことに、この共通認識が明確でないままIT業界は「サービスモデル」へと進んでいるように思える。もちろん、大手ベンダーはリサーチ会社との提携や買収などにより着実にサービスモデルへの変革を睨みながら垂直統合を行い、サービスの提供能力を強化してきているのだが、多くの水平分業のパートを担っていたベンダーが取り残され気味にバズワードに振り回されながら大手ベンダーの影を追いかけているように見える。
まずは、「サービス」の定義を明確にしたいと思う。
マーケティング マネジメントではバイブルとも称される「コトラー＆ケラーのマーケティング マネジメント」では、
サービスとは、一方が他方に対して提供する行為や行動で、本質的に無形で何の所有権ももたらさないものをいう。サービスの生産には有形製品が関わる場合もあれば、関わらない場合もある。
マーケティングにおいて、対象となる製品は有形製品を含み、無形のサービス（サービス プロダクト）をも含む。
それでは、ITサービス マネジメントのフレームワークである ITIL （IT Infrastructure Library）の「サービス」の定義はどうだろう。
サービスとは、顧客が特定のコストやリスクを負わずに達成することを望む成果を促進することによって、顧客に価値を提供する手段である。
これらを踏まえて、今までのITの利用者である「顧客」、つまり、ユーザー部門はITとどのように付き合ってきたのかを考えると、その大きな違いが見えてくる。
＜ユーザーとITの付き合い方＞
・ユーザー部門が必要とするITの処理、能力、期待する結果を要件としてまとめる（IT部門はそれを支援する）
・IT部門が支援し、まとまった要件を実現するためのテクノロジーと、その導入・運用コストを試算する
・ユーザー部門が、試算にもとづいた予算を確保し、発注する
・IT部門が、調達し、または、開発し、システム統合を行い利用可能な状態を構築し、ユーザー部門へ提供し、システム運用のサービスを提供する
簡単に上記にまとめたポイントを含めて現状を解釈すると、ユーザーが所有するITテクノロジーがリスクやコスト管理など、本来ユーザーが求めているITによる処理能力と、期待される処理結果を大きく超える負担となることが容易に推察できる。これは、一極集中型におけるITでは存在しなかった負担だ。一極集中型では実現が困難だった市場の変化に対応するニーズ「迅速性」を獲得した「分散処理型」は、複雑なネットワーク環境と構成に起因する所有リスクとコストの上昇によりユーザーの負担を大きく増加させる結果となった。
言い換えれば、ユーザーが変化対応力や迅速性を求めた結果、リスクが増加し、コスト管理が困難になったと言える。変化対応力や迅速性は損ないたくない、できれば向上したい、さらに、特定のコストやリスクは負いたくない、という結果、サービスを志向するようになる。
そんな要求への解として、ユーザーの負担を軽減しつつ、迅速性を維持・向上させるために登場したのが、「サービス指向アーキテクチャ」であり、その実現のために「コンソリデーション（統合）」や「バーチャリゼーション（仮想化）」が進化してきた。
ユーザーが必要とするのは、ITがもたらす処理能力と処理結果であり、ITテクノロジーを所有することで発生するリスクの増加や、コスト管理の能力は、そもそもユーザーが欲するところではない。
つまり、ユーザーが求めるITのサービスとは、「所有権をもたらさずに、特定のコストやリスクを負わずに成果を得る」ことを期待していると言える。
したがって、ITサービスを提供するということは、サービスプロバイダが所有する資産で、リスクを背負い、コスト管理能力を発揮して、ユーザーに成果を提供し、その提供した価値にみあったコストを課金して回収する、と言い換えることができる。
サービスモデルにおけるIT資産管理とは？
サービスモデルにおけるIT資産管理の前提条件として、前述のITサービスの定義からスタートすると、
・IT資産はサービスプロバイダが所有する
・顧客に提供するITサービスを構成する資産はサービス資産である
・顧客に提供するITサービスを実現するために必要となるサービス 能力を支援するに必要なIT資産を含む
IT資産の定義として上記のポイントを考慮すると、
IT資産とは、サービスプロバイダが所有するIT資産（有形・無形）全般を指し、サービス資産を含み、顧客に提供するサービスを構成しないサービスプロバイダの資産をも含む
と、考えることができる。
しかし、テクノロジーモデルからサービスモデルへの変化には、それ相応の時間がかかる。その間、所有がユーザーであるIT資産や、所有がサービスプロバイダであるIT資産もあり、一方でコストの全体最適化を実現するためにプールされる資産は、そのどちらをも含むというトランジション フェーズが何年か続くだろう。
つまり、サービスモデルへのトランジションは、複雑に入り組んだ所有権とプールされる資産を、誰が（所有と利用）、何のために（紐づくサービス）、どのように利用される（リスク・コンプライアンスの管理）のかを明確に管理することが重要となる。
サービスカタログ、要求実現でおさえるべきIT資産管理プロセス
サービスモデルを標榜する組織では、IT資産管理のプロセスはサービスカタログ、要求実現のプロセスにおいて開始される。
サービスカタログはユーザーに分かりやすいカタログ化という一面と、そのサービス提供を可能とする裏方が利用するテクノロジーの詳細という一面が存在する。
例えばユーザーの端末機器は、サービスを提供する上でエンドポイントとなり、エンドポイントの機器、環境の提供や管理などサービスカタログにおいて標準化されたパッケージサービスがユーザーに分かりやすく、詳細の構成情報などはサービスプロバイダに分かりやすく設計されている必要がある。
IT資産管理のプロセスは、要求実現のプロセスにも大きく関与する。ユーザーまたはサービスプロバイダが所有する資産を、サービス実現のために提供するにはIT資産の在庫管理が正確に実施されていることが前提条件となる。これは有形のハードウェア資産、無形のソフトウェア資産（契約）の在庫管理の能力、つまり、資産プールの管理や、再利用のために必要な処理という能力が求められる。
IT資産管理においては、標準化、調達、IMAC（インストール、移動、追加、変更）、ソフトウェア ライセンス（使用権）の最適化などのプロセスがこれらに関係し、サービス管理のプロセスとの統合が求められる。サービス管理との統合を念頭に考慮されていないIT資産管理は、独立したマネジメント システムを複数構築し、無駄が発生し、管理コストを上昇させるだけでなく、リスク増加の原因ともなるので十分な注意が必要だ。

サービス資産、構成管理でおさえるべきIT資産管理プロセス
ユーザーの端末はエンドツーエンドのサービスのエンドポイントであり、ユーザーの端末環境を含むエンドポイント プラットフォームの提供をサービスと捉えれば、「ユーザーにPCを提供する」というサービスを構成するサービス資産であるPCハードウェアやOS、アプリケーションおよび、それらの設定を含む構成情報は、サービス資産および構成管理の範疇であり、IT資産管理プロセスと重複するので、統合を念頭に考慮されなければ前述の無駄やリスクが発生する。
もちろん、サービス管理におけるサービス資産とは、能力や人材などサービスを提供する上で必要となる構成要素すべてを含み、IT資産管理が対象とする資産は、サービスを構成する資産に限らず、サービスを提供するために必要なサービス管理インフラの資産をも含む。
サービスプロバイダとしては、これら重複するプロセスを共有しながらも、独立した固有の目的をも対応しつつ、二つのマネジメント システムの統合と共存を図ることが求められる。

IT 資産管理プログラムの定義の目的は、組織内のIT 資産管理業務のミッション、全体戦略、目的、測定項目、優先順位を要約し、定義することである。
IT 資産管理プログラムは中央集中型のプロセスで、これにより、全ての活動が定義、実装、統制、監視される。
プログラムの内容、IT 資産管理チームの重要性、組織が得る価値を伝えるために、ミッションステートメン トはプログラムにおいて重要である。ミッションステートメントがプログラムの目的を役員に正確に伝え、 役員の信頼と承認を得ることが、非常に重要である。
全体戦略と目的がIT 資産管理プログラムのミッションをサポートするロードマップを定義する。戦略と目 的は、組織のニーズに基づく適切なIT 資産管理プログラムへの道のりを、明確に示すべきである。
測定項目が、IT 資産管理プログラムの有効性の判断に必要なフィードバックを提供する。IT 資産管理者は、このフィードバックを基に、IT 資産管理プログラムの長所と欠点を把握し、組織のニーズに照らして必要な調整を行うことができるのである。
IT 資産管理プロセスと関連タスクの優先順位は、組織のビジネスドライバー次第である。IT 資産管理者は、常に、これらのビジネスドライバーに基づき、IT 資産管理プログラムに関連するプロジェクトとタスクを優先しなければならない。そのためには、組織の他の部門とのコミュニケーションが円滑でなければならない。
IT 資産管理プログラムは、組織の全てのビジネスドライバーに有益な影響を及ぼすという点で稀有なプログラムである。
IT 資産管理プログラムは、単に、全ての活動の定義、実装、統制、監視のための集中管理ポイントであるだけではない。プログラムは、IT 資産管理のマーケティング部門としても機能し、組織のあらゆる部門が、適切に統合されたIT 資産管理プログラムの成果を享受できるようにする。

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資産管理プログラムに取り組む必要があると言える。

PC資産のライフサイクル管理をアウトソース（シートマネジメント・サービス）しIT部門の負担軽減を図りたいという期待が高まる中、アウトソーサーに対して明確なアウトソーシング内容の理解が期待されている。
標準対応（サービスカタログ）、申請・承認ワークフロー、発注、受領、キッティング、運用、廃棄のフェーズにおける様々なプロセスや管理項目としてのセキュリティ、コンプライアンス、資産ライフサイクル、サービス管理統合までを一気通貫でアウトソーシングできればIT部門の負担は大きく軽減される。
しかし、IT部門がサービスプロバイダとしてエンドツーエンドの環境をサービス提供することから、ヘルプデスク（サービスデスク）はアウトソーシングされたPC環境であってもサービスの一部としての対応ができる体制が求められる。
つまり、ヘルプデスクが行う一次対応へのデータの提供や、エスカレーションパスとしてのPCテクニカルチームの対応連携、インシデント管理情報やKEDB（既知のエラーDB）情報への情報統合、問題管理へのエスカレーションパス、変更管理、リリース・展開管理など一次サービスプロバイダであるIT部門が安心してアウトソーシングできる体制が期待される。
それを実現するためのプロセス能力や自動化テクノロジーがPC管理のアウトソーサーには求められている。
PC管理アウトソーサーは、IT資産管理プログラムを管理し、IT資産管理のベストプラクティスに則って、また、ITIL などITサービス管理のプロセスとの統合や二つのマネジメントシステムで使用される自動化テクノロジー（CMDB および CMS）の統合を念頭に提案ができているだろうか？

１．危機意識を高める
２．変革推進のための連帯チームを築く
３．ビジョンと戦略を生み出す
４．変革のためのビジョンを周知徹底する
５．従業員の自発を促す
６．短期的成果を実現する
７．成果を活かして、さらなる変革を推進する
８．新しい方法を企業文化に定着させる
多くのIT関係の組織が今、サービスプロバイダへの進化のみが将来の生き残りの道として選択の余地もなく明らかとなった。
サービスプロバイダとしてサービスのプロセス能力を養い、プロセスを常に改善する仕組みが定着し、サービスプロバイダとしてサービスプロダクトのメーカーになれる組織は、一握りの組織だろう。
大規模な変革は、企業文化を変えるほどの進化が求められる。
ITのサービスプロバイダは、プロセスを管理し、プロセスレベルでのBPR を継続的に行い、結果を自動化テクノロジーへと結んで効率性を最大化することが求められる。

クラウドコンピューティングを理解するための鍵

ユーティリティコンピューティング

1990年代の後半に、ユーティリティ コンピューティングは再度、市場に現れる。

ITベンダーにとってユーティリティモデルは、ハードやソフトウェア を毎回販売して利益を得る「フロー型ビジネス」から、電気、ガス、水道、電話のように毎月ほぼ固定的に利用料を徴収できる「ストック型ビジネス」への、よ り安定性の高いビジネスモデルへの転換だから歓迎だ。むしろ、ユーティリティモデルのようなストック型ビジネスの方が年間の予算は見えるしビジネスは安定 する。しかも、顧客を囲い込むことができるので、毎回激しい競合との価格競争により利益率が悪化する一方の、それまでのビジネス形態から脱却することがで きる。 ユーザにとっても、日々業務に追われながら複雑に進化するIT技術を追いかけるより、従量課金制のサービスとして利用し、月々のコストとして処理するほうがはるかに楽になるはずだった。

しかし、個人情報や機密情報、ビジネス優位性を有するビジネスプロセスなどを完全に企業の外に出してしまい、ITベンダーに預けてサービスとして利用するITには、現時点では様々なリスクを伴う。これらリスクの課題が完全に解決されるまでは、機密情報や企業優位性を有するビジネスプロセスを、完全に企業の外に出した時のリスクに懸念を抱く企業にとって、完全なユーティリティモデルへの移行は不可能だ。もちろん、IT技術がさらに進化し、機密性、安全性が完全に確保され、ユーティリティモデルによるコストメリットを享受できるのであれば、最終的には完全にユーティリティモデルへ移行することが考えられる。この場合は、ユーティリティ データセンターにはサービスを提供する先の複数の企業の変化に対応するための、非常に高い変化対応力が求められる。それだけではなく、提供するサービスの ビジネスにおける重要性に応じてサービス料金もいくつかのレベルを持つ必要がある。可用性、堅牢性が高く求められるミッションクリティカルなサービスと、 そうでないサービスの料金はユーザからすれば当然同じ金額を払うことはできないからだ。もちろん、ユーティリティモデルへの移行時期には例外もある。前述のケースは中堅・大手企業で既に自前のデータセンターを 持っている場合のことで、中小企業などで「サーバを自社購入して、運用管理はサービスを提供しているデータセンターへ実機を置いてお任せしている」、とい う場合は早急にパブリッククラウドへ移行し、全てをコスト化してしまった方が良いケースもある。

中小企業にとってはパブリッククラウド環境が一日も早く安定提供され、最大限の活用による無駄なコストの削減と、IT運用の効率化が競争力の鍵となるだろう。これらのユーティリティモデルへの動きはIT業界における、ITベンダーの垂直統合やグローバル化の動きを見ても、最終形としてのユーティリティモデルによるサービス化をゴールとしていることが伺える。既に飽和状態のIT市場においてフロー型ビジネスではこれ以上の成長は望めない、垂直統合を行い、ユーティリティデータセンターをグローバルに展開し、サービスとしてグローバル企業を取り込むことで30%しか手を出すことができなかったIT市場の100%を視野に入れて成長路線を歩むことができるからだ。

クラウド コンピューティングの登場

現時点でのユーティリティモデルの課題を解決する方法として、提案されたのがクラウドコンピューティングだ。
クラウドには、パブリック クラウドとプライベート クラウドがある。
パブリッククラウドは、SaaS、PaaS、XaaSな どソフトウェア、プラットフォーム、ハードウェアなどをサービスとしてベンダーにより提供され、対してプライベート クラウドは、企業内のユーティリティモデルといえる。企業内ユーティリティモデルでは仮想化された一つのプラットフォーム上で、複数業務に対して組織横断 的にサービスを提供する。仮想化されたリソースプールを効率的に利用することで稼働率90%を実現し、可変的に必要となるリソースは企業外のサービスをパブリック クラウドという形で柔軟に利用する。 また、企業内では優先度や稼働率が低いサービスなどもパブリッククラウドを利用することで無駄な投資を避け、従量課金で最もコスト効率の良いサービスを利用することが可能だ。さらに、企業内にはない優良なシステム（例：SalesForceなど）をサービスとして利用することで、あえて社内でシステム開発をしないで無駄な開発コストや管理コストを抑制することができる。

クラウドにおいては物理的な異機種混合環境を、論理的なリソースプールとして統合し、仮想化することでハードウェアの稼働率の最大化を図る。さらに、管理層により再利用性の高いサービス指向アーキテクチャ(SOA)のアプリケーション層の変更管理を行い、迅速な変更を可能とし、変化対応力を向上する。業務アプリケーションでも、管理アプリケーションでも粒度の粗い、疎結合のシステムにすることで連携や統合を容易にし、サービスとサービスの連携の仕方や、新たなサービスを加えて連携させることで、変化への対応力を高めている。その実装技術としてWebサービスによるHTTPなどを利用したファイアウォール越えの連携がある。今まではAPIを使い、ローカルポートを利用した密結合の連携でしか実現できなかったアプリケーションの連携が、Webサービス技術により、アプリケーションの違いや、開発言語の違いを乗り越えて疎結合の連携を可能とし、比較的簡単に短時間で連携を実現し変化に対して迅速に対応することを可能とした。

そんな疎結合で柔軟性、変化対応力の高いクラウドでより一層明確になったのは管理層の重要性だ。

今までシステムの監視と管理は、開発にくらべ後ろ向きなコストとされ、開発などの投資が30%に対して、運用コストが70%という、後ろ向きなコストを削減するべきだと言われ続けてきた。ところが、異機種混合のハードウェア環境において開発されたアプリケーションを最大限に生かし変化に対応するためには、管理 層の機能は開発同様に戦略的で迅速な対応が求められる。監視と管理という運用における役割は、「再利用性の高いサービスコンポーネントや、仮想化されたプ ラットフォームの変化対応力を最大化する管理層を構築し運用する」という形で、今まで川下と考えられていた運用とは全く異なり、IT戦略の中枢で非常に重要な役割を担うことになる。

クラウド実現の鍵は、「変化対応力を備えた管理層の構築だ」といっても過言ではない。

そして、クラウドの管理層の構築で最も重要なのは、決して管理ツールで自動化すれば解決する問題ではないということだ。管理 ツールは、標準化された運用管理のプロセスをサポートし、自動化、効率化を実現する重要な役割を持っていることは確かだが、ツールの導入で運用管理プロセ スが構築されることはない。変化へ対応するための変更を全てツールにより自動化することは不可能なので、迅速な変化対応を実現するためにはツールを生かすための人によるポリシーベースの変更プロセスが機能しなければならない。

クラウド環境の進化

企業のITのあり方として今日のクラウドコンピューティングに至るまで、「ユーティリティ コンピューティング」や「グリッド コンピューティング」などが提案されている。これらは変化対応力やコストの最適化、投資効率の最大化などを課題として取り組まれてきたもので、今日のクラウド コンピューティングへの進化の過程であり、クラウド コンピューティングとも混同しやすい。

以下にそれぞれの定義を簡単にまとめてみる：

１． グリッド コンピューティング

スーパーコンピュータ、仮想コンピュータがネットワーク化され、疎結合されたコンピュータのクラスターを構成し、膨大なタスクに対して複数のコンピュータが協力して処理する分散処理コンピューティングの形態。

２． ユーティリティ コンピューティング

電気など、公共ユーティリティサービスのように従量課金サービスとして、演算処理やストレージなどのコンピュータリソースを提供するサービスをパッケージ化したもの。

３． クラウド コンピューティング

動的な拡張性があり、仮想化リソースがインターネット上で提供されている。クラウドを利用するユーザは、クラウドをサポートするインフラ技術の制御、専門知識、いかなる知識も必要としない。

クラウドの概念は以下の組み合わせにより構成される：

①IaaS (infrastrucrure as a service)

②PaaS (platform as a service)

③SaaS (software as a service)

④XaaS (everything as a service) その他、最新のインターネット上でユーザのニーズに対応するテクノロジなど。

特にユーティリティ コンピューティングは、クラウド コンピューティングのデリバリ モデルとしての従量課金サービスという共通項があるので混同しやすいが、クラウドはユーティリティ コンピューティングを現在のインターネット時代に合わせて具現化したものと考えた方が良いのかもしれない。

ユーティリティ コンピューティング

コンピュータの演算処理やストレージのようなリソースを必要な時に、必要なだけ利用でき、使用量に応じてサービス料金を支払えたらユーザ企業にとってどんなにかコストの最適化が楽だろうか。

「電気、ガス、水道、電話のような公共サービス(public utility)と同じようにコンピュータも公共インフラサービスのような利用形態を将来とることができる」

1961年当時 MIT で教鞭をとっていたJohn McCarthy が MIT 100年際 で初めてユーティリティ コンピューティングにについてこのように公言した。以来、20年に渡ってIBMなど大型汎用機ベンダーは銀行や大手企業に対して世界規模のデータセンターでユーティリティ コンピューティング モデルを「タイムシェアリング」というサービスで提供した。しかし、ミニコンやオープン系の進化により、ほぼ全ての企業がコンピュータを導入できるようになり、このユーティリティモデルのサービスは廃れていった。

オープン系の進化により、分散処理型のクライアント/サーバ システムによる業務ごとに必要なサーバを立てるという柔軟性の高いシステム構築の方法が紹介されると、必要に応じていくらでもサーバを構築して新たな業務システムを追加できる柔軟性に、次々とサーバが立てられ、新たな業務へと対応が行われた。しかし、あまりに次々とサーバが追加され、そもそもは最終的に80%ぐらいの稼働率を予定して20～30％稼働率で構築されたサーバは、いつまでたっても30%ぐらいの稼働率のまま、ともすると何の業務アプリケーションが使用されているサーバかを管理することすら不可能な状態になっていった。同時期に研究が行われていた技術として、平行/分散処理システムを実現しようとしたのがグリッドコンピューティングだ。グリッド コンピューティングが実現され、 70%もある余剰CPUリソースを集めて分散処理のCPUリソースとして再利用できれば、ユーザは安心して次々とサーバをたて、余剰CPUリソースは新たな業務に仮想的に割り当てることができる。ところが、残念なことにグリッドの技術では余剰CPUを適宜、動的に利用して新たな業務に割り当てるという目的を果たすことは実現されなかった。

なぜ、変更管理が重要か？

今までは「川上の開発」、「川下の運用管理」というイメージで運用管理は捉えられてきた。しかし、その構図こそが全体最適化によるコスト削減の妨げの一因となってきた。

「運用管理のコストがIT投資全体の70%を 占めているからコストを削減しなければならない」長い間、運用管理部門にはこの命題が与えられていた。しかし、そもそも運用コストは上昇する構造だったと したら…川下で帳尻を合わせるということが不可能だったとしたら…以下の図は分散環境における業務システムの新規投入を表している。

非稼動資産＝余剰資産
業務システムの使用度が成長し、導入後に徐々に稼働率が向上することを考慮して、当初導入時は稼働率30%ぐらいで設計し、将来予想されるピーク時を80%ぐらいと考えて構築されたシステムは、結果として稼働率が予定どおりに向上せずに、70%ぐらいの余剰資産が次々に投入されるという事態を招くことになった。

変化に対応する手段として登場した分散システムは、安定稼動のために業務システム毎にCPUを追加し、１OS上に１業務アプリケーションを配置し、必要に応じて次々とサーバを投入するという状態へと導いた。その結果、運用管理部門は増殖するサーバにより複雑化するサーバネットワークの死活監視と管理に追われることとなった。

分散処理の１OS・１業務アプリケーションという構造を見る限り、コストが上昇する結果は明らかだ。

これら課題の解決策として「サーバ統合」によるネットワークの整理と、「仮想化」による稼働率向上が提案されることになる。

一方、業務アプリケーションの開発も、開発効率と変化対応力の向上のために「サービス」という粒度が高く、「再利用性」の高いサービス指向アーキテクチャ（SOA）へと進化していき、稼働率向上をめざす統合されたサーバ環境の仮想化環境上にSOAシステムが構築されていくこととなる。

もちろん、CPU使用率のピークの波を上手く合わせながら稼働率の向 上を図り、変化する市場にたいしてサービスのキャパシティや、システムも変化させていくとなると所有している資産だけでは収まらなくなるケースも出てく る。そうなるとプライベートクラウドが構築されたデータセンターでは必要性に応じて所有しない資産を「利用する」パブリッククラウドのリソースの有効利用 までも念頭においてサービスの提供を構築することが求められる。

クラウド化のけん引役「サーバ統合（コンソリデーション）」と「仮想化（バーチャリゼーション）」は複雑化を進める

サーバ統合と仮想化により稼働率と変化対応力の向上をしながらコスト削減を実現するクラウド環境へ一歩近づいたといえる。

しかし、変化対応力が向上すると期待されるクラウドは、一方では、頻繁に変化する環境をしっかりと管理しないとサービスの品 質の低下や、可用性の問題を発生する可能性が増大するというリスクを抱える。つまり、クラウドの実現にはリソースプールを利用し、必要に応じて構成変更を 行い変化に対応するシステムの管理が鍵となる。

クラウド実現のための仮想化環境における管理対象例

１． １サーバ上に複数のアプリケーションが動作する環境で、共有するリソースの競合の可能性が大きくなるため、共有されるリソースの管理が必要となる

２． サーバ上のレイヤーが多くなり、アプリケーションが依存する複数のレイヤーとCPUなどのサーバリソースの依存関係が変化し続けるため、ハードウェア・ソフトウェアを含めた全ての構成要素のリレーション管理が必要となる

３． 構成変更が頻繁に行われるので複雑なレイヤーを含めた依存関係の遷移を管理する必要がでてくるため、変更前・変更後などのタイミングでの全ての構成要素のリレーションのスナップショットの管理が必要となる

仮想化環境では変化対応力が向上し構成変更が容易に行えるようになる。しかし、このメリットを生かすためには、運用管理のポ リシーにおける変更プロセスを変更の頻度が高くなっても対応可能にしなければならない。具体的には変更に関わる影響分析が複雑なレイヤーや関係するハード ウェア全域、さらにはサービスを構成する全てのアプリケーションと、そのアプリケーションに関係する全てのソフトウェアレイヤーとハードウェアの構成が管 理されていなければならない。

複雑化に対応する運用管理
変化対応力やコストの最適化を実現するとして期待されているクラウドだが、前述のように、その実現には複雑化する環境を運用する管理層の充実が不可欠なことがわかる。

管理層の充実は、すでに運用管理のポリシー策定にとどまらず、「戦略」、「設計」、「導入」、「運用」、「変更」といった全てのフェーズに関わっているといっても過言ではない。

そんな変化対応力を実現する企業ITを実現する一助として注目されているのが「Information Technology Infrastructure Library （ITIL）」なのだ。

ITIL Version 3 への期待

ITIL V2 の当時は運用管理の部分だけが注目を集めたが、実はITIL は運用管理に特化したガイドラインではない。ITをサービスととらえ、あたかもユーティリティサービスを提供する際に必要となるサービス提供の全域に渡ってサービスの品質向上を実現するためのガイドラインとして策定されたのだ。

ITIL V3 ITサービスの５つのライフサイクル

１． サービスストラテジ（戦略）

２． サービスデザイン（設計）

３． サービストランジション（導入・変更）

４． サービスオペレーション（運用）

５． 継続的なサービス改善

ここで重要なことは、管理層の充実は５つのライフサイクル全てに関係しているということだ。すなわち、運用管理部門の関与も 管理層の充実という観点から考えるとライフサイクル全般を意味する。「運用管理が戦略的な役割を担う」というのもクラウド環境において運用管理層を考慮せ ずに前述の5つのフェーズのどれも語れないからだ。

クラウド時代における運用管理は川下ではなく、「運用管理こそがクラウド戦略の要」であるといえる。

変化対応力を実現するための変更管理

迅速な対応が求められる変化への対応。それには変更管理のポリシーやプロセスが機能しなければならない。特に組織横断的に利用されるリソースプールを基礎としたプライベートクラウド環境では、組織横断的にサービスの優先順位が明確化されていなければならない。具体的には、「いざとなった時に、どのサービスから犠牲にするか」ということも管理されていなければならない。全てのサービスが可用性100%を求められるわけではない。時間帯や曜日、季節によっても可用性の要件はことなるはず。

「いやいや、うちのサービスは常に利用可能な状態でなければ困ります」という部門毎の主張を受け入れてしまうと、せっかくの全体最適化実現の可能性を失ってしまう。

つまり、組織横断的にSLAを検討し、サービスの優先順位を明確にしなければ全体最適化によるコスト最適化は不可能だといってもよい。重要な社内システムとはいえ、社員が利用する時間外は可用性が高い必要性はない。一方で、一般のユーザが利用するサービスは特定の曜日、時間帯に平日昼間の数十倍、数百倍のキャパシティを必要とする場合もあるだろう。なんらかの時事的要因で例外的に急激なキャパシティ要求の増加に対応しなければならないことも考えられる。それぞれのサービスが必要とされる時間帯や曜日、季節などを特定し、さらに影響される金額に換算して、実際に企業活動の目的 といえる営業利益にどのような影響を及ぼすのかの金額の大きさを基礎に優先順位を明らかにする必要がある。そもそも企業活動の目的とは利益を生むというこ とであることを営業部門のみならず、全ての部門において理解し、IT戦略においても利益創出活動の優先順位によって明確な優先度を持つべきである。また、稼働の計画性が低いサービスや、使用頻度が低かったりというサービスは、同等のサービスがパブリッククラウドで同等コ ストで提供されていないかを検討する必要もある。この場合は会計的観点から「所有＝資産」であるから、当然「総資産回転率」といった経営指標に影響を及ぼ すことを考慮し、資産回転率に悪影響をおよぼすような要因は排除し、費用計上が可能な「利用」形態をとることを検討する必要があることをIT部門も考慮する必要がある。このように変更管理のポリシーの策定には、企業ITの戦略や方針の策定の成功が大きく関与する。

戦略や方針の策定がしっかりしていないと、サービスの優先順位が明確化されず、変更管理のポリシーが策定できず、変更プロセ スが作られていても機能しなくなる。組織横断的に管理されるサービスの優先順位は、企業戦略の変化や経済の変化により変化し続けるので、これらの変化に合 わせて随時アップデートされ管理されて変更管理のポリシーに反映されなければならない。SLAや優先順位の管理は、変更管理ポリシーの策定では一つの要素にすぎないが、これらを踏まえて、変更管理のプロセスが機能するように策定、運用されなければ変化対応力の向上にはならず、全体最適化の実現もできない。これは変更管理プロセスに限ったことではない、情報セキュリティ管理（ISMS）やソフトウェア資産管理（SAM）などもISO化されコンプライアンスが要求され、形ばかりは遵守しているようにつくろっていても戦略や方針が徹底していなければいずれは綻びが生じ問題が発生する。最も重要な前提条件は、企業戦略に則ったITの戦略や方針が経営者により明示、徹底され、それに基づいて現場のポリシーが策定され、設計されたプロセスにより運用されることだ。こればかりは、運用管理ツールを導入すれば何とかなるという問題ではない。もちろん、運用管理ツールが不要だということではない。複雑化が進むクラウド環境を効率よく運用するには様々な重要な項目を抑えているITIL のようなガイドラインを参照することは有効だ。また、ITIL に 準拠した統合管理ツールベンダーの製品を利用して管理対象の全てを可視化し、制御し、可能な限り自動化しながら、人的プロセスの一助として利用することも 効率的な運用管理には不可欠といっていい。膨大な管理対象や項目を人手だけで管理することは不可能だし、ポリシーに則って自動化できる運用は、自動化し、 空いた工数はポリシーのアップデートや、組織横断的な優先順位の管理や調整などに充てるなどすべきだ。常に最新にアップデートされた優先順位を含むポリ シーや、有効な危機対応プロセスを維持することで、危機レベルの比較的低いエラー一つで無駄に数多くの人員を夜中にたたき起こすなどということは回避され るはずだ。プロセス自体が可視化され、制御可能な状態で、可能な限り自動化されていることも重要だ。「ツールを導入したが、プロセスは属人的」では有効な ポリシーベースのプロセスは機能しない。

NUP などのライセンスでは、登録するユーザー数だけではなく、実装されているサーバーのプロセッサ数により最小ライセンスの消費カウントが異なるので注意が必要。

http://www.oracle.com/…/…/e-pl101005-101005a-n-176288-ja.pdf

…

Oracle Webサイトより引用：
当該製品の最少ユーザー契約数は、当該製品がインストールされるハードウェアのプロセッサ数により異なります。実際のユーザ
ー数が該当するハードウェアの最少ユーザー数を下回る場合は、ハードウェアの最少ユーザー数にくり上げたユーザー数を契約す
る必要があります。詳細については、価格表定義のページの「最少ユーザー数」を参照ください

最少ユーザー数
Oracle 製品を導入するハードウェアに対して最少ユーザー数（Named User Plus）の制限が適用される製品があります。実際のユーザー数が該当するハードウェアの最少ユーザー数を下回る場合は、ハードウェアの最少ユーザー数にくり上げたユーザー数を契約する必要があります。
ライセンス購入後、プロセッサ（CPU）を追加または変更した結果、該当するハードウェアの最少ユーザー数を満たしていない場合は、そのハードウェアに適用される最少ユーザー数に対して、不足分ライセンスを追加購入する必要があります。最少ユーザー数の制限が適用される Oracle 製品は次の通りです。

例えば、10ユーザーしか使用しないからといって１０NUP を購入しても４プロセッサのハードウェアに実装すると、1プロセッサあたりの最小ユーザー数が25なので、25ｘ４＝ 100 ユーザーが最小ユーザー数となってしまう。
つまり、使ってもいない 90ユーザーのライセンス違反となってしまう。

例えば、IBM のサブキャパシティで使用しているつもりでも、サブキャパシティにおけるライセンスの割り当て管理ができていないと、フルキャパシティで勘定され、ハードウェアの最大キャパをベースとしたライセンスの購入が求められます。

このようなことに成らないためには、利用規約ライブラリなどとの自動化された突合・整合化が不可欠となります

資産管理を効率的、効果的に実施するためには規程・ポリシー/プロセス/手順の策定と、中長期的なロードマップを持った IT資産管理プログラムの運営が必須となる。

プロセスを効率化するには、どのような自動化テクノロジーを使用するかの選択が重要となるが、テクノロジーを導入しただけでは失敗するケースも少なくない。

多くの場合、資産管理の自動化の成功には欠かせない CI（構成アイテム）の定義と、CI の関係性の定義が明確でないことに起因する。

残念ながら CI の関係性は全ての組織で同じというわけではない、契約やソフトウェアライセンスの買い方などにより CI の関係性が異なることから、ツールを導入すればテンプレートでやってくれるというわけではないところが失敗を導く要因となっている。

対策としては、具体的には、ハードウェア、ソフトウェア毎に関係する CI を洗い出し、その関係性をトポロジーマップにして効率的な管理が評価対象のツールで可能かを評価することが大切だ。

CI は、PC ハードウェアに関係するリース契約、保守契約などから、ソフトウェア契約、ライセンス、使用条件などあるが、ソフトウェアの購入形態により、その関係性は異なる。

同じソフトウェアでも異なるライセンス形態の契約を複数保有している場合などは、親 CI となる 「ソフトウェア名称」 に、「ソフトウェア契約」 の子 CI が複数存在し、それぞれの子 CI には付与されたライセンス数の孫 CI となる「ライセンス（使用権）」が存在する。

このライセンス CI は、その条件により割り当てられるデバイス（またはユーザー）紐付られる。

具体的には、MS Office 2010 のボリュームライセンスを各部門で保有し、パッケージやOEM版なども、ある部門では保有している場合などは前述のCI の関係性を管理し、それぞれの契約に紐づき割り当てられたデバイスが特定できなければならない。

これらは、ソフトウェア契約の内容や保有するライセンスの形態により管理するために必要なCI が異なるため、まずは現在の状態を把握し、求められる管理対象となる CI の粒度を定義し、CI 間の関係性を可視化することが必要となる。

サーバー アプリケーションの契約で、コア単位のキャパシティ ライセンスという形態であれば、サーバー ハードウェアの CI は、サーバーの親 CI に、CPU という子 CI、コアという 孫 CI が紐づき、これら孫 CI に割り当てられた「ライセンス CI」 を追跡し、管理する必要がある。

CI を定義し、CI の関係性を定義した上でツール（CMDB やITAM リポジトリ）のテーブル設計と比較し、もとめているレベルの管理が可能かどうかを評価することが重要だ。

ベースライン： Baseline
ソフトウェアライセンスの最適化をも視野に入れたIT資産管理システムを構築する際に、システムを運用開始するために必要となるデータを入力し、ベースラインを構築します。
この際のベースラインには以下のデータが必要になります。

多くのソフトウェアのメーカーにとって今日の市場はすでに成熟しきっている（もちろん、コンプライアンス意識が低いという問題を抱える東欧、アジア、アフリカ諸国は除く先進国の話ではあるが）と考えられている。
そのことから、「既存のユーザーからできるだけ売上をあげる」のは、ソフトウェア・メーカーの常識となっている。
さらに、複雑化するIT環境においては、ライセンスのTerms ＆ Conditions 、つまりライセンス契約の利用規約を常に正確に把握し、コンプライアンスに遵守するというユーザーの義務を遂行することは、必要ではあることは理解していても、非常に困難であることも知られている。

そこで、多くのソフトウェア・メーカーの営業姿勢は、「包括契約の方が、安全ですよ。なんでも利用できるし、安心できて、お得です。」と、非常に高価な契約を勧める。
欧米でもこんな状況で、実際は既に利用していないライセンスを数多く保有していたり、利用価値のない製品のライセンス料を支払っている企業は少なくない。
ここ数年、これらの複雑なソフトウェア・ライセンスの管理や最適化のソリューションがSLO（Software License Optimization）として注目され、複雑なライセンスの利用規約にもとづくメトリクスの管理が可能となり、実際の使用状況が明確に把握できることになったことから、ユーザーは、これらの情報やIT戦略、ソフトウェアの今後の利用、運用戦略情報などを用いて、ソフトウェア・メーカーとの「ライセンス契約の最適化」に動いている。

ソフトウェア・メーカーとしても、実情に合わない製品を無理に押し付けるよりも、今後の「サービス化」の流れが強まる中、ユーザーとの良好なパートナーシップを求む機運も高まり、適切で正確な情報を基にしたユーザーの交渉を受け入れざるを得ない状況になっている。

つまり、強気な SAP のライセンス契約であっても、他のソフトウェア・メーカーの契約同様、「契約は交渉可能」なのである。
これはできません、あれもできません、は交渉の結果として結ぶ「契約」ごとにはあり得ない。

「契約は交渉の結果」であり、すべての契約は交渉が可能である。

欧米では、アメンドや、必要であれば、製品利用やIT戦略のロードマップを基に、既存の契約を終了し、単年度の最適化された契約へ移行するという企業も増加している。

まずは、現状を明確に把握し、戦略、ロードマップに基づいた「あるべき姿」と現状のギャップを識別し、その情報を基に、戦略的な交渉により、契約の最適化が実現可能であるということを欧米の事例から理解することができる。

ちなみに、欧米のリサーチ会社やメディアでは、この議論が数年前からかなり話題になり、いろいろなヒントや、ホワイトペーパーなども発行されている。