TypeScript用のDIライブラリを公開しました

エンジニアリンググループの冨岡です。

TypeScript向けのDIライブラリを公開したので紹介します。

github.com

モチベーション

Clean Architecture等の設計手法を使ってコードを書いていると、抽象に依存することが多くなってきます。

class CreateUserAccount {
  constructor(private userAccountRepository: UserAccountRepository) {}
}

const forProduction = new CreateUserAccount(
  new PostgreSQLUserAccountRepository(
    buildPostgreSQLConfig(process.env)
  )
)
const forTest = new CreateUserAccount(new InMemoryUserAccountRepository());

テストしやすく、また責務がはっきりわかれていて良いですよね。ただ、別の辛みもいくつかでてきます。

• インスタンスの組み立てが巨大で、かつ順番に依存にした複雑な処理になる
• 本番用とテスト用など、共有したい部分とそうでない部分がでてきてうまく管理するのが面倒になってくる

こういった辛みに対応するのがDIライブラリです。しかし私の調べた限りでは、既存のDIライブラリは少し大げさな印象でした。 例えばメジャーなライブラリであるInversifyJSは、decoratorをベースにしており大げさ＆マジカルです。

依存先を容易に切り替えられる既存のライブラリの利点は残しつつ、以下を満たすシンプルなライブラリがほしいと思いました。

• 依存をシンプルに表現できる
• 変な魔法を使わず、明示的である

そこで作ったのがこのtypesafe-diです。

エムスリーエンジニアリンググループ第三回開発合宿を開催しました！

エンジニアリンググループ・マルチデバイスチームの金丸 (@maru333) です。

年度またぎのバタバタで遅れてしまいましたが(言い訳)、先日(3/15〜3/17)、第三回開発合宿を開催しましたので、その様子をご報告したいと思います！

ご参考までに、これまでの開催の様子 (第一回、第二回) も貼っておきますので、ご興味あればそちらもご参照ください！ (第一回の様子,  第二回の様子)

開発合宿を行っている背景

第一回でもご紹介していますが、基本的には日々の業務や既存施策ではできない「新しいもの」を生み出すことが目的だと思っています。
日々仕事をしているオフィスから離れ、少し歩けば海の音が聞こえるような快適な開発環境の中で、リラックスした状態で開発できること。普段別チームで、仕事上あまり関わることのないメンバーも含めて1つのチームになり、皆で立てたお題の中の1つについて好きなだけ開発をし続けられる環境というのは、開発合宿以外ではあまり実現できないことだと思います。
私も去年末にjoinしてから今回初参加の開発合宿でしたが、開催日が近づくワクワク感は何にも代え難いものがあります。また、今回はVPoE山崎が3日間フルに参戦となり、オフィスでは話せないようなくだらない話も含めて盛り上がり、楽しい時間を過ごすことができたことも付け加えておきます。

エムスリーの人事グループでエンジニアの採用担当を募集します!

人事の友永です。この度、人事としてエンジニア採用を担当いただく方を1名追加で募集、私と一緒に2名で担当していくことになりましたので（嬉しい！）この記事を通じて、エムスリーのエンジニア採用は楽しいぞ！ということをお伝えしたいと思います。

なぜ、採用担当を募集するのか

エムスリーのエンジニアリンググループは、2020年度末までにエンジニアの人数を約65名→120名の体制にしていきます。エンジニアリングで解決できる医療の問題はまだたくさんあり、エンジニアの力がもっと必要です。そのために、人事の採用担当を増やすことになりました。

エンジニア採用チームの構成

エンジニアの採用をどんな体勢で行っているかを説明します。特徴は人事の採用担当とエンジニアがチームを組み協力しながら日々の採用活動を行っている点です。

• 人事グループ

採用担当1名（私）ともう1名オペレーションをフォローしてくれるメンバがいます。ここにもう1名採用担当を募集します。 もちろんエンジニア以外の採用ポジションもあるので、人事グループには他にも採用担当が数名いますし、労務担当なども所属。これらメンバとの連携も日常的にあります。

• エンジニア採用チーム

エンジニアリンググループの中にあるチームです。VPoEの山崎さん、CTO矢崎さん、人事を兼務している機械学習エンジニアの西場さんに加え、現時点で3名のエンジニアがエンジニア採用チームを兼務しています。他にもエンジニアのグループリーダーやチームリーダー、面接官などが採用に関わっており、人事の採用担当はこれらのメンバと連携しながら日々業務を進めています。 加えて、技術顧問としてLINEの藤原さんが採用に協力してくださっています。藤原さんからは実践的なアドバイスをいただいたり、いつも本当に本当に丁寧に対応してくださるので、とても感謝しています！恵まれている環境ですね。

エムスリーは「RubyKaigi 2019」にプラチナスポンサーとして協賛 & ブース出展します

RubyKaigi2018のスポンサー欄

エンジニアリンググループの三角です。

エムスリーは、4/18(木)から4/20(土)に開催される RubyKaigi 2019 に今年もプラチナスポンサーとして協賛します！ エムスリーでは、コンシューマ向け事業やキャリア事業など複数のプロダクトで Ruby を使用しており、一緒にコミュニティを盛り上げるべく協賛することにしました。 当日は弊社の Ruby エンジニアも参加し、ブース出展もしていますので、是非お越しいただけたらと思います。

UX改善は利益に繋がる!? 利用頻度&利用の質が高いユーザーは平均の約8.4倍も利益が高かった

エンジニアリンググループの水野です。

サービスのUX改善活動の一環で、ユーザーのサービス利用頻度・利用の質と利益との関係を計測した際に気づきがあったためご紹介します。

チームの概要

私たちのチームでは主に、医療系ポータルサイトであるm3.comのメディア系のサービス開発を担当しています。担当しているサービスの中には直接的に収益を産むわけではないサービスもありますが、知識を得る、診療に役立つ、または楽しんでいただける価値をユーザーに提供し、収益を生む別のサービスも利用いただくことで間接的に収益を生み出しています。

チームの課題感

古くから動いているサービスも多く、UXにはまだまだ課題が多くあります。「デザインを重視する企業の株価成長率は高い」、「ユーザーファースト」などとよく言われますが、実際にUX改善の効果を数値化し評価することは難しいと感じます。

利益を優先すると、UI/UXはしばしば後回しになりがちです。それはUI/UXの向上が利益にどう結びつくか一見分かりにくいことが原因です。つまり、UI/UXの効果を定量的に示し、他の施策と比較可能な形で説明できなければ、UI/UXの向上に取り組みにくい場合があります。

したがって、提供価値を最大化するUI/UX改善を絶えず進めるために、その効果を定量的に計測できるようにすることが重要であると考え、今回UI/UXと利益の関係を分析してみました。

あるサービスに関する分析

チームでは、ユーザーへの提供価値を最大化しイケてるサービスにするために、ユーザーのニーズと体験、その評価を可視化すること、またそのための組織やプロセス構築、プロダクト開発を進めています。

その活動の一環で、あるサービスで、サービスの利用頻度・利用の質*1とNPS*2、利益との関係を計測した結果、次のようなことが分かりました。*3

サービスの利用頻度と利用の質の計測結果

• ライトユーザーに比べ、ヘビーユーザーは1.42倍利益が高い
• ライトユーザーのうち、サービス利用の質が低いユーザーに比べ、高いユーザーは1.21倍利益が高い
• ヘビーユーザーのうち、サービスを他者に薦めたいとは思っていないユーザー（批判者）に比べ、薦めたいと思っているユーザー（推奨者）は1.3倍利益が高い
• サービス利用者の平均的なユーザーに比べ、利用頻度&利用の質が高く、更に他者に薦めたいと思っているユーザー（推奨者）は8.43倍利益が高い

サービスの利用頻度・質

ユーザーが何に魅力を感じているか

またヘビーユーザーへのアンケートで次のことが分かりました。

• サービスを他者に薦めたいとは思っていないユーザー（批判者）は、特典を魅力に感じている人が比較的多い
• サービスを他者に薦めたいと思っているユーザー（推奨者）は、サービス自体の提供価値に魅力を感じている人が大半

ユーザーが魅力に感じている項目

仮説

上記結果から次の仮説が考えられます。

• 個々のサービスにおいて、ユーザーの課題解決や楽しさを追求すること、ユーザー体験を高めることが、m3.comや全体に最も利益をもたらす
• 特典は、来訪や定着化に一定寄与するが、サービス自体の提供価値に比べると利益への効果が低くサービスへの愛着や魅力には繋がりにくい

一見当たり前の事であるように思えますが、特に直接収益を生まないサービスにおいては実際に可視化されていないことも多くあります。本当にそうなのか、そしてどの程度そうであるのかを示していくことが大切だと考えています。

これから

私たちのチームでは、これまで以上にUX改善に力を入れていきます。 プロダクトの改善だけではなく、UX指標の定量的な計測手法・計測環境の構築、ブランディング強化などにも取り組んでいきます。

We are hiring!

エムスリーでは、フロントエンドエンジニア、UI/UXデザイナー、プロダクトマネージャー等の採用も強化しています。

m3.comは、既に国内の相当数の医療従事者に利用いただいていますが、ユーザー体験・サービスの質の向上による伸び代はとても大きいと感じています。巨大でレガシーな医療業界は変革の可能性に満ち溢れており、社会貢献度の大きい業界でユーザー体験をよりベターなものに、一緒に変えていける仲間を募集しています。

jobs.m3.com

*1:ユーザーの能動的なアクションの度合い。掲示板サービスであれば投稿数のような指標。

*2:NPS®は、ベイン・アンド・カンパニー、フレッド・ライクヘルド、サトメトリックス・システムズの登録商標です。

*3:調査の詳細は割愛します。

とりあえず使えそうな SQLAlchemy 入門（※ ORM機能は使いません）

物資難の時代、化学者はカップ酒をビーカー代わりに使った・・・らしい（本文とは関係ありません）

こんにちは、エムスリー・エンジニアリングG・基盤開発チーム小本です。

SQLAlchemyはPythonのSQLライブラリのデファクトスタンダードで、エムスリーでも使っていますが、意外と導入の障壁が高い。そこで、とりあえずSQLAlchemyを使い始めるのに必要な情報を調べました。

具体的には生の（文字列の）SELECT文を組み立て、クエリする方法を説明します。

なぜこの記事を書いたか

SQLAlchemy の入門記事をググると、

SQLAlchemy は ORM です DBに接続しメタデータを取得します ベースモデルを継承し、モデルを定義し、テーブルと関連づけます

といった、 「重い」使い方の記事ばかりがヒットします。そのせいか、

• 「SQLAlchemyは難しい」
• 「SQLAlchemyはORMだからウチには不要」
• 「SQLAlchemy使わずに文字列連結で済ますのがクール」

という誤解をしている人も中にはいるようです（これについてはPlaySQLAlchemy: SQLAlchemy入門というスライドが秀逸です）。

しかし、実際にはエムスリーでは（多分他の現場でも）、SELECT文を組み立てクエリするだけの「軽い」使い方がむしろメインです。そこで、新入社員や他部署から異動してきた新メンバー用に「軽い」使い方の入門とした書いたのがこの記事です。

日本経済新聞社さんと Kotlin 座談会を開きました

エンジニアリンググループの松原@ma2geです。

先日、株式会社日本経済新聞社のエンジニアの方々にお越しいただき、Kotlin 座談会を開きましたのでその様子を報告します。

日本経済新聞社様からは、長島様、浦野様、野口様の御三方が、弊社からは滝安、松原と技術フェローの前原が参加しました。 長島様が課金周りを、浦野様、野口様が認証周りのシステムを担当されているとのことです。