エムスリーさんと合同で、機械学習勉強会を開催しました
機械学習の開発及び、データ分析を行っています長谷川(@Hase8388)です。 先週の2/5にエムスリー株式会社さんの機械学習エンジニアの皆様と、合同で勉強会を開催しました。
テーマは、最近話題に上がることが多い『MLOps』。機械学習における開発、運用をする上でのハマりどころや、円滑にプロジェクトを進めるための知見についてです。
弊社からは、自社サービスの一角である、広告プロダクトにおける機械学習をどのように導入したかについて私(長谷川)が、また、同じく自社プロダクトで、従業員同士で感謝と給料を贈り合うHRサービスのUniposでのデータ分析及び、機械学習の活用について同じチームの水谷(@tenajima)が発表しました。
また、エムスリーさんからは、チームリーダーである西場正浩(@m_nishiba)さんと、AI・機械学習チームの河合俊典(@vaaaaanquish)さんにご登壇頂き、自社で開発されているOSSのgokartについて、開発に至った背景、運用方法、他のパイプラインフレームワークと比較したときのメリット・デメリットなどについて、開発者だからこそわかる知見を発表して頂きました。
登壇内容
gokartを作った話(M3: 西場さん)
最初は西場さんから。
gokartの開発に至った背景と、gokartが実際のプロダクトにおいて、どのような良さがあるのかについて発表していただきました。
gokartという『型』を提供することで、レビューとキャッチアップの負担を減らし、複数プロダクトを回す上での負担を少なくすることで、本質的な改善箇所に集中することができるというのは、機械学習チームが大きくなるにつれ、かなり大きなメリットとして活きてくるのではないかと思いました。
機械学習を無理なく広告システムに導入する(F81: 長谷川)
私(長谷川)の内容です。
広告配信システムにおいては、かなり速いレスポンス(最大でも20ms以内)が求められます。その条件下で、配信側のシステムを開発するエンジニアと齟齬なく協力しながら開発し、機械学習システムを運用する方法について発表しました。
gokartの運用と課題について(M3: 河合さん)
三番目は、エムスリーの河合さんから。 gokartのサポートしている(していない)部分から、様々な観点からみた際の強み、エムスリーさんにおける運用方法などについて発表して頂きました。 gokartの導入の検討から、実際の運用までフェイズごとに、さまざまな知見を得ることができる内容です。また、gokartだけでなく、周りをサポートするthunderboltなどさまざまなOSSライブラリもご紹介頂いており、gokartで開発・運用する際は、リファレンスとして、発表内容を改めて参照させて頂きたいです。
gokart導入のきっかけと運用の現状(F81: 水谷)
最後は、水谷の発表です。
Fringe81では、Uniposのデータ分析におけるのパイプライン構築において、gokartを積極的に採用させて頂いてます。実際に現場で使用するにおいて、どのような点でgokartの良さが活かされているのかについて、Luigi単体の場合と比較しつつ発表しました。
おわりに
懇親会では、弊社開催のイベントで定番になりつつあるまい泉のヒレカツサンドを片手に、参加者の皆様と一緒に、機械学習プロジェクトの難しさ、面白さについて意見を交換しあい、非常に盛り上がる事ができました。
イベント終了の直前、gokartのスター数がちょうど100(blog執筆時点では119)となり、全員で盛り上がりました⭐
UniposチームにおけるElmエンジニア達の成長環境
どうもみなさん、おはこんばんちは。Fringe81ソフトウェアエンジニアの泉です。
この記事はFringe81アドベントカレンダー2019の15日目の記事になります。私の方からはUniposチームに所属するElmエンジニアたちが、いかにしてオンボーディングし、そしてElmを学んでいるのかについてを簡単にお話させてください。
UniposとElm
弊社のプロダクトであるUniposではElmをそれなりの規模（現時点で5万行から7万行）でプロダクト開発言語として採用しています。これは現時点では日本国内ではほぼ最大です。
最初にUniposのフロントエンドがElmで書き始められてから、かれこれ2年近くが経ちました。開発初期と比べて、すくなからずElmそのもののプラクティスも変化し、そして0.19がリリースされるなど、UniposはElmとともに多くの変化の歩みを進めてきたと言えます。
Elmは一般的には言語仕様の小ささや、そもそもElmという言語がフロントエンド領域に閉じた言語であるという特性からも、さほど学習にかかる労力は大きくないという印象が強いです。 とはいえ、いきなりほったらかしでプロダクトのElmコードを書いてもらうよりも、少しづつでも基礎的な部分からElmに慣れ親しんでもらい、学習曲線の角度を無理なく上げていくのほうが理想的です。このような理由から、Fringe81では誰もがElmエンジニアとしてのステップを踏み出せるようになるためのラダーが用意されています。
というわけで、具体的にどのような取り組みが存在しているのかを紹介します。
Elmアカデミー
Fringe81の技術開発本部にはアカデミー制が存在しています。これはElmに限らずScalaやJavaScriptなどでも同様です。
プロダクトでElmを書き始めたい！という場合には、まずは社内にいるスペシャリストと呼ばれる人たちのメンタリングを受けながら、基礎的なElmの文法からSPAの開発までを学びます。最終的にCRUDができるSPAを完成させることができるまでがゴールです。もしWebpackやNode.jsなどElm以前の基礎的なツールチェインの知識がなければ、そこからの学習も行います。
ElmのSPAサンプルとしてあまりにも有名なものはRichard Feldmanのelm-spa-exampleかと思いますが、やはり初っ端からあのコードベースを読み解くのはかなりタフです。Elmアカデミーではそれよりも、より基礎に近い形でSPAを作ってみるという目標の達成に向かって取り組みます。
基本的には既存のメンバー／新卒問わず、まずはこのアカデミーから始まります。このアカデミーを終えるだけでも、ほぼ全員がある程度Elmをプロダクトレベルで書けるようになるまでの準備が整う形になります。
びわ会（Elmエンジニアたちの情報共有会）
Uniposチームでは半年ちょっと前から「びわ会」と呼ばれるElmエンジニアのための情報共有会を毎週30分間やっています。 もともとはもう少しミーティングの体をとる存在でしたが、そこから舵切りをして、よりウェットで柔軟な「楽しくElmに強くなれる会」という方針の時間としました。
びわ会ではフロントエンドでコードを書いているエンジニア全員が、チームのみんなに聞きたいこと、教えたいこと、話し合いたいこと、などを持ち寄ってそれぞれのトピックでワイワイしていく形になります。例えば、びわ会で話されたトピックは以下のようなものです。
- ビルド速度を50%カイゼンしたよ、のはなし - lazyの使いドコロ再確認 - ドメインモデルが共用になっているせいでモデルが歪んでいる件の共有 - ElmでのSVGの扱いについて - ViewModelsディレクトリの使い方、どんなものを入れるべきか？が曖昧なので定義したい！！ - CustomTypeを定義するときの注意点を発見したので共有
この会の運用として気をつけていることのひとつは、まずはみんなが「楽しいと思える」ようにするということです。年長者や技術のある人間だけが盛り上がるような排他的な会ではなく、もっとカジュアルに気軽に質問したり問題提起できるような、そんな場所です。
楽しくなければわざわざ会に来るモチベーションも沸かないし、みんなでElmを学ぼうという気持ちもなくなります。参加できる頭数が揃わなかったり、全体でリリース作業などの忙しさが見える場合には潔く会をスキップすることもあります。とにかく、みんながモチベーション高くいられる会であることが一番です。
初期の取り組みでは、NoRedInk社のエンジニアであるRichard Feldmanによるカンファレンスでのトーク動画をみんなで観てディスカッションする会を実施したりもしました。その際見たトークに関しては、私の個人ブログとなりますが以下の記事にてご紹介しています。興味があれば御覧ください。どれも実践的で有用なものばかりです。
まとめ
こんな感じでFringe81ではエンジニアたちがElmを学んでいます。ここ最近ではサーバーサイドがメインだったエンジニアがフロントエンドへとコンバートしElmを書き始めるケースもあります。自分もそのうちのひとりでした。
Elmは学習曲線のゆるやかな言語として有名ですが、それでもスケーラビリティやElmらしさを追求したアプリケーション開発をしていくためには、間違いなくチームでのディスカッションやベストプラクティスの発見などが必要だと言えます。弊社におけるアカデミー制やびわ会は、持続的な開発組織を支えるためのひとつの方法です。
今回の記事の内容と親しいトピックを私がElm Europe 2019で話したものがありますので、興味があればご覧ください。英語の発音が微妙なのはご容赦いただけると幸いです。
次回予告
Fringe81アドベントカレンダーの気になる明日は、我らがUniposチームをレペゼンするスーパーデザイナー@miyabt_による「デザインレビューの体制をつくった話」です。どうぞお見逃しなく。
Scala関西Summit 2019に参加してきました #scala_ks
こんにちは！Fringe81 エンジニアの谷口です。2019年10月26日(土) - 27日(日)に開催されたScala関西Summit 2019に同期の大沼と参加してきました。
Scala関西Summit
Scala関西Summitは、Scalaをテーマとした関西で最大級の技術カンファレンスです。Scalaの導入事例やTIPSなどなどScalaに関わるあらゆる人を対象にしたカンファレンスです。
2日間の開催で、1日目は講演・ハンズオンdayです。講演は公募によって選ばれ、大変幸運なことに私のプロポーザルを採択して頂きました！
2日目はアンカンファレンスdayです。当日の朝に参加者全員で何を話すかが決められます。1日目の会場のホワイトボードに挙げられた『こんなこと話してほしい！』について話せる人を募ってセッションのタイムテーブルを決めていきます。講演で質問に上がったことを深ぼったりとライブ感のある日です。
ここからは当日のセッションをいくつかご紹介したいと思います。
1日目：講演・ハンズオン
Dependent method types を利用した軽量Clean Architectureの紹介
がくぞ（@gakuzzzz）さんの発表です。
ドメインのコードから実装詳細を分離する方法としてFreeモナドやTyped Finalが用いられますが、それらは使う側がモナドを意識する必要がありました。そういうものを使わなくてもDependent method typesを使うことでモナドを明示的に扱わなくてもドメインコードと実装詳細を分離できるという話と、実際にそれを実現するために考慮するべきことについての話でした。示されたコードを見ると、確かに利用者側はモナドを意識せずに使えるようになっていて、比較的見通しのよい記述が実現できそうだと感じました。
Java 5.0時代の非同期処理技術から学び直すScala/Java非同期処理
リチャード 伊真岡（@RichardImaokaJP）さんの発表です。
非同期処理の歴史とOS/CPUの内部での動作や、非同期処理によって起こる問題とそれに対する解決策や、共有すべき状態をどのように扱うべきか、などのことをわかりやすく（すごい丁寧に作られた動画で本当にわかりやすかった…）説明してくれるセッションでした。質疑応答のときにスレッドプールの使い分けの話で盛り上がり、2日目のアンカンファレンスでもとりあげられたのが印象的でした。非同期処理は人間には難しい。
Scalaで圏論ﾁｮｯﾄ学ぶ
私（@ravineport）の発表です。
Scalaで関数型について深めていくと登場するモナド、そして圏論。勉強してみたものの挫折したという方も多いのではないでしょうか（私も何回も挫折しています…）。そこで、圏論とはなにか、圏論におけるモナドとはなにかを感じつつ、Scalaのモナドがどう表現されているのかを眺める、というのが本発表でした。 圏論ﾁｮｯﾄわかった！という気持ちになって頂ければ幸いです。
Scala における Monad って何だろう？
Naoki Aoyama（@AoiroAoino）さんの発表です。
Scalaにおけるモナドの基本からどう実装するのかまで、Scalaのコードで丁寧に解説してくれるセッションでした。モナドを使うことでなにがうれしいのかから始まり、様々なモナドの実装、抽象的なモナドの扱いまで、すぐにでも活かせる実用的な内容でした。コードベースの説明で実装イメージがとてもつかみやすかったです。Scalaにおけるモナドは知っておくと便利なツールの一つ！
2日目：アンカンファレンス
1日目の発表の実装例の紹介や質問に対する深堀り、Monix導入、Airframeハンズオン、モブプログラミングなどが行われました。
最後に
私も大沼もScala関西Summitには初参加でしたが、様々な経歴のScalaエンジニアが知見を共有し語り合うアットホームな雰囲気の素敵なカンファレンスでした。2日目のアンカンファレンスも1日目とはまた違った雰囲気で貴重な経験をさせて頂きました。
懇親会でも発表の内容だけにとどまらずScalaについて語ることができ、楽しい時間を過ごすことができました（なんと食事に生ハムの原木も登場しました）。
Scala関西運営スタッフの皆様、本当にお疲れ様でした！素敵な場と時間をありがとうございました！
