DevOpsは単一のフレームワークや方法論ではなく、複数のものを組み合わせて活用するものです。具体的には、アジャイル開発・リーン 方式・ITサービスマネジメントが挙げられます。
まず、DevOpsはアジャイル開発が作り上げた手法によって極めて効果が上がります。チームを小規模に保ち、信頼できるリリースを頻繁に行って、ITチームの生産性を大きく向上させるというものです。また、DevOpsはリーン方式によって、作業フローを向上させ、ITバリューストリームの無駄を削減します。最後に、DevoOpsはITサービスマネジメントの適用によってボトルネックを省き、リードタイム・サイクルタイムの短縮化を達成します。これらの方法論を組み合わせて、より高い生産性と経済的な価値を実現します。
DevOpsは新しい開発と運用の進め方を提案します。その考え方を説明するために、いくつかのフレームワークが提唱されました。ここでは二つのフレームワークを紹介します。まず、「3つの道」は開発と運用、そして実験と学習を意味します。次に「CALMS」という原則は、5つの単語からDevOpsの価値を説明します。
DevOpsの開発フロー、フィードバック、実験と学習を表す「三つの道」
DepOpsの原則を表す「三つの道」は「The DevOps 逆転だ！究極の継続的デリバリー」で提案されました。三つの道は、プロセス・手続き・実装を考える上で効果的な方法です。まず、一つ目の道は「フロー」です。開発フローを理解し、高度化します。開発チームを左、IT運用チームを右に描いたときに、左から右へ向かう流れです。次に、二つ目の道は「フィードバック」です。フィードバック・ループを短くし継続的な改善を実現します。その流れは、右から左へと向かいます。そして、三つ目の道は「継続的な実験と学習」です。リスクを取り、失敗から学び、実験を促進する文化を育みます。また、繰り返しと実践が成熟の必要要件だと理解する文化が求められます。
DevOpsの三つの道について、以下に具体的な要素に分解します。
開発プロセスの最適化を推進することが重要です。特に、ボトルネックや非効率な手作業を特定するよう、可視化・監視のツールやプロセスを構築しなければなりません。デプロイやテストの自動化を促進します。
一つ目の道：フロー
- 継続的インテグレーション：少なくとも毎日、共有されたリポジトリにコードをコミットすることを開発者に求める手法。
- 継続的デリバリー：開発ライフサイクル全てを通じて、ソフトウェアが常にリリースできる状態に保つ方法論。
- 継続的デプロイメント：すべての変更が自動化テストを通過し、自動的に本番環境へデプロイできる方法。
- カンバン方式：作業の流れを図示し、管理可能な開発速度でプロセスを取り扱う手法。
- 制約理論：最も重要な阻害要因を明らかにする方法論。阻害要因にならなくなるまで改善を続け、ゴールを達成する。
- バリュー・ストリーム・マッピング：各チームをまたがった成果物や情報の流れを書き出して、時間や品質を含めた無駄を定量化するツール。
二つ目の道：フィードバック
開発プロセスを回す中で得られた洞察から、運用方法の改善を図ります。全ての工程で、何が起きているのかを計測し、問題があればチームで共有し、より良いプロセスの構築を目指すことが重要です。
- 自動化されたテスト
- 本番環境の変更に対するピアレビュー
- 監視とイベントマネジメントのデータ
- ダッシュボード
- 本番環境のログ
- プロセスの計測
- ポスト・モータム（プロジェクト終了後の振り返り）
- 問い合わせ対応のローテーション
- 変更管理・インシデント管理・問題管理・知識管理の情報
三つ目の道：継続的な実験と学習
DevOpsは文化の醸成が含まれるという特長があります。チームが一丸となって、失敗を許容し、新たなアイデアを試し、継続的に学習していくという態度が求められます。本番環境をリスクにさらすことなく、より良いプロセスを構築するよう目指します。
- 実験と学習
- PDCA（デミング）サイクル
- 型（あるいは、プロセス）の改善
- 失敗を活用し頑健性を改善する
- ITサービスマネジメントの実践
「3つの道」を実装する上では、ツール・プロセス・文化にまたがる課題が考えられます。例えば、DevOpsの仕組みを構築する際に、既存のシステムやプロセスが邪魔になってしまう可能性があるのです。一つの変更をするのに影響範囲が大きい、あるいは範囲の特定が難しいと、柔軟な開発プロセスが採用できず、DevOpsの実現が困難になります。
また、プロセスの観点からは、チーム間がサイロ化していると「3つの道」にたどり着くのが難しくなります。開発チームは新機能を実装するのを目的としている一方、運用チームはシステムに変更を加えず安定性を保ちたいと考えているものです。複数のチームが同じ方向を持って、DevOpsの方針に向かって新たなプロセスを構築しなければなりません。
さらに、新たなDevOpsの考え方を実現するには文化的な抵抗も考慮する必要があります。これまでに無い方法を実装する場合、心理的なハードルを感じるものです。経営層やリーダー層が中心となって、リスクをとり、より良い開発環境を構築するよう文化を醸成します。
CALMS：文化、自動化、無駄がない、計測、共有
DevOpsの価値を表現するフレームワークとしてCALMSという言葉が提唱されました。（参考：What is DevOps?）Culture（文化）、Automation（自動化）、Lean（無駄がない）、Measurement（計測）、Sharing（共有）の5つから構成されます。前述した「3つの道」と比較しても、それぞれ該当する点や、補足して、より深めている点などが存在します。
Culture（文化）
文化はDevOpsに関わる人とプロセスに影響します。複雑すぎず、単純過ぎない「ちょうど十分な」プロセスが実装し、メンバーが効果的に対話と協業できるよう助けます。また、継続的な学習や、新たな意見の実験といった文化も重視されます。DevOpsの文化無しには、自動化の試みは意味をなしません。「3つの道」においては主に「継続的な実験と学習」に該当します。
Automation（自動化）
リリース管理・構成管理・監視ツールといった技術は、開発フローを高度化します。繰り返しの手作業を省き、開発プロセスを円滑にするよう、DevOpsでは自動化が鍵を握ります。自動化されたプロセスは再現性があり、人的エラーを防ぐといった効果が期待されます。「3つの道」では開発プロセスのフローであり、自動化を導入・運用するステップとなります。
Lean（無駄がない）
リーン生産方式は、開発フローを改善して無駄を最小化しながら、顧客価値を最大化する試みです。製造分野では1980年代にリーン方式によってプロセスが革新的に進歩しました。今日ではリーン方式がソフトウェア・デリバリーに適用され、ITを革新的なものにしています。開発プロセスを可視化・定量化した後、ムリやムダを省いて、効率化を促進します。「3つの道」に当てはめると、フィードバックによって開発プロセスを最適化する点が共通していると考えられます。
Measurement（計測）
「計測できなければ管理できない」「計測できなければ改善できない」といった古い格言があります。DevOpsの実装に成功するには、人・プロセス・技術的パフォーマンスの全てを計測します。重要な指標、つまりKPIを特定し、うまくいっている点、いっていない点を明らかにする必要があります。「3つの道」においても、フローやフィードバックの根幹となる考え方です。
Sharing（共有）
共有とはCALMSサイクルのフィードバック・ループを意味します。チームがアイデアや問題を共有しあう文化を醸成するのは、対話と協業を促進するだけではなく、組織全体の改善を進めるのに重要です。特に、チーム間で情報を共有し、異なる役割を持ったチームも同じ目標を共有できるようにします。属人化を防ぐよう、知識やノウハウを文書として残すことが推奨されます。「3つの道」においても「継続的な実験と学習」の重要な要素として共有の文化が強調されています。
まとめ
DevOpsは開発と運用チームの関係性を見直し、実験と学習によってプロセスを改善していく取り組みです。その考え方は、三つの道やCALMSといった枠組みで解説されます。この原則を理解した上で、継続的デリバリーや継続的インテグレーションの実装を行い、組織への導入を進めると、DevOpsの効果が期待できます。
