DevOps入門 ― 本質を理解して実践しよう！
DevOpsとは何か？ そのツールと組織文化、アジャイルとの違い
分かるようで分からない「DevOpsの定義」を原典からひもとく。またアジャイルや継続的デリバリーとの違いに言及し、DevOpsを現場で実践するためのアドバイスを提示。
DevOpsとは何か？
最近、さまざまなイベントでDevOps（読み方は「デブオプス」）をテーマにしたものを見る機会が増えてきた。そのイベントも、ツールベンダーが主催のものだけでなく、ユーザーコミュニティが主催しているものまで多種多様であり、裾野の広がりを見せている。一方で、本原稿執筆時点においても残念ながら、DevOpsの厳密な定義は存在していないのが実情だ。そのため、DevOpsに対してさまざまな誤解が生じてしまっているのも事実である。
本稿ではDevOpsの原典をひもとき、なぜDevOpsが今、あらためて脚光を浴びているのかを分かりやすく解説しよう。
DevOpsの原典
DevOpsとは「開発チーム（Development）と運用チーム（Operations）がお互いに協調し合うことで（図1参照）、開発・運用するソフトウェア／システムによってビジネスの価値をより高めるだけでなく、そのビジネスの価値をより確実かつ迅速にエンドユーザーに届け続ける」という概念である。
※この図は、次のリンク先のPDF内にある画像を参考に、新たに書き起こしたものである。
・【参考元】「Enterprise DevOps」の「DevOps のワークフロー」 © Microsoft
この概念の原典ともいえるものが2009年にオライリー主催の「Velocity 2009」というイベントにおいて、当時Flickrに所属していたJohn Allspaw氏とPaul Hammond氏による「10+ Deploys Per Day: Dev and Ops Cooperation at Flickr（1日10回以上のデプロイ： Flickrにおける開発と運用の協力）」というタイトルのプレゼンテーションである。
【引用】プレゼンテーション「10+ Deploys Per Day: Dev and Ops Cooperation at Flickr」（英語）
両氏はこのプレゼンテーションの中で、それぞれの役割の違いから対立することの多い開発者（以下、Dev）と運用者（以下、Ops）の対立構造を次のように示した。
Devの役割が“システムに新しい機能を追加する”である一方、Opsの役割は“システムの安定稼働”である。そのため、Devが新しい機能を追加したくても、Opsはシステムの安定稼働のために変更を加えたがらない、という対立構造が作られてしまっていた。
しかしDevとOpsのそれぞれのミッションは（DevOpsの概念と同じく）、どちらも「システムによってビジネスの価値をより高めるだけでなく、そのビジネスの価値をより確実かつ迅速にエンドユーザーに届け続ける」ことである。そのミッションを達成するための手段が、上記のとおりDevは“システムに新しい機能を追加する”であり、Opsは“システムの安定稼働”なのである。つまり、同じ「ミッション」を掲げているにもかかわらず、それぞれの「手段」が対立しているために、お互いのミッション達成に悪影響を与えてしまっている。これは、ソフトウェア開発の現場でよくある問題である。
そこで両氏はこの問題を解決するために、FlickrのDevとOpsが取り組んだことについて、ツールと組織文化の観点から以下のように提示した。
- 【 ツール 】
- 1自動化されたインフラストラクチャ（Automated infrastructure）： インフラの構築を自動化する。よく使われているツールにはAnsibleやChef、Dockerなどがある
- 2バージョン管理システムの共有（Shared version control）： GitやMercurialなどの同じバージョン管理システムをDevとOpsで共有する
- 3ワンステップによるビルドとデプロイ（One step build and deploy）： 手順書などを使い、手動でビルドやデプロイをするのではなく、ビルドやデプロイを自動化する。よく使われているツールやサービスにはJenkinsやCapistranoなどがある
- 4フィーチャーフラグ（Feature flags）： 詳細は後述のコラムで説明。コード中の機能の有効／無効を設定ファイルで管理する
- 5メトリクスの共有（Shared metrics） ： 取得したメトリクスの結果をダッシュボードでお互いに共有する。よく使われているサービスにはNew RelicやApplication Insightsなどがある
- 6IRCとインスタントメッセンジャーのBot（IRC and IM robots）： SlackやHipChatなどのチャットツールに自動的にビルドやデプロイのログ、アラート内容を投稿する仕組みを作ることで情報をお互いに共有する
- 【 組織文化 】
- Aお互いを尊重する（Respect）： 一緒に働く相手のことを心から思いやる、相手を一人の人間として扱い、能力や功績を評価する
- Bお互いを信頼する（Trust）： 自分以外の人は優秀で、正しいことをすると信じる。信じて仕事を任せる
- C失敗に対して健全な態度を取る（Healthy attitude about failure）： 新しいことに挑戦すれば自ずと失敗は起こってしまうもの。失敗は起こるものであり、相手のミスだと責めるものではない
- D相手を非難しない（Avoiding Blame）： 相手に非があると断じて言葉で責めるのではなく、次に同じ問題が起こらないように建設的な批判を行う
両氏がプレゼンテーション中で提示した項目は多岐にわたっているものの、全体の方向性として、より早くビジネスの価値を高め、エンドユーザーに届け続けるためには、ツールと組織文化の両面からカイゼンしていく必要があることを示していた。そして、このプレゼンテーション後、このようなカイゼン活動をDevOpsと呼称するようになったのである。2016年現在のDevOpsは、このプレゼンテーションで提示された要素「ツールと組織文化」以外に、
- 人（People）： マインドセットや考え方
- プロセス（Process）： 開発や運用の手法
- プロダクト（Product）： ツールや技術
という3つの要素の観点で説明されたり、
- Cluture（文化）
- Lean（リーン）
- Automation（自動化）
- Measurement（計測）
- Sharing（共有）
という5つの要素の観点（アルファベットの頭文字を取って「CLAMS」と呼ばれる）で説明されたりするなど、さまざまなパターンで要素分けされたいくつかのDevOpsの考え方が提唱されている。
【コラム】Feature flags（フィーチャーフラグ）
Feature Togglesとも呼ばれるこのテクニックは、アプリケーションの中に新たな機能（feature）を組み込んでおくが、その機能を有効にするかどうかは設定ファイル（＝フラグ）によって決めるというテクニックである。このテクニックによって、リリースのタイミングと機能の有効化のタイミングを分けることができる。
例えば、4月1日だけ有効にしたい機能を考えてみよう。このテクニックを使わない場合、4月1日の0時にアプリケーションをリリースし、4月2日の0時に機能を削ったものをリリースする必要がある。一方でこのテクニックを使うと、機能を有効化するには設定ファイルを配置し、機能を無効化する際に設定ファイルを削除するだけで済み、機能を無効化にするためだけのリリースが不要になる。
DevOpsにまつわるよくある誤解
前掲のプレゼンテーション「10+ Deploys Per Day: Dev and Ops Cooperation at Flickr」をきっかけに、さまざまな組織や人がDevOpsに取り組んだが、DevOpsという用語を間違った認識で使っていることが多い。自らをDevOpsエンジニアと呼称する人やDevOpsエンジニアを募集する組織があるが、この認識は誤りである。また、ある開発チームが「DevOpsをしている」と言いつつ、インフラチームや他のチームと一切協調しない姿も見てきた。他によく見るDevOpsの誤った最初のステップとして、ChefやPuppet、Ansible、Dockerなどのツールの利用を検討することである。カイゼンするべき問題を何ら定義していない状態で、何かをカイゼンする流行りのツールを導入したとしても全く意味がない。
繰り返すがDevOpsとは、より早くビジネスの価値を高め、エンドユーザーに届け続けるために行う、文化の変化を伴うカイゼン活動である。これは現状からムダやボトルネックを取り除くことを意味している。多くの場合、ムダやボトルネックとしては次のようなものが挙げられる。
- 手動での環境構築に伴う一貫性のない環境 …… 前述の「ツール」の12を実施することでカイゼンされる
- 手動でのビルド、手動でのデプロイ …… 「ツール」の23を実施することでカイゼンされる
- 組織内部の部署間のコミュニケーションの欠如 …… 「ツール」の56や「組織文化」のABCDを実施することでカイゼンされる
- 相手に対する理解や配慮の欠如 …… 「組織文化」のABCDを実施することでカイゼンされる
上記以外にももちろんムダやボトルネックはある。それらによって必要のない時間やお金が費やされている状況を、それらのムダやボトルネックを取り除くことでカイゼンしていくのがDevOpsである。このようにDevOpsとは、人でも、役割でも、役職でも、プラクティスでも、ツールでもないのである。
DevOpsとアジャイル開発や継続的デリバリーとの違いは何か？
DevOpsという言葉と同じくらいよく聞くのがアジャイルソフトウェア開発（以下、アジャイル開発）や継続的デリバリーという言葉だ。中にはアジャイル開発とDevOpsを混同して理解している人もよくいるので、以下でその違いについて説明しておこう。
アジャイル開発との違いは何か？
アジャイル開発を理解するには、原典とも言える「アジャイルソフトウェア開発宣言」（以下、アジャイルマニフェスト）と「アジャイル宣言の背後にある原則」を読み解くのが大事だ。双方を読むと、「システムの運用をどうするのか？」という点についてあまり触れられていないことが分かる。これはアジャイル開発が迅速かつ適応的に開発を行う軽量な開発手法のためである。
では、なぜDevOpsの文脈と共にアジャイル開発が現れるのか？ それは、そもそもDevOpsが、アジャイル開発のムーブメントから生まれたためだ。まず、アジャイルマニフェストに記述されている思考の変化が起こった。次に、よりカイゼンするために思考の変化にとどまらず、組織文化の変化をも引き起こしたものがDevOpsなのである。そのため、DevOpsを実践しているチームではアジャイル開発の手法を取り入れているところが多い。
継続的デリバリーとは何か？
継続的デリバリーは、よく継続的デプロイメント（または継続的デプロイ）と混同される。
継続的デプロイメントとは、全ての変更が自動的に本番環境にデプロイされていることを意味する。具体的には、ソースコードをバージョン管理システムにコミットすると、コミットをトリガーとして自動的にビルドとテスト（ここが継続的）が行われ、ビルドやテストに問題がなければビルドしたアプリケーションが自動的に本番環境にデプロイされるということである。
一方で、継続的デリバリーとは、全ての変更を本番環境にデプロイ可能な状態（＝いつでも本番リリースが可能な状態）を保証していることを意味する。つまり自動的にデプロイするわけではない。継続的デプロイメントではなく継続的デリバリーを採用する一般的な理由としては、「変更があるたびに頻繁にデプロイするのが好ましくない」といったビジネス上のルールなどが挙げられる。これらの継続的デプロイメントと継続的デリバリーの関係を図2に示す。
※「継続的インテグレーション」については以下の本文で説明する。
※2016/05/10修正： より分かりやすくなるように、この画像は差し替えました。
図2を見るとまず、全ての土台となるバージョン管理がある。これがなければビジネスの変化に対応するために行うソースコードを管理することができない。
それに積み重ねるのが継続的インテグレーションである。ここでは詳細は説明しないが、継続的インテグレーションとは、バージョン管理システムにソースコードをコミットしたタイミングで自動的にソースコードのビルドとテストを実行することで、問題がないかをできるだけ早期に検出する手法である。
さらにそこに積み重ねるのが、継続的デプロイメントになる。継続的インテグレーションの結果、問題がなければビルドしたアプリケーションを本番環境に自動的にデプロイする。
そして、継続的デリバリーとは、これらすべてを積み重ねた上に、本番環境へのリリースタイミングの決定をビジネス側が行えるようにするものとなる（＝問題なく動作するソースコードをコミットしたタイミングに本番環境にデプロイするのではなく、ビジネス側の希望するタイミングで本番環境にデプロイするということ）。
DevOpsを組織に適用する方法
DevOpsの意味するものが組織文化の変化であり、アプリケーションなどの製品開発に関与するさまざまなチーム間のより良いコミュニケーションや協調を実現することなのだとすると、どうすればそのような変化を自分たちの組織に適用できるのだろうか？ という疑問が浮かぶことだろう。
DevOpsの文化を組織に適用する場合、
- 何のために行うのか、組織内で認識を合わせ、
- その後、現状認識とあるべき姿に向け、組織内で連携・協調する
という観点で行うと効果的である。この2点についてより具体的に説明していこう。
何のために行うのか、組織内で認識を合わせる
組織内のメンバーが自分たちの存在意義を明確に理解し、その認識を共有することが重要である。存在意義とは、「自分たちは何を達成しようとしているのか？ 目的は何なのか？ それはどうしてなのか？」である。これらを認識し、共有するためには組織内のメンバーとコミュニケーションを取る必要がある。もし、あなたの組織内にDevOpsを誤って認識しているメンバーがいる場合は、DevOpsという単語はいったん忘れて使わないというのも手だ。DevOpsとは目的を達成するための手段であって、DevOps自体が目的ではないことを肝に銘じておこう。
現状認識とあるべき姿に向け、組織内で連携・協調する
何のために行うのか、認識を合わせた後は、現状認識とあるべき姿に向け、組織内で連携・協調する。これは以下のステップを実施することで、達成できる。
- バリューストリーム・マップを描く：
バリューストリーム・マップとは、トヨタ生産方式における手法で、特定の製品が原材料の加工から顧客の手に渡るまでの全工程の経路と、各工程がどこからの指示で実施されるのかを示したものである。製品開発であれば、組織内で発生する情報や成果物の流れを示す。 - バリューストリーム・マップから制約（ムダ、ボトルネック）を見つける：
バリューストリーム・マップから、時間が費やされている箇所やボトルネックになっている箇所などの制約を見つけ出す。このとき、「これは仕方がない」「これは排除できない」といった考えは捨てること。 - 見つけた制約（ムダ、ボトルネック）を取り除く：
このとき、見つけた制約（ムダ、ボトルネック）を取り除くスケジュールや目標に向かっているかを確認するメトリクスも決めること。 - 1～3を繰り返し、継続的にカイゼンのプロセスを回す
作ったパンは全て売れるパン屋さんを例にして、上記の4ステップを説明しよう。
- 何のために行うのか組織内で認識を合わせる：
1日8時間の業務時間で毎日焼き立てのパンの売上を今よりも上げる。 - バリューストリーム・マップを描く：
「生地を作る」のに1人で30個／2時間、「パンを焼く」のに1人で15個／1時間、「パンを販売する」のに1人で1個／3分、店員は3人であることが分かった。 - バリューストリーム・マップから制約（ムダ、ボトルネック）を見つける：
生地は90個／日、焼き上げは75個／日、販売は100個／日なので、「パンを焼く」部分がボトルネックであると分かる。この数値は図3のように計算した結果だ。 - 見つけた制約（ムダ、ボトルネック）を取り除く：
1時間に25個焼けるようにオーブンを買い替える。「パンを焼く」のが1人で25個／1時間になったので、生地は90個／日、焼き上げは125個／日、販売は100個／日になった（計算方法は図4の上を参照）。 - 1～3を繰り返し、継続的に改善のプロセスを回す：
今後は「生地を作る」部分がボトルネックになる。パンが焼きあがるまでパンの販売は手が空いているので、生地を作るのを手伝うことで、最初の2時間は「生地を作る」のが1.5倍の45個／2時間にカイゼンできる（図4の下）。
すると次のボトルネックは……以下繰り返す。
以下に計算方法のヒントとして補足説明を箇条書きで記す。
【生地の作成】
・1日の業務時間＝8時間
・1サイクル分の生産能力＝30個
・サイクル時間＝2時間
・サイクル可能回数＝3回＝（1日の業務時間［8］－最後の「生地の作成」サイクル時間は生地を作っても売れない［2］）÷サイクル時間［2］
※1日の生産能力＝90個＝1サイクル分の生産能力［30］×サイクル回数［3］
【パンを焼く】
・1サイクル分の生産能力＝15個
・サイクル時間＝1時間
・サイクル可能回数＝5回＝（1日の業務時間［8］－最初の「生地の作成」サイクル時間は生地がないので焼けない［2］－最後の「パンを焼く」サイクル時間はパンを焼いても売れない［1］）÷サイクル時間［1］
※1日の生産能力＝75個＝1サイクル分の生産能力［15］×サイクル回数［5］
【パンを販売】
・1サイクル分の生産能力＝1個
・サイクル時間＝3分＝0.05時間
・サイクル可能回数＝100回＝（1日の業務時間［8］－最初の「生地の作成」サイクル時間はパンがないので売れない［2］－最初の「パンを焼く」サイクル時間はパンがないので売れない［1］）÷サイクル時間［0.05］
※1日の生産能力＝100個＝1サイクル分の生産能力［1］×サイクル回数［100］
「パンを焼く」部分のボトルネックをカイゼン
「生地を作る」部分のボトルネックをカイゼン
以下に計算方法のヒントとして補足説明を箇条書きで記す。
【生地の作成】
・1日の業務時間＝8時間
・1サイクル分の生産能力＝30個（※最初の2時間は2人で1.5倍の「45個」とする）
・サイクル時間＝2時間
・サイクル可能回数＝3回＝（1日の業務時間［8］－最後の「生地の作成」サイクル時間は生地を作っても売れない［1］）÷サイクル時間［2］
※1日の生産能力＝105個＝（最初の2時間：1サイクル分の生産能力［45］×サイクル回数［1］）＋（残りの時間：1サイクル分の生産能力［30］×サイクル回数［2］）
【パンを焼く】
・1サイクル分の生産能力＝25個
・サイクル時間＝1時間
・サイクル可能回数＝5回＝（1日の業務時間［8］－最初の「生地の作成」サイクル時間は生地がないので焼けない［2］－最後の「パンを焼く」サイクル時間はパンを焼いても売れない［1］）÷サイクル時間［1］
※1日の生産能力＝125個＝1サイクル分の生産能力［25］×サイクル回数［5］
【パンを販売】
・1サイクル分の生産能力＝1個
・サイクル時間＝3分＝0.05時間
・サイクル可能回数＝100回＝（1日の業務時間［8］－最初の「生地の作成」サイクル時間はパンがないので売れない［2］－最初の「パンを焼く」サイクル時間はパンがないので売れない［1］）÷サイクル時間［0.05］
※1日の生産能力＝100個＝1サイクル分の生産能力［1］×サイクル回数［100］
開発プロセスに依存しない説明として、パン屋さんを例として説明した。大事なことなので何度も繰り返すが、この例で示したようにDevOpsとは、より早くビジネスの価値を高め、エンドユーザーに届け続けるために行う、文化の変化を伴うカイゼン活動であり、人でも、役割でも、役職でも、プラクティスでもないのである。
■
以上、DevOpsの定義を説明し、現場への適用に関するアドバイスを紹介した。DevOpsについてさらに詳しく理解するには、続けて筆者の連載「ALM Essentials」の「第1回： ALMとDevOpsとリーンスタートアップは何が違うのか？」もぜひ一読してみてほしい。
