アジャイルソフトウェア開発やスクラムは企業が本当にアジャイルの約束を果たすために十分なものではない、とDave van Herpen氏は言う。彼が提案するのは、企業全体を通じたコラボレーションを改善するために、ITサービス管理がアジャイルやリーンのプラクティスをDevOpsとあわせて適用する、ということだ。
5月13日にアムステルダムで行われるアジャイルガバナンスカンファレンスにおいて、Dave氏は"企業のアジリティへの道は、善意で敷き詰められている"と題した講演を行う。InfoQは氏にインタビューし、アジャイルやリーンのやり方でのサービス管理や継続的にITサービスを改善する方法について聞いた。
InfoQ: ITILには継続的サービス改善（CSI）があります。CSIとはどんなもので、なぜ組織がそれをしたがるのか、説明してもらえますか？
Dave氏: ITILによる継続的サービス改善は、ITプロセスやサービスの、効率や有効性を継続的に改善するプロセスです。これをトヨタ生産システムの（システム）カイゼン、スクラムにおけるレトロスペクティブセレモニーと比較したくなるかもしれません。どれも（例えば組織、プロセス、製品、サービスなどの）システムの継続的改善を目的としたものです。ITILのアプローチとここに挙げたようなそれ以外の方法の主な違いは、ITILがCSIを分離した1つのプロセスとみなす一方、それ以外の方法論は継続的改善を（日々のビジネス）プロセスの一部であると考えることです。ITILでは、CSIのほかに4つのプロセスエリアあるいは出版物を定義しています：サービスストラテジ、サービスデザイン、サービストランジション、そして、サービスオペレーションです。CSIはこれらすべてのプロセスの弾み車となることが狙いであり、ITサービス組織がそのプロセスやサービスを継続的に最適化し、その結果として（内部または外部の）顧客に届ける価値を継続的に改善することを可能にします。
InfoQ: あなたの書いた記事アジャイルCSI：継続的サービス改善を正しく行う（Agile CSI: continual service improvement done right）では、アジャイルやリーンのプラクティスをITサービス管理にどのように適用するかについて述べています。なぜ、アジャイルとリーンなのでしょうか？
Dave氏: ITサービス組織がこの、例えば10年ほどの直面してきた主な課題は、デリバリー（変更）の速さ、サービスの質、柔軟性、文化的側面や行動的側面、顧客満足、ビジネス改善、そして、IT（プロセスやサービスの）ランドスケープの複雑さの増大などに関するものです。ITILはこれらの課題のごくわずかに対してしかガイドラインを提供していません。実際のところ、プロセス数の増大によって、サービス組織の複雑さや管理負担が増大しているだけなのです。
リーンやアジャイルの原理、方法、手段は数多くのビジネス組織やIT組織においてこれらのギャップを埋めることが明確に照明されてきています。たとえば、リーンは純粋に学習の文化を実現するもので、効果的なバリューストリームと顧客志向にフォーカスします。アジャイルは製品やサービスの柔軟で高速なデリバリに貢献することが示されており、継続的改善と分野横断的コラボレーションにフォーカスします。
InfoQ: あなたが継続的改善を追跡した手法と、アジャイルやリーンの概念を活用してそこから得られた結果について、教えてくれますか？
Dave氏: 私がブログの中で書いた組織では、最初に、過去数年の間に積み上がっていた巨大な改善のバックログをなくすためにスクラムを活用しました。つまり、それまでは、組織の文化、個人の態度、ITプロセスやその対象物が積極的かつ継続的な改善において目標とされていなかったのです。単にある作業を実施するだけでなく、日々の作業やサービスの改善にフォーカスし明らかな価値を置くようになって、これらはすべて変わり始めました。このことで、改善に関する完全なバックログができ、それはスクラムボード上で追跡されるようになりました。3つのスプリントの終わりにはカンバンボードに移行し、インシデント、問題、変更、改善を含むようになりました。その時以来、カンバンボードはパフォーマンスや改善の進捗の追跡に使われています。他にも、ツールの母Excelをボードに載らなくなったあとの過去の改善（メトリック、サイクルタイム、価値）の追跡に利用しています。
InfoQ: DevOpsは開発と運用がより密接に連携するための一つの方法です。DevOpsは彼らが継続的に改善するのに役立つでしょうか？役立つ例をあげていただけますか？
Dave氏: DevOpsのマインドセットと哲学をよく見ると、それが開発と運用についてだけのものではないとわかります。ビジネス、サプライヤー、アーキテクチャー、セキュリティ、テスティングなどの密接なコラボレーションにも関係しています。それを実施する中で、リーン、アジャイル、ToCからの基本的原理によって、顧客の焦点、デリバリの速度、そして継続的改善をも確実なものになります。私が見てきたDevOpsチームの中には、レトロスペクティブ（振り返り）に取り組んでいるチームもあれば、システムや現場のカイゼンを採用するチームや、独自の方法を発見したチームもありました。それに加えて、DevOpsはコラボレーションや文化に強く焦点を置くだけでなく、自動化に重きを置くことで、スループットの速さ、フィードバックループ、品質の予測性を確実にします。最後に、DevOpsの文化は、継続的改善のための基礎的なベースとして、評価指標（例えば、タイムトゥバリュー（価値実現までの時間）、MTTR（平均修復時間）など）に強くこだわります。
InfoQ: 顧客に対するITサービスを改善するよりよい方法を発見したい組織に対して、何を行うことを提案しますか？
Dave氏: 最初に継続的改善のためのマインドセットを獲得することにフォーカスすることを提案します。これにより常にITガバナンスにおける変化も共に起こるはずです。つまり、従業員の中に継続的改善のマインドセットをつくり出すことができても、（中間）管理職がその動きに報いることがなかったり、これらの改善に対する（時間的、あるいはフォーカスできる）余地をまったく与えなかったりすれば、決してうまくいかないでしょう。アジャイルやリーンの原理や手段を活用することで、ずっと先まで（私の考えでは、例えばITIL CSIよりもずっと先に）行くことができますが、顧客やサプライヤー、マネジメントも含めて関わる人々から望ましい態度や行動を勝ち取るために必要な努力を過小評価してはいけません。
InfoQ: アムステルダムでのアジャイルガバナンスカンファレンスで、あなたはエンタープライズアジリティへの道について語りますね。この道はどのようなもので、どのように旅すべきものですか？
Dave氏: プレゼンテーションでは、エンタープライズアジリティにとっての4つのとても重要なパターンについて講演するつもりです:
- 戦略とリスクアライメント（例：ポートフォリオ）
- サイズと複雑性を扱うこと（例：スケーリング）
- ライフサイクル全体を通じたコラボレーション（例：DevOps）
- 外部の関係者を統合すること（例：SIAM）
これら4つのパターンは、相当な大きさがあり、独立した内部のソフトウェア開発チームの中だけではなく、企業全体でのアジリティを実現しようと努力している組織にとっては基本的な事柄です。私は、現実に行われているいくつかの例を使って、企業レベルでのこのアジリティを実現する現実的な手段について述べる予定です。