はじめに
皆さんは、「ITIL」について知っていますか？
最近、少し勉強してみたので内容を共有してみようと思います。正直なところ、勉強する前は「ITインフラ周りの技術的なルール集」のようなものを想像していたのですが、実際に学んでみると、思った以上に「ビジネスの考え方」が中心にありそうと感じました。
本記事では、自分が学んだことの整理も兼ねて、まず「ITILとは何か」を簡単にまとめたうえで、4つのプラクティス（需要管理・可用性管理・キャパシティとパフォーマンスの管理・サプライヤ管理）を、自分なりの理解で書いてみようと思います。
まだ勉強中なので、解釈が違っている部分もあるかもしれません。
そもそもITILとは？
ITIL（Information Technology Infrastructure Library） は、ITサービスマネジメントのベストプラクティスを体系的にまとめたフレームワークです。
もともとは1980年代にイギリス政府が「増え続けるITコストをどう管理すればよいのか」という課題に対処するために策定したものだそうです。
現在はPeopleCert社が管理しており、世界中の企業や組織で広く採用されているようです。
ITILの特徴——技術よりもビジネスが先にくる？
勉強していて一番驚いたのは、ITILが技術ではなく「ビジネス価値」を中心に据えていることでした。
たとえば、「サーバーの稼働率を上げる」ではなく「顧客がサービスを使いたいときに使える状態を維持する」、「システムを増強する」ではなく「ビジネスの成長に合わせた処理能力を確保する」。
このように、ビジネス側の観点からシステムを設計するという内容だと感じています。
ITIL 4の全体像
2019年にリリースされた「ITIL 4」では、中心概念としてサービスバリューシステム（SVS）というものが導入されています。これは、組織のあらゆる活動を「価値の共創」に結びつけるための包括的なモデルのようです。
ITIL 4では34のプラクティスが定義されていて、従来の「プロセス」よりも広い概念として整理されています。本記事で取り上げる4つも、このうちの一部にあたります。
また、ITIL 4には7つの基本原則があります。
- 価値に着目する — すべての活動はステークホルダーへの価値提供に繋がるべき
- 現状から始める — ゼロから作り直すのではなく、今あるものを活かす
- フィードバックをもとに反復的に進める — 一度に完璧を目指さず、小さく試して改善する
- 協働し可視性を高める — サイロを壊し、情報をオープンにする
- 包括的に考え取り組む — 部分最適ではなく全体最適を目指す
- シンプルかつ実践的にする — 不必要な複雑さを排除する
- 最適化し自動化する — まず最適化し、その上で自動化する
個人的には、この原則を見たときに「ITに限った話じゃなくて、仕事全般に言えることだな」と感じました。
01. 需要管理（Demand Management）
どういうものか
需要管理は、サービスに対する需要のパターンを把握・予測し、それに見合ったリソースを確保するためのプラクティスのようです。
自分なりに噛み砕くと、ポイントは「来てから対応する」のではなく「来る前に備える」ということだと思います。需要の波を読めなければ、サービスは過剰投資か品質低下のどちらかに傾いてしまいますよね。
ビジネスシーン
たとえば、ECサイトを運営する企業を考えてみます。毎年12月にはセール需要が急増し、アクセス数が通常の5倍に跳ね上がるようなケースです。
需要管理の考え方がなければ、次のどちらかが起こりそうです。
- サーバーがダウンして売上機会を丸ごと失う
- 逆に、年間を通じてピーク用のインフラを維持し続けて無駄なコストを垂れ流す
過去の販売データ・アクセスログ・マーケティングカレンダー等を分析して「いつ、どのくらいの需要が来るか」を予測し、その上でクラウドを計画的に設定しておくことが需要管理の実践にあたるのだと思います。
感想
飲食店が曜日ごとにスタッフの人数を変えるのと同じ発想だと感じました。「未来の需要を予測して、過不足なくリソースを配置する」という考え方は、IT以外でも日常的にやっていることなのかもしれませんと思いました。
02. 可用性管理（Availability Management）
どういうものか
可用性管理は、サービスが「使いたいときにちゃんと使える」状態を確保するためのプラクティスです。
ここで面白いなと思ったのは、ITILでは可用性を単なる稼働率の数字ではなく、ビジネスが求めるものに対してシステムがどれだけ応えられているかという観点で捉えているところでした。
ビジネスシーン
銀行のオンラインバンキングで考えてみます。「稼働率99.9%」と聞くと十分に聞こえますが、年間で約8.7時間のダウンタイムがあるとします。
もしそのダウンタイムが月末の給与振込日に集中したらどうでしょう。顧客にとっての体感は「使えないシステム」になってしまいます。
可用性管理では、単純な稼働率だけでなく「ビジネス上の重要な時間帯にどれだけ安定して稼働しているか」を設計することが大切だそうです。
- ピーク時には冗長構成を強化する
- 深夜帯にメンテナンスウィンドウを設定する
感想
24時間365日を均等ではなく、「ビジネスの優先度に合わせて守るべき時間帯を見極める」という発想がビジネス的だなと感じました。
03. キャパシティとパフォーマンスの管理（Capacity and Performance Management）
どういうものか
キャパシティとパフォーマンスの管理は、サービスが現在および将来の需要に対応できるだけの「処理能力」を持っているかを管理するプラクティスです。
需要管理が「どれだけ来るかを予測する」プラクティスだとすると、キャパシティとパフォーマンスの管理は「それを捌けるだけの力があるかを確認する」役割を担っているように見えます。両者はセットで考えるとわかりやすいのではないかと思いました。
ビジネスシーン
サービスが急成長し、毎月ユーザー数が20%ずつ増加しているとします。
今は快適に動いていても、3か月後にはデータベースの応答速度が許容範囲を超え、半年後にはストレージが枯渇する……そんな可能性がありそうです。
キャパシティとパフォーマンスの管理では、CPU・メモリ・ディスク・ネットワーク帯域などのリソース消費トレンドを継続的にモニタリングし、「このままの成長率なら○月にボトルネックが発生する」というシミュレーションを行うそうです。
その結果をもとに、先手を打ってインフラの増強や設計の見直しを計画するという流れで考えるようです。
感想
レストランに例えるなら、客足の伸びに合わせて座席数や厨房の設備を先回りして投資していくようなイメージかなと思いました。
04. サプライヤ管理（Supplier Management）
どういうものか
サプライヤ管理は、外部のベンダーやパートナーとの関係を管理し、彼らが提供するサービスの品質を担保するためのプラクティスです。
考えてみると、現代のITサービスは自社だけで完結することがほぼなく、クラウドプロバイダー、SaaSベンダー、開発委託先、通信キャリアなど、多くの外部パートナーの上に成り立っていますよね。
ビジネスシーン
ある企業が顧客向けサービスを構築する際、インフラにAWS、決済にStripe、その他メール配信、監視等に他企業のサービスを利用しているとします。
自社のコードに問題がなくても、StripeのAPIが障害を起こせば売上が止まります。
サプライヤ管理では、こうしたリスクに対して以下のようなアプローチをとるようです。
- 特定のベンダーに依存しすぎないよう代替手段を確保する
- ベンダーを分類し、重要度に応じて管理の粒度を変える
感想
「自社サービスの品質は、パートナーの品質の上に成り立っている」という考えは大切だと思いました。サプライチェーンの弱い環が全体を壊すのは製造業ではあることで、ITでも一緒なんだなと感じました。
最後に
ITに関する勉強をこれまで様々行ってきましたが、「ビジネス価値」を重視されたことを学習することは初めてだったので、とても新鮮でした。
少し勉強してみて、ITILはこれからマネジメントを行っていきたい人におすすめだと思いました。
興味のある方は学習してみてください。
※ ITIL® はPeopleCert Group Limited の登録商標です。
※ 本記事はITIL 4の学習内容をもとに筆者の理解と解釈をまとめたものであり、公式見解を代表するものではありません。