エムスリーテックブログ

エムスリー(m3)のエンジニア・開発メンバーによる技術ブログです

プロダクトマネージャーカンファレンス2017に参加してきました! #pmconfjp

AskDoctorsプロダクトマネージャーの江波です。

2017/11/14(火)・11/15(水)に開催された Product Manager Conference 2017 に単独で参加してきました。

f:id:enamingo:20171120182153j:plain
机ありの良席を確保できました。

Product Manager Conferenceとは?

日本におけるプロダクトマネジメントに関わる人やそれを目指す人が集うカンファレンスです。 プロダクトマネージャーという職種の認知を高め、プロダクトマネジメント業務に携わる人々が共に学ぶ場を持つきっかけを提供することを目的に、昨年から開催されています。

プロダクトマネージャーという職種は、特にこの1~2年で国内における認知度が広がってきたような気がします。

今回のカンファレンスも、公開数日で定員300名が埋まり、150名以上がキャンセル待ち状態(!)に。 急遽定員が400名まで拡大されたということからも、プロダクトマネージャーへの興味関心・注目度が高まっていることを実感できます。

カンファレンスのテーマ

前回は「さぁはじめよう!日本のプロダクトマネジメント」というテーマだったのに対し、今回のテーマは「深める、広げる」。テーマの変遷からも、この1年で国内におけるプロダクトマネジメントの進化を読み取ることができます。 テーマの通り、単純な事例紹介に留まらず、組織文化・チームビルディング・UXリサーチ・経営者目線・人工知能ブロックチェーンとの向き合い方など、多岐にわたるセッションが開催されました。

twitter上でも賞賛の声が多かった当カンファレンスですが、本当に学び・気付きがたくさんあり、個人的にも大満足の2日間でした。

当日のツイートまとめはこちら。

togetter.com

togetter.com

togetter.com

個人的に良かったと思う2つのセッション

素晴らしいセッションばかりだったのですが、その中でも特に印象深かったセッションを2つ紹介したいと思います。

Salesforceで行われているプロダクトマネジメント

前半:VCから見た良いプロダクトについて

(登壇者:セールスフォース・ベンチャーズ日本代表/浅田慎二 氏)

ポイントとして以下3点を挙げられていました。

  1. どのユーザーのどういうPainを対象にしているかがクリアである
  2. ユーザーPainのストーリーが描けており、それに適合したSolutionになっている
  3. (一部のコアユーザーにとって)Must Haveになっている

特に3点目については、「UIが優れていることがベストだが、仮にデザインがイマイチでも、ユーザーのPainを解決していれば良い」とのことで、個人的に非常に共感したポイントでした。 プロダクトマネージャーとしては、どうしても「見た目が良いプロダクトを作りたい」「UIにこだわりたい」という思いが強くなりがちですが、それが強くなりすぎるとプロダクトの本質を見失ってしまいますね。

また、プロダクトに取り組む際の3大原則として

  1. Make it Simple
  2. Release it Quickly
  3. Ask Users

を挙げられていました。よく言われることと言ってしまえばそれまでですが、年間1,000社以上を見ているVCが改めて強調するほどに重要なことなんだと再認識しました。

後半:USでの開発プロセスや開発チームの役割について

(登壇者:米国セールスフォースドットコム プロダクトマネージメントディレクター/Ken Wakamatsu 氏)

「優れたビジネスの背景には優れたプロダクトマネジメントあり」と嫌でも思い知らされるくらい、相当に成熟したプロダクトマネジメント文化が存在していることが分かりました。

  • イノベーションはダイエットや筋トレと同じで、プランとメソッドが大事
  • 独立してやらない。会社全体で同じプランを実行する
  • V2MOM=組織内の意思統一をするプラン
    1. Vision:ビジョン(目標は何か)
    2. Values:価値(なぜ重要なのか)
    3. Method:方法(どうやって実現するのか)
    4. Obstacles:障害(成功を妨げる課題は何か)
    5. Measures:測定基準(パフォーマンスをどう測定するか)
  • ADAM(Adaptive Delivery Methodology)

ADAMの何がすごいかというと、5~10名程度の計400以上の開発チームが、同じサイクルで年3回のリリースを実現している(!)ということです。 1チームのリリースでも大変なことなのに、400チームって。。。

そして、このADAMは次の7つの規律によって構成されているとのこと。目新しいものはないですが、これが徹底されているからこそ、上記が実現できているのですね。いや、本当にすごい。

  1. Respect People
  2. Eliminate waste
  3. Build quality in
  4. Deliver fast
  5. Create knowledge
  6. Optimize the whole
  7. Just in time decisions

その他にも、

  • DesignのFail fast:開発中に次のリリースを並行でプランニング開始(デザインとプロトタイプのチーム)
  • ApprovalのFail fast:リリース毎に機能を更新、スケジュールをエグゼクティブにプレゼン。月に1回、役員が全製品の進歩をレビュー。
  • Trust が最も重要:最初から高いクオリティを維持する
    • リリースの最後にクオリティを管理するのではなく、毎日クオリティを下げない
    • クオリティは製品のパフォーマンス
    • テストプラン、オートメーション化、コードレビュー、などの品質管理やテストは日々行われる。
    • アジャイル開発にはオートメーション化が最も重要
    • スプリント毎に行われるフィードバックを伝える反省会も重要

などなど。(オートメーションには相当の時間とお金を使っている、とのことでした。) セッション終了後に軽く凹んでしまうくらい、内容の濃さに圧倒されました。

ちなみに、セールスフォースではエンジニアが働きやすい環境を作っており、その一つに「木曜日はエンジニアとmtgをしてはいけない」というのがあるそうです。エンジニアは出社もしなくて良いとのこと。 ただ、コードのチェックインは木曜日が最も多く、テストのfailが最も少ないのは金曜日とのことでした。顔を合わせない方が仕事が捗る、という事実はプロダクトマネージャーとしては少し複雑な気持ちになりましたが、、、エンジニアが集中できる環境を整えることも大事だということですね。

プロダクトマネージャーに経営者が期待するもの

(登壇者:株式会社フリークアウト・ホールディングス代表取締役社長/佐藤祐介 氏)

プロダクトマネージャー本人ではなく、経営者から見たプロダクトマネージャーに関する講演でした。

プロダクトマネージャーに求めるものとして、「(高い次元でプロダクトマーケットフィットを実現するという前提で)プロダクトバリューの変化を厭わないこと」を挙げられていました。

  • 「一貫したプロダクトバリュー」というのは、一部の特殊ケースを除き幻想・嘘である。
  • 持続的価値を持ち続けるプロダクトバリューの条件は、市場選定や市場ポジションによるもので、これはプロダクトマネージャーにはどうしようもない
  • プロダクトマネージャーが向き合うべき事実は、GoogleAppleFacebookAmazonMicrosoft以外のソフトウェア製品は、常に大きな変化に晒されているということ。技術・市場・ユーザーの変化に合わせて柔軟に変化し、サバイブし続けることが重要

プロダクトマネージャーからするととても刺激的な表現が満載ですが、「最重要はプロダクト・サービスが継続すること」と思っている自分にとっては、耳が痛くも非常に納得感がありました。

また、こういった話はプロダクトマネージャーだけで集まっているとなかなか出てこないようにも思うので、当カンファレンスのテーマ「深める・広げる」をまさに体現するような、有意義なセッションだったと思います。

番外編:プロダクトマネージャーの採用と育成

(登壇者:Google inc. Product Manager/Bryan Cheng氏 & Capella Yee氏)

2つと言ったのに、3つ目を番外編として紹介してしまいます。 Googleのお二方が、APM(Associate Product Manager)という新卒社員向けの育成プログラムについて講演されました。 APMとは、あのマリッサ・メイヤーによって作られたGoogleにとって最高のプロダクトマネージャー」を育成するプログラムで、もう15年以上も続いているとのこと。

登壇したお二方は相当に謙遜されて話していましたが、私を含め参加者の多くは「超狭き門を潜り抜けたスーパーエリートに、膨大な時間とお金を投資して理想的なプロダクトマネージャーを会社として本気で育成している」と理解したようです。

全体を通じて感じたこと

色んなことを学び感じた2日間でしたが、次の2点が最も強く感じたことです。

プロダクトマネジメントとは、小手先のスキルやhow toではなく、組織の文化・思想・哲学である

セールスフォースやGoogleの成功の裏には、長い時間をかけて蓄積され、浸透し、また改善されてきた強固なプロダクト文化があるということを痛感しました。経営レイヤーまでプロダクトに対して深くコミットしている点や、10年以上続いているプロダクトマネージャー育成プログラムの存在がそれを物語っています。また、他の登壇者様も、それぞれ「自社におけるプロダクト文化」を発表されていたという印象がありました。

そういった文化・思想・哲学を醸成したり組織に根付かせるように働きかけること、またそれらが組織において健全に体現されている状況を実現することが、プロダクトマネージャーの真の仕事なのかなと思いました。

そう考えると、「教科書的なプロダクトマネージャー像というものはなく、組織によって様々である」と言われるのにも納得がいきますね。

プロダクトマネージャーに必要なのは、コミュニケーション能力

教科書的なものはないという一方で、ほとんどの登壇者が共通して言っていたのが「プロダクトマネージャーに必要なのはコミュニケーション能力」ということ。それは、面白いことが言えるとか口が巧いということではなく、プロダクトに携わる様々なステークホルダーを巻き込み、文化・思想・哲学を体現していくこと、なんだと思います。

自分にそんな大層なコミュニケーション能力が備わっているとは思えませんが、特に「医療」という社会貢献度が高い領域において、エンジニアやデザイナーとともにプロダクトを作り、成長させ、顧客に価値を届けることが心底楽しいことだけは確かです。

最後に

プロダクトマネージャーカンファレンスは来年も引き続き開催されるようなので、個人的には絶対に参加しようと思っています。また、次回はAskDoctorsチームのエンジニアやデザイナーを巻き込もうと思っています。CTOも誘っちゃう。プロダクトマネジメント = プロダクトマネージャーだけのもの、ではなく、組織の文化だと思うからです。

カンファレンスを通じて学んだことを日々の業務に活かしながら、周囲にいる仲間を少しずつ巻き込み、エムスリー流のプロダクト文化を作っていきたいと思います。

エムスリーでは、そんな思いに共感してくれるプロダクトマネージャーやエンジニアを随時募集中です。カジュアルイベントも随時開催しておりますので、興味がある方は以下より応募ください!個人的なランチやお茶のお誘いも大歓迎です。

jobs.m3.com

JJUG CCC 2017 FALLにゴールド&コーヒースポンサーとして参加しました #jjug_ccc

こんにちは、エムスリーのエンジニア前原([twitter:@maeharin])です

11/18(土)に日本最大のJavaコミュニティイベント、JJUG CCC 2017 FALLが開催されました

http://www.java-users.jp/ccc2017fall/

弊社エムスリーは💰ゴールドスポンサー💰 & ☕コーヒースポンサー☕として参加しました。また、スポンサーセッションとして私が登壇させていただきましたので、そのレポです

登壇内容

午前11:00からのセッションで私のチームで進めているサーバーサイドKotlinを用いたシステムリニューアルについて登壇させていただきました。会場でKotlinを触ったことがある方に挙手いただきましたが、触ったことがある方は全体の10%くらいだったのが印象的です。KotlinはAndroidの開発言語として有名ですが、サーバーサイドでもどこでも使える言語ですので、まだ触ったことがない方は是非触ってみてください!(スライドの中でも触れていますが、Spring Initializrを使うと、たった3ステップでKotlin APIサーバーをHello Worldできます)

f:id:maeharin:20171118114352j:plain

f:id:maeharin:20171118105807j:plain

スライドはこちらです

speakerdeck.com

サンプルコードもgithubにあげてます。TypeScript(Vue.js, Element) ・ Ruby(Rails) ・ Kotlin(SpringBoot)などを用いた技術スタックになっています

github.com

コーヒースポンサー

前回のJJUG(JJUG CCC 2017 Spring)に引き続き、今回もコーヒースポンサーをさせていただきました。カップの表にはエムスリー主催のイベント「どこでもKotlin」のキャラクター「ことりちゃん」をプリント。

裏にはエムスリーのエンジニアで日本Kotlinユーザグループ代表である長澤太郎([twitter:@ngsw_taro])の顔写真をプリントしました。飲み終わったらかさばらないように、くしゃくしゃにして捨てます

f:id:maeharin:20171119185513p:plain

ちなみに、ビールスポンサーはSmartNewsさんでした。

スポンサーブース

スポンサーブースでは、エムスリー主催のイベント「どこでもKotlin」でLTしてくれたこともある [twitter:@kikutaro_] さんがSendGridのブースを出典されてました。LT資料ではJavaだけでなく、Scala、Groovy、KotlinでSendGridを使うコードが紹介されてました

また、サムライズムの[twitter:@yusuke]さんのブースでは、IntelliJ IDEAなどが紹介されてました。一緒に参加した[twitter:@oboenikui]は「IntelliJ IDEAハンズオン」に@yusukeさんのサインもらってました。いいなー(私は電子書籍で購入済み。)

他のセッション内容

私自身はJJUG初参加・初登壇だったのですが、Javaだけでなく、コミニュティの話しや、Kotlinの話しなど盛り沢山のイベントでした。各スライドはこちらにまとめられていくようです。スタッフ・ご登壇者のみなさまお疲れ様でした!

github.com

ちなみに、最後の懇親会ではじゃんけん大会があったのですが、幸運にも勝ち残り、賞品のDuke君マウスをGETしました!横たわる姿が愛くるしい。

f:id:maeharin:20171119231436j:plain:w300

さてさて、ここからは告知です

11/22(水)に「どこでもKotlin #4 〜秋のLT大会 その弐〜」を開催します!

11/22(水)にKotlinイベントやります!エムスリー長澤太郎も、エムスリー以外の方も交じってのLT会です。絶賛受付中なのでちょっとでもKotlinに興味があるかたは是非ご参加ください!

m3-engineer.connpass.com

一緒に開発してくれる仲間を募集中です!

エムスリーではKotlinだけでなく、Java、Scala、Ruby、Elixirなどが適材適所で大活躍してます。一緒に開発する仲間を絶賛募集中です!メンバーとカジュアルに話す場も設けてますので是非気軽にお問い合わせください!

jobs.m3.com

エムスリー Tech Talk 81 回目を開催しました #m3dev

今回は 11/1 に実施したエムスリー Tech Talk 81 回目のレポート記事です。

エムスリー Tech Talk とは

いきなり81回目と言われても意味がわからないと思われるので簡単に紹介をさせてください。

エムスリー Tech Talk はエムスリー社内で定期的に行われている技術発表会で、隔週1回くらいの頻度で2013年より実施しています。 時間は5から15分程度で自由に設定、発表内容は「やってみた」レベルのものから高度なもの、普段使っている技術とは関係ないものまで様々で、 発表したい人が気軽に発表できる場になっています。

最近では社内だけでなく外部のゲストの方に発表していただいたりといった試みもしております。 もし参加してみたい、発表してみたい方がいればこちらからご応募ください。

今回の発表内容

今回は以下3つの発表を簡単に紹介します。

  • Make it easy to input |> @ma2ge
  • What's new in Ruby on Rails 5.2 @ryohashimoto
  • SQLをアプリケーション層で並列化してみた~Python編~ @takeruko

Make it easy to input |>

私@ma2ge の発表です。Elixir 言語のパイプ演算子 |> は2回キー入力が必要なことが私としてはプログラミングする上で課題なのですが、 これを ErgoDox の firmware 設定で 1 キーで入力できるようにした話です。

ErgoDox カスタマイズするの楽しいので、興味があったら皆さんも挑戦して見てください。 スライドの最後に ErgoDox をカスタムしている記事のリンクを色々と載せましたが、皆さん面白いことを色々していて見てて飽きないです。

https://speakerdeck.com/ma2gedev/make-it-easy-to-input

What's new in Ruby on Rails 5.2

橋本@ryohashimoto からの発表で、Rails の 5.2 に入るであろう機能を紹介してくれました。 Rails も進化の速度が速いプロダクトなので、新しいものをウォッチしていくのは中々大変ですが、 こうやってまとめていただけるとキャッチアップが楽になったり、議論のきっかけとなったりして嬉しいです。

Active Storage は今まで外部の Gem を使ったアップロード部分が、Rails 標準で用意されることになるので、プロダクトにも採用していきたいと感じました。 Current attributes はスレッドローカル変数をリクエストごとに書き換えているようで、ちょっと危険な香りがしそうなので様子見ですかね。少なくともしっかり調べてから判断したいと考えています。

https://speakerdeck.com/ryohashimoto/whats-new-in-ruby-on-rails-5-dot-2

SQLをアプリケーション層で並列化してみた~Python編~

笹生@takeruko からの発表で、SQL をアプリケーション層で並列化した話です。 出だしの主な TV 出演歴でさらりとアイスブレイク、真似したいけど真似できない。

非常に重い SQLPython 側で並列化して現場課題を解決できるか検証したという内容です。 私は Python に明るくないのですが、thread のところで GIL(Ruby にもあるよね) の話が出てきて CRuby と同じだと思ったり、 名前だけは聞いていた Pandas が何をしているのかざっくり掴めたりと少し Python 事情に詳しくなった気がします。

https://speakerdeck.com/takeruko/sqlwoapurikesiyonceng-debing-lie-hua-sitemita-pythonbian

まとめ

今回は ErgoDox, Rails 5.2, SQL & Python といつも通り色々なテーマでの話でした。 個人的には普段触れない色々な技術知識に触れられるのもエムスリー Tech Talk の魅力です。 時々こんな形で一端をお見せできればと考えています。

各発表について詳しいことは各スライドを見ていただければと思います。

最初の方にも載せましたが、もし参加したい、発表したいという方がいましたら、こちらから申し込んでいただければと思います。

どこでもKotlin #2 〜サーバーサイドKotlin特集〜 を開催しました! #m3kt

エンジニアの星川 id:oboenikui です。

2017/09/28にSpeeeさんのオフィスにて、弊社主催のKotlin勉強会である「どこでもKotlin #2 〜サーバーサイドKotlin特集〜」を開催しました。

エムスリーではAndroidの開発言語としてだけでなく、サーバーサイドでもKotlinを実戦導入しています。

「どこでもKotlin (通称どこコト)」は、そんなKotlinがアプリやサーバーサイドなどどこでも使える言語として、一部の会社だけではなくどこでも使われるようになって欲しい、という願いを込め、Kotlinを盛り上げるために約月1回の頻度で開催していく予定の勉強会です。

第2回目の今回は、サーバーサイドにフォーカスを当てた回として予告しており、発表3つ全てがサーバーサイドKotlinに関する内容となりました。 Kotlin勉強会で内容がサーバーサイドのみのものというのはあまり例がなく、弊社としてももちろん初の試みでしたが50人超の方々にお越しいただけました!

本記事では、当日の模様をお伝えします。

f:id:oboenikui:20170928194124j:plain

なお、前回の模様はこのブログ立ち上げ前だったので、前原 id:maeharin の個人ブログにまとまっております。

maeharin.hatenablog.com

発表内容

KotlinとSpring BootとDoma2でAPIサーバーを作る

まずは前回に引き続き前原のKotlinを使ったSpring BootでのAPIサーバーの作成、そしてJSONのパーサー・オブジェクトマッピング用ライブラリであるJacksonやDBアクセスフレームワークDoma 2などをKotlinで使う話でした。

前回はマネジメント視点でのサーバーサイドKotlin導入に関する話でしたが、今回はより技術的な話でした。

f:id:oboenikui:20170928194224j:plain

関連リンク

Demo github.com

Swagger CodegenAPIクライアントgem自動生成

次は、前原と同じチームの滝安による、SwaggerとKotlin連携の話。

Spring Frameworkを使ったサイトの実装からSwaggerのspecファイルを自動生成するプロセスにKotlinを導入した話と、その躓きポイントの解説です。また、その躓きポイントを克服したfull Kotlinの自作ライブラリ "Springfennec" も作ったそうです!

f:id:oboenikui:20170928195007j:plain

関連リンク

Springfennec github.com

Demo github.com

黒べこ本の話 + Ktor試してみた

トリはご存知、長澤太郎のKtorの話と自著の新刊の宣伝 (^_^;) でした。

Ktorについて

KtorはKotlinの記法やコルーチンを用いることでよりシンプルに書けるように設計された、大部分がKotlinで書かれているJetBrains謹製のウェブフレームワークです。

現在、Kotlinで扱えるウェブフレームワークと言えばSpring、という風潮になってきていますが、シンプルな用途であれば今後取って代わる可能性のあるフレームワークだと考えられます。

今回はその導入についての解説でした。

新刊について

長澤太郎の新刊、「Kotlin Webアプリケーション」(通称:黒べこ本)は本日10/6に発売です!!

また、JetBrainsのDmitry Jemerov, Svetlana IsakovaによるKotlinの解説本、 "Kotlin in Action" の日本Kotlinユーザーグループによる翻訳本も10/31に発売予定です。

f:id:oboenikui:20170928202038j:plain

関連リンク

Demo github.com

懇親会

懇親会ももちろん開催。Kotlin談義に花を咲かせました。

f:id:oboenikui:20171003160430j:plain

なぜかおにぎりの山が…… f:id:oboenikui:20171003155310p:plain

前回同様、アプリからサーバーサイドまで、幅広いエンジニアにご参加いただきました! これも今後Kotlinがどこでも使われることに期待してのことだと思います。

弊社も今後もKotlinを盛り上げていく所存です!

次回「どこでもKotlin #3 〜秋のLT大会 その壱〜」は10/23開催!

どこコトの第3回目は5分または10分のLT形式でお送りします。 次回はどこコト初の、弊社社員以外の登壇者をお招きしてのLTとなります!

m3-engineer.connpass.com

実は#2参加者の中から次回登壇者を募っていたのですが、予想を超える多くの方に登壇を希望していただきました! 次回はその方々にご登壇いただく予定です。お楽しみに!

また、本ブログでも今後Kotlinについての動向・ノウハウを共有していく予定です。乞うご期待!

Enjoy Kotlin!!

f:id:oboenikui:20170928204357j:plain

Railsでクレカ決済付きECサイトを作ってみよう!【勉強会イベント紹介】

M3ではWebサイト開発が未経験の学生さんに向けて、Webサイトの開発の楽しさ体験してもらう勉強会イベントを不定期で開催しています!

この記事では、クレジットカード決済ができるECサイトRuby on Railsアプリで開発して、Heroku(サーバ)に公開するまでの手順を紹介します。RubyGemsをうまく組み合わせることで、シュッと作成できるのでWebサイト開発をちょっと試してみたい方にオススメです。

ちなみに、M3は日本/世界に医療に貢献するようなサービスを開発しています。この記事がそういった社会に貢献するサービスの開発に興味を持ってもらうきっかけになれば幸いです。

f:id:ke-mori:20171002113724j:plain

目次

(01) RubyとRuby on Railsについて
(02) ローカル環境構築の準備
(03) Railsアプリケーションの作成
(04) 商品管理画面の作成
(05) MVCとは?
(06) 本番DBにPostgreSQLを使うようにする
(07) Herokuサーバにデプロイ
(08) 認証機能の追加
(09) CSSフレームワークbootstrapの導入
(10) クレジットカード決済機能の追加
(11) 勉強会イベント参加者のコメント
(12) 勉強会イベントへ参加したい学生さん大募集

続きを読む

エムスリーは #RubyKaigi 2017 にスポンサーとして参加しました

エムスリーエンジニアの松原 @ma2ge です。

2017/09/18から09/20に広島にて開催された RubyKaigi 2017 にて Gold Sponsor としてスポンサーしました。 弊社からは今年4月新卒入社の加藤 @m3_ryo_kato2 と私松原の2名が参加しました。 今回初めてスポンサーブースも設置させていただき、swag にはマスクとうちわをご用意しました。

f:id:ma2gedev:20170927121419j:plain
エムスリースポンサーブース version 1.0

周りのスポンサーブースを見渡すとみなさまテーブルクロスをしておりましたので慌ててパッチを当てて version 2.0 をリリースし直しました。

f:id:ma2gedev:20170927121517j:plain
エムスリースポンサーブース version 2.0

ブースに訪れていただいたり、話しかけていただいたりと皆様ありがとうございました。 お好み焼き美味しくて広島も最高でしたね。

www.instagram.com

エムスリー と Ruby

Kaigi 中「エムスリーが Ruby を使っていることを知らなかった。」という声をいくつかいただいたのですが、 2012 年くらいから本格的に使い始め、今では大体 40 〜 50% くらいのアプリが Rails で作られており、メインの言語の一つとなっております。

Ruby コミュニティへの貢献という形では、Tokyo RubyKaigi 11 での Ruby3 Sponsor、昨年の RubyKaigi 2016 で Gold Sponsor をさせていただいております。

次の RubyKaigi 2018 は仙台ということですので、何らかの形で引き続き継続したいと考えております。

f:id:ma2gedev:20170927121932j:plain
次の RubyKaigi 2018 は仙台

ちなみに Rails が半分くらいという話をしましたが、Ruby 以外の言語も色々と使っていて、それらのコミュニティへもスポンサーしてたりします。この辺りの話はまた別の機会に。

個人的によかったと思う2つのセッション

いずれもよかったのですが、個人的観点で2つ選ぶならコレというものをあげさせていただきます。

Pattern Matching in Ruby

1つは @yotii23 さんのパターンマッチを Ruby に入れるという話です。 理由は Ruby 本体に手を入れて、さらにそのリポジトリを公開もしているという点と、私が Elixir 言語信者という点です。

@yotii23 さんは Programming Elixir を日本語訳し出版されている方でもあるのですが、 Elixir 言語のコードを例示しながらパターンマッチの紹介をしてくれました。 私も Elixir を書くときはパターンマッチを使いますし、 Ruby にも入ってくれたら嬉しいと思っていたので、興味深くセッションを聞いておりました。 ちなみにエムスリーも Elixir を本番で使っていますが、これはまた次の機会に話します。

Ruby とパターンマッチでいうと、いくつかの gem があります。 例えばセッションでも紹介されていた、@k-tsj さんの pattern-match gem ですとか、 Egison 言語を作られている @egison さんの egison gem とかですね。

ですが本発表では gem ではなく Ruby 本体を変更してしまうというところが新鮮で面白かったと思います。 またそのコードを公開されておりますので、同じようにすることで自分自身でも再現ができますし、 目的に対してどのように Ruby を変更していくのかも分かるので私としては大変勉強になりました。

Resources

Memory Fragmentation and Bloat in Ruby

2つ目は @nateberkopec さんで Ruby のメモリに関するパフォーマンスの話です。 こちらを選んだ理由はメモリ消費事例について分かりやすく説明してくれたこと、 スライドが Deckset で作られていて私も Deckset ユーザの一人で共感したためです。

@nateberkopec さんは The Complete Guide to Rails Performance の著者で、Rails のパフォーマンスについてのコンサルタントをしておられるようです。 今回の発表では Ruby のメモリに関するパフォーマンス劣化を引き起こす原因をいくつか紹介しながら、 Ruby の下回りの仕組み、対処方法について紹介してくれました。

例えば以下のような事例を紹介してくれました。

  • RailsUser.all.each { |u| ... } を実行してしまう(これはよく耳にする事例ですね)
    • ユーザ数が多い場合に一気にメモリが消費される
  • Puma が Unicorn よりもメモリを消費するケース(スレッドモデルなので驚きました)
    • 特にスレッドをたくさん作って、その上でメモリも確保するようなアプリケーション
    • glibc にスレッドごとのメモリアリーナ機能というものがあり、スレッドごとにメモリ領域(アリーナ)を確保するためにこのようなことが起こり得る

対処方法については Ruby コード側でなんとかするというのもあるのですが、Ruby がメモリ管理をしているのだから、 なるべく Ruby コードでは意識しないようにしたいということで以下のようにいくつか紹介されていました。

  • glibc のメモリアリーナ機能で確保されるメモリ領域を抑えるために MALLOC_ARENA_MAX 環境変数の設定を見直す
  • glibc ではなく別の malloc 実装、例えば jemalloc を使う(jemalloc はメモリのフラグメンテーションに効くようです)

ただし何れにしてもトレードオフの関係があることは意識しておく必要があります。例えば MALLOC_ARENA_MAX の値を下げることでメモリ消費量は減るが、その分メモリのロックを取る確率が上がり速度が下がるなど。

私としては Puma のメモリ消費事例、スレッドごとのメモリアリーナ、jemalloc のいずれについても知らなかったことでしたので、 知ることができてよかったですし、Ruby の下で何が起こってるかについて少しだけ詳しくなり有意義な時間となりました。

Resources

最後に

毎回思うのですが RubyKaigi のクロージングはこみ上げるものがありますね。年々涙腺が弱くなっている身としては、堪えるのがだんだん辛くなってきております。 クロージングでも言われていたのでここでも言いますが、今回の RubyKaigi には仕事として参加しており、旅費周り含めてサポートもしてもらっております。

エムスリーではエンジニア仲間を募集しています!

エムスリーでは Ruby, Rails などのテクノロジーを活用して医療に貢献するエンジニアの仲間を募集中です!勉強会の見学やカジュアル面談も随時受け付けてますのでご興味があれば以下よりご応募ください!

エムスリー機械学習ミニコンペを開催しました! #m3dev

こんにちわ。エムスリーのエンジニアまえはりん @maeharinです

先日エムスリーのAIチームメンバーが主催で機械学習のミニハッカソンを開催しましたので、その様子をレポします。場所はYahoo!JAPANのコワーキングスペース『LODGE(ロッジ)』

f:id:m3tech:20170915073204j:plain

お題はワインの品質当て!

お題は「ワインの要素(アルコール度数とかpHとか)とその品質(10段階のクオリティ)のデータを元に、品質を予測するモデルを作成してその精度を競おう」というもの

【課題】

  • ワインの品質を予測するモデルを作成しましょう。
  • モデルの精度はaccuracyを10 fold cross validationで評価。
  • データ・セットは次のURLからダウンロードできます!!
  • 赤ワインと白ワインのデータがあるが、赤ワインのデータを使う
  • 当日に着手してもいいですし、事前に準備しても構いません。AWS使ってもいいですよー。猫型のAIも利用可です。

この人が主催者。エムスリーのAIチームのエース(通称:インテリラガーマン)。今回の私の目標はこの人を倒すこと

f:id:m3tech:20170915073153j:plain

機械学習ニコンペ開始!

やり方は人それぞれ。python + scikit-learnで頑張る人や、TensorFlow使う人など様々

モデルの選択やパラメータチューニングをモクモク

私はwindows azure mlで勝負

windows azure mlならデータソースをアップロードして、GUI上でモデルや評価手法を選択してつなげていくだけなので楽ちん。データソースの概観をvisualizeすることもできるし(分散や散布図をサクッとみれる)

f:id:m3tech:20170915113809p:plain

モデルを変えて再実行したりも簡単。ローカルPCよりも実行時間は早そう。これなら機械学習初心者でも勝機があるかも!?

f:id:m3tech:20170915114049p:plain

スコアが上がったり下がったりの中盤戦

精度が出ないからってPCに念を送り出すI氏

f:id:m3tech:20170915073237j:plain

が、精度あがらず

f:id:m3tech:20170915073226j:plain

コンペ終盤、激しいデットヒート

チューニングを重ねていった私が暫定一位に!うほほほほ!

しかし、他のメンバーのサポートをしていたN氏(通称:インテリラガーマン)がものすごい勢いで追い上げてくる

結果発表

デッドヒートの結果は…

f:id:m3tech:20170915073249j:plain

私は2位!結局AIチームのエースを倒す目的は叶わなかったですが、機械学習初心者にしては上出来かな(^ω^)

ハッカソン後はリアルワイン品質品評会で締め!

f:id:m3tech:20170915073305j:plain

エムスリーではエンジニア仲間を募集しています!

エムスリーでは機械学習などのテクノロジーを活用して医療に貢献するエンジニアの仲間を募集中です!勉強会の見学やカジュアル面談も随時受け付けてますのでご興味があれば是非ご応募ください!