【DevOps Enterprise 2015 参加レポート】第 1 回 - 米 Target 社の DevOps Journey

  • Article

10 月 19 日 ～ 21 日 San Francisco で開催された DevOps Enterprise 2015 (https://devopsenterprise.io/) に参加してきましたのでレポートをお届けしたいと思います。

DevOps Enterprise は DevOps や継続的デリバリを組織に導入している人がリーンの考えを自社のバリュー ストリームに持ち込むことを目的としているとあります。DevOps は Dev と Ops が協力してソフトウェア ライフサイクルを改善していく活動ですので、そこに、DevOps の元になっているLeanやAgileの考え方を応用してしていかにその改善をうまくやっていくかということを目的にしています。この改善のためにはマインドセットだったり、プラクティスだったり、テクノロジーだったり様々な要素が関係してきます。

私は DevOps の組織的な導入に興味があったのでこのイベントに参加しました。Gene Kim 氏がホストするイベントです。彼は Phoenix Project という海外では DevOps のバイブルになっている書籍を執筆した人物です。これは熱いですね!
余談ですが個人的に Gene Kim 氏と日本のDevOpsコミュニティについてもお話ししてきました。では是非お楽しみください!

全体的な総括

私は DevOps Enterprise に初参戦させていただきました。セッションは大まかに分類すると、DevOps の組織的導入にスポットを当てたものと、テクノロジーに焦点を当てたものがありました。
特にテクノロジーでは、マイクロ サービスが相当ホットなトピックでした。DevOps の楽しいところは、テクノロジーだけではなく、ホットな技術要素にも触れることができるところです!
その他の要素として多くの人がフォーカスしていたエリアとして、メトリクスがありました。はやり、マインドセットの転換が最も難しいところで、そのためにもメトリクスが活用されているという印象でした。Docker に関してよく言われるセキュリティに関する講演もいくつかありました。

DevOps 事例もさまざまなケースが紹介されていました。日本ではびっくりしてしまうような大手企業が DevOps に従来から取り組んでいて大変驚きました。

例えば、アメリカで 2 番目に大きなディスカウント系流通業の Target 社、フォーチュン 500 の保険業 USAA、クレジットの最大手の一つ CapitalOneやBank of America。彼らはまさにエンタープライズのど真ん中で、しかも最も導入が難しそうな企業です。
北米ではアジャイルの導入の時にあった大手企業だから無理だとか、金融・保険業だから無理だといわれたタイミングは過ぎているようです。

いくつかの事例では、組織の中のレガシー システムの扱いに関しても発表されていました。国際的な競争力を得るためには DevOps はまだ早いとか言ってられませんね。

今回の DevOps Enterpriseで、個人的なベスト プレゼンテーションを 2 つあげるとすると (Re)building an Engineering Culture: DevOps at Target - Heather Mickman & Ross Clanton | Target と、Immutable Awesomeness?: Where Containers Collide with SW Supply Chains - Joshua Corman & John Willis | Sonatype & Docker というセッションでした。それぞれ組織導入部門と、テクニカル部門という意味合いです。他にも興味深いセッションがたくさんありましたが、それをピックアップして数回の連載でお届けしたいと思います。

(Re)building an Engineering Culture: DevOps at Target

★資料 (スライド)
https://www.slideshare.net/hmmickman/rebuilding-an-engineering-culture-dev-opstgt?qid=ce0b1941-ea67-4de5-bc60-6533ce831dd8&v=qf1&b=&from_search=1

初日のキーノートにして、私が DevOps の組織導入に関して最も衝撃を受けたプレゼンテーションです。アメリカで 2 位に規模を誇るディスカウントリテーラーの Target 社が当初ウォータフォール開発を実施し、何もトップのサポートがない状態から、80 デプロイ/週の環境を作り上げた DevOps 導入事例です。

日本語で導入というと 1 回限りのイメージがありますが、北米では DevOps の導入は、「導入」ではなく、DevOps Journey といわれるようです。つまり旅の途中。彼らは DevOps Enterprise 2014 のキーノートだったようです。他のセッションも相当面白いのに彼らが 2 年連続でキーノートになるのはそれだけのものを持っているからだと思います。

彼ら のDevOps Journey は人、プロセス、技術の全ての面で全く隙がなく、地に足がついていて本当に素晴らしいストーリだと思いました。

DevOps 成熟度のフェーズ

彼らは”our phases of DevOps maturity”という名前で DevOps 導入の 4 つの段階を整理していました。

  1. Change agent(s): チェンジ エージェント
  2. Grass roots: 草の根活動
  3. Top down: トップダウン
  4. Scale: スケール

今でこそ、DevOps を導入して、実績として 30 の API、週に 80 回のデプロイ、月々 500 万のボリューム、それなのにインシデントが月に 10 個以下とのことです。
これがスタートアップならわかるのですが、ウォータフォールで、大手で文化的にも導入が難しく、オフショアも実施しており、複雑なサイロがあり、尚且つレガシーもたくさん持っているという最高レベルに DevOps の導入が難しい地点からスタートされたようです。

当初の彼らにとっての課題は次のようなものでした

  • データ (データにレガシーはない)
  • マニュアル テスティング
  • ウォータフォール
  • 手を挙げろ! (hand ups)

この課題をどのように解決していったのかを深堀していきましょう。

Change agent(s): 変革をもたらす人々

DevOps やアジャイルの導入は、単なるツールの導入だけではありません。新しい考え方を導入することでもあります。個人的に講演後に Ross さんに話を聞いてみましたが、彼らにとって最も難しいのは「マインドセットを変えること」だったとおっしゃっておられました。

彼らはアジャイル開発の導入から初めて、Chef、GitHub、Cassandra といった新しいテクノロジーを徐々に導入していき、それに伴い、会社のルールもシンプルにしていったそうです。
Change agent つまり変革をもたらす人は、どうやって見つけたらよいでしょうか? それは、パッションを持っていたり、ビジョンがあったり、忍耐強さを持っていたり、現状維持を打ち破ってリスクをとる覚悟を持っている人だったり、コミュニティの中で活発に活動することをしていたりします。そういう点に着目して注意深く観察すると見つけることができるかもしれません。

また、かっこいい言葉でモチベーションするよりも、実績で周囲に説明していくことが大切とのことでした。

当初、彼らのテクノロジー文化を一から作り直す必要がありました。最初からトップからの十分なサポートが得られたわけではありませんでした。
しかし、パッションを持った技術者は組織のいろんなところに存在していました。チェンジ エージェントを見つけてコミュニケーションを取り始めた彼らは次にそれをムーブメントにする必要性を感じました。

Grassroots: 草の根活動

彼らはムーヴメントを起こすために次の活動を行いました。

  • #DevOpsDays
    社内DevOpsミニ カンファレンス
  • DevOps@TGT
    社内ソーシャル メディア サイト
  • automation demo spotlight
    オンラインの、デモやセッション、技術の共有など
  • automation make day
    四半期に一度のインフラ自動化ツールを使ってみるハッカソン

カンファレンスは、ゲストも呼ぶ豪華なものです。2014 年 2 月に始めたときは 160+ の参加者、37名のコミュニティ フォロワーでした。ところが 1 年後の 2015 年 2 月には 400+ に増え、コミュニティのフォロワーも 592 人になったようです。講演時にはこれが 975 人にまで増えていると言っていたような気がします (手元メモなので間違っているかもしれません)。

これら様々な努力で、サーバー構築のための時間が平均 174 日かかっていたものが 45 分短縮されたようです。これは劇的な効果ですね。こういった活動が順調になってきたので、さらにトップダウンアプローチを行うことにしたようです。

Top down: トップダウン

草の根活動をメイン ストリームの活動にするため、そして全社にスケールさせるため、彼らはトップダウン アプローチを仕掛けたようです。

課題を次のように設定しました。

  1. 戦略的にフォーカスするところを決定する
  2. ツールやメソドロジを継続的に新しくする
  3. AgileやDevOps のより高度な適用を行う
  4. 速度や変化やアジャイルさを増加させる
  5. 技術的負債を支払う

技術的なアプローチはどうだったかというと、次のようなものでした。

  • 単純化する
  • 100+ のプロジェクトをウォータフォールから、Scrum とか Kanban へ
  • 疎結合
  • API ベース、クラウド ベースのモダンなアーキテクチャ
  • 軽量なアーキテクチャ

(注：API ベースのアーキテクチャはDevOps を実施するときのトレンドのようで、他の発表でも多くみられました。レガシーも API でラップしてモダンなアーキテクチャと結合できるようにしていきます。これはマイクロ サービスの動向と合わせて大変興味深い動きですね。)

彼らはどのように技術的アプローチをすすめていったのでしょうか? 具体的には次のようなことのようです。

  1. 方向づけ、戦略的ロードマップ、チャーターの作成
  2. Agile/DevOpsムーブメントの統一
  3. Dojo (道場)

1. 方向づけ、戦略的ロードマップ、チャーターの作成

DevOps journeyが正しい方向に進んでいるかをThought Worksのmaturity modelを活用して確認しました。(Continuous Delivery maturity model: https://info.thoughtworks.com/rs/thoughtworks2/images/Continuous%20Delivery%20\_%20A%20Maturity%20Assessment%20ModelFINAL.pdf) 他に、DevOps とオートメーションに関してゴールと優先順位を設定しました。また、上位マネジメントのポートフォリオをそれらの KPI に結び付けるようにしたそうです。

彼らいわく、成功するためにはチャーターが必要で、例えば次のようなものを制定したとのことです。

  • 一つの分野に固執しない
  • 「他の家」を持っている人と仲良くなる
  • 期待しないことが起こることを期待する
  • 心地よくない状態でいることで、心地よくなる

　　マインドセットですね! 　

2. Agile/DevOpsムーブメントを統一

社内で、アジャイルやLean、DevOps のコミュニティが草の根活動により様々なところっで出来てきたので、それを統一して 1 つの活動にしたようです。

3. Dojo(道場)

組織の技術力の底上げのために、新しい技術に浸って技術力を向上できる場所を用意しました。
90 分のセッションのオープンラボ、フラッシュビルドと呼ばれる 1～3 日のイベント。チャレンジと呼ばれる DevOps/Agile/Lean の知識や、テスト駆動開発や Infrastructure as Code 等のエンジニアリング プラクティスを学べる場所です。
プロジェクトから定期的に Dojo に行くことが推奨されていて、技術的に困ったら道場に駆け込んでいたようです。

DevOps 道場の例 (Target 社の例ではありません): https://dzone.com/articles/devops-dojo-infrastructure

アドバイス

最後に今回のレポートを彼らの Takeaway (持ち帰ってほしいこと) でしめることにしましょう。

  • DevOps Jouney は 1000 マイルの旅 (始めるのを待たない、いいシューズと冒険のセンスが必要になってくる)
  • 学んだことを捨て去る勇気
  • 内部のチェンジ エージェントを応援しよう
  • passion + vision + inspiration
  • むっちゃ人を巻き込むこと
  • 技術イケメンから学ぶ
  • エイリアンコンセプトの仲良く
  • 分のゴートファームから始める
  • サイズは関係ない!
  • 我々はいまだ学んでいる、実験している。あなたのフィードバックを待っている

感想

本当に衝撃的なスピーチでした。どのような人でも大抵は「まだはやい」とか「うちは特殊」とかいってなかなか新しい旅を始めないものだと思います。ところが、彼らは他の大抵の会社よりもよっぽど難しい環境なのに、ステップを積み重ね、人、プロセス、ツールに対して改善を行い、週に 80 回デプロイできるまでの環境を作り上げました。
しかもそれが 1 つ限りのプロジェクトではなくて、持続性のある活動になっているところが何よりも素晴らしいと思いました。

私は DevOps エバンジェリストとして、そして DevOps コミュニティのメンバとして、このような会社が日本から沢山でてくるようなお手伝いが少しでもできればという思いを新たにしました。

私も英語力が凄いわけではありませんので、もし何か間違いを発見された場合は是非コメントくださればと思います。よろしくお願いいたします。

次回

次回は DevOps Enterprise 2015 のレポートの続きをお届けします。次はいくつかの発表のいいところをピックアップしていくつかお話ししていこうと思います。