図2の最下段には、Chefやgit（バージョン管理システム）、Jenkins（継続的インテグレーションツール）をはじめ数々のオープンソース製品や商用製品が含まれる。それらが主に担当する「開発」「ビルド」「デプロイ」の効率化や自動化がDevOpsであるという捉え方もある。

　しかし「テスト」は品質確保のためにおろそかにはできないが、大変な時間がかかり、リリーススピード向上には自動化が必須である。また本番環境への「リリース」作業を適時、確実に行う部分もオペレーションミスを防ぐという運用視点から自動化が望まれるポイントである。

　現在のような複雑に組み合わされたシステムでは、開発サイクルのスピードアップと比例して頻繁に発生する構成変更をおろそかにすると運用面で大変な人的負荷が発生する。間違った構成情報をベースに作業をすることで手戻りが発生するが、頻繁に変更される構成情報のメンテナンスは多大な人的負荷が発生するという矛盾があり、この問題を解決していく必要もある。

　これら一連のプロセスをできるだけ標準化し、合理的に短時間で流れるようにしなければ、企業レベルの観点で不整合や生産性の低下が発生し、ビジネス効率改善効果は限定的になってしまう。現在ではテスト自動化ツールやリリース管理ツール、ITILベースの運用管理ツールなどまでも含めて一貫したDevOpsプロセス管理可能なツールが取りそろえられており、より広い視野でDevOpsが捉えられるようになっている。

運用からのフィードバックを活用したビジネスプランニングもスコープに

　また図2では、発見された不具合ならびに提供されたフィードバックに基づく前工程の改善、次期リリースや新規プロジェクトに向けた要件の抽出や評価基準の設定などの事業改善に向けた取り組みも、DevOpsの一部であることが示唆されている。

　結果のフィードバックと評価、分析、改善ポイントの洗い出しは、継続的によりよいアプリケーションリリースを行う上でも大切だが、事業部門の事業計画とITとの整合性をとり、ビジネスに必要なITをタイミングよく追随させるために不可欠なものだ。

　業務部門からの要求を早くシステムに反映させ、運用も含めてそのサイクルを向上させるといった企業全体、広い視野でのDevOps、すなわちエンタープライズレベルでのDevOpsという概念が登場し、それを考慮した時には上記のような領域を視野に入れることが不可欠になるだろう。

　他のベンダーも、この運用結果のフィードバックを含めたビジネス効率改善サイクルを含めた全体最適化を視野に入れている。図3はIBMが提供するDevOpsプロセスのイメージ図だが、基本的に同様のプロセスが組み込まれている。具体像はこの図の方が分かりやすいかもしれない。

画像をご覧いただくには会員登録が必要です

会員登録・ログイン

図3 DevOpsエントリーポイントと開発、運用工程（出典：日本IBM）

　とはいえ、一気にこのようなサイクルを構築するのは難しく、リスクも高い。まずは図2の左から右への一方向でよいので、個々のDevOpsプロセスを連携させる仕組みづくりに取り組むことが望ましい。ただし部分最適に陥らないよう、将来的な自社のDevOps像を描いて、それに沿ったツール導入が肝心だ。

コラム：SoRとSoEって何？

　DevOpsの話題の中でよく聞かれるキーワードに「SoR（Systems of Record）」と「SoE（Systems of Engagement）」がある。前者はデータの記録が中心となるシステムであり、システムの安定運用と確実なデータ保護に注力するシステムのことをいい、後者はユーザーとの関係性を重視して新規サービスを迅速に提供できるような新技術を利用するシステムのことをいう。

　SoEでは変化のスピードが速いため、高リリース頻度が求められてアジャイル開発と継続的デリバリーが有効、クラウドがプラットフォームとなることが多い。SoRではリリース頻度が低く、ウォーターフォール開発、ITILベースのサービスデリバリー、オンプレミスプラットフォームが一般的だ。ITの新旧対比の一例として用いられることが多い。SoEの方がDevOpsの効果が顕著に現れるといわれている。