DevOpsとは何（ではないの）か、そしてどうやって実現するのか

原文(投稿日：2014/03/06)へのリンク

この記事では、DevOpsにまつわる誤解をいくつか議論し、文化の変化をもたらすことができるプロセスの序論を示す。その文化の変化こそがDevOpsのすべてなのである。

「いや、あなたはDevOpsエンジニアではない」と題した記事で、Mike Kavis （Cloud Technology PartnersのVP兼主任アーキテクト）は、DevOpsにまつわる誤解のいくつかに言及している。たとえば、彼が言うには、DevOpsという用語を間違って使っているチームがある。

企業はDevOpsに取り組もうとしている。それらの企業の多くはDevOpsが何なのかを知らないが、それでもみなDevOpsを求めている。あちこちで、インフラチームが自分たちをDevOpsと呼び、草の根活動を主導しているのを見たことがある。開発チームはいないのかと尋ねると、しばしば彼らは次のどちらかの答えを返す。「彼らは呼ばなかった」か、もっと悪い場合は「彼らとは話をしたことがない」である。

自分自身をDevOpsだと宣伝するエンジニアもいるが、Kavisによれば彼らはDevOpsではない。なぜなら「DevOpsとは、人でも、役割でも、役職でもない」からだ。DevOpsエンジニアはどこにもいない。たとえ自分自身をそう呼ぶ人がいたとしても。DevOpsが役割でも資格でも役職でもないとすれば、DevOpsとは何なのか？Kavisの定義は以下の通りである。

DevOpsとは文化の変化または運動であり、素晴らしいコミュニケーションとコラボレーション（チームワークとも呼ぶ）を奨励することで、より良い品質のソフトウェアをより確実で迅速に構築することを促進するものである。

詳しい説明は以下の通りである。

DevOpsとはウォーターフォールからアジャイルやリーンへ移行するソフトウェア開発ライフサイクル（SDLC）の進化である。DevOpsはアジャイルをさらに推し進め、SDLCからムダを取り除くことに焦点を当てている。多くの場合、ムダやボトルネックは次の形で発見される。一貫性のない環境。手動のビルドおよび展開プロセス。品質やテスト技法の低さ。IT部署間のコミュニケーションと理解の欠如。頻繁な停止とSLA違反。そして貴重なITリソースを要求する一連の問題点によって、重要な時間や金がシステムの稼働を維持することに費やされる。…

他に見た頻出パターンは、“DevOps”チームの最初のステップとして、ChefやPuppet（またはSaltとかAnsibleや、話題のものならなんでも）の利用を検討することが多いということである。彼らは解決するべき問題を定義していないにもかかわらず、それらを解決するためのツールを手にしている。多くの場合、こういうチームは数千行のスクリプトを構築する羽目になり、次のような悩みが生じる。「我々はChefスクリプトを書くのが仕事なのか？市場により速く到達するのを、もっと高品質でもっと確実なものにするのが仕事ではないのか？」こういうチームにありがちなこととして、コーディングによって独自スクリプトの山々に追い込まれ、実際にはもっと多くのムダをシステムに追加してしまう。そうではなく、システムからムダを取り除くこと、それこそがすべてのDevOpsムーブメントの背後にある原動力なのである。

DevOpsの意味するものが文化の変化であり、製品開発に関与する様々なチーム間のより良いコミュニケーションとコラボレーションを実現することなのだとすれば、次に浮かぶ疑問は、ではどうすればよいのかである。どうすればそのような変化を我々の会社にもたらすことができるのだろうか？

DTO Solutions の共同創設者、Damon Edwardsは、 DevOps Days Mountain View 2013の基調講演「DevOpsの変換を開始する方法」で、DevOpsの文化を組織に導入するために推奨する3ステップのプロセスを提示した。

1. 「何のために？」を固める

Edwardsによると、組織のメンバーが、自分たちの存在理由について明確に理解することから始めることが重要である。何を達成しようとしているのか、そして目的は何なのか。その理由を知るためには、組織内の人々と交流し、自分たちが存在する理由を尋ねるだけでもいいかもしれない。組織の主な目的こそがDevOps文化を実現する唯一の理由で、他には存在しない。

DevOpsとは目的を達成する手段にすぎず、それ自体が目的ではないとEdwardsは考えている。「DevOpsはあなたの動機ではないし、同僚の動機でもない。きっとあなたのビジネスの動機でもないはずだ。」彼はDevOpsという単語をいったん忘れることすら提案している。注意してみると、彼は代わりにサービス・デリバリーという単語を使っている。なぜなら「我々はサービスを作るビジネスをしている」からだ。

2. 組織的な一致団結を固める

Edwardsが説明するプロセスの次のステップは、組織全体を一致団結させることである。そうすることで、誰もが「前提条件やルールをまとめて共有し、共通の目標に向かって」働くようになる。組織が正しく一致団結している状態とは、複数の人に共通のゴールを設定したならば、各自の目的を達成するために同じ方法が選択されることを指す。同じ課題には同じ解決策を導ける状態、それこそが「組織的な一致団結の究極の夢」である。

このような団結を達成するためには、組織の中でDevOpsの未来像を作り上げる必要がある。しかしそれは、何かのプロセスを教えるだけでは実現できない。なぜなら、人は単に手順を機械的になぞろうとするものだからだ。必要なのは考え方を教えることである。Edwardsによれば、これは以下の手順に従うことによって達成することができる。

1. 基本的な概念を教える。たとえば、 「1個流し、バッチ生産、仕掛り制限、プッシュ型とプル型、継続的デリバリー」といったものや、使用されるツールなど。組織内で共有される共通語彙を構成するような概念である。
2. 全員の認識を合わせる。
   A. バリューストリーム・マッピング - リーンのコンセプトで、組織内で起こる情報や成果物の流れを明らかにし、価値創造につなげること。
   B. タイムライン分析 - 時間が費やされている箇所やボトルネックの箇所を発見しようとする試み。
   C. ムダ分析 - 組織が生み出すムダを徹底的に調べ上げて、それらをできる限り取り除くこと。
3. 見える化の連鎖を作り出す。価値提供の連鎖にまたがる活動や、自分の活動が他者の活動にどのような影響を与えているかをを測定するということ。
4. ベースラインに反するプロジェクト/実験を特定する。ベースラインから逸脱しているプロジェクトや活動を特定し、是正措置を取る。
5. 手順2・を繰り返す。それが継続的改善のプロセスである。
・

これらのアイディアを実行に移すために、Edwardsは3日間のプログラムを提案している。

• 1日目 - 原則を教え、ケーススタディやパターン／アンチパターンを提示する
• 2日目 - 組織の現在の状態を分析し、問題を特定する技術やカイゼンの指標を提供する
• 3日目 - 解決策やツールチェーンの自動化主義について議論し、ロードマップを構築する

3. 継続的な改善の繰り返し

継続的にプロセスを改善するために以下を繰り返す。すなわち、計画の立案、計画の実施、成果の測定、継続指針の決定である。

先日、EdwardsはQCon London 2014のセッション中にこれらの原則を提示した。「DevOpsの成功のためのDev “プログラミング” Ops」というセッションは、InfoQで後日公開されることになっている。