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

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

自動運転、コネクティッドなどの技術革新にともない、自動車業界は今まさに「100年に1度のデジタル変革期」。これらに挑戦すべく、デンソーはアジャイル開発を2017年5月からはじめ、わずか半年でDevOpsを活用したデジタルトランスフォーメーションを成し遂げました。開発以外の無駄な作業はなくす、開発者が集中できる部屋づくりなど、開発者主体のスタイルに、メンバーからは「もう戻れない」と喜びの声が。本セッションでは、デンソーでのアジャイル開発方法と、アジャイル開発を支えるコネクティッドIoTプラットフォームについて紹介いたします。

Bing has been on a long journey to improve Agility, and along the way we have discovered that we have two distinct groups of users: the users of Bing, who want differentiated, relevant, and useful features, and the developers at Bing, who want a world-class development environment. Pleasing both sets of users has been a rewarding, complex challenge, and the goal line continues to move because the original dream of daily shipping quickly became status quo. In this talk, we will explore some of the philosophies and strategies that went into improving Agility at Bing as well as some of the optimizations we have made to keep it running at a very high scale.

The current environment of Continuous Disruption requires companies to transform how they work and how they engineer their products. Transformations are notoriously hard to execute, yet many companies have succeeded. What can we learn from them? Can we produce a blueprint for a transformation?

This presentation will cover several distinct approaches that companies take to achieve transformation. Each approach utilizes different levers and comes with its own advantages, tradeoffs, costs, risks, and outcomes.

LINEがDevOps・CI/CD・テスト自動化などの施策をなぜ推進しているのかを、

心（組織文化）・技（技術）・態（ビジネス指向）の3つの観点から、

具体的なプラクティス・事例と共に紹介します。

特にLINE初のSET（Software Engineer in Test）の立場から、

LINEがどのような取り組みを行っているのかを「見える化」します。

皆様の「Kaizen」のヒントになれば幸いです。

Does your product run on Linux, or attempt to and you struggle to find ways to keep up with building and/or testing? Let's explore the world of Docker and how it can help you quickly and easily accomplish these things on one system without the hassle of virtual machines. This talk assumes no prior knowledge of Docker so it will only cover basic scenarios.

Recruiting top talent is getting harder, and between firefighting, you have no time to learn new skills. Sometimes you forget that there is a world away from the toil.

The good news is that there is a better way — and it will make your life better. Be a trailblazer; a trailblazer for DevOps, your career, and yourself. Find the inner disruptor in both yourself and in your wider team, and start the process of changing how your company does things.

You can find quick wins, and we will tell you how Heroku can help you. Where you may need vendors and HR, you can reduce your dependence by integrating some of our tools and best practices into your tool kit.

Through it all, we will emphasize the benefit and importance of investing in yourself. You are going to find out what LifeOps is and how you are going to benefit both yourself and your employer by working less and learning more. After all — you can't be a trailblazer if you don't try to shake things up.

Coming soon...

DevOps is not just about technology, processes and practices. It's also about creating an organisation, where teams are empowered to enable them to deliver results early and continuously.

You can have frequent releases, use Jenkins for CI and still have a miserable culture. DevOps is of course about speed, rapid delivery and reliability - and additionally to that it's also about collaboration and culture. My talk focuses on creating and managing high-performing teams. Through a presentation of research and own experience I am providing an insight why do we need to create and manage teams based on

• “soft skills”,
• purpose,
• nurturing and
• strengths of the individuals.

Jan de Vries will share his experiences that he gained during the roll-out of DevOps in a large insurance company. During his presentation, the following topics will be covered:
- What were the reasons to start experimenting with DevOps? Or did we already start and didn't we realise?
- which obstacles occurred? And where they mostly technical or organisational?
- which discussions were necessary with management? And why did we re-scope several times?
- how did the organization become convinced of the benefits of DevOps? And who tends to benefits from what?
- what slowed down the implementation and how did we accelerate again? And what is the relationship with job security and common goals?
- which widely applicable lessons can be drawn from this example? And how do these relate to the Cuckoo Effect, Antifragility, the 4 colour backlog, liminality, the difference between Leading and Lagging indicators and Agile Leadership?

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

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

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

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

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

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

パブリッククラウドをつかっているからといってオンプレに比べて、システム運用の負荷が必ずしも減るわけではありません。

クラウドのマネージドサービス、サーバーレス、Dockerを始めとするコンテナ技術を組み合わせることで、クラウドを最大限活用、運用負荷の軽減することができます。そうすることでシステムのコアな部分の開発に集中することができます。

実際の事例を交えつつ、ワークロードや特性に合わせて、”マネージレス”なアーキテクチャを組む考え方について解説いたします。

Just because you're using public cloud does not mean that the effort required to run the system decreases.

By appropriately combining managed services, containers and serverless, you can more effectively utilize the potential of cloud, get fewer things to manage, and focus on the core of the system.

I will explain the basic ideas, anti-patterns and cases.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

DevOps ToolchainとしてのGitLabが目指す、これからのDevOpsツールのあるべき姿を紹介します。
GitLabは近年進化を遂げ、バージョン管理システムの機能だけに留まらず、Chatツールを代表とした開発ワークフローから、継続的インテグレーション(CI)、継続的デプロイメント(CD)、フィードバックまでの継続的デリバリを実装できる機能を提供しています。これは、数多く存在するDevOps Toolchainの選定コストを排除し、アプリケーション開発に集中できるプラットフォームを提供するための最善策とも言えます。
本セッションでは、実際にGitLabのCI/CD機能を使ったアプリケーションデプロイメントパイプラインのデモを交えて紹介します。さらに、最新版で強化されたDevSecOpsのセキュリティ機能やKubernetes上で展開するアプリの実装について、GitLabの魅力を最大限お伝えいたします。

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

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

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

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

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

DevOps tools and practices have traditionally been Linux-focused, which has presented a significant adoption hurdle in Windows-based organizations. Windows sysadmins rarely need to use a command line to do their job, let alone Ruby, Git, or other tools. Although tool vendors have tried to make “Windows versions” of their Linux tools, and Microsoft has tried adding “Linux features” to the Windows, many organizations still view DevOps as a square peg in a round hole.

To bring DevOps to Windows-based organizations, it’s important to not only understand the cultural differences between Windows and Linux, but learn how you can build a process that truly crosses development and operation silos, and doesn’t just become “the DevOps team”.

This is where "WinOps" comes in. WinOps strives to address the same challenges as DevOps, using different tools with a Windows approach.

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