書籍紹介：『アポロ13』に学ぶITサービスマネジメント ~映画を観るだけでITILの実践方法がわかる!
アポロ１３号でなぜITILを学ぶのか？
アポロ１３号の事故は1970年、一方ITIL:Information Technology Infrastructure Libraryは1989年にイギリスで初版が公開された。
従ってこれらには直接の関連性はなく、それは本書の中でも再三繰り返されている。
しかし、ITILがアメリカの成功体験を分析することで策定されたという逸話もあるので、「成功した失敗」と呼ばれるアポロ１３号の教訓からITILの本質を学ぶという筆者の考えには共感できる。
目次
■第1部 ITサービスマネジメントとアポロ13
●第1章 ITサービスマネジメントとは
-ITサービスの価値を高めるために-
●第2章 『アポロ13』でITSMを学ぶ意義
-アポロ計画とビジネスストラテジの共通点-
■第2部 サービスストラテジ
●第3章 「ニール・アームストロングが月に降り立ちました」
-アポロ計画における戦略-
●第4章 「14号があればだが」
-アポロ計画における「顧客」とは-
●第5章 「月を歩くんだね」
-サービスという単位を考える-
■第3部 サービスオペレーション
●第6章 「ヒューストン、 センターエンジンが停止した」
-インシデント管理-
●第7章 「反応バルブを閉じろ、と伝えろ」
-サービスデスク-
●第8章 「自分の字が読めないんだ。思ったより疲れているみたいだな」
-問題管理-
■第4部 サービスデザイン
●第9章 「絶対に死なせません」
-サービスレベル管理-
●第10章 「チャーリー・デュークが風疹にかかっている」
-可用性管理-
●第11章 「問題は電力だ。電力がすべて」
-キャパシティ管理-
●第12章 「トラブルが発生した」
-ITサービス継続性管理-
■第5部 サービストランジション
●第13章 「なんとかして、この四角をこの筒にはめ込むんだ」
-構成管理-
●第14章 「この飛行計画は忘れよう」
-変更管理-
●第15章 「こちらヒューストン。打ち上げ準備完了です」
-リリース管理-
■第6部 継続的サービス改善
●第16章 アポロ計画は改善のかたまり
-継続的サービス改善-
読後感
「アポロ１３号」というタイトルに惹き付けられて手にした本書だったが、予想以上に面白い本だった。
例えば、
●第4章-アポロ計画における「顧客」とは-では
- 顧客：アメリカ大統領、政府役人
- ITサービス・プロバイダ：NASAヒューストン管制センターと管制官
- ユーザ：３名の宇宙飛行士、バックアップ宇宙飛行士
- インシデント管理マネージャー：主席飛行管理官
のように、具体的な登場人物を映画「アポロ１３」の場面から引用することで、ステークホルダーやその他ITILの重要なキーワードをわかりやすく説明している。
これは、各章で一貫しているスタイルなので、DVDを観ながら読み進めると非常に面白い。
実践には概念を現実に昇華させる方法が必要であり、この本の手法はとても参考になる。
なぜ日本ではITILが浸透しないのか？
IT業界に長く身を置いているのだが、ITILを始めて聞いた2004年ごろから現在までITILの考え方を取り入れて成功した例をあまり聞いた実感がない。単純に成功体験に接する機会に恵まれなかった結果なのかもしれないが、行った現場はことごとくITIL的でない状況だった。
ただし
「多くの会社でSLAとして作成された文書を実際に確認してみると、現状そのほとんどは単なる契約書であり、ITILで解説しているSLAとはまったく違っていて、愕然とします。しかし、すでにSLAがあることになっていますので、別途（本来の）SLAが策定されることはありません。SLAという名の契約書（実際には、法務部門のレビューまで受けて押印された、ただの契約書）が存在していますので、SLAを権威づけするような契約書が別途交わされることもありません（本当の意味でのSLAが存在しないのですから、当たり前と言えば当たり前なのですが…）。このような状況ですので、外部プロバイダとの間でUCを取り交わすようなことはあっても、プロバイダ内部でOLAを策定しようと考えるIT部門は、残念ながらもほぼ皆無です（筆者の知る限り、きちんとOLAを策定していたITサービス・プロバイダは1社だけでした）」（読書位置：1672）
とあるように、ITILを正しく実践できている会社がほとんどないというのが現実なのかもしれない。
構成管理データベース（CMDB）から始めよう。
データベースに深く関わっている立場から感じることは、ITILを実践できないのは中核となる構成管理データベース（CMDB）がないからだと思う。本の中から構成管理について述べられた部分を抜粋する。
「この構成管理、実はこれそのものは何の利益もユーザ満足ももたらしません。そのため、つい後回しに、ないがしろにされてしまいがちなプロセスです。しかし、構成管理は前述のとおり、構成管理データベースを常に最新の、正確な状態に保つことを目的としたプロセスです。構成管理データベースは、ほかの重要なプロセスがITサービスの提供に利益をもたらすことを確実にするために、とても重要な情報を提供します。したがって、構成管理は（地味なプロセスなんですが）非常に重要である、と言えるでしょう。」（読書位置：2693）
「構成管理の観点では、ストレージは単なるサーバーの属性の１つ（どのサーバーに何テラバイトの容量のストレージが割り当てられているか）に過ぎないかもしれません。また、物理的なサーバーの中に仮想サーバーが10台存在するなら、構成管理としては、その仮想サーバー10台もそれぞれ構成アイテムとして管理する必要があるでしょう。さらに、SLAや組織図などの文書は資産管理では扱いませんが、構成管理では非常に重要な構成アイテムとして管理対象に含めます。」（読書位置：2706）
「筆者がJAXAに勤めている人から話を伺ったところ、世界初のデータベース管理システムは、このアポロ計画で宇宙船に積み込む備品のリストを作るために作られたのだそうです。ヒューストンの管制センターで全体の管理をしていたコンピュータ・システムはIBM社のSystem/360でしたから、おそらくこの世界初のデータベース管理システムは、System/360上で稼働していたことでしょう。もっとも、IBM社初のリレーショナル・データベースである System R は1977年に初めて売れた、ということですので、この世界初のデータベース管理システムは、現代風のリレーショナル・データベースではなかったのかもしれません。」（読書位置：2731）
以前、某ITサービス・プロバイダに在籍していた時、構成管理データベースの重要性を実感していたにも関わらず日々の業務に追われ結局実現することができなかった。
構成管理データベースはオープンソースのツールが存在したりしているが、出来合いのツールに合せていくのではなく、現状どこにでもあるExcelベースで管理している構成情報をモデリングしCMDB構築のヒントを模索していこうと思う。
これが漠然とした今年のテーマである。