新しい世界。アジャイルとデブオプスはITSMとITIL®にとって何を意味するか

by チャールズ・T・ベッツ 例えば、 Christoph Goldenstern

アジャイルとDevOpsが最近のIT全般に与えている影響を見逃している人はいないでしょう。新興企業から世界最大の企業まで、アジャイルとその関連技術は、ITの計画、構築、提供、運用の方法を変えつつあります。

この変化は、ITサービスマネジメントの専門家とそのフレームワークであるITILにとってどのような意味を持つのでしょうか。 たくさんあります。DevOpsは予想外の方法で話題を変えました。例えば、長い間、変化は安定の敵であると考えられてきました。そのため、企業は頻繁ではない「計画的な」リリースを選択してきましたが、これは決してうまくいくとは思えませんでした。

そして、DevOpsの登場です。「10 Deploys a Day at Flickr」というのが2009年の最初の叫びでした。きっとシステムは常にクラッシュしているに違いない?いいえ、そんなことはありません。継続的デリバリがよく理解され、正しく実行されると、システムの安定性が向上します。 シリコンバレーのスタートアップ企業だけでしょうか?2016年9月、Barclays Bankは、800のアジャイルアプリケーションチームが頻繁にデプロイするほど、サービスの安定性が高まると述べています。どのような規模であっても、複雑なシステムをより小さく、より漸進的に変更する方がリスクが低く、安定性を促進することは明らかです。 さらに、そのような小さな漸進的な変更の迅速なフィードバックにより、(リーン・スタートアップの用語で言うところの)Minimum Viable Productを迅速に顧客に提供することで、仮説の検証に基づく新しい学習文化を実現することができます。

アジャイルやDevOpsの影響を理解する1つの方法として、スケーリングモデルやエマージェンスモデルがあります。アジャイルやDevOpsの影響を理解する一つの方法は、スケーリングモデルまたは「エマージェンス」モデルを用いることです。 ITILやCOBITのようなフレームワークの問題点は、企業規模で提示されていることです。フレームワークには、特定の企業のニーズに合わせるべきだと書かれているかもしれませんが、具体的にどうすればいいのかはコンサルタントに任されていることが多いのです。大企業ではうまくいっても、新興企業ではうまくいかないこともあります。Verne Harnishは、Scaling Upという本の中で、ある規模の企業には自然とクラスターができると述べています。

  • 1-3人
  • 8-12人
  • 40-70人
  • 従業員数350~500名
  • 2,500~3,500人

スケーリングプロセスは、"DevOps対ITIL "など、業界で現在行われている議論を理解するのに役立ちます。このような言葉でITプロセスを考えてみましょう。10人規模の会社に本格的な変更管理プロセスを推奨しますか?3,000人規模の会社で、変更管理プロセスなしで運営できるでしょうか?どの時点で導入するのか、そしてその理由は?他にどのようなプロセスをいつ導入しますか?

アジャイルは小規模なコンテクストに適しています。アジャイルはチーム指向であり、あらゆる規模の企業が、価値を生み出すのは協調的なチームであると認識するようになっています。確立された研究によると、協調的な文化は他のすべての文化(競争的な文化を含む)よりも優れていることがわかっています。10人の会社はチームですが、50人の会社は "チーム・オブ・チーム "であると考えなければなりません。問題は、それらのチームの整合性を失わないための「接着剤」をどのように提供するかということです。スポティファイのエンジニアリング・カルチャー用語でいうところの「疎結合」であればあるほど、コラボレーションや問題解決を促進する共通のアプローチで「緊密に連携」する必要があります。

当たり前のことですが、企業の規模が大きくなると、機能別に特化するパターンが多くなります。

  • マーケティング
  • リサーチ&ディベロップメント
  • 売上高
  • オペレーションとサービス
  • バックオフィス(財務、人事、IT)

さらに、各機能の中にもサブスペシャリティが存在する(例えば、ITはアプリケーションチームとインフラチームにさらに特化し、インフラチームはサーバー、ストレージ、ネットワーク、24×7 NOCなどに特化する)。

IT部門は、ビジネスとの関係においても、社内においても、自らを「オーダーテイカー」として組織化しています。例えば、アプリケーションチームは、必要なリソースを求める「チケット」をインフラチームに提出します。このモデルでは、ある程度安定したITシステムやサービスを提供することができますが、多くの場合、提供に時間がかかり、変化にも対応できません。これは皮肉なことですが、ITILのようなフレームワークが提唱していることとは異なります。

今日、デジタルトランスフォーメーションはサイロに挑戦し、破壊しています。市場に投入される製品にはますます多くの情報技術が使われるようになり、「バックオフィス」のITは研究開発や一般的なオペレーションやサービスと融合しています。今やITは企業の存続に欠かせないものであり、市場のニーズにより迅速に対応することが求められています。安定性が求められるのは変わりませんが、変化の激しい市場のニーズに応えられない安定したシステムは価値がありません。

機能的サイロは、ハンドオフを必要とします。ハンドオフは、遅延や応答性の低下を引き起こします。機能的サイロは、サービスを提供しているチームやサービスを要求しているチームに対して、「我々対彼ら」という態度をとる傾向がある。だからこそ、アジャイル手法では複数のスキルを持ったチームが推進されるのです。 インスピレーションお客様に愛される商品の作り方 チームは最低限、製品を3つの必要な品質へと導くことができる必要があります。

  • 価値のあるものですか?
  • 使えるかどうか?
  • 実現可能なのか?

この3つの次元に沿って成果を推進できるチームは、「フルスタック」と呼ぶことができます。スクラムをはじめとするアジャイル手法では、チームが外部からの依存や妨害を最小限に抑えて、一般的に自力で活動できることが繰り返し強調されます。

もうひとつの現在の慣行は、「You build it, you run it」です。これは良い習慣であり、開発者が実際に本番で動作するソフトウェアを書くことにほとんど責任を持たなかった昔の「壁に投げつけて走らせる」時代からは大きな変化です。基本的には、垂直的なITの「工場モデル」から、より「水平的な管理」のアプローチに重点が置かれます。これは、インシデント管理や問題管理といったITILの伝統的な分野も含めて、チームがエンド・ツー・エンドで責任を負うというものです。

アマゾンのCTOであるWerner Vogelsは、「開発者に運用責任を与えることで、お客様と技術の両方の観点からサービスの品質が大幅に向上した」という有名な言葉を残しています。現在、開発者はますます「ポケベルを着ける」ようになり、ユーザーの期待する機能を満たすだけでなく、安定性、拡張性、操作性に優れたソフトウェアを書くようにインセンティブが与えられています。

ITILはどうなる?

このようなチームベースのアプローチは驚くほど効果的であることがわかっているため、世界中の大小さまざまな組織がアジャイルやDevOpsの導入を急いでいるのです。

しかし、「チーム・オブ・チーム」と呼ばれる大規模な組織レベルでは、コミュニケーションとコラボレーションがチームを超えて行われなければなりません。このようなコミュニケーションの必要性を最小限にするように努力することはできますが、ある時点で、2つの変化が衝突しないことをどうやって知ることができるでしょうか?活動を調整し、同期させるためのチーム横断的なプロセスでは、オペレーションに不可欠で、最小限ではあるが必要不可欠な品質チェックを行う重要な情報(例:インシデントや問題の記述)に素早く焦点を当てる必要があります。

チーム全体で問題解決のための共通のアプローチをとることで、インシデント、問題、変更管理の間の障壁を取り除くことができます。誰もが「同じ問題解決と実行の言語を話す」ようになれば、非効率的な活動や反復的な活動による「デッドタイム」を最小限に抑え、データの使用と共有の方法を改善することができます。

チェンジマネジメントt

ITILは長い間、厳格な変更プロセスを提唱してきたため、アジャイルやDevOpsを支持する多くの人々にとって障害となっています。しかし、変更のスループットを低下させること(ITIL変更管理が行う傾向がある)は、システムの安定性とは相関していない。

さて、ITILの公平性を考慮すると、一般的にプラットフォームが安定しているアプリケーションやサービスへの継続的なアップデートは、議論や承認を必要としない「標準」の変更と見なされます。これを妨げるものはITILにはありません。しかし、あまりにも多くの組織では、1~2週間の変更管理サイクルを使用して「開発者を待たせる」ことが現実となっています。

運用エンジニアが本番環境への必要な変更を行う責任を負っている場合、変更の遅延は、チーム間の同期が取れていないことではなく、工程内の作業が多すぎることが原因である可能性があります(リスクを評価するために隔週で行われる変更承認ボード会議の利用などが挙げられます)。しかし、より多くのチームが「あなたが作り、あなたが動かす」ベースで運営されているため、オペレーションが本番の変更を実施することは付加価値がないと考えられています。よく言われる「職務分掌」の懸念も薄れています。(DevOpsのエバンジェリストであるGene Kim氏とIT監査人のJames DeLuccia氏が共同で執筆したDevOps Audit Defense Toolkitを参照)

チェンジマネジメントを超えて

変更管理を超えて、アジャイルやDevOpsのチームはどのようにITILを経験してきたのでしょうか?ヘルプデスク機能や24×7センター(これは2つの異なるサービスです)を含むオペレーションを管理するチームは、ITILのトレーニングと用語を採用し、サービスチームが機能的サイロとして運営される傾向にあります。

このようなサイロは、"すべての開発チームにそれぞれの運用担当者やインフラエンジニアを配置するだけの人手がありません!"といったコメントで守られています。しかし、これは現代のクラウドベースのDevOpsプラクティスのポイントを外しており、ITサービスマネジメントの重要な側面を見落としています。ITILでは、サービスカタログの構築を提唱していますが、これはインフラサービスの「フロントエンド」によく使われます。歴史的には、サービスリクエスト管理プロセスがこれらのサービスをサポートしていましたが、多くの場合、手作業で行われていました(例えば、エンジニアが新しいサーバーのリクエストを分析するなど)。

クラウドやマイクロサービスのアプローチは、一貫したカタログベースのフロントエンドと完全に自動化されたサービスによって、サービスリクエスト管理のあり方を変えつつあります。AmazonやAzureのクラウドポータルは、高度に自動化されたサービスカタログに他なりません。セルフサービスと自動化は、機能チームに力を与え、インフラチームはオンデマンドのコンサルティングやエンジニアリングサービスから解放され、共有されたセルフサービス型のインフラの構築と維持に専念することができます。

エンタープライズ・スケールへの移行

アジャイルの考え方を真の企業規模に持ち込むとどうなるか?チーム・オブ・チーム」の調整が必要になるだけでなく、リスク管理やガバナンスなどの問題も出てきます。事業継続、問題管理、大規模インシデントへの対応が重要な問題となります。Kepner-Tregoe社の見解では、特に大規模なインシデント管理には、壊滅的な損害や損失から企業を守るための専門的なスキルが必要です。大規模な障害が発生したときに出血を止める「その場しのぎの能力」には、優れた問題解決能力だけでなく、ファシリテーションやコミュニケーションのスキルを兼ね備えたスペシャリストが必要である。

さらに、変化の激しい環境の中で、組織は同じ古い問題を解決し続けることはできません。克服できない未解決問題のバックログ(したがって、インシデント量の増加)がある組織に、アジャイルやDevOpsの原則を導入することは、危険な試みです。アジャイルとDevOpsを成功させるためには、組織は問題管理に真剣に取り組み、問題の根本原因を見つけるためにリソースを投入する必要があります。問題管理を、新しいユーザー「ストーリー」と同じように、チームのバックログに戻すことは、新しいベストプラクティスです。

逆に、スケールアップのリスクとしては、組織があまりにも多くのプロセスを導入したために、重要なチームエクスペリエンスが阻害されることが挙げられます。アウトプットの価値よりも管理や文書化の必要性に駆られて複数のプロセスを導入すると、チームのデリバリーが妨げられ、チームの結束力や顧客価値を提供する能力が低下します。

結論として

ITSMのプラクティスは、新しいアジャイル/デブオプスの世界に提供できるものがたくさんあります。ITSMのプラクティスは、言語や実績のあるプラクティスに沿ったものです。サービスカタログ、変更管理、インシデント管理、問題管理のすべてが関連しています。しかし、ITILのようなフレームワークの本来の意図を失い、サービスの成果よりも構造やプロセスを重視する根拠としてITSMを使用しないように注意する必要があります。ユーザーの成果に対するサービス中心のアプローチは、長い間、ITSMの哲学の一部でした。そして、その焦点を維持し、「スピードのある品質思考」を適用する能力を持つサービスマネージャーは、今後もうまくやっていけるでしょう。結局のところ、すべてはお客様の体験であり、品質と安定性の両面でお客様のデジタルシステムに遭遇する日々の瞬間のことなのです。

ケプナー・トリゴーについて

ケプナー・トリゴーは、問題解決のリーダーです。ケプナー・トリゴーは、60年以上にわたり、より効果的な根本原因の分析と意思決定のスキルを通じて、世界中の何千もの組織が何百万もの問題を解決するお手伝いをしてきました。ケプナー・トリゴーは、問題解決のためのトレーニング、コンサルティング・サービスの提供を通じて、コストを大幅に削減し、
業務パフォーマンスを向上させるために企業と提携しています。

関連

シフト・レフト?いいえ、サービス・サポートの成功のために「シフト・ダウン」してください。

株主価値の最大化におけるカスタマーサポートの戦略的役割

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

お問い合わせ

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