DevOps と ITIL の比較 -- チームにとってどちらが重要ですか?

1. DevOps は ITIL に取って代われる

「もう ITIL を使わない。今では、私たちは DevOps を使う職場になった!」短い間でもテクノロジーに携わっていると、というような宣言を誰かが言うのを聞いたことがあるでしょう。

問題は、それが単に真実ではないということです。IT 部門は、ITIL トレーニングやプロセス サイロから離れることもありますが、それでもサービス管理のいくつかの側面を実行する必要があります。運用、サポート、ガバナンス、原価計算など、これらは重要なビジネス機能であり、DevOps はプロセス ガイドラインを ITIL のように提供していません。そのため、今では DevOps のみの職場であると屋上から誇らしげに宣言しているような場合でも、いくつかの ITIL のプロセスや原則に引き続き従っている可能性もあります。

2. DevOps = 継続的開発、統合、自動化されたデリバリー

DevOps には継続的開発、統合、自動化されたデリバリーが含まれますが、それだけを提供するものではなく、必ずしもプラクティスの核となるわけではありません。DevOps の背景にある状況と精神のほとんどは、古い部門から離れて、相互に尊重し誰も責めることのない文化の下で協力することに関するものです。

まさしく、コラボレーション、目標の共有、相互の尊重、誰も責めることのない姿勢なのです。

このコラボレーション アプローチにより、チームが自動化されたデリバリーや継続的開発をまだ完全に採用していなくても、あらゆるビジネス指標を向上させられます。

3. ITIL/ITSM はチームの作業効率を低下させる厄介なプロセスで、常にドキュメントが大量にある

解説用に公開されるガイダンスではなく、「ルール」として不正に流用されている ITIL の例は非常に多く存在します。

実際には、ITIL はチームが作るものです。煩わしいと感じたら、そのような選択がなされてしまったからです。そのような選択は変更可能です。

ほとんどの企業で管理しなければならない複雑な IT プロセスを理解するための出発点として、ITIL は最もよく見られます。すなわち、ロードマップでありガイドブックなのです。またこれは唯一の方法ではなく、意思決定を行って IT チームを可能な限り効果的かつ効率的に運営するために必要な状況を提供することを目的としています。

ITIL がルールブックとして認識されている場合、通常はドキュメントとお役所的な手続きが積み上がっています。しかし、ITIL をガイドラインとして使用することで、運用の柔軟性を損ねることなく運用を合理化できます。

4. ITIL/ITSM は大企業しか使えない

大企業が ITIL の普及を主導したことは事実です。しかし、これは中小企業がガイドラインから恩恵を受けられないことを意味するものではありません。あらゆる規模の企業は、ITIL が基盤を築く他の基本的なビジネス タスクの中でも特に、変更管理、重大なインシデント、ナレッジ マネジメントの運用方法を理解する必要があります。

スタートアップ企業が成功するには、ある時点で IT チームを編成する必要があります。そうしないと、規模の拡大に失敗します。中規模な企業でも同じです。2 人の自己資金によるアプリ プロジェクトでも、オンコール計画とインシデント管理戦略が必要です。それがなければ、1 回の停止が命取りになる可能性があります。

DevOps で新しいリリースを加速する

DevOps のアジャイル アプローチは、スピードとリスク管理の両方のメリットを提供します。小規模で定期的なリリースでは、開発段階での進捗が速く、インシデント発生時のロール バックや修正が容易です。

ITSM で IT サービス デスクへの問い合わせを削減する

ITSM のナレッジ マネジメントのベスト プラクティスは、IT チームが問題を解決しつつ、ドキュメントを作成することを意味します。これにより、社内外の顧客に対しセルフサービス オプションを提供することで、サービス デスクの作業負荷を大幅に削減する可能性が生まれます。

ITIL と DevOps によってインシデントを防止する

ITIL で見つかったインシデント管理の実証済みのプロセスを DevOps と併用して、レビュー プロセスの自動化、誰も責めることのない事後分析の実施、「作った人が運用責任を持つ」というアプローチに重点を置くことで、インシデントの数を減らして所要時間を短縮するための方策を得られます。

DevOps でインシデントの根本原因を把握する

DevOps がもたらす最も価値のあるものの 1 つは、誰も責めることのない文化です。エンジニアがミスの責任を取らないという意味ではありません。自らのミスについて正直に話して、上手くいかなかったことについて率直に話し合い、解雇されることを恐れることなくこのような意見交換を行うことを意味しています。

この文化的な変化により、チームはインシデントの根本原因に迅速に到達して、インシデントにつながる一連のイベントにおける問題として、個人を標的にするのではなく実際の修正に集中できます。

ITIL によって顧客の混乱を軽減する

SLA (サービス レベル アグリーメント) は、ITIL のベスト プラクティスです。製品においてまたは顧客に対して、何を保証しているか、何を保証していないかを示しているので、混乱を減らして苦情の防止に役立ちます。

DevOps と ITIL でプロセスを最適化する

ITIL は IT プロセスのバイブルです。長い期間をかけて、業界の絶え間なく変化するニーズに合わせて進化してきました。

独自のプロセスを考え出すとき、土台から作り直す必要はありません。ITIL には、実証済みの出発点が用意されています。

そして、誰も責めることのない事後分析、自動化、より協調的なアプローチなどを伴う DevOps を使用して、改善を促進できるような環境下においては、ITIL のプロセスを微調整してさらに改善できます。