DevOpsの本質はツールではなく考え方と実践――国内での普及を目指すDevOpsハッカソンの狙いと実態：リリースサイクルを改善し、ビジネス価値を生み出していく

日本マイクロソフトは9月5日、6日、DevOpsの本質を知るためのハッカソン「DevOpsハッカソン」を開催。本稿では、同ハッカソンを企画し、国内におけるDevOpsの普及に力を注ぐ、米マイクロソフト シニア テクニカル エバンジェリスト DevOpsの牛尾剛氏に「DevOpsの本質とは何か」についてあらためて話を聞き、ハッカソン当日の模様をリポートする。

[PR／＠IT]

PR

　国内でも普及が始まりつつあるDevOps。だが、明確な定義がないこともあり、捉えどころがない側面もある。そんな中、日本マイクロソフトは9月5日、6日、DevOpsの本質を知るためのハッカソン「DevOpsハッカソン」を開催。米マイクロソフトのDevOpsチームリーダーDavid Tesar氏を中心に、DevOpsの考え方や手法を紹介した。

　本稿では、同ハッカソンを企画し、国内におけるDevOpsの普及に力を注ぐ、米マイクロソフト シニア テクニカル エバンジェリスト DevOpsの牛尾剛氏に「DevOpsの本質とは何か」についてあらためて話を聞き、ハッカソン当日の模様をリポートする。

DevOpsハッカソン2日目、成果発表前の追い込み時期の様子（日本マイクロソフトセミナールーム）

DevOpsはツールよりも考え方と手法こそが重要

　「DevOpsをエンタープライズ分野にも適用していこう」という機運が高まっている。米国では業種、領域を問わずDevOpsを適用する動きが進んでおり、国内でもそれを受けて取り組みを進める企業が増えている。だが牛尾氏によると「国内の状況を見ると、ツールの導入が先行するあまり、DevOpsの本質が見落とされがちだ」という。

米マイクロソフト シニア テクニカル エバンジェリスト DevOps 牛尾剛氏

　「ツールをどう利用するかはDevOpsの取り組みに欠かせない要素の一つです。ただ、それよりも重要なのは、DevOpsにどういった考えで取り組めばいいのか、どのような手法や方法論を実践すればいいのかといった、マインドセットやプラクティスです。その本質の部分をよく理解していれば、むしろツールは何でもよく、OSS（オープンソースソフトウエア）であれ、商用製品であれ、好きなものを使えばいいのです」（牛尾氏）

　牛尾氏は、OSS畑出身の開発エンジニアだ。2001年ごろからアジャイルコミュニティのエバンジェリストとして大手企業からスタートアップに対してアジャイルやDevOpsの導入支援を行ってきた。2015年8月に米マイクロソフトのDevOpsテクニカルワーキンググループメンバーとして、日本国内でのDevOps普及に力を注いでいる。

　マイクロソフトのDevOpsと言うと、どのようなソリューションやツールが提供されているのか、すぐに思いつかない方も少なくないはず。だが同社は、OSSへの積極的な関与やクラウドサービスの拡充し、DevOpsを進めるためのツールや基盤を整えてきている。

　「マイクロソフトは素晴らしいツールをたくさん持ってはいるのですが、DevOpsではツールありきのソリューション提供に力を入れてはいません。むしろDevOpsの考え方や手法を整理し、それを紹介する過程で、もしツールとしてフィットするならぜひ使ってくださいという立場をとっています」と牛尾氏。

ソフトウエア開発の歴史から見るDevOps

　DevOpsの本質が見落とされがちなもう一つの要因として牛尾氏は次のように主張する。「国内は、米国のように、エンタープライズ環境でもアジャイル型開発を積極的に採用するような環境ではないことも大きい。ウオーターフォール型開発に起因する課題への対応など、歴史的な背景を抑えつつ、DevOpsの本質を理解していく必要があります」

　加えて牛尾氏は、DevOpsの取り組みについて「大きな目的は、リリースサイクルを改善し、ビジネス価値を生み出していくことだと考えられます。そのためには、ビジネスプロセスを含めてムダを発見し、改善していくことが求められます」と補足する。

非効率な世界（講演資料より）

　このことは、ソフトウエア開発の歴史を振り返ると理解しやすいという。まず、リリースサイクルの改善にフォーカスした場合、「早く」「頻繁に」「安全に」という三つの要素がポイントになる。この三つの要素にうまく対応できればリリースサイクルの改善は進むが、逆に、対応できなければ課題として立ちはだかる。

　エンタープライズ環境での一般的な開発では、「要求」「分析・設計」「開発」「テスト」というフェーズで作業が進む。リリースサイクルは1〜2年、早くて半年だ。ここで、リリースサイクルを1カ月程度に「早く」しようとするとどうなるか。具体的には、アジャイルの手法を取り入れて、動くソフトウエアを2週間で作成したとする。ところが、製品のデプロイやリリースが2週間でできるかというと必ずしもそうはならない。

　「“エンドゲーム”が発生するからです。例えば、製品の出荷前に必ず負荷テストや品質保証などを行うプロセスが入ります。2週間で開発できても、最後のエンドゲームが数カ月続きます。そうなると、リリースサイクルはアジャイル導入前と変わらないわけです」（牛尾氏）

　これに対処する工夫として考え出されたのが、システムテストや品質保証を前倒しして、開発段階に組み込んでいく方法だ。負荷テストやシステムテストを最初から「頻繁に」行うようにし、自動化を取り入れながら「安全に」エンドゲームの作業を各スプリントに分散していく。これでうまくデプロイできるかなと思ってはみたものの、実際にはできないことが多いという。

　「“インフラの引き渡し”があるからです。ドキュメントを整備し、ユーザーマニュアルをそろえ、レクチャーや操作教育を行って、サポートする必要がある。技術的な問題でない分、エンジニアだけで解決はできません。アジャイルコンサルタントの仕事をしていたとき、最も難しかったのはこの部分への対応でした」（牛尾氏）

　牛尾氏の考えでは、DevOpsはこの課題に対応する中で生まれてきたものだ。アジャイルの取り組みが深まると同時に、インフラ自動化技術と、Webオペレーションの技術が成熟し、その中から、インフラをコードとして扱うInfrastructure as Codeをはじめとする考え方が整理されていったという。

　また牛尾氏によると、DevOpsは特定の領域に限った話ではなく、全ての領域で適用できる。例えば、「DevOpsは、顧客とのエンゲージメントを作るフロント側のシステムに向いている」「安定稼働が求められる基幹システムではDevOpsを適用すべきではない」といった意見も国内では散見される。だが、牛尾氏によると、こうした考えは「まったくナンセンスであり、むしろ捨て去るべき」ものだと話す。

　「どのドメインかどうかは関係がありません。原則と考え方を理解して、ここに使ったら成果が上がるのではないかというところに適用していけばいいのです。DevOpsの取り組みで使われるテストの自動化などの考え方は、これからのソフトウエア開発の標準になるものです。Infrastructure as Codeや構成管理という考え方は基幹システムにも同じように適用できます。基幹システムのリリースが早く、安定することで困る人は誰もいないのです」（牛尾氏）

マイクロソフトが考えるDevOpsの実現方法

　マイクロソフトが具体的なDevOpsの取り組みとして提案しているのが、「People（人）」「Process（プロセス）」「Products（ツール）」の三つの「P」に着目し、取り組みを進めるものだ。

　「明日から変えるというのは簡単ではありません。ツールだけではなく、人やプロセスという要素に注目しながら、課題に対応していきます。課題としては、コミュニケーションやビジネスプロセスの違いなどから生じる“ストレス”、作業の“遅れ”、取り組みの対象が広範囲にわたり“中身が分からないこと”の三つが代表的でしょう」（牛尾氏）

　こうした課題に対応しやすくするため、マイクロソフトでは「DevOpsの成熟度評価」を体系化し、顧客に提供している。成熟度評価は、以下の七つの項目から構成されている。

DevOpsの成熟度評価（講演資料より）

　例えば、バックログとは、「企業がどれだけ上手に要求を管理し表現できるか」を計る項目だ。また、フローとは、「開発環境から本番環境への流れ、どれだけソフトウエアがビジネス価値を提供できたか」を計る項目だ。これら7項目を顧客の環境に当てはめながら、どのような手法とツールを適用していくのが望ましいかをアセスメントしていくことになる。

　「利害関係があるいろいろな部署との共同した取り組みになります。むしろ協力しないと絶対に実現できません。その意味では、経営者がコミットする形で取り組みを進めることもポイントです。DevOpsのメリットはさまざまに指摘されていますが、私の肌感覚でも相当に破壊的です。今の技術を使ってビジネスプロセスを改善することは、企業に大きな価値をもたらすことは確かです」（牛尾氏）

珍しいDevOpsのハッカソンだったが、大盛り上がり

　こうしたDevOpsの考え方と手法を実際に学べるものとして9月5日、6日に開催されたハッカソンは、インフラ技術者と開発者で構成される6チーム33人が参加する盛況なものとなった。

　牛尾氏に加えて、日本マイクロソフト シニア テクニカル エバンジェリストの寺田佳央氏や米マイクロソフト DevOps シニア テクニカル エバンジェリストのDavid Tesar氏なども講師、審査員として参加。Tesar氏はハッカソンの最初に、マイクロソフトが重視するDevOpsの考え方や手法、マイクロソフトがDevOpsを実践するために提供するツールなどについて講演し、ハッカソンの主旨を説明した。

プレゼンテーション時の様子（右手前で参加者の話を聞くTesar氏）

　ハッカソンの条件としては、Infrastructure as Codeと別のDevOps手法（自動テスト、デプロイ、監視など）一つ以上をアプリに実装しなければならないとなっている。その上で審査のポイントとしては、「クリエイティブなソリューションかどうか」「他のユーザーが再利用できるものであるかどうか」「どのようなDevOps手法を実装したか」の三つが挙げられた。

　さまざまな実装が試みられ、最後に6チームがプレゼンテーションを7分ずつ行い、ハッカソンの成果を披露した。審査の結果、優勝したのはチームナンバー「6」。このチームはクラスター管理ツールのApache Mesos（以下、Mesos）とVisual Studio Online（以下、VSO）を用いた継続的インテグレーションとデプロイ環境の構築を目標とした。インフラ技術者側は、ChefでMesos環境、Microsoft Azureのインフラ、VSOでDockerイメージを構築する環境の三つを一から作成。VSOのGitコミットを使ってMesosにデプロイしたという。

チームナンバー「6」のプレゼンテーションに真剣に聞き入る審査員陣

　開発者側はASP.NET 5アプリケーションをDockerイメージにし、Microsoft Azure上で動かしMesosに渡すことを目指した。最初はVisual StudioからDockerに直接デプロイすることを目指したが、ASP.NET 5がベータ版であるため、難しかった。続いていろいろなビルド環境の構築を試したが、ASP.NET 5のコードはサーバーにデプロイするだけで動くことに気付き、ビルドしなくてもよいということに。結局、ハッカソン終了の間際でコミットしたら自動でDockerイメージに含めるタスクを作成する方針になったが、途中でハッカソンが終了したという。

　Tesar氏は最後に「今日は楽しかったですか？」と聞くと会場からは拍手喝さい。次のように締めくくった。「開発者とインフラ技術者が共同で作業することは、会社ではなかなかできないと思いますので、良い機会になったのではないでしょうか。今日はありがとうございました」

　マイクロソフトは、今回のようなDevOpsハッカソンを10月24〜25日、11月12〜13日、12月9〜10日、さらにそれ以降も開催することを予定している。本稿でDevOps、そしてDevOpsのハッカソンに興味を持った読者は、下記で当日の詳細な様子を参照し、参加を検討してみてはいかがだろうか。

DevOps ハッカソン開催報告 (9/5〜6) ＆ 次回予告

直接の申し込みは以下から行える。

10月24日(土)〜25日(日)

　開発者はこちら

　インフラ技術者はこちら

11月12日(木)〜13日(金)

　開発者はこちら

　インフラ技術者はこちら

12月9日(水)〜10日(木)

　開発者はこちら

　インフラ技術者はこちら

ハッカソン終了後に参加者全員で記念撮影