DevOps と OpsDevそして改善の原理原則について
DevOpsはScrumやアジャイル、カンバン方式、LeanITやITIL等から全く違ったエリアから借りてきたり同化したりしていくつかの解釈やアプローチができてきました。これらはすべてビジネス成果を最大化し、企業が新たなビジネスのペースについていく為の支援といった共通の目標を持っています。過去2回の内容を通してエンタープライズでのDevOps適応のためのシンプルなモデルを紹介してきました。最終回の本稿ではDevOpsを進めていく上でなぜ3つの視点が必要かについて考えてみたいと思います。
DevOpsは、Patrick Deboisによって2009年に作られた造語といわれています。DevOpsはさまざまな解釈がされていますが、基本的には迅速なデリバリという共通のビジネス目標のため、協調によるオーバーヘッドや開発者と運用の責任範囲をシェアし、部門間で迅速に、多くの情報フィードバックするループを可能とする文化であり方法論です。日本での大企業でのDevOpsの実践と方法論の適応は、ビジネスラインやその開発者からは決して望まれているわけではなく、多くの場合IT運用側でドライブされているケースが多いことを実感しています。これは海外でも一緒で運用主体でのDevOpsを私たちはOpsDevと呼んでいます。とはいえ最近では特に海外を中心としてDevOpsの多くのケースではアジャイル開発のチームによってドライブされだしてきています。アジャイル開発のターゲットは、IT運用が彼らの業務の中で多くのリクエストを処理しなければならない環境など、特にスピードとビジネスのアジリティが増加しているからです。日本では抵抗があるユーザも多いアジャイルですが、エンタープライズアジャイルとして最近は「ディシプリンド・アジャイル・デリバリー」のような書籍も出てきて一部では導入の検討が進みつつあります。いずれの場合でもすすめ方には以下のような視点があります。
- サービスデリバリーモデルの工業化
IT運用のための既存の課題は、サービスを提供するため（サービスデリバリー）のコストとスピードの最適化を目的としたITの工業化です。家内制手工業から脱却する手段としてはITプロセスに製造のベストプラクティスを適用することです。Lean開発・製造における経験で1つの原理原則は、デマンドからフルフィルメントまでのライフサイクルすべてに渡ったサービスデリバリプロセスの標準化と自動化です。この方向性はプロセス成熟度と同じ方向性となります。 - プロセスの自動化
工業化では大量生産の達成のため、IT運用ではプロセスの自動化が必要です。自動化を行わないと大量生産に比例して人数がかかってしまいます。自動化には例えばリリースによる変更、環境のプロビジョニング、モニタリング、問題の解決などが含まれます。これらのプロセスの自動化は、特定のサービスや環境、タスクに対して行われるべきものではなく、組織全体のために行われるべきもので、自動化適応のためにはプロセスや部品の標準化が有効な手段となります。 - 利害関係者とのコラボレーション
業務側の要件を柔軟に反映させるなどビジネスの柔軟性を向上させると、スピードとリスクのバランスを最適化するためIT運用とビジネスや開発チームとの間で別なレベルでのコラボレーションが必要となってきます。今後ITのロールは、開発よりもむしろサービスをコーディネーションする仕組みを作る側に変わっていくと考えられます。つまりガイダンスやポリシー、IT利用者に利用されるフレームワーク等を提供し、標準的なサービスに対してはセルフサービス機能などを提供するようになるでしょう。これらの移行にはビジネスラインのIT利用者と、外部サービス提供者やアウトソーサ等との間で異なったレベルでのコラボレーションが必要となります。 特にアウトソースのサービスの場合、プロセスの可視化、フレームワークのシェア、そしてトレーサビリティの確保がより一層重要になり、効率解消のためのバラバラなツールよりは、こういったサービス提供の仕組みの為の新たな仕組みやツールが必要になって来ることを意識すべきと思います。
DevOpsとOpsDevは、最初に指摘したようにビジネス成果の最大化を共通の目標として持っていながらドライバが異なる場合があります。また多くの場合上述のような標準化・自動化・コラボレーションといった3つの次元で移行が進んで行きます。自動化をうまく成功させるには標準化が重要で、デリバリ高速化により発生する進捗管理や工数の最適化、変更のマネージには新しいコラボレーションな為の仕掛けは必須といえるでしょう。
おわりに
サービスの有効利用には使う側の態度や前提条件が存在します。DevOpsというソリューションを買ってきたからすぐに利用できるという物ではなく、あくまでリリースサイクルを短くしたり、コストやリスクのバランスを取るというITの目的をサポートする一手段で、その利用のためには利用者側でも環境やプロセス、場合によっては組織のミッションを変更しないとうまくいかない可能性があるということがおわかり頂けたと思います。組織のロールや情報の開示のためKPIの収集など検討が大がかりになって適応が後回しになることで競合の後塵を拝することがあってはなりません。今回紹介してきた成熟度モデルなどを利用してバランスよくステップバイステップで工業化がすすみソフトウェアを含むサービス市場投入までの期間が短くなることを願ってやみません。