アジャイルとITILは、それぞれ異なる時期に、従来のビジネス手法への不満への対応として注目を集めた、人気のIT手法です。一見すると、この2つは相容れないように見えます。 ITIL方法論 一貫した価値を繰り返し提供するために IT 組織が採用すべきプロセスと考え方を体系化することを目的としています。 アジャイル 進化する環境で迅速に価値を提供するために、大胆に革新し、疑問を投げかけ、「物事を壊す」ことへの恐怖を捨てることを目指しています。

しかし、どちらの方法論も、互いの弱点を補う強みがあり、今日のビジネスの世界で非常に高く評価されている俊敏性を犠牲にすることなく、IT 組織が関係者に最大の価値をもたらすための青写真を示しています。

この投稿では、1 つの方法論が他の方法論から学び、チーム、利害関係者、顧客に価値を提供する機会について説明します。

なぜアジャイル手法は現代のビジネスで高く評価されているのでしょうか?

アジャイル手法は、アイデアとその結果の間にある障壁を可能な限り取り除くことを目的としています。明確に規定されたサービスレベル契約（SLA）を満たすための厳格な方法論を重視するITILとは異なり、 アジャイル方法論 組織が小規模なチームに権限を与え、自律的かつ熱意を持って働けるようにすることを奨励します。

チームは 多分野にわたる専門家日々の業務の中で、どの分野に重点的に取り組むかを決めることが求められます。これらの取り組みの成果として期待されるのは、目に見える成果を迅速に提供することです。チームは「スプリント」と呼ばれる単位で作業を進めます。 反復的なプロトタイプを作成する これにより、パラメータを設定し、さらなる目標を設定するための基盤が提供されます。イテレーションが構築されると、次のスプリントシリーズを通じて改善を重ねることができます。

その 基本的な4つの信条 には次の値があります:

1. プロセスとツールを介した個人と相互作用
2. 包括的なドキュメントを介した作業ソフトウェア
3. 契約交渉に関するお客様のコラボレーション
4. 計画に従った切り替えへの対応

Agility キーです 変化の激しい環境では、このような考え方を ITIL に適用することで、IT サービス チームが変化をすぐに受け入れることができるようになります。

アジャイルの世界でもITILが重要な理由

ITIL方法論は、デジタル技術がビジネス環境に深く浸透するようになった1980年代後半に誕生しました。 オリジナルガイドブック IT サービス管理 (ITSM) のための繰り返し可能なロードマップを提供しました。

ITILのメリットは、すべてが文書化されていることです。チームは、誰に報告し、何に取り組むことが期待されているか、そして変更、修正、改善を実施するプロセスを把握できます。文書化により、変更の監査や特定のアクションへの遡及が容易になります。

このような硬直的なアプローチは、アジャイル環境においては課題に直面する可能性があり、チームが必要に応じて計画された行動方針に適応したり変更したりすることを妨げます。例えば、 今日の ITIL ガイドに従うチームは、変更リスクを継続的に予測し、管理できる必要があります。

「ITILプロセスの永続性は、あまりにも堅固すぎる可能性がある」とナンシー・ヴァン・エルサッカー・ルイノードは「最高情報責任者「当初の事前にプログラムされた計画から逸脱する余地はほとんどなく、これは非アジャイル環境の定義です。」

ITILメソッドは、その代わりに予測可能性と説明責任を提供します。SLAは、期待値と成果物を明文化した文書を作成します。しかし、このシステムは完璧ではありません。チームがSLAを履行しても、ユーザーやステークホルダーの不満が残る場合があります。これは、記載されたパラメータが関係者の真のビジネスニーズを反映していない、あるいはニーズが変化している可能性があるためです。

この課題を考慮すると、一部のチームは、ITIL プロセスの基盤をそのまま維持しながら、アジャイル IT 管理アプローチを採用することに利点を見出すかもしれません。

例えば、チームはSLAを超えて視野を広げ、真の目標を特定することができます。チームは 実際のユーザーからのフィードバックを含める顧客やステークホルダーの意見をレポートにまとめ、その反応に基づいて優先順位を決定しましょう。また、こうした意見を正確に反映する指標も策定する必要があります。テクノロジーの実際のユーザーからフィードバックを求めることで、SLA違反に該当しないという理由だけで、ITチームが重大な問題を見落としてしまうことを防ぐことができます。

ITILに準拠した組織がアジャイル手法を適用するもう一つの方法は、1つ以上のイノベーションチームを編成し、SLAや組織の日常的なニーズといった限定的な視点にとらわれずに活動するために必要な自主性を与えることです。これらのチームは、小規模なユーザーテストグループでパイロットプログラムを実行したり、組織に劇的な改善をもたらす可能性のある、想定外の変更点を特定する実験を行ったりすることができます。これらはすべて、関係者全員にとって価値を生み出します。

社内に「スカンクワークス」チームを結成することで、ITインシデントの増加といった根深い悩みを解決できるだけでなく、新たな機会への扉を開くことも可能です。現在Slackとして知られるビジネスチャットクライアントを開発したチームは、当初は社内コミュニケーションの問題を解決したいと考えていました。しかし、イノベーションのためのリソースが与えられたことで、社内的にも社外的にも非常に価値のあるツールを生み出すことができました。 外部から.

アジャイルITマネジメントは、複雑な組織構造に内在する冗長性とマイクロマネジメントの多くを排除することを目指しています。チームが継続的な報告や監督、承認待ちなしに業務を遂行できる場合、 リーダーシップの役割を担う人は「企業ビジョンの作成と調整、戦略的イニシアチブの優先順位付け、業務の簡素化と集中化、適切な人材のタスクへの割り当て、部門間の連携の強化、進捗の障害の除去など、自分にしかできないより価値の高い業務に、より専念する。」

アジャイル環境においてITILの価値を維持する

すべてのプロセスがアジャイルアプローチの恩恵を受けられるわけではありません。反復的で予測可能であり、安定したビジネス環境内で行われる業務では、アジャイルIT管理手法が混乱を招く可能性があります。さらに、組織内のサイロ化によって誰もが納得する明確な解決策が考案され、何度も繰り返し実行されてきた業務もあります。つまり、イノベーションは不必要なリスクを招いてしまうのです。

ITILのこうした優れた特性を念頭に置き、アジャイル組織は少なくとも、成功の測定、危機への対応、あるいはSLAの一形態としてベースラインの期待値を満たすための基本ルールを定めるべきです。もしそれが厳格すぎると感じるなら、チームはその文書をビジネスニーズに合わせて進化できる「イテレーション」と捉えることができます。

チームはプロセスの変更をテストし、評価することで、重要なビジネス機能に関連するものを「壊す」ことがないよう確認する必要があります。実験的なスクラムチームは、重要なビジネス機能に関連するプロトタイプ製品やプロジェクトを開発する際に、プレッシャーの少ない環境から恩恵を受けることができますが、最終的なイテレーションは、繰り返し可能なプロセスに従って徹底的に検証・テストされた安定した製品である必要があります。

アジャイルチームは、目標とその達成責任者を明確に理解する必要があります。そうすることで、初期のITILチームが当初避けようとした組織的な混乱のリスクを軽減できます。

ITILとアジャイルを比較する際に得られる重要な教訓は、それぞれの手法にはITチームが認識し、状況に応じて活用すべきメリットがあるということです。ITILフレームワークには、現在でも有効なベストプラクティスが備わっており、アジャイル手法にも応用できます。

今日のビジネスの世界は絶えず変化しており、それを支えるテクノロジー環境も同様です。ITチームは、最新のテクノロジーとそれに伴うニーズに常に対応していく必要があります。それだけでなく、サービスに関する新しい考え方にも常に対応していく必要があります。 ビジネスサービス管理ソリューション今日の IT 文化では、使用されるフレームワークはアジャイルの目的に適合する必要があり、その逆ではありません。