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に参加してきましたので、フィードバック会として参加者たちのパネルディスカッションを行いたいです。

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

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

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

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

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

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

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

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

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

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

スクラムショーワークショップは、スクラムの説明をショー（寸劇）形式で行うワークショップです。
このワークショップを通じて、参加者はスクラムの基本を体験・学習できます。

スクラムショーワークショップは、yycr2019（アジャイルコーチとスクラムマスターの宴、通称：よなよなコーチングリトリート）で
生み出されたワークショップです。「短い時間でアジャイルを知るようにしてほしい」というニーズに応えるために、最大2時間でアジャイル・スクラムの理解を高められるワークショップをみんなで作りました。
会社の中で展開するために、できるだけ準備が少なく済ませたいという要望にも応えています。

最小100分間のワークショップで、スクラムの動きを身に着けられるほか、
皆さん自身で、スクラムショーワークショップを実践できるようになります。

紹介動画はこちらから！

詳細はこちらの記事をご参照ください。

Agile Testing Days で学んできた、DevOpsパイプラインゲームをやってみます！

DevOpsやアジャイルなんて当たり前、という組織もたくさんありますが、中には必要性を何となく認識しながらも未だ十分な取り組みにはつながっていなかったり、レガシーなやり方や組織の文化に阻まれて、なかなか浸透していない組織も多くあるのではないかと思います。

本セッションでは、社内にアジャイルを推進していく中で得られた気付きをもとに、組織がDevOpsを実現する上で何を考えたらよいか、DevOpsが組織に何をもたらすかを、いくつかの視点で考察していきます。

自分の組織の状況に合わせて、それぞれ違った気づきを得てもらえると嬉しいです。

MLOpsには、機械学習プロジェクトをより安定稼働させることが求められていると思います。そのためにあらゆるプロジェクトでモデルのデプロイ自動化やバージョン管理などが行われています。

ただ、モデルの品質を保つための必要十分条件はデプロイ自動化のみでしょうか。そもそも、モデルの品質を担保するのは学習データの質と量で、最初から完璧なデータセットを用意するのは不可能であったり、ユーザーの傾向が日々変わる中で常にデータセットをメンテナンスしていく必要があり、デプロイ自動化のみでそれが為されるわけではないはずです。

つまり、本来はサービスの中で予測に用いられたデータをモデルの学習につなげるサイクルを高速に何度も回せる仕組みがあるべきなのに、自分のプロジェクトも含め、多くの機械学習プロジェクトがなんらかの理由によってそこまでたどり着けていないもしくはその優先度が下がっているのではないかと考えられます。

実際、機械学習はそれ単体で成り立つものではなくソフトウェアの一部として組み込まれることで初めてユーザーに価値を届けることができるため、システムの中でそのサイクルを回せる仕組みを作っていくことは可能です。したがって、MLOpsは機械学習モデルをソフトウェアの一部として考え、モデルのデプロイ自動化やバージョン管理だけでなくシステムの中での学習データ作成の半自動化によって、ソフトウェアとして価値を届けることがあるべき姿なのではないかと考えています。

このセッションでは機械学習プロジェクトとMLOpsがこれからどうあるべきなのかを考え、自分たちのチームで取り組んでいる事例に基づいてお話します。

2010年頃から、バックエンドではJenkinsやMaven等を使ってそれまでの手順書やシェルスクリプトによるDevOpsから急速に進歩してきました。
それから10年が経過し、モバイル等の通信インフラストラクチャーの進歩、クラウドコンピューティング等、さまざまな進歩とともに、バックエンドだけではなくフロントエンドも大きな変化が起こりつづけていて、フロントエンドにおいてもDevOpsを実践していくことが求められてきています。
このセッションでは、フロントエンドにおけるDevOps実現に向けた活動についてお話します。