ベロシティの高いチーム向けの ITSM
DevOps と ITIL の比較 -- チームにとってどちらが重要ですか?
IT 業界では、DevOps と ITIL についてさまざまな意見があり、そのような意見ではこの 2 つの IT アプローチは競合するものと認識する傾向があります。多くの考え方では、DevOps 派と ITIL 派に分かれ、白か黒、またはどちらか一方のみというように、どちらかの立場を支持する必要があると考えられています。
このような議論はテクノロジー ニュースのサイクルの中では興味深い読み物になりますが、この全部かゼロかのアプローチは、実務担当者とビジネスにとっては、コストがかかって混乱を招き、役に立たない可能性があります。実際、全部かゼロかではなく、支持する立場もないのです。
DevOps と ITIL は相互に排他的ではありません。これらは補完的なアプローチであり、それぞれが独自のメリットをもたらします。混合アプローチによって、アジリティとコラボレーション、プロセスとコントロールなど、両方のメリットを活用できます。
DevOps とは何か?
DevOps は、開発と運用のギャップを埋めるプラクティスです。その基本原則は、オープンなコミュニケーション、コラボレーション、目標の共有です。
「ITIL のようなフレームワークとは異なり、DevOps チームのベスト プラクティスに関する『公式な』文書はありません。しかし、DevOps の中核をなすのは、組織的なサイロを解体して透明性を高めて、開発者と IT 運用チーム間のオープンなコミュニケーションを促進することで組織にビジネス上の価値をもたらすことであるという点については、一般的に合意を得られます」
ITIL とは
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 と ITIL のユース ケース
DevOps と ITIL のユース ケースは膨大ですが、ここでは、両者を使用して取り組めるさまざまな課題の例と、最適な解決に到達するために両者のアプローチが必要となるケースを紹介します。
DevOps で新しいリリースを加速する
DevOps のアジャイル アプローチは、スピードとリスク管理の両方のメリットを提供します。小規模で定期的なリリースでは、開発段階での進捗が速く、インシデント発生時のロール バックや修正が容易です。
ITSM で IT サービス デスクへの問い合わせを削減する
ITSM のナレッジ マネジメントのベスト プラクティスは、IT チームが問題を解決しつつ、ドキュメントを作成することを意味します。これにより、社内外の顧客に対しセルフサービス オプションを提供することで、サービス デスクの作業負荷を大幅に削減する可能性が生まれます。
ITIL と DevOps によってインシデントを防止する
ITIL で見つかったインシデント管理の実証済みのプロセスを DevOps と併用して、レビュー プロセスの自動化、誰も責めることのない事後分析の実施、「作った人が運用責任を持つ」というアプローチに重点を置くことで、インシデントの数を減らして所要時間を短縮するための方策を得られます。
DevOps でインシデントの根本原因を把握する
DevOps がもたらす最も価値のあるものの 1 つは、誰も責めることのない文化です。エンジニアがミスの責任を取らないという意味ではありません。自らのミスについて正直に話して、上手くいかなかったことについて率直に話し合い、解雇されることを恐れることなくこのような意見交換を行うことを意味しています。
この文化的な変化により、チームはインシデントの根本原因に迅速に到達して、インシデントにつながる一連のイベントにおける問題として、個人を標的にするのではなく実際の修正に集中できます。
ITIL によって顧客の混乱を軽減する
SLA (サービス レベル アグリーメント) は、ITIL のベスト プラクティスです。製品においてまたは顧客に対して、何を保証しているか、何を保証していないかを示しているので、混乱を減らして苦情の防止に役立ちます。
DevOps と ITIL でプロセスを最適化する
ITIL は IT プロセスのバイブルです。長い期間をかけて、業界の絶え間なく変化するニーズに合わせて進化してきました。
独自のプロセスを考え出すとき、土台から作り直す必要はありません。ITIL には、実証済みの出発点が用意されています。
そして、誰も責めることのない事後分析、自動化、より協調的なアプローチなどを伴う DevOps を使用して、改善を促進できるような環境下においては、ITIL のプロセスを微調整してさらに改善できます。
DevOps と ITIL のユース ケース
パフォーマンスの高いチームはすでに知っていますが、IT には ITIL と DevOps の両方の要素が必要です。
DevOps は、自動化された開発を凌駕するものです。コラボレーションと誰も責めることのない文化が存在して、競合する目標についてサイロ化した作業を行うのではなく、チームが協力して最善を尽くすためのスペースを作るプラクティスです。
同様に、ITIL はドキュメントを凌駕するものです。チームの効率が落ちたり、お役所的な手続きに悩まされたりする必要はありません。コア プラクティスは健全で実証されており、アジャイルな方法でアプローチすれば、IT パイプラインを行き詰まらせるどころかむしろ効率化できます。
Atlassian's guide to agile ways of working with ITIL 4
ITIL 4 is here—and it’s more agile than ever. Learn tips to bring agility and collaboration into ITSM with Atlassian.
ホワイトペーパーを読むサービス リクエスト管理とは - ガイド
サービス リクエスト管理により、IT チームは顧客のリクエストを迅速かつ容易に満たすことができます。プロセスとベスト プラクティスを確認しましょう。
記事を読む