We will open the DevOpsDays Tokyo conference by giving a brief introduction of DevOps, the purpose and goals of the conference, as well as giving some of the sponsors an opportunity to introduce themselves.

DevOps を始める最初のステップとして、大変有効なValue Stream Mappingの具体的な進め方について解説いたします。Value Stream Mappingによって、皆さんのプロジェクトの無駄や、自動化可能箇所を発見、共有することができ、リードタイムの削減に大変貢献いたします。特に日本で必要なステップやステークホルダの巻き込み方、ファシリテートの仕方まで踏み込んで解説いたします。

　講演者は、Value Stream Mapping を多数実施した経験そして、第一人者のMary Poppendieck との共演で学んだこと、他国の動向も含めて楽しく解説していきたいと思います。

チームの人数が少なすぎますとビルドとテストの時間が減ってしまいます。Progetを使えば簡単に数個のフィードを立て、社内でも社外でもNugetパケージを提供することができます。それによって、どのビルドがどうなっているかすぐ解ることができます。しかも、Nugetパケージ自体を使ってテストすれば、nuget.orgにそのままリリースできます。Couchbaseではこの方法を使って1週間おきにデベロッパー版を出すことができます。Progetを効果的に使いましょう！

If your team is too small, it can lead to time loss for build and testing . With Proget, you can set up several feeds and offer Nuget package builds both inside and outside the company.  Using this, it is easy to determine what is happening with every build.  Furthermore, if you test with the actual Nuget package, you can release it as-is to nuget.org.  At Couchbase, I use this process to release a developer build every other week.  Let's learn some ways to use Proget effectively!

DevOps represents a simple idea: increase collaboration across teams while automating processes. Although the concept is relatively new to Japan, American IT organizations have been trying to implement DevOps in recent years: many have found success, while others have seen failure.

One of main causes of failure is adopting the wrong culture. Although companies like Netflix and Etsy dominate the DevOps conversation, most enterprises do not have the same problems to solve, nor do they employee the same types of engineers. Thus simply, attempting to emulate Netflix will often yield failure.

It’s similar in Japan; the culture of Japanese IT organizations are quite different from western companies, and attempting to emulate western DevOps practices will often result in failure and other setbacks.  Thus, in order to be successful with adopting DevOps practices, those practices must first be adapted for Japan.

In this talk, I’ll compare and contrast the unique cultural differences in Japanese IT organizations and discuss how you can adopt DevOps practices that specifically address those.

既にDevOpsという言葉ができて9年になります。(https://en.wikipedia.org/wiki/DevOps) これまでに社内文化としての開発系の話、自動化の話、インフラの可搬性の話などが中心に話されてきました。しかしながら、運用を開始したら絶対に無視できない、インフラの可観測性、監視のベストプラクティスについてはあまり議論されてきませんでした。

Formula 1 を見ていても分かるように、どんなに素晴らしいマシンを開発しても勝てるとは限りません。ピット作業が速く確実なのは当たり前で。レースの勝敗は、一定期間続くそのレースををどのように走りきるかで決まります。逐次変わるマシンの状況や路面の状態をリアルタイムで計測し、ピットで常に可視化、レース展開の戦略にいかに活かすかではないでしょうか？

DevOpsのゴールは、企業としてのF1レースに勝つことではないでしょうか?今回のセッションでは、運用で勝つObservability文化について話したいと思います。

モノからコトへ。「作るシステム」から「使い続けるシステム」へ。昨今、顧客が求める価値に向かい、素早く継続的にサービスを提供しつづけるためには「リーンスタートアップ的な手法」や「DevOps」はかかせません。その一方で、クラウド技術の発展に希望を持ちつつも、従来型のアーキテクチャ設計は依然、事前の土台がためが必須です。「やりたいコト」と「用意しなければならないモノ」。この間に生じるズレや葛藤は、プロダクトオーナーの悩みの種となっています。

本セッションでは、私がこれまで支援してきた事例の中で、企画サイドや開発サイドがこの悩みに対しどのように動くべきだったのか、私なりのふりかえりを交えつつ、みなさんと考察を深めていきたいと思います。

Windows and Linux are very different; not just technologically, but philosophically. Tools are a major component to establishing DevOps, and the lack of Windows-centric tools limited early Windows DevOps adoptions as most initial supporting technologies emerged from Linux and open-source communities. WinOps strives to address the same challenges as DevOps, using different tools with a Windows approach.

This talk will be tool-focused, and give an overview of the major tools used in Windows DevOps environments.