システムライフサイクルについての管理手法と破棄の時の措置の仕方

読者の方からいただいた質問「システムライフサイクルについての管理手法と破棄の時の措置の仕方」について、とてもわかりやすく回答してくれています。ぜひ、一読を！
by BMCソフトウェア編注

番外編 Vol.001 - 2009年01月23日

当コラムの読者の方から、「システムライフサイクルについて管理手法と破棄の時の措置の仕方について教えてほしい」というご質問をいただきました。

確かに ITIL v3 では、サービスのライフサイクルについてはかなり詳しく書かれています。書籍もサービスのライフサイクルに合わせて5冊にまとめられています。しかし、そのサービスを構成するITシステム（インフラストラクチャ）に関するライフサイクルについては、あまり詳しくは書かれていません。これは ITIL がフォーカスしているのはあくまでも ITサービスであり、システムはそのITサービスを提供するための材料（サービス資産）に過ぎない、と考えているからだと思われます。

ITIL的には、システムのライフサイクルそのものが主人公になることはありません。主人公はあくまでも、サービスのライフサイクルです。

サービス資産（ハードウェアやソフトウェア）のライフサイクルは、

1. サービスのライフサイクルと密接に関係している部分
2. ライフサイクルと関係なく変化する部分

とがあります。

本連載ではよくレストランを題材にしています。ITそのもので考えるよりも混乱を招きにくく、わかりやすいからです。レストランにおいて「サービス」とは「おいしい料理を顧客に提供すること」で、サービスカタログにあたるのはさしずめお店のメニューといったところでしょう。一方そのサービスを提供するために、厨房には様々な構成アイテム（CI）が存在します。冷蔵庫やシンク、コンロといったものはハードウェアにあたるもので、レシピや具体的な料理の作り方はソフトウェアにあたるものでしょう。

扱うメニューが変わったり、メニューの種類や顧客の数が増えたりすれば、冷蔵庫やコンロのキャパシティに影響するでしょう。メニューが増えるということはレシピ（ソフトウェア）が増えるということですから、新しい料理の作り方（ソフトウェア）を開発しなければならなくなります。また、「うちではもうお酒は提供しない」とか「もうエビフライは提供しない」とか、サービスの廃止を決めたら、ワインセラーというハードウェアやエビフライのレシピといったソフトウェアも廃止することになるでしょう。

つまり、ハードウェアやソフトウェアのライフサイクルは、サービスのライフサイクルと密接に関係することになります。

それとは別に、使用中に冷蔵庫やコンロが壊れることによって（ハードウェアの）修理をしたり、リース期間が切れたので入れ替えたり、エビフライの味付けを変えてより良い味にしたり（ソフトウェアの改良）、つまりサービスのライフサイクルと関係ない部分で状態が変化することがあります。

いずれにしても、それらの変化を計画したり、スケジュールしたりするのは「変更管理」の役割です。また、「変更管理」が計画した変更内容を本番環境に投入するのは「リリース管理」の役割です。さらに、IT資産そのものの管理は「サービス資産管理および構成管理」プロセスの役割です。これらはすべて、 ITIL書籍では「サービストランジション」で詳しく述べられています。当コラムが「サービストランジション」を扱うようになったときに述べようと思っていますが、今回は簡単に触れておきましょう。

まず、各サービスを構成する要素（構成アイテム、CI と言います）は漏れや抜けがないように、構成管理データベース（CMDB：Configration Management DB）で管理することになります。この中には、各CIの具体的な説明のほかに、現在の CI のステータス（ライフサイクルにおける現在の状態）も記入するようにします。サービスのライフサイクルの例としては、本コラムの vol.005【サービスデザイン】サービスデザイン概要２で紹介した

制定済み
設計済み
開発済み
構築済み
テスト
リリース済み
運用中
廃棄済み

といったものが参考になるでしょう。これに加えて「修理中」とか「一時停止中」といったステータスも考えられます。

ステータスが変化するトリガとなるのは、「変更管理」と「リリース管理」です。組織内のすべてのサービス資源の変更は、必ず「変更管理」と「リリース管理」を通らなければならない、という仕組みを制定します。

重要なのは、廃棄したサービス資源をすぐに CMDB から削除してしまわないことです。廃棄した（そのサービス資産がかつて存在していた）ということをしばらくの間は残しておくほうがいいでしょう。場合によっては、一度廃止したサービスを復活させなければならなくなる場合もあります。そのような場合、廃棄済みの CI 情報は、サービスを再開させるときに大きな参考になります。

廃棄の措置は、ITIL書籍「サービストランジション」に次のように記述されています。

1. 廃止されるハードウェアから、展開されたソフトウェアとデータのコピーを削除する。
2. 再展開可能なライセンスやその他の資産を識別する。ある領域で廃止されるソフトウェアも、他の領域では通用する場合もある
3. 環境上の方針と手順に従って機器を廃棄する
4. 必要に応じて、再展開可能な資産をセキュア・ストア（安全な保管庫）へ移動させる。特にハードウェアは、現在稼動している機器のスペアとして有効になる場合がある

これと、先ほど指摘した「廃棄したということを記録し、しばらくは CMDB に残しておく」ということも重要です。ソフトウェアの利用を廃止する場合は、そのソフトウェアをシステムからアンインストールし、ステータスを「廃止済み」にした後でも、しばらくはインストールキットを残しておくほうがいいでしょう。