This is the story of transforming Microsoft to using Azure DevOps and GitHub with a globally distributed 24x7x365 service on the public cloud. We’ll show you round the system that handles the load of some of the most demanding engineering teams in the world and share some stories about how they got there.

TBA

Ever had that: after a simple change, suddenly 50+ tests are failing! Brittle tests that hinge on GUI specifics and result in the dreaded NoSuchElementException are a main headache when testing with Selenium.

The open source project recheck offers a simple and elegant solution. Not only is a virtual identifier unaffected by UI changes, you can define it for otherwise hard to specify elements, i.e. that would require complex xpath or CSS selector expressions. And on top of that, tests are easier to create and maintain and yet much more complete in what they check. This talk gives a practical introduction to the underlying approach and the tool, complete with a life coding session.

Jeff Sutherland氏、Martin Fowler氏、Taichi Ohno氏。世界の業務プロセスに変革を導いた彼らは共通的に「カイゼン」について強調しました。

彼らの本を読みエンジニアとしての道を歩んできた私たちにとって、「カイゼン」は第一の価値として認識されていると思います。

皆さんは、今日より良い明日のために何に力を入れてますか？毎日が忙しすぎて、何かを改善するどころかストレスだけ溜まってたりはしてないでしょうか。

楽天のランキングサービスグループは開発と運用、いわばDevOpsを実践していますが、そのプロセスに対しいくつか問題を抱えていました。開発の段階で発生するボトルネック、効率的だとは言えない運用環境。

何よりも問題だったのは、こういったボトルネックにおいて改善の文化が定着しにくいということでした。せっかく良いアイデアを思いついても、そのボトルネックから発生するコストの問題で後回しにするしかなく、そうなればなるほどチームの改善力はどんどん下がっていきました。

私たちランキングチームは２つの解決策を決め、それを同時に進め相乗効果を発生させることでこの状況を乗り越えようとしました。

ランキングチームが挑戦したトライアルそしてテクニカルな変化によるチームカルチャーの変化。より安全で良いサービスの提供のために、日々工夫を重ねているあなたのために、私たちのお話を特別に公開します。

DevOpsという言葉の世界はますます拡がり、様々な○○Opsが生まれました。DevOpsDays Tokyoに集まったプロポーザルを見ても、たくさんのDevOpsがあることがわかります。定義を1つに統一する必要はないですが、自分の中のDevOpsを更新し続けることは大切だと思います。

そこで今回の朝まで生DevOpsは「結局DevOpsとはなんだったのか」をテーマに、定義の話を超えてDevOpsから我々は何を学ぶべきなのかについて考えていきたいと思います。

パネラーは随時追加していく予定です。
また、このパネルディスカッションは飛び込み参加可能なオープンパネルディスカッションです。

DevOpsを成功させるには、技術も文化も大切だと言われています。
今回は技術にフォーカスを当てます。その中でもチームが重要だと思ったCI/CDを導入し活用するまでの軌跡をお話します。

私達のチームは、自動車会社で社内向けのシステムを作っています。
1.5年前にできたチームだけあってインフラも貧弱で、とても良い開発環境とは言えませんでした。当然、インフラの知識も十分ではなかったです。その中で、一番やらないといけなと感じていたのがCI/CD。

ずっとやりたかったCICD
でも、難しそう、やり方がわからない等の理由で後回しにしてしまいました。

しかし、実際にやってみると意外と簡単。もっと早くやっておけば良かったと思いました。
実際のインフラ構成とどの様に構築してきたかを順を追って、ポイントをお話します。

時間があれば、デザイナーと協力して、コンポーネント化してリードタイムを短縮した話もするかもしれません
ラーメン二郎でDevOpsの話も

モブプログラミングとは...

「同じことを、同じ場所で、同じ時間に、同じコンピューターで」

私たちはモブプログラミング（以下モブプロ）を「デフォルトの働き方」として採用し、一年間ほとんどすべてのタスクをモブプロで実施してきました。
これら自分たちのチームのモブの実践と、様々なチーム、ときには海外でモブプロを経験し、その行動を観察するうち、モブプロを実践するときに共通して見られるいくつかの行動を発見しました。

なぜモブプロなのか

書籍「Effective DevOps」によると、DevOpsは４本の柱からなる文化であるとされます。
４本の柱とはすなわち、

- コミュニケーション
- アフィニティ
- ツール
- スケーリング

「同じことを、同じ場所で」全員で実施するモブプロは、開発チームのコミュニケーションを促進し、そして開発チームを超えてビジネスや運用チームとのアフィニティを高め、信頼を醸成する最良の手段の一つであると言えます。

実際に僕たちのチームでは、モブプロをきっかけにチームのコミュニケーションが改善され、いまでは自己組織化された機能横断的なチームを実現しています。

'効果的な' モブプログラミング

モブプログラミングは「全員で１つのことをやる」という性質から、
「効率的に働く」つまりリソース効率の最大化、単位時間あたりのアウトプット総量の最大化をめざすのではなく、
「効果的に働く」つまりフロー効率を最適化し、単位期間あたりの仕事の成果（Outcome）を最大化するための手段であると言えます。

自分たちのモブを観察するうち、成果を出せているときとそうでないときそれぞれに特定の共通した行動が見られることに気が付きました。

これらの行動のうち、良い影響を与えるものを増長し、悪い影響を与えるものを最小化するため、意図的にチーム内でのモブにおける役割を定義しました。
このロールの組み合わせによって、モブにおける「フォーメーション」あるいは「カタ」として名前をつけ、いくつかのカタログを作成しています。

本セッションでは僕たちのチームで発見したモブプロの「カタ」を紹介し、カタを通して効果的にモブプロを行う方法について議論します。

事業の成長、開発組織の成長においても、イテレーティブさを担保することは非常です。事業という不確実性の高いものをグロースさせる作業に対して小さく失敗しながら、イテレーティブ（反復）に施策をユーザーに提供していきます。

その施策を実行する組織として、どのように「小さく失敗するか」を考え、どうやって「失敗できる」環境を作り出せるかは、事業・組織双方の成長において欠かすことはできません。
実現するためには、事業戦略・データドリブン・組織文化といった幅広い部分に適応する視野を持ちつつ、ビジネスサイド、エンジニアサイドともに連携して、事業を一緒に作っていかなければいけません。

今回は、事業を作り出す開発組織においての「失敗」をどのように考え、実践しているのかを事例を交えながらお話していけたらと思います。

ドイツのポツダムで毎年開催されるAgile Tesing Days 2019に参加してきましたので、フィードバック会として参加者たちのパネルディスカッションを行いたいです。

海外カンファレンスの「フェス感」が伝えられることを最大のゴールにしてます！

今までウォーターフォール開発にQAとしてどっぷり浸かっていた私が、開発チームがアジャイル開発を始めた時の失敗談と、そこから得た学びを語りたいと思います。

どうすればチームが自走し、安定して組織が拡大するのでしょうか？

組織が大きくなっていくとチームの数も増えていくと思います。

DevOpsを実現できるチーム作りでは、自動化やCI/CDなどの基盤となる仕組みを作っていくところから始まります。

ではその仕組みは０から作るのでしょうか？それともうまく行っているチームを参考にするのでしょうか？

もし、チームが増えるごとに０から仕組みを作っていては基盤作りだけで何日も、へたをすれば何週間も使ってしまうでしょう。

もし、他のチームを参考にしたなら、自分たちのチームに使えそうな部分を探し出すのに膨大な時間を費やしてしまかもしれませんね。

私が所属する組織でも同じようなことが起きました。

いくつかのチームを調べた結果、原因となっていたのは各チームが作った「秘伝のタレ」でした。

私たちは秘伝のタレの製造を防ぐために、共通のエンジニアリング基盤を作りました。

この基盤によってチームは素早くプロダクトの開発に着手でき、自走できるようになりました。

本セッションでは、私の組織で実現した、チームの自走を助け、安定して組織が拡大することを実現するエンジニアリング基盤について紹介します。

私たちは、東京に本拠点がある企業向けの案件管理アプリ（iOS/Android）を沖縄のチームでリモート開発をしています。

エンドユーザーとプロダクトオーナーは東京、開発チームは沖縄という体制ですが、遠隔地での開発であっても素早くユーザーからのフィードバックを得てアプリの価値を高めていくために、GitHubやBitriseを組み合わせてモバイルアプリを迅速かつ正確にリリースすることができる仕組みを構築しています。

このセッションでは、東京と沖縄でのリモート開発においてどのようにコミュニケーション密度を上げているか、迅速かつ正確なリリースを行なうためにどのような仕組みを構築したか、またそれを実現することで得られる効果について紹介します。

ふくおかフィナンシャルグループ（FFG）では、2018年4月、DevOps・アジャイル開発を実践していくための組織が立ち上がりました。
昨今厳しいと言われる銀行業界でイノベーションを起こしていくための組織です。

2018年5月にゲーム会社から銀行へと異色の転職で入社以降、このアジャイル開発チームに携わってきました。

古くからある大きな企業でのアジャイル開発を進めていくには、技術的な面・組織的な面で非常に多くの問題が存在していました。
そもそも外注開発しかしたことのない組織が内製開発に取り組むということで、その問題の大きさは想像に難くないでしょう。
実際、前職とはかけ離れた環境やフローが存在し、多くのカルチャーショックにぶちあたってきました。

このセッションでは、そんな組織の中で、ゼロからアジャイル開発を進めてきた1年半の歴史を組織・技術的な観点から紹介していきたいと思います。
地銀という古い体制の組織・規制の厳しい金融業界、そんな世界でどういったようにアジャイル開発を行っているのか、少しでもみなさんの今後に役立つことができれば幸いです。

• アジャイル組織の変遷
• 開発の手法や技術的な取組
• 人財育成
• 既存や新規のルールに対する取組
• 拡大していく組織とチームの役割

　Kubernetesやコンテナ化を自社に推進したいと考えるエンジニアやアーキテクト、CTOの方も多いのではないでしょうか。
ところが、その推進が停まる理由の一つに「チーム内の技術スキルの差」が挙げられます。必ずしもチームの技術スキルレベルが一定である必要はないものの、複雑なKubernetes環境を運用していくためには、そのチーム体制や運用プロセスの変化が求められます。
　Kubernetesが一般化されていく中、これからのプロジェクト推進者は何を考えなければならないのでしょうか。Kubernetesを導入する現場で直面する、DevとOpsの新たな関わり方についての考察を紹介します。個別のチームだけでなく、業界全体で考えなければいけないKubernetes推進という大きなプロジェクトに対して、ともに考え、ともにつくることを目指したいと思います。

Value Stream Mapping ワークショップです。 Value Stream Mappingを使ったプロセスの見える化・カイゼン案の検討を実際に体験してみましょう。

Value Stream Mapping = ソフトウェア開発工程の流れ(価値の流れ)を見える化するために作成するプロセス図です。アイデアが生まれてから顧客に対して価値が届くまでの全行程を見える化することによって、ムダな作業や非効率なフローをチーム内で共有することができるようになるため、カイゼンに役立てることができます。

４、５人でグループを作ってグループワークを行います。Value Stream Mapping が描けるようになるだけではなく、チームで作った時の効果も感じられると思います。

Site Reliability Engineering の中核となる考え方に SLO - Service Level Objectives があります。これは信頼性を SLI - Service Level Indicator として計測し、目標値（Objective）を定め、それを下回った時のポリシーを決めることで、サービス開発の信頼性と機能開発の優先順位をつけることに役立ちます。しかしこれらを実現するには、信頼性とは何を指すのか、何を計測すべきなのか、そしてどのようにプロセスとして組織で取り組むべきなのかを考える必要があります。本発表では信頼性を計測する理由、考え方、具体的な実現方法を説明します。また、このプロセスを組織で取り組むことによってプロダクト開発の信頼性と速度にどう影響するのか、その実践例も説明します。

① チュートリアルの概要

テスト自動化において、テストコードの作成コストや保守性の悪化、テスト記述の可読性の悪さなどの問題が発生することがあります。この対処方法の一つがキーワード駆動テストです。本チュートリアルでは、自動テストの考え方とキーワード駆動テストの考え方について説明します。

定員は、最大で１５名です。

【問題 vs 私たち】で考えることが大事！というのは、DevOpsを進めているようなチームであれば当り前のことでしょう。
日々、立ち向かう【問題】を「どう解決するか？」ということに頭を悩ませ、チームでよりよい解決策を考えて改善活動を継続的に行っているかもしれません。

ところで、

立ち向かっている【問題】が、本当に今あなたのチームが立ち向かうべき【問題】か？
その【問題】が解決できた時にチームが辿り着けるゴールはなにか？

と考えたことはありますか？

• 【問題】に対して効果的なTry/Actionが出せない
• 【問題】に立ち向かい続ける改善のサイクルは回しているが終わりがみえない
• 立ち向かう【問題】が見当たらなくなってしまった

と悩んだことはありませんか？

様々なチームの支援を行っていると、次のような光景に出会うことがあります。

• 目についた【問題】と次々に戦い続けていて、チームがレベルアップした実感が持てずに改善疲れをしている
• まだチームで【問題】に立ち向かうプロセスが出来上がっていない段階でラスボスのような巨大な【問題】と戦って疲弊している
• 次に立ち向かうべき【問題】が見つけられず、改善活動やチームの成長が停滞している

こんな時は【問題】を「どう解決するか？」を考える前に、チームが立ち向かうべき【問題】が「なにか？」を見極めることが大切です。

DevOpsを進めるチームによくある【問題】を例に、【問題】を捉えなおすことによっておきる嬉しい変化についてお話します。

また、チームで【問題】に立ち向かうプロセスをどのように構築していくか？についても言及します。

あなたのチームが【問題】に立ち向かいながらレベルアップし、楽しく改善を進めていくヒントを持ち帰っていただければ嬉しいです。

改善疲れから抜け出し、チームが自信をもってレベルアップした！と実感できる活動にシフトしていきませんか？

より大規模なプロダクト開発を推進するにあたり、あるタイミングからチームのスケールアップを視野に入れることが必要とされてきます。

これに伴い、当初スタートアップとして勢いよく開発を開始したプロダクトも、組織のスケーラビリティに対応できるものに「変化」させていくことが必要と捉えています。

一方で、短期的なビジネス要求を実現するため、現在のチームの開発速度を大きく損なうことなく、片や裏では少しずつアーキテクチャを改良していく、という「バランス」の取り方はなかなか難しいと感じています。

本セッションでは、我々が開発するプロダクト「yamory」を成長させる上で直面したマイクロサービス導入、それに伴うインフラ含めたアーキテクチャ構築の生の事例について紹介します。

組織と共にプロダクトも成長させたい！けど糸口がつかめない・・・そんな方の助けとなれば幸いです。

ウォーターフォール開発がメインのNTTデータでDevOpsを推進するためにDevOps Transformationなる施策を立ち上げて、どのように活動してきたかを事例を交えてお話しします。

また、エンタープライズにおいてDevOps実践に向いている/向いていないプロジェクトは何かについても考察していきます。