エムスリーテックブログ

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

M3 USA 出張記 #1 : M3 USA 出張のあらまし と 海外長期渡航のTips

Global

2018-10 月から 12 月に掛けて、M3 USA (NY) へエンジニア 3 名(冨岡, 矢崎, および 11 月から笹川)が出張しております。

f:id:Saiya:20181013040249j:plain

US での雰囲気やエンジニアリング面での試みなどを数回に分けて ご紹介するシリーズの第一弾として、NY のオフィスや US への長期渡航の tips をご紹介します。

M3 USA

エムスリー(株)の会社概要の連結子会社の一覧 にありますように、M3 には USA, 英国, フランス, ドイツ, スペイン, 中国, 韓国, インド と数多くの国に関連会社があります *1。

そのうちの一つである M3 USA の歴史はインターネットサービスとしては古く、 MDLinx という医療情報提供サービスが 1999 年に始まり、エムスリーグループへの参加も 2006 年にさかのぼります。 今現在でも MDLinx は M3 USA の主要サービスの一つです。

そのように長い歴史があるゆえに、近年に現れた技術などを MDLinx へ導入することで改善や新しい価値を発揮できるポテンシャルがあるというのが技術面での見込みです。

そういった可能性を検討・概念実証すべくエムスリー (日本) のエンジニアが US へ赴いているという状況です。 今回は上記の内容に加えて NY オフィスの様子と海外長期出張の tips をご紹介し、次回以降で技術面でのツールやアプローチ、あるいは NY 滞在にまつわるトピックなどをご紹介しようと思います。

*1:筆者が把握できていないだけで更に他の国にも関連企業があるかもしれません

続きを読む

ソフトウェアエンジニア 前原 秀徳さんがエムスリー エンジニアリング フェローに就任しました！

お知らせ

こんにちは、人事の友永です。本日はエンジニアリング フェローにソフトウェアエンジニアの前原さんが就任しましたのでお知らせいたします。
Kotlinエバンジェリスト 長澤さん・株式会社ジノビア代表 堀井さんに続き3人目のフェロー就任となります。

エンジニアリング フェローとは

在籍中または卒業後に顕著な活躍をしたエンジニアに対して、エムスリーを卒業後しても継続的にフェローとして称えるものです。また、エムスリー卒業生として定期的な意見交換を行ったり、エムスリーとエンジニアコミュニティをつなぐハブを担ってもらうという役割もあります。

フェローの紹介

前原 秀徳 さん

  • 医師・薬剤師キャリアのシステムリニューアルをリードしビジネス成長を加速
  • Vue.jsやサーバーサイドKotlinを初導入するなど技術的なチャレンジを推進
  • 「どこでもKotlin」など勉強会の主催や外部イベント登壇を通じてエンジニアブランドを向上し採用へ貢献
    これらを称えフェローに就任いただきました！
f:id:otkmym:20180928135646p:plain:w350

慶應義塾大学総合政策学部を卒業後、金融機関でWebディレクターを経験。28歳でエンジニアに転向しベンチャー企業に勤めた後、2014年5月にエムスリー入社。エムスリーでは医師・薬剤師キャリア支援事業のエンジニアチームリーダー、グループ会社の取締役、採用チーム担当等を歴任。

2017年5月にサーバーサイドKotlinとVue.jsを用いたシステムリニューアルを立ち上げ、10年前の技術スタックで構成されていたレガシーシステムをモダンなシステムにリプレイスするプロジェクトをリードした。また、エンジニア向けイベント「どこでもKotlin」の主催や、Kotlin Fest、JJUG CCC、v-meetupといった外部イベントでの発表、テックブログの立ち上げなど社外に向けた情報発信に力を入れた。2018年9月にエムスリーを退職し、フリーランスエンジニアに。

自慢は自身のブログで「はてぶ1200超え」を達成したこと。好きな漫画はベルセルク。

インタビュー・発表資料等

続きを読む

Play2向けSentryライブラリを作成しました

エンジニアリンググループ 中村です。
Play Framework 2.x (以降: Play2)向けのSentryライブラリを公開したので紹介します。

github.com

Sentryとは

エムスリーでは、Sentryというエラートラッキングツールを利用しています。

アプリケーションのエラー発生時に、単にログファイルに出力するだけではエラーに気づくことができません。 代わりにアプリケーション自身からメールを送るなどすることがありますが、普段のメールが埋もれてしまったり、大量に起きたときにメールが詰まることもおきかねません。

そこで、メールの代わりにSentryにエラーの情報を送ります。 Sentryでは同じ種類のログをひとまとめに束ねてくれたり、その種類ごとでの通知頻度を調整してくれたりと便利です。 記録する情報はログテキストだけでなく、例外発生時のスタックトレースやHTTPリクエストの詳細などを含めることもできるため、単に「エラーが起きた」ということ以上の原因追求ための情報もわかるので非常に助かります。

例: Sentryのサンプル画面
f:id:taknakamura:20180927135920p:plain:w300

Javaでの組み込み方法

Sentryを利用するには、アプリケーションにSentryクライアントを組み込むことになります。
各種の言語向けにクライアントライブラリがあり、Java系であればロガーライブラリごとにクライアントモジュールが用意されています。 例えば、logbackに対応したsentry-logbackがあります。 導入ガイドに従っていけば、Sentry用ログアダプタとして利用することができるため、通常のログ出力をそのままSentryへ送信することができるようになります。 またwebアプリであれば、Sentry用のServletRequestListenerが用意されているおかげで、自動でHTTPリクエストの内容もSentryの記録につけてくれるようになります。 Sentry用のServletRequestListenerによって、リクエスト受けた時にHTTPリクエスト情報をスレッドローカルに保持しておき、Sentryへのログ出力時にそれを使うようになっています。

Play2への対応

Play2でSentryを使うには前述のJavaのライブラリを使えばよいのですが、以下の問題があります。

  1. sentry-logbackはServlet APIのみをサポートしているため、Play2のHTTPリクエスト情報は取得できない
  2. Futureを使ったマルチスレッド処理を多用すると、スレッド間でHTTPリクエスト情報の受け渡す必要がある

そこで、これらに対処するためのライブラリを作成しました。

https://github.com/m3dev/play2-sentry

このライブラリでは、主に以下のことをしています。

  1. Play2のplay.api.mvc.RequestHeaderの内容をSentry向けのデータに変換し、スレッドローカルに保持する
  2. 独自のAkka Dispatcherによって新スレッド起動時に、HTTPリクエスト情報を親スレッドから新規スレッドに渡す

ライブラリを組み込む時にはSentryクライアントそのもの手順に追加して、拡張したSentryを使うようにすることと、独自のAkka Dispatcherを使うようにするための設定変更が必要です。 詳細な手順は、リポジトリのREADMEを参照してください。

未対応なこと

社内での必要性に沿って作ったものなので、Play2の最新版ではなく2.4が対象になっています。追って最新版への対応もしていきたいと思っています。

また、Sentryのログへ付与するメタ情報の一部がまだマルチスレッド間の対応ができていない部分もあるので、随時機能追加したいと思います。

エンジニア募集

エムスリーでは技術で医療の課題を解決するエンジニアを募集しています。 Sentryを利用するような開発環境の改善、利用を促進する共有モジュールの開発など、この記事を読んで興味を持った方はぜひ下記リンクよりご応募ください！

機械学習エンジニアインターンがすごい楽しかった話

インターン 機械学習 採用

こんにちは！エムスリーのエンジニアリングG、AI・機械学習チームで2週間ほど機械学習エンジニアインターンをしていました、松岡玲音と申します！（Twitterアカウント: @lain_m21）普段はマサチューセッツ工科大学の博士課程でロボティクスの研究をしたりしています。インターンとっても楽しかったので、これからエムスリーでのインターンを考えている人や、エムスリーのAIチームでの仕事に興味のある人たちにぜひ読んでいただきたいです♪

簡潔に良かった点をまとめると、

  • 実際の業務に使われる機械学習アプリの開発ができて、達成感があった

  • チームでの開発やテストのノウハウなど、研究室や個人レベルでの開発ではなかなか得られない経験ができた

  • メンターの西場さんが（特に）強かったので、いい感じにストレッチされて自分の成長に繋げられた

こんな感じです！これら以外にも、私個人に最適なインターンのテーマを考えていてくれたり、期間中は1 on 1のミーティングの時間を設けてくれたりと、ただのインターンではなくチームの一構成員として扱ってくれる感じが常にあってとても嬉しかったです。その分、自分のプロジェクトへの責任や当事者意識などは強く意識する必要があり、程よく良い緊張感を持って取り組めました。

ここからは、実際に私が期間中どのようなことをしたのか、どのように取り組んだのかなどを簡潔に書いていきますね♪

続きを読む

エムスリーSREチームのご紹介

SRE

こんにちは。エンジニアリングGでSREチームのチームリーダーを務めている池田（@progrhyme）です。

以前のエンジニアリングG内には、システムインフラの構築・運用を主に担当する「インフラチーム」が存在していましたが、今年の7月から改称して「SREチーム」と名乗ることにしました。
以降では、SREチーム設立の経緯や、その役割、ミッション等について記します。

SREとは

SREは「Site Reliability Engineering」の略で、2003年にGoogleで誕生したSREチームが実践してきたプラクティスに基づくシステム運用の新しい形です。
2016年にO'Reillyから同名の書籍が出版されたことで、IT業界を中心にその考え方やメソッドが広く普及していったと思います。

SRE Book

SRE（= Site Reliability Engineer）が単なる運用チームと異なるのは、彼らがソフトウェアエンジニアだということです。
言い換えれば、同じ作業の繰り返しや人手による管理を良しとせず、それを自動化するソフトウェアを設計・実装する能力を持つ、ということです。

エムスリーのSREチームにおいても、このようなSREの在り方を追求していく方針です。

チーム改称のねらい

インフラチーム時代にも、チーム内にSREが所属しており、SREの取り組みも業務に含まれていました。
が、チーム内に肩書上SREでないメンバーも属しており、業務範囲とジョブタイトルの区分が明確でない状態でした。

その辺りを明確にすることと、チームとしてSite Reliability Engineeringを推進していく姿勢を打ち出すことを目的として、「SREチーム」と改称することを私が提案しました。
その提案がメンバーやマネージャー陣に快く受け入れられ、改称に至りました。

インフラチームがこれまでやってきたこと

エムスリーのインフラチームが従来、主に担当していた業務は次のようなところでした。

  • システム構築や改修における基礎部分の対応:
    • オンプレミスの場合、ハードウェアの調達や設置を伴うことも。
    • OS, ミドルウェア、アプリケーション実行環境のセットアップと構成管理
  • ログの収集と可視化
  • システム監視やアラート対応
  • セキュリティの維持
  • 開発・QA環境の整備

SREチームとしてこれからやっていくこと

SREチームになったからといって、インフラチームが担っていた業務をなくせるわけではありません。 従って、上記の業務は基本的にSREチームが引き続き担当しています。
加えて、以下についても（より積極的に）取り組んでいきます:

  • 各サービスのSLI/SLOの管理
  • トイルの削減
  • ソフトウェアエンジニアリング(〜コードを書くこと)による問題解決の推進

この内、「SLI/SLOの管理」については、メンバーの高橋が先日記事を書いてくれました。

また、チームのミッションも定めましたので、紹介します。

SREチームミッション

  1. エムスリーが提供するサービスのシステム基盤について、現在から将来に渡って高い信頼性やセキュリティを保った管理・運用を行うことで、顧客が安心して快適にサービスを利用できるようにする。
  2. ビジネス要求や環境の変化に素早く柔軟に対応できるようなシステム基盤を実現し、スケール可能なチームづくりとその維持を行う。

これらのミッションを果たし続けられるように、頑張っていきます。

まとめ

エムスリーにおけるSREチーム発足の経緯と、その役割やミッションについて記しました。
今後もこのテックブログ等を通じて、SREの活動を紹介していければと思います。

SREを募集しています！

エムスリーでは私たちと一緒にソフトウェアの力でサービスの信頼性を守るSREを大募集しています！
ご興味のある方は是非、下のフォームからご連絡下さい。
なお、SREの募集要項はこちらです。

builderscon tokyo 2018 に初参加&LTしてきた

イベント

エムスリーエンジニアリングG松原@ma2geです。 builderscon tokyo 2018 に参加してきたのでブログにまとめます。

builderscon ですが、実は 2016 年開催の第1回目からとても参加したかったカンファレンスです。 理由は技術のことであればテーマをあまり絞っていないことでした。 私自身色々な技術が好きで、プライベートではキーボードのファームウェアを弄ってたり、 キャリアとしては組み込みから始まって、サーバサイドに移ったりと色々なことをしています。 ですのでまさに builderscon のようなカンファレンスがあったら参加したいとは常々思っていました。 これまで都合がつかなかったりで参加できていなかったのですが、第3回目にしてようやく参加することができ内容も期待通りだったので感無量です。

特に印象に残ったセッション

Microservices、DB、設計、テスト、IoT と本当に様々なセッションがあったのですが、ここでは特に印象に残っているセッションを2つだけピックアップします。

「ファミコンエミュレータの創り方」

ファミコン世代なのでどうしても見たかったセッションです。 資料の中身もかなり濃くて、どう見ても 60 分で終わらない感じの充実っぷりだったのですが、 終始 LT な感じのテンションで進み、気づいたらちゃんと終わっていました。 発表者の熱がこっちにも伝わってきて、ライブじゃないと味わえない楽しさがありました。 私も機会があったらこの資料を読んでエミュレータにチャレンジしたいと思いました。

ファミコンエミュレータの創り方 - builderscon tokyo 2018

「なぜ私はキーボードを作るのか」

同じ沼に住むもの同士ということで、参加せざるを得なかったセッションです。 自作キーボードでの失敗を惜しげも無く公開してくれていて、かなり盛り上がった発表でした。 この後に自分の発表だったので自作キーボードに対して参加者の方を盛り上げていただけたのはとてもありがたかったです。 「自分に道具を合わせる」というメッセージはプロフェッショナルな印象を受けて心に響きました。

なぜ私はキーボードを作るのか - builderscon tokyo 2018

LT でキーボードのカスタマイズについて発表してきた

Lightning Talk に選んでいただけたので発表してきました。 発表したカスタムのファームウェアは会社の ErgoDox EZ にも入れて使っています。

f:id:ma2gedev:20180910162915j:plain
右側の特別感のあるキーが発表したやつです

発表内容の詳細はこちらをご覧ください。

medium.com

イベントを通しての感想

参加していて困ることはほとんどなくて、休憩にコーヒー飲みに行ったり、うまい棒もらったり、WiFi も繋がるし快適でした。 強いて言えばランチがあるのかないのか良くわかっておらず、 弁当売り切れっぽい状況からランチ探すことになったり(ランチ情報のおかげでそんなに困らなかったですが)、 電源がなかったので LT するまで電源切らさないように気をつけないといけなかったくらいでしょうか。

セッション関連

相当数ある CFP をくぐり抜けて来ているだけあって、参加したどのセッションも参加していてよかったと感じることができる内容でした。 あと質問も比較的長めに受け付けてくれるので、理解が深まったり、双方向のコミュニケーションが生まれるきっかけになってよかったです。 人気セッションだとすぐに立ち見になっちゃうのが少し厳しかったですね。 動画公開される前提でいくつか参加を諦めたセッションもありました。

サポーター特典

今回サポーターチケットで参加したので電子ガジェット(電子名札)を受け取って遊びつつセッションを聞いていました。 電子ペーパー付きって結構珍しいので、これから会社で色々試してみようと思います(参加費用を会社で出してもらっています)。 イベントで電子ガジェットつき、しかも自分でカスタムできるものがついてきたのは、とても面白かったので次も期待しています。

まとめ

あれだけ人が参加しているイベントで、大きなトラブルもなく進行していたのは発表者、参加者、スタッフの皆様のおかげかなと思います。 技術を楽しむことに集中でき、とても満足できたので、本当にありがとうございました。

エムスリーも色々な技術を使っており、9/27(木) に行う M3 tech meetup でも、9/18(火) に行う OSS もくもく会第4回でも技術に縛りはありません。 もし興味がありましたらご参加お願いします。

m3-engineer.connpass.com

m3-engineer.connpass.com

We're hiring

エムスリーにはカスタムしたキーボードを使っていたり(そのうちキーボード特集したい)、IoT ガジェットを趣味で作っている技術好きなエンジニア達がいます。 そんな仲間達と一緒に、手を動かし、技術で医療の課題を解決するエンジニアを募集しています。興味を持った方はぜひ下記リンクよりご応募ください!

M3 tech meetup! #4 ～医療を支えるエンジニアのLT大会～ を開催します！

エンジニアリングG、ソフトウェアエンジニアの @suusan2go です。この度、「M3 tech meetup!」というテックイベントを開催することになりました！

M3 tech meetup

  • 日時
    • 2018/09/27(木) 19:00 〜 21:30
  • 会場
    • エムスリー (赤坂インターシティ)
      • 溜池山王駅（銀座線、南北線）

詳細は以下をご確認ください。

m3-engineer.connpass.com

M3 tech meetup とは？

M3 tech meetupの前に、Teck Talkについて説明させてください。エムスリーでは、月2回ほどの頻度でTech Talkという社内LTイベントを開催しています。このTech Talkの凄いところは、もう数年継続して開催されているということです。実は9月には通算で100回目のTech Talkが開催されます。100回目ともなると正直マンネリ化しているんじゃないかと思う方もいると思いますが、フロントエンドからバックエンド、機械学習、モバイル、インフラ、セキュリティなど様々な分野の発表が現在も活発に行われています。

たとえば最近では以下のような発表がありました。

docs.google.com

docs.google.com

今回のM3 tech meetupはこのTech Talkの社外公開版という位置づけです！これまでTechTalkで発表されたものの中から評判の良かったものと新ネタを合わせて社外の方々にもバーッンと公開します。

登壇者・内容紹介

「API サーバを GraphQL でリニューアルした我々は」

現在開発中の API サーバを GraphQL でリニューアルするプロジェクトで見えてきた、GraphQL の輝いている点と、デメリットの部分を話す予定です。

登壇者：松原 崇幸 @ma2ge

マルチデバイスチームという Android/iOS からサーバサイドも開発するチームのチームリーダーをしています。 Ruby/Elixir が好きで OSS として公開しています。隙あらば Elixir を導入しようと日々狙っています。

「怖くないCats」

Scalaの関数型ライブラリCatsを題材に、関数型プログラミングは怖くないということを説明します。

登壇者：冨岡 純 @jooohn1234

電子カルテチームリーダー。社内でScalaや関数型プログラミングを布教しています。

「Knowledge Graphをうまいこと使ってシャーロック・ホームズを作る」

青空文庫「まだらのひも」の犯人はお前だ！！！ もうミステリ読んで犯人を当てられない悔しさとはサヨナラ！！！

登壇者：大瀧 貢 @_329_

AIチームで自然言語処理と推薦システムやってる @329 です、ダジャレを言ったら笑ってください

「AWS FargateでElixirのコンテンツ管理システムを運用してみた」

夏の AWS Fargate & Amazon ECS/EKS 祭り で発表した内容です。ElasticBeanstalk から Fargate への移行について。

園田 亮平 @ryoryoryohei

M3遊撃エンジニア。所属はゲノムチームだが、いろんなサービス（主にtoC）を手がけてる。もっぱらAWS案件が多いけど、JavaとJSでWebアプリ書きたい人。

「VTuberって知ってます？」

最近流行りのVirtual Youtuberを取り巻く環境と動向、それらを支える技術のざっくりとしたお話をします。

青木 大樹 @blue_1617

電子カルテチーム期待の新人。趣味はEmacsいじりとVTuber鑑賞。発表内容が浮いてて笑っている今日この頃。

「今だから話せるリニューアルの裏側」

約1年半かけて実施したシステムリニューアルで出会ったアンチパターンや失敗談についてお話しします

前原 秀徳 @maeharin

エムスリーではサーバーサイドKotlinやVue.jsを用いたシステムリニューアルを実施。自慢は、はてぶ1200超えしたこと

豪華(当社比)な登壇者から様々な知見を一気に聞ける場となっております！

ぜひご参加ください！

connpass から申し込みしてください！お待ちしています！ m3-engineer.connpass.com