ITIL v4とSREの違い｜中堅企業が目指す運用品質の高め方

「ITILは知っているが、SREという言葉も最近よく聞く。自社の運用品質を大企業並みに引き上げるには、どちらを取り入れるべきか」。中堅企業の情シス部門からは、こうした相談が増えています。結論を先に述べると、ITIL v4とSREは対立する選択肢ではなく、「型」と「エンジニアリング」という役割の異なる補完関係にあります。中堅企業が目指すべきは、どちらか一方の全面導入ではなく、自社の運用規模に合わせて要素を取り入れる段階的なアプローチです。

まず前提を整理します。ITIL v4(Information Technology Infrastructure Library、ITサービスマネジメントの世界的な実践知の体系)は、サービス価値システム(SVS)を中核に据え、IT部門内の様々な活動を「ビジネス価値を生むサービス提供」という共通言語で束ねる枠組みです。手順書ではなく、現場に合わせて設計し続けるための考え方の型という性格が強く、インシデント管理・変更管理・問題管理といったプロセスの体系として機能します。

一方、SRE(Site Reliability Engineering、サイト信頼性エンジニアリング)はGoogleが提唱した運用手法で、ソフトウェア工学と自動化の技術を使い、システムの信頼性を工学的に担保する実践群です。エラーバジェット(許容できる障害時間の予算)やSLO(サービスレベル目標)を軸に、手作業での対応を減らし、障害を未然に検知・自動復旧させる文化を重視します。

両者は中規模システムの運用品質向上という同じゴールに向かいながら、ITIL v4は「組織全体の共通言語とガバナンス」、SREは「技術的な信頼性の作り込み」という異なる軸を担っています。インシデント対応の場面では、複数人が同時に動く「インシデント・スウォーミング」という考え方を双方が重視しており、重なる部分も少なくありません。

ITIL v4とSREの比較は、本来はGoogleのような超大規模システムを運用する企業が直面してきたテーマでした。ところが近年、中堅企業の情シス部門でもこの議論が持ち上がる場面が増えています。背景には次のような事情があります。

• クラウド移行でシステム構成要素が増えた:オンプレミス1系統だった時代に比べ、クラウドサービスの組み合わせが複雑化し、「信頼性をどう設計するか」という問いが避けられなくなった。
• 大企業品質への要求が強まった:取引先や親会社から、大企業並みのセキュリティ・可用性基準を求められる場面が増え、サービスレベルの説明責任が重くなった。
• 情シスの人員は増えない:運用品質を上げたい一方で、人を大量に増やせる状況にはなく、「少人数でも品質を担保できる仕組み」への関心が高まった。

つまり、中堅企業がITIL v4やSREという言葉に行き着くのは、流行を追っているからではなく、運用品質の説明責任と人員制約の板挟みという切実な事情があるためです。

ITIL v4・SREのどちらを検討する前に、自社の運用品質がどの段階にあるかを確認します。次の5項目のうち3つ以上に当てはまる場合、運用品質の仕組み化が急務と考えてください。

1. 障害対応の手順が、特定の担当者の頭の中にしかない。
2. サービスレベル(復旧目標時間、稼働率など)を数値で定義していない、または定義していても形骸化している。
3. 同じ種類の障害が繰り返し発生しているが、根本原因の分析(問題管理)まで手が回っていない。
4. 変更作業(設定変更・リリース)の履歴と承認プロセスが記録されていない。
5. 監視・一次対応の多くが手作業で、自動復旧の仕組みがほとんどない。

1・2・4番はITIL v4的な「型」の不足を、3・5番はSRE的な「エンジニアリングによる信頼性作り込み」の不足を示しています。自社がどちらの弱さを抱えているかで、取り入れるべき要素の比重が変わります。

ITIL認定資格をフルセットで取得させたり、専任のSREチームを新設したりすることは、人員・予算に制約のある中堅企業には現実的ではありません。実務的には、両者から中堅企業の体力に合う要素だけを抜き出して組み合わせるアプローチが有効です。

例えば、ある中堅企業の情シスでは、障害の重大度判定が担当者の感覚に依存していたため、ITIL v4のインシデント管理の考え方を参考に重大度の定義表だけを先に整備しました。その上で、繰り返し発生していた深夜アラートについてはSREのポストモーテムの手法を取り入れ、根本原因を記録・共有する運用に切り替える、という段階的な進め方が現実的です。

要素を段階的に取り入れると、運用の状態は次のように変わります。

要素を取り入れる際、次のような失敗に陥りやすい点にも注意が必要です。

• ドキュメント作成が目的化する:プロセスを文書化すること自体がゴールになり、現場の実態と乖離した手順書が量産される。重要なのは文書の量ではなく、実際の対応品質が変わるかどうかです。
• SLOを設定しただけで終わる:数値目標を決めても、未達時に何をするかのルールがなければ、SLOは形骸化します。
• 一度整備して満足してしまう:運用品質の仕組みは、システム構成の変化や人員の入れ替わりのたびに陳腐化します。整備は始まりであって、終わりではありません。

これは、BFTが20年超にわたり金融・公共分野の大規模システム運用に携わってきた中で一貫して見てきた傾向でもあります。ITILv4/SRE/AIOps(AIを活用した運用自動化の実践)に準拠した運用品質を維持できている現場ほど、「一度決めて終わり」ではなく、仕組みそのものを継続的に見直すサイクルを組み込んでいます。

図:ITIL v4の「型」とSREの「エンジニアリング」を、循環的に見直し続けることで運用品質が積み上がっていく構造。

ここまで見てきたセルフチェックや要素の組み合わせは、あくまで現時点の運用品質を「点」として把握するための材料です。健康診断と同様に、一度の点検で弱点が見つかっても、その後の生活習慣(運用)を変えなければ同じ不調が再発します。

ITIL v4の型とSREのエンジニアリング手法は、どちらも「一度導入すれば自動的に品質が維持される」種類のものではありません。システム構成は変わり続け、人員も入れ替わるため、仕組み自体を定期的に点検し、更新し続ける運用体制が不可欠です。大企業品質の運用を目指すのであれば、この「直し続ける」仕組みをどう内製または外部と分担するかが、次の検討テーマになります。

[関連記事: 運用代行・MSP・BPOの違いとは]
[関連記事: AIOps導入は現場で何が変わる？効果と失敗しない進め方]

• ITIL v4は「組織の共通言語とガバナンスの型」、SREは「技術的な信頼性エンジニアリング」で、対立ではなく補完関係にある。
• 中堅企業でこの比較が話題になる背景には、クラウド化による複雑化と、人員を増やせない制約がある。
• 全面導入ではなく、自社の弱点(型の不足かエンジニアリングの不足か)に応じて要素を選択的に取り入れるのが現実的。
• SLO設定やドキュメント化そのものを目的化せず、未達時のルールや実態との整合性を伴わせる。
• 運用品質の仕組みは一度整備して終わりではなく、継続的に見直すサイクルが前提になる。

Q. 中堅企業がITIL v4とSREのどちらを優先すべきですか?
A. 優先順位は自社の弱点によって異なります。障害対応や変更管理の手順が属人化しているならITIL v4的な型の整備を、手作業の監視対応や繰り返す障害が多いならSREのエンジニアリング要素を優先するのが現実的です。

Q. SREエンジニアを専任で置かないと導入できませんか?
A. 専任チームの新設は必須ではありません。既存の運用担当者がSREの考え方(SLO設定、ポストモーテムなど)の一部を取り入れることから始める企業も多くあります。

Q. ITIL認定資格を取得する必要がありますか?
A. 資格取得は必須ではありません。ITIL v4は共通言語としての考え方の体系であり、資格よりも自社のプロセスにどう落とし込むかが重要です。

Q. 運用品質の仕組みを整備した後、何に注意すべきですか?
A. 整備した手順やSLOが形骸化していないか、定期的に見直すことが欠かせません。システム構成や人員の変化に合わせて、仕組み自体を更新し続ける体制を持つことが重要です。

自社の運用品質が大企業水準に届いているか、まず現状を把握したい方へ

上記のセルフチェックで複数当てはまった方は、まず自部門の運用を客観的に整理することをおすすめします。

ITIL v4・SREのどちらの要素を取り入れるにせよ、重要なのは「直し続ける」仕組みです。伴走型での運用改善については、YOROZU STEADYのご相談 もご利用ください。