ITILはSREの味方です
こんにちは。ばばと申します。
SREであり、株式会社X-Tech5のCTOをしています。
インターネットではnetmarkjpと名乗っています。
SREのノウハウやパワーが足りない現場の支援やパフォーマンスチューニング、トラブルシューティングなどを、事業会社さんやSIerさんなど幅広くご提供してご飯を食べています。
今回はSRE × ITILを広めたくて記事を書きました。
みなさんから「SRE × ITILならばばさん（ないしはX-Tech5）」と言ってもらえるよう活動しています。
この記事を一言で表すと 「SREにおいて、ITILは実践的に効きますよ」 です。
ITILはSREの味方です
大企業の中で、あるいは非常に手堅い運用を続けてきた現場の中で、変革が必要になることは少なくありません。
それに変革を「要求」されることもままあります。
そんな時はキーワードとして「SRE」が担がれ・降りてくることがままあります。
- 複雑で大規模なコンピュータシステムを運用するときに、システムの成長・拡大に比例して運用系エンジニア数がどんどん増えてしまうのをなんとかしたい
- AI活用時代でもあるし、プログラムを書いてソフトウェアの力で運用フェーズで欠かせないあれこれをソフトウェア化しよう
志はOK。総論OK。よし、ではやっていこう。
ところが、その一歩を踏み出した瞬間に、よく壁にぶつかります。
「SREとは呼んでいなかったけれど、同じことはやってきたはずだよ」
「うちはITILでやってきたから」
「気持ちはわかるけど現実的じゃないよね」
巻き込みたい相手から、そんな反応が返ってくる。
ありがちだし、実際よく遭遇します。
そんな時にわたしはよく、ITILの知恵と権威を借ります。
いまのITILはSREの味方なのです。
「ITIL」と聞いて重厚な管理プロセスや分厚いドキュメントが思い浮かぶのであれば、それは多くの場合ITIL v3の姿です。
ITILの転機はITIL 4
ITIL v3は2007年〜で、2011年に改訂されています。
2011年はAWSの東京リージョンがオープンした年です。
タイミング的にはパブリッククラウドサービスが登場し盛り上がってきた頃で、まだファーストチョイスとして定着する前です。
ですから、インフラをソフトウェアとして扱うのが難しかった時代を前提としていました。
SREが業界で盛り上がってきたのは2010年代半ば以降です。
SRE本は原著が2016年4月に発売され、日本語訳は2017年8月に発売されました。
ITILの転機は2019年のITIL 4でした。
ちなみに「ITIL v4」ではなく「ITIL 4」だそうです。
ここでアジャイルやDevOpsの考え方を取り込み、「価値の共創」を中心に据え直したのです。
そしてこの路線はいまもITIL （Version 5）（2026年2月）へと引き継がれています（ITIL 4は2027年末まで並行提供予定とのこと）。
なお「ITIL 5」ではなく「ITIL （Version 5）」だそうです。
www.peoplecert.org
New ITIL Explained for Certified Professionals | ITIL (Version 5) PeopleCert
New ITIL Explained for Certified Professionals | ITIL (Version 5) Already ITIL-certified? Discover how ITIL (Version 5) builds on your existing knowledge, what’s changed, and how to continue your ITIL journey with confidence.
www.itil.com
New ITIL Explained for Certified Professionals | ITIL (Version 5)
いまのITILを支える7つの指針
DevOps、SRE、Platform Engineering…。
SREの現場に絡む概念やプラクティスは多々あります。
これらの要素・観点を素晴らしく体系化・言語化しているのがいまのITILです。
この記事で切り口にする7つの指針も、ITIL 4で整えられたものです。
ITIL （Version 5）になっても土台は変わらず、長く使える道具になっています。
| ITIL 4の7つの指針 | 訳（筆者による） |
|---|---|
| Focus on value | 価値に焦点を当てる |
| Start where you are | 現状から始める |
| Progress iteratively with feedback | フィードバックを得ながら反復的に進める |
| Collaborate and promote visibility | 協調し、可視性を高める |
| Think and work holistically | 全体的な視点で考え・行動する |
| Keep it simple and practical | シンプルに・実践的にあり続ける |
| Optimize and automate | 最適化し、自動化する |
本記事ではITILの指針を切り口に、事例風に活用例を紹介します。
手堅い現場がコストカットを迫られる話
※これは見聞きした話をゴニョゴニョした架空のケーススタディですが、自社サービスの運用現場でも、受託の運用でも、社内の情報システム部門でも、起きることは同じです
そのチームはITIL v3に則って、長年とても手堅くやってきました。
作業一覧で見れば、ほとんどが半自動化済み。
SLAも守っている。優秀です。
ところが、提供メニューが増え、メンバーが増え、いつの間にか「人数が増えすぎ」「高コスト」と言われるようになっていた。
クラウド、クラウドネイティブ、そしてAIへと時代が移るたび、顧客や上層部からは「同じ内容なら、もっとコストを下げてほしい」とコストカットを求められる。
「同じことを同じように行い続けるだけであれば、その価値は時間経過とともに小さくなる」
「リスクは管理するもの。無くす・避けるは管理の一手法」
「品質には適切な"範囲"があり、不足だけでなく過剰にもなる」
というのは広く一般に知られた事業運営のセオリーですが、正確・確実を求められる現場にいるとなかなか実感・体現が難しいものです。
（ですから現場がディフェンシブになるのは基本的に現場レベルの課題ではなく事業運営レベルの課題ですが、事業運営と現場の相互依存で固定化することが多いのでここでは現場に着目します）
ここで効いてくるのが、ITILの価値に焦点を当てるです。
コストカットの圧力に対して、いきなり「何を削るか」「何を効率化するか」「何を自動化するか」を考えると、たいてい現場が疲弊するだけで終わります。
過去の経緯で、特定依頼者の個別対応が積み上がっている。
過去の経緯で、特定条件の例外対応も積み上がっている。
過去の経緯で、ダブルチェックや承認フローも積み上がっている。
「変化せよ」と言われても、現場は困ります。
これらをなんとかカバーしたり、あるいは拒否したり、を考えがちです。
明確化された要請を果たし、要求を満たすことに特化して磨いてきた組織ほどその傾向が強いように感じます。
これは困った。というわけで、ITILの7つの指針、価値に焦点を当てて、現状から始めるのです。
SRE方面の言葉を借りると 『ユーザーに焦点を絞れば、他のものはみな後からついてくる』 です。
この『ユーザーに焦点を絞れば〜』は、『SREエンタープライズロードマップ』にあるGoogleの基本原則です。
価値は、ユーザーをちゃんと見た結果として後からついてくるというわけです。
sre.google
Google SRE - sre roadmap guide: enterprise roadmap to sre
最適化し、自動化する
SRE×コストカットと言うと、目先はまずトイル削減が思い浮かびます。
ITILの指針のなかで最もトイル削減に絡むのは 「最適化し、自動化する」 です。
順序が大事で、最適化が先・自動化が後なのですね。
自然体で取り組むと、この順序を取り違えることが本当に多くあります。
個別対応や例外まみれの、人力前提の手順をそのまま自動化する方向になります。
すると、間違いを、より速く、より大量にやるようになります。
自動化は手順を増幅する装置なので、微妙な手順を自動化すると、微妙さが増幅されます。
昨今はAIによってこれがさらに加速・増幅されます。
2025年のDORA Reportでも『AI is an amplifier』がKey takeawayとされていますね。
DORA | State of AI-assisted Software Development 2025
さて、ある現場は、すでに作業の大半が「半自動化済み」でした。
作業の一覧表ベースで見ると、なかなかの網羅率を誇っていました。
その中身をよくよく見てみると……半自動の継ぎ目に人が貼り付いていてダブルチェックや特別対応がぶら下がっている、作業結果の確認と次の作業の分岐を人力で判断していてミスの可能性があまり減っていないといった状況でした。
だから、いったん立ち止まって、まず最適化から入りました。本当に要るチェックか、過去の経緯で残っているだけの形式的な作業か……。
作業に色々なパスがある中でほとんどは特定のハッピーパスだったので、ボリュームゾーンの手順を素直な形に直してから、「基本は全自動化、例外として既存パスを整備する」へ段階的に移していきました。
またある現場では、「そのような順で実施すべきなのはわかっているが、即効性を求める上からの圧力が強く目先の自動化が優先になってしまう」ことがありました。
この時にはITILの 「最適化し、自動化する」 を引き合いにして相互理解と説得をはかり、結果としてマイルストーンを半年後と2年後に設けて段階的に進めることになりました。
SLOは焦らずに
SREの支援をしていると「まずSLOを定義したい」とよく言われます。
でも、長年回ってきた既存の運用現場で、いきなり意味のあるSLOを置けることは、正直あまりありません。
価値がまだ言語化できていないのに、それらしい数字を先に置いても、誰も使わない飾りになります。
一般に「目標を先に立てる」こと自体は手法としてアリです。
しかし目標が有効に機能するためには必要条件があります。
目標が計測可能・行動可能・コントロール可能の必要条件を満たしていることと、関係者みんなが合意・共感することが不可欠です（これらを満たせる状況下・対象なら仮決めは大いにアリです）。
そこで、わたしは目標指標と目標値であるSLOを先に決めるより、計測・観測サイクルを回すことを優先しています。
フィードバックを得ながら反復的に進めるのです。
自社ブログに書いた SRE成功の鍵は「定点観測会」だと思っている - 株式会社X-Tech5 は今も変わっていません。
SLOは、ループを回す中で後から立ち上がってくる。順番を逆にするとスムーズです。
このケースでやったのは、非常に地味な定点観測でした。
作業ごとの所要工数を継続的に計測して、可視化します。
時系列のヒートマップを作り、（平均値はミスリーディングなことが多いので）中央値や分散を見て、ボリュームゾーンへの対処と例外への対処を別の取り組みとして進めていきました。
そして、計測・可視化したものを材料に、現場とは現場の言葉で、上層部とは上層部の言葉で、それぞれ活動を合意していきました。
データをもとに判断するデータドリブンはSREの基本ですよね。
推測で語り合うのをやめて、計測した事実の上で意思決定します。
新しいツールやルールも、入れただけでは効果は出ません。
導入後も継続して計測・可視化し、効いたか効かなかったかをフィードバックに返す。
前述の自社ブログにもある通りわたしはOODAループを軸に進めることが多いですが、ITILのフィードバックを得ながら反復的に進める、協調し、可視性を高める、全体的な視点で考え・行動する、シンプルに・実践的にあり続けるはここでも活きてきます。
おわりに：道具箱に、ITILも入れておく
冒頭に「SRE × ITILならばばさん（ないしはX-Tech5）」と書きましたが、別にITILを軸にすべきだ・ITILを軸にしてほしいというわけではありません。
ITILも選択肢のひとつとして、気軽に使いましょうよと言いたいのです。
『SREエンタープライズロードマップ』には『SREの実践はITILフレームワークと共存できる』という項があります（『結果が一致していてもやり方を調整する必要があることを肝に銘じてください。』という記述もあります）。
ITILは組織構造を所与の制約として、そのうえで価値をどう届けるかを長年言語化してきた体系です。
歴史と権威があり、非常にうまく言語化されています。
ボトムアップでチームの外を巻き込むとき、共通言語として受け入れられやすいです。
SREの取り組みはしばしば個人や組織の組織変革を伴います。
SREを運用組織の外へ、技術組織の外へ広げていくフェーズで、ITIL 4の指針はとても使い勝手のいい切り口になります。
古いイメージのままにしておくのは、もったいないです。
ITILの7つの指針を眺めてみると、きっと、いつも現場でやっていることと地続きだと感じると思います。
より楽しい・より素晴らしい明日の情報システムやインターネットのために、使える道具は何でも使っていきましょう。
@netmarkjp 株式会社X-Tech5 - 株式会社X-Tech5（株式会社クロステックファイブ）はユーザー体験（UX）を中心にした運用プラットフォームを提供しています。 株式会社X-Tech5（株式会社クロステックファイブ）はユーザー体験（UX）を中心にした運用プラットフォームを提供しています。
株式会社X-Tech5 - 株式会社X-Tech5（株式会社クロステックファイブ）はユーザー体験（UX）を中心にした運用プラットフォームを提供しています。
