前回はDevOps成熟度モデルの概要を紹介しましたが、第2回では実際に組織間での異なった環境が存在するのにどのようにして自社のDevOpsの成熟度モデルを推測するかと、あるレベルから次のレベルまでの移行に必要なものが何かを紹介したいと思います。

この章に直接飛んでこられた方は、DevOpsの成熟度モデルその1のコラムもぜひ参照してください。

Level 2 - Managedへの改善

ここでは多くの日本のIT組織が直面する初期の段階からリリースプロセスでの成熟度レベル２に該当する例を示します。このプロセスではそれなりにリリースの管理がされていますが、組織間での標準化はされていません。各々の開発チームは彼ら自身のリリースプロセスのみを管理しており、ITリリースチームは独自の手順でリリースを行っています。組織内でのチーム内では頻繁にコミュニケーションを取っており、開発環境から運用へのリリースバイナリの移行や、リリースステータスのフィードバック、運用チームで測定されたパフォーマンス集計などの作業をコーディネートしています。自動化なども箇々の開発での最適化がされていますが逆に複数の開発がまたがるようなエンドトゥーエンドでの自動化はありません。あくまでも個別の活動が管理され自動化されています。各々のチーム間でコラボレーションや共有のアカウンタビリティがないため機能の重複が見受けられます。例えばアプリケーションのためのリリースチームと運用のためのリリースチームが存在したり、アプリケーションリリースとITILのプロセスに基づいたITリリースで自動化の為の基盤が異なっていたりします。検証のための基盤などもバラバラにもっていてつながっておらず必要なときに人のコミュニケーションを通じて調整されます。

Level 3 - Definedへの改善

成熟度2から3に移行するために、先ほどの例に挙げた組織では

機能の重複を避け、サイロでのオペレーションを排除し、エンドトゥーエンドでのリリースプロセスを用意しなくてはいけません。このプロセスに関与するすべての利害関係者は、それぞれの活動のプロセスと成果に自分の範囲での説明責任と、プロセスの可視性を共有している必要があります。エンタープライズアーキテクチャの例を挙げるまでもなくビジネスとビジネスに紐付いたビジネスプロセスが標準化され例外のプロセスが最小化される仕組みが必要になります。このプロセスはみんなが定義された同じやり方で生産行為を行うことに特徴付けられます。つまり全体がアーキテクトされてプロセスがしっかりと定義されていることが必須になります。日本の会社の多くが業務側でそれぞれのITの予算を持っていてITでシステムを構築するかと思いますが、業務側がコストを持っていることで個別業務最適が進み、全体最適のガバナンスがきかないケースが散見されます。このような問題に対しては組織のミッションを変えるなど標準化の為に大がかりな変更を余儀なくされ結果後回しになることが多くなっています。

Level 4 - Measuredへの改善

レベル4の測定された状態は、プロセスのエンドトゥーエンドによって生成された結果を分析することによりもたらされます。組織がこの段階で達成できるゴールは、予測可能性とよりよいリスク評価になります。この活動はレベル5の成熟度の活動と大きく変わりません。この段階でコストや時間、ビジネス価値がメトリック測定されます。数字を取らないことには改善に優先順位が付けられません。また開発・運用以外での他のITでの優先順位項目とのバランスを取っていくことも必要になってきます。日本ではよくKPIの設定で他の会社がどんなKPIを設定するかに興味を持ち、それを自社で適用しようとする管理者が多いのですが、このアプローチが正解かは半分当たっていますが半分は間違ったケースがあります。そもそも自社が開発や運用でどのような方向に行こうとしているのかを決めてそれに対しての確認にKPIを設定するわけですが、方向性なくKPIだけ測定してもオーバーヘッドばかりで意味がありません。

Level 5 - Optimizedへの改善

初期にルールを作っても現状とそぐわなかったり最適なプロセスでない可能性があります。最終的にはメトリックを測定しそれを最適化することで全体最適が実現されます。Level4で測定されたKPIに対して次のステップとして行われることは最適化やセルフサービスとしてのサービス提供による効率改善となります。

おわりに

サービスの有効利用には使う側の態度や前提条件が存在します。「お客様は神様」といってもたとえば散髪というサービスを受けるのにぐらぐら頭を揺らしていたら期待したサービスを受けることは難しくなります。DevOpsというソリューションを買ってきたからすぐに利用できるという物ではなく、あくまでリリースサイクルを短くしたり、コストやリスクのバランスを取るというITの目的をサポートする一手段で、その利用のためには利用者側でも環境やプロセス、場合によっては組織のミッションを変更しないとうまくいかない可能性があるということがおわかり頂けたと思います。次回はDevOpsを取り巻く環境や視点についてあれこれ書いてみたいと思います。