ITILの終焉?

たぶん、ないと思います

アジャイルやDevOpsの登場により、「ITILは死んだ!」という声も聞かれます。これは本当でしょうか?短い答えは「NO!」です。

しかし、ITILとの関連性やITサービスマネジメント(ITSM)の陳腐化という主張の根拠を理解する必要があります。ITILを導入した」、あるいは「ITILに準拠した」、「ITILに沿った」組織の多くが、現在多くの課題に直面していることは確かです。これらの課題には、不必要な官僚主義、柔軟性に欠ける複雑なプロセス、時代遅れのツールや技術、サイロ化し敵対するIT部門、その他重大な問題や機能不全などが含まれます。

ITILやITサービスマネジメント(ITSM)は、独断的で硬直的なプロセスに固執しているという見方が一般的です。また、ITILはソフトウェア開発よりも運用に強い偏りがあるため、「アプリ屋さん」には関係ないという認識も一般的です。

誤認識の問題

多くの組織がITILのベストプラクティスを間違って解釈したり、ITSMの原則を間違って実装したりしています。同様に、多くの組織がアジャイルをめちゃくちゃにします。特に、アジャイルの解釈が「腰から撃つ」と同義である場合は、なおさらです。今後数年間、多くの組織がDevOpsを試みて、そして失敗するのを見ることになる可能性は高い。しかし、一部の組織がアジャイルとDevOpsをうまく実装できないからといって、これらの非常に強力なコンセプトを非難するべきではありません。ITILを含むこれらのフレームワークのいずれにおいても、欠陥よりも「ユーザーエラー」の方が多いのです。

ITILは、本来は ワンサイズ のソリューションは、どの組織でも同じように導入することができます。ITILのモットーの1つに "adopt and adapt "があります。この訓示の目的は、ITILフレームワークを柔軟に導入することを奨励することです。

ITILは官僚的であったり、アジリティやイノベーションを阻害するようなものではないとされています。その逆です。ITILは、ビジネスのニーズを満たし、顧客のために価値を創造するために、新しいテクノロジーの導入とイノベーションを奨励します。ITILのコンセプトは、人、プロセス、テクノロジーの観点から、結果を最適化するように実施されるべきです。

想定される対立が存在しない

一般に信じられていることとは異なり、ITILはアジャイルやDevOpsの考え方と相反するものではありません。また、ITILはインフラストラクチャやオペレーションに限定されるものではありません。ITILの最新版では、エンドツーエンドのサービスに焦点が当てられています。これには通常、アプリケーションの管理、開発、インフラ、運用、ビジネス戦略や顧客価値との整合性などが含まれます。

さらに、ITILはアジャイルやDevOpsが採用しているソフトウェア開発ライフサイクルとほぼ同じ原則に基づいた開発ライフサイクルを採用しています。ITILのライフサイクルの大きな部分を占めるのは「サービスデザイン」であり、ITILはアプリケーション開発をどのように行うかというテーマについては、かなり無頓着なのです。ITILは、ウォーターフォール型のプロジェクトマネジメントに偏ることなく、アジャイル型やその他のあらゆるサービス設計やプロジェクト実行のアプローチに対応します。ITILは、ツール、組織構造、ポリシーと手順の設計に関しては、ほとんど非規定的です。

非互換性なし

ITILで説明されているベストプラクティスやコンセプトの多くは、アジャイルやDevOpsで提唱されているものと同じではないにしても、似ていますし、少なくともITILと互換性がないわけではありません。例えば、ITILは四半期ごとに「ビッグバン」リリースを行う必要があるとは言っていませんし、遅くて複雑な変更管理プロセスを持っているわけでもありません。ITILは、頻繁なリリースと軽快な変更プロセスを可能にします。

最近出版された本。 サイトリライアビリティエンジニアリングGoogleはどのようにプロダクションシステムを運営しているのか。 では、GoogleのDevOpsの導入について詳しく説明しています。GoogleにおけるDevOpsは、アジャイル手法、ITILのベストプラクティス、体系的な問題解決と意思決定、責任のない継続的改善の成熟した文化が融合したものです。もちろん、これらはすべて、アプリケーション、仮想化インフラ、監視・アラートツールなど、Googleの高度な独自技術で実行されています。Googleは、1980年代からITILによって提唱されてきたものと同様に、人、プロセス、テクノロジーを統合し、全体的な観点からベストプラクティスを活用しています。

Googleや他の多くの組織は、DevOpsの2つの重要なコンセプト、継続的インテグレーションと継続的デリバリーを使用して、頻繁なリリース、場合によっては1日あたり数百のリリースを奨励しています。これらのコンセプトは、ITILと対立するものではなく、ビジネスのニーズに沿った一連のプロセス、ツール、およびスキルを用いて、管理された方法で行われることを示唆しているのです。DevOps、アジャイル、そしてGoogleはすべて同意しています。

DevOpsとアジャイルはITの「西部劇」ではない

効果的かつ効率的なリリース管理システムを構築するためには、体系的な分析、堅実な計画、そして慎重な管理が必要です。これは、四半期ごとにリリースを行う従来のアプローチでは重要ですが、継続的デリバリーを目的とするDevOpsモデルではさらに重要なことです。DevOpsやアジャイルは、ずさんであったり、"ワイルド・ワイルド・ウェスト "であったりすることとイコールではありません。ITIL、アジャイル、そしてDevOpsには、規律と構造が不可欠です。この点では、Googleも例外ではありません。

ITILのベストプラクティスとDevOpsやAgileの融合

では、継続的インテグレーションと継続的デリバリーは、ITILやその他のITSMのベストプラクティスにどのように適合するのでしょうか。

継続的インテグレーションとデリバリーは、できるだけ多くの変更を標準的な変更(つまり事前承認済み)のカテゴリに押し込むことで、部分的に達成することができます。たとえば、ITILに沿った変更ポリシーとして、「提案された変更要求が必要なテストにすべて合格したら、追加の許可や管理監督を必要とせずに変更要求を実行することが事前承認される」(したがって、典型的な週次変更諮問委員会などを回避する)というようなことができます。もうひとつの補完的なアプローチは、変更管理プロセスにおけるできるだけ多くの承認ポイントを自動化することです。

自動化がカギ

自動化されたテストとモニタリングは、長い間存在しており、ITILのベストプラクティスによって完全にサポートされています。DevOpsは、これをさらに一歩推し進めたものです。DevOpsでは、開発ライフサイクルのできるだけ早い段階で自動テストとモニタリングの機能を実装することが目標です。コードベースの自動テストが組み込まれているため、プログラマーは、システムで発生する可能性のある問題をほとんどすべて検出できるアプリケーションを開発するようになります。もしプログラマーが本当に賢いのであれば、検出されたすべての問題を、人間の介入なしに自動的に修正するソリューションを組み込もうとするでしょう(新しいインシデントチケットを発行する必要はありません - システムがイベント管理システムに情報アラートを作成することはできますが)。

レガシーシステムにDevOpsは一般的に向いていない

とはいえ、多くの組織では、あらゆる場面でアジャイルやDevOpsを使うことが必ずしも現実的でなく、望ましいわけでもないことを忘れてはならない。レガシーシステムはどうでしょうか?仮想化もクラウドベースもないシステムはどうでしょうか?必要なスキル、ツール、文化的成熟度、組織構造などが不足しているため、組織がアジャイルやDevOpsを使う準備ができていない場合はどうでしょうか。従来のITILやその他のサービスマネジメントのフレームワークは、レガシーなITシステムやサービスを管理するための最良の方法の1つであり続けています。

結論から言うと多くの組織では、いくつかのアプローチを組み合わせて使用することが理にかなっています。多くの組織では、あるものはITIL、ある開発はアジャイル、その他のプロジェクトはウォーターフォール、そして条件が許す限りはDevOpsというように、さまざまなアプローチを組み合わせて使うことが賢明でしょう(おそらくパイロット版を実行するか、新製品やデジタルサービスだけにDevOpsを使用するか)。

では、ITILは死んだのでしょうか?いいえ。ITILはまだ有効であり、場合によってはこれまで以上に必要とされています。

ブログ画像1
ITIL環境での問題管理品質の測定、その1
ブログ画像1
ITIL環境における問題管理品質の測定、パート2
ブログ画像1
ITIL環境における問題管理品質の測定、第3回
ブログ画像1
ITIL環境における問題管理品質の測定、第4回

私たちは以下の専門家です:

お問い合わせ

お問い合わせ、ご意見、詳細確認はこちらから