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

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

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

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

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

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

なぜモブプロなのか

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2019年に訪問した海外の現場の話を報告します！

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

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

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

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

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

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