新しい世界。ITSMとITIL®にとってアジャイルとDevOpsは何を意味するのか?

by チャールズ・T・ベッツ そして クリストフ・ゴールデンシュテルン

最近、アジャイルとDevOpsがITのあらゆることに影響を与えているのを見逃すのは、岩の下で暮らしている人でなければならないだろう。新興企業から地球上の大企業まで、アジャイルとその関連技術は、ITの計画、構築、配信、運用の方法を変えつつある。

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

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

何が起きているのか、そして、このことは、既存の企業と新興の組織とで、どのような意味を持つのだろうか。アジャイルとDevOpsの影響を理解する1つの方法は、スケーリングまたは「創発」モデルを通じて行うことである。 ITILやCOBITのようなフレームワークの問題は、それらが企業規模で提示されていることである。フレームワークは、特定の企業のニーズに適合させるべきであると述べているかもしれませんが、具体的にどのように適合させるかは、コンサルタントに委ねられることが多いのです。大企業でうまくいくことが、新興企業では意味をなさないこともあるのです。Verne Harnishは、「Scaling Up」という本の中で、特定の規模の企業には自然なクラスターが存在すると述べている。

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

スケーリングプロセスは、"DevOps vs ITIL "といった、業界における現在の議論を理解するのに役立ちます。ITプロセスをこのような観点で考えてみましょう。10人規模の会社に本格的なチェンジマネジメントプロセスを勧めますか?3,000人規模の企業であれば、チェンジマネジメントプロセスを導入せずに経営することは可能でしょうか?どの時点で導入するのか、またその理由は?他にどのようなプロセスを、いつ導入しますか?

アジャイルは、小規模な文脈でうまく機能します。アジャイルはチーム指向であり、あらゆる規模の企業が、協調的なチームこそが価値を生み出す場所であることをますます認識するようになってきています。よく知られた研究によると、コラボレーション文化は他のすべての文化(競争文化を含む)よりも優れていることが分かっています。10人規模の企業もチームですが、50人規模の企業も "チームの中のチーム "であると考えなければなりません。問題は、それらすべてのチームの「接着剤」をどのように提供し、整合性を失わないようにするかです。Spotifyのエンジニアリングカルチャーでいうところの「疎結合」であればあるほど、コラボレーションと問題解決を促進する共通のアプローチで「密結合」する必要があるのです。

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

  • マーケティング
  • 研究開発
  • 売上高
  • オペレーションとサービス
  • バックオフィス(財務、人事、IT)

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

IT部門は、ビジネスとの関係においても、社内においても、「発注者」として組織化されている。たとえば、アプリケーション・チームは、必要なリソースを求めてインフラストラクチャー・チームに「チケット」を提出します。このモデルでは、ITシステムやサービスはそれなりに安定しますが、提供するのに時間がかかり、変化にも遅れることがよくあります。機能サイロとエンドツーエンド・プロセスの考え方が主流であり、ITILのようなフレームワークが提唱するものとは異なるため、少し皮肉なことではありますが、これは事実です。

今日、デジタルトランスフォーメーションは、サイロに挑戦し、破壊しています。市場に投入される製品に含まれるITの量が増え、「バックオフィス」のITは、研究開発や一般的な業務・サービスに収斂されています。ITが企業の存続に欠かせない存在となった今、ITには市場ニーズへの対応力がより一層求められています。安定性は必要ですが、変化の激しい市場ニーズに対応できない安定したシステムには価値がありません。

機能別サイロでは、ハンドオフが必要です。ハンドオフがあると、対応が遅れ、応答が遅くなります。機能サイロは、サービスを提供しているチームやサービスを要求しているチームに対して、「私たち対彼ら」という態度をとりがちである。これが、アジャイル手法が多能工チームを推進する理由です。Marty Caganは、影響力のある著書で次のように述べています。 インスパイアされる。顧客に愛される製品の作り方。 そのためには、最低限、3つの必要な品質に向けて製品を推進する必要があります。

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

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

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

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

ITILはどうなる?

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

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

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

チェンジマネジメントt

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

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

運用エンジニアが本番環境に必要な変更を加える責任を負っている場合、変更の遅れは、チーム間の同期の欠如ではなく、工程内の作業が多すぎることに起因することがあります(たとえば、リスクを評価するために隔週で変更承認委員会を使用する場合など)。しかし、「You-build-it, you-run-it」方式で業務を行うチームが増えるにつれ、運用担当者が本番環境の変更を実施することは、付加価値のないこととみなされるようになりました。よく言われる「職務分掌」の懸念も薄れてきています。(DevOps エバンジェリスト Gene Kim と IT 監査人 James DeLuccia の共著である DevOps Audit Defense Toolkit を参照してください)。

チェンジマネジメントの先にあるもの

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

こうしたサイロ化は、"すべての開発チームに独自の運用担当者やインフラストラクチャ・エンジニアを与えるには人数が足りない!"といったコメントで擁護されます。しかし、これは最新のクラウドベースのDevOpsの実践のポイントを外し、ITサービスマネジメントの重要な側面を見落としている。ITILはサービスカタログの確立を提唱しており、これはインフラサービスの「フロントエンド」によく使われる。歴史的には、サービスリクエスト管理プロセスがこれらのサービスをサポートしており、多くの場合、手作業(例えば、エンジニアがいくつかの新しいサーバーのリクエストを分析する)で行っていました。

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

エンタープライズ規模への移行

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

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

一方、規模を拡大する際のリスクとして、組織があまりにも多くのプロセスを導入したために、重要なチームエクスペリエンスが損なわれることが挙げられます。管理・文書化の必要性よりもアウトプットの価値に重きを置いたプロセスが複数存在すると、チームの活動が阻害され、結束力が低下し、顧客価値を提供する能力が低下してしまいます。

おわりに

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

Kepner-Tregoeについて

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

関連

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

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

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

お問い合わせ

お問い合わせ、詳細、ご提案はこちらから