DevOpsには技術的な側面だけでなく、開発や運用をはじめとするさまざまな部門を繋げる組織文化を構築するという重要な側面があります。 つまり単にDevOpsツールなるものを導入したりアジャイルなプロセスを導入すれば良いというわけではありません。

本セッションでは、主にDevOpsの文化的な事柄に着目し、異なるゴールを持つチームが親和性を高め、矛盾する目標のバランスを取りながら最大限の力を発揮する方法を説明します。

データ分析基盤の開発・運用において、サーバーレスやイベントドリブンなど新しいアーキテクチャを採用して、運用負荷の低減と機能開発への集中を行った事例をお話します。

リクルートライフスタイルでは、じゃらん、ホットペッパーをはじめ、大小30以上のサービスを展開しています。
データプラットフォームチームではすべてのサービスのデータが集まる分析基盤を有しており、サービス/ユーザーの分析のために無くてはならない存在となっています。そのためデータ分析基盤も、より高度な分析のための機能開発や安定的な運用が求められています。

データ分析基盤のワークロードは安定運用、データ品質の確保、データ開発、ユーザビリティ向上など、一般的なアプリケーションとはかなり異なります。
さらにデータ量は年々指数関数的に増加しており、運用にかかる負荷も増加しています。

そこで運用工数の増加率を限りなく抑えるため、イベントドリブン+サーバーレスという手段を取りました。
しかしこのアーキテクチャは、管理するサーバがなくなる代わりに従来のシステムとは異なる観点で運用を設計する必要がありました。

サーバーレスなど新しいシステム、従来のシステムが入り交じるカオスな状況で、私たちのシステムのDevOpsのプラクティスはどう変わっていったのか、現場目線でお伝えします。

AWSのCodeシリーズを利用してサーバーの管理を不要にしたフルマネージドな環境で、DockerコンテナのフルマネージドなオーケストレーションであるAWS Fargateへの継続的デリバリーをどのように実現するかをデモを交えながら解説します。

私達楽天のEmailサービスチームは開発と運用を同じメンバーで行っています。
DevOpsにおいて開発からリリースまでのプロセスは開発者から高い関心が寄せられており知見も十分に集まっている印象です。
一方サービス運用に対して有効なプラクティスやツールの活用事例を耳にする機会はあまり多くなく私にとってはは試行錯誤が多い領域でした。
どのようにすれば、リリース後にサービスを安定稼働させ稼働実績から有益ななフィードバックを得ることができるでしょうか？
本セッションでは私達のチームが過去〜現在において直面している課題とその解決へ向けた取り組みやプラクティスを紹介します。

過去２回のDevOpsDays Tokyoは、2017年1月末のシアトル訪問から始まりました。
Microsoftを訪問し、いくつかの多様性のある開発現場を見せていただき、英語での闊達な議論もしてきました。

今年のキーノートの Chap Alex さんもそこで出会った一人です。
彼はもともとテストの自動化の役職にいたわけではありません。
スカンクワークスで数年、チームになって３年くらい、今は30人のチームになったといっていました。

別のチームの人は、TFSというプロダクトを作っていましたが、
「ほら社内でこんなに使われるようになったんだよ」
と言っていました。計画経済のようにトップを説得して全体に使わせるなんてことはやっていませんでした。

さらに、そのチームは部屋を工夫し、チーム全員が一部屋に集まり、それでいてほかのチームとは共有しない部屋を作っていました。徐々にほかのプロダクトに広がっていると言っていました。

日本人エンジニアの河野通宗さんが言っていました。
「上司もエンジニアなので意思決定が速いです」
意思決定が速いと何がうれしいのですか？
「クラウドは常にどこかが壊れている。なのですぐに検知して直さなきゃいけない」

世の中がガラリと変わってしまう音が聞こえました。

もう開発者もデザイナーもマネジメントも経営陣も関係なく、リアルタイムに動き続ける世界を相手にして動かないといけない。途中の誰かがわからないから通訳してくれといえば、そこでリアルタイムから弾き出される。

テスト自動化だけ、チームビルディングだけ、上手なデリバリーだけ、得意ななにかをひたすら追いかけて、エンジニアのキャリアパスだけ考えて、残りはほかの人のせいにしておけばよい時代は終わってしまった。全体としていい仕組みを作った企業が生き残る。誰も安住できないグローバル競争をしたたかに生き残って時価総額を伸ばし続けるエンタープライズがシアトルに一つありました。競争している企業もいくつもあります。

私たちの DevOpsDays Tokyo そこから始まりました。

それから一年ちょっとがたちました。

世の中の何が変わったのか、そして、心境はどう変わったのか、ここからどうなっていくのか。

話し合ってみたいと思います。

上長に「お前は技術もマネジメントもビジネスも何も分からないクズ」と言われ、本当に自分が「技術もマネジメントもビジネスも何も分からないクズ」なのかどうかを確認しようと思い立った。

確認する方法としてテスト駆動開発(TDD)でお馴染みの三角測量(その人にはたまたまそう見えたということが起こらないように2つ以上の値を使用してテストをする)で確認することに思い至り、ちょうどタイミングよく運転資金が枯渇し閉店を余儀なくされた馴染みの飲食店とパン屋があったので、そこに自己資金を運転資金として投入し、自分の技術と知識と能力を使って閉店を免れられるのかどうかを確認した結果を紹介する。

Kubernetesはクラウドネーティブの世界における、事実上の標準としての地位を確立している、と言えます。Dockerを代表とするコンテナ技術をベースに、マイクロサービス型のアプリケーションを運用管理するフレームワークとして、Kubernetesは急激に利用者が増えています。
"Linux of the Cloud"とも呼ばれ、今後特定のクラウドに依存しないアプリケーションの開発／運用のOSSプラットホームとして成長していくことが期待されています。
発表者はCNCFのメンバーとして、当団体の様々な活動に参画しており、最近の動き、そして将来的にどのようなクラウドネーティブ技術が登場するのか、導入事例なども含め、報告します。

アジャイル開発センター発足から1年以上、DevOpsをもっと浸透させるための箱はできました。

実情としては、上手くいっているプロジェクトもあれば、改善が必要なプロジェクトも多々あります。

業務部門、事業部門と兼務した経験から見えてきた、「リリースサイクルを短くするためのDevOps」が浸透しない理由、

そして現在挑戦している対策等を共有したいと思います。

国立情報学研究所では、2010年からプライベートクラウドを構築・運用しており、その中で、2015年から「Literate Computing for Reproducible Infrastructure（以下、LC4RI）」と呼ぶ独自の実践を行っています。
LC4RIは、「Infrastructure as Code」をベースにする点で、他の良く知られたDevOpsにおける運用手法と似ていますが、IPythonの開発者F.Perezの「Literate Computing」から発想を得て、一連の作業の「物語」をNotebookで表現するという特徴を持ちます。
このセッションでは、LC4RIのツールとプラクティスについて紹介します。そのうちのいくつかは、皆さんに新しい知見をもたらすでしょう。