エムスリーテックブログ

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

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

f:id:deltama:20190404113253j:plain
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倍利益が高い

f:id:takao-mizuno:20190329142043p:plain
サービスの利用頻度・質

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

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

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

f:id:takao-mizuno:20190329160706p:plain
ユーザーが魅力に感じている項目

仮説

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

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

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

これから

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

We are hiring!

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

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

jobs.m3.com

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

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

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

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

One cup ozeki regular 2014

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

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

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

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

なぜこの記事を書いたか

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

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

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

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

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

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

続きを読む

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

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

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

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

f:id:ma2gedev:20190401143946j:plain

続きを読む

M3 における CTO - 権威ではなくロールとしての CTO

2019 年度から M3 (日本)の CTO を Global CTO の Brian から引き継いだ矢崎(id:Saiya)です。

...とは言いましたものの、CTO という単語は幅広い解釈が可能であり、M3 の CTO がどのようなものかというのも自明ではないように思われます。

そこで、弊社の特性・魅力の宣伝も兼ねて、M3 における CTO が(現時点で)どのようなことを目指しているのか、を記してみました。


エムスリー (株) について

弊社は2000年の創業から 19 年弱を経ている企業です。

「インターネットを活用し、健康で楽しく長生きする人を一人でも増やし、不必要な医療コストを一円でも減らすこと」をビジョンに、インターネット・コンピューティング技術を活かしたビジネスを展開しております。

f:id:Saiya:20190315152644p:plain

19 年という歴史はありますが、しかし会社説明資料*1の背景画像の建設中のサグラダファミリアが暗示しておりますように、事業の新規拡大・成長余地はまだまだ存在する、というのが弊社の考えです。

そのような中で、技術的側面を中心にエンジニアリングを補佐する意味合いで CTO を拝命いたしました。

CTO (Chief Technology Officer) とは...?

CTO と言いましたものの、企業によってニュアンスに違いがあるのが現状であり、厳密な定義は確立されていないのではないでしょうか。そこで語義に立ち返りますと、英語の officer"A person holding a position of authority" すなわち階層構造上の権威を持つ人と解釈できます *2

よって、CTO の言葉上の意味としては「エンジニア組織階層上の第一権限・権威を持っている人」が自然なように思われます。

M3 におけるエンジニアリングと CTO のロール

では、M3 のエンジニアリングにおいて、 権限・権威を持っている人 が必要なのでしょうか?

私はそのようには考えませんし、業務執行役員 VPoE (VP of engineering) の山崎も同意見でした。

なぜならば、M3 のエンジニア文化の良い点として、 Microservice 的な分散・自治の文化 *3 があります。例えば特定の技術を採用するべし!といった圧はなくチームごとに自主的に採用技術を決めていますし、全社の文化的にも上意下達よりもフラットな文化が重視されています。

権限・権威に基づいて動くのではなく、お互いをプロフェッショナルとして尊重*4し対等なプロとしてロジカルに対話して物事を決めてゆくというのが弊社の文化であり良い点です。なので、その美風を維持しまた高めてゆくというのが意図するところです。

また、前掲の会社説明資料にありました通り、弊社は 2018 時点で事業タイプ数 26、展開事業数 41、売上 945 億円の規模となっております。このように多様なビジネス・サービスが存在するため、CTO という個人が全てのプロダクトやチームの状況を常時完全把握するのは不可能です。

この点を踏まえても、それぞれのプロダクトの状況を最もよく知っている各チームの判断が尊重されるべきものと私は考えております。

上記の考えに基づき、M3 における CTO としては以下を目指しております:

  • こうしてゆく: 多サービスを展開・維持するための足回りを手伝ったり応援する役割のエンジニア (ロールであり、対等なエンジニア)
  • こうではない: トップダウンな意思決定をする、技術者の上に位置する上司・役員 ("CTO" の原義である権威・権限のイメージ)

今後の取り組み

まだ始まったばかりでありピボットする可能性もありますが、例えば以下のような取り組みを考えております:

  • 全体でやるとメリットがある or スケールする技術課題の推進
    • 例えば Distributed Tracing の導入推進など
  • サービスの立ち上げや改善の現場に混ざって支援
    • そこで得たものを他のチームへもフィードバック
  • その他、サービス立ち上げ時などのレビューにも混ざって技術面の知見支援や情報交換をする

このような取り組みを通してエンジニアをエンパワーメントし、その結果として「インターネットを活用し、健康で楽しく長生きする人を一人でも増やし、不必要な医療コストを一円でも減らすこと」をしてゆけたらと存じます。

See also

本記事とあわせて、事業や組織の拡大をエンジニアリング観点で担う VPoE (VP of Engineering) 山崎のインタビュー記事などもご覧いただけますと、より弊社の社風や雰囲気を感じていただけるかと存じます:

www.m3tech.blog

We are hiring

弊社のフラットかつ個々のエンジニアが活躍する文化や、あるいは技術が好きな人間が集まっている点、または 本ブログQiita で発信しておりますさまざまな取り組みなど、何かしらの点に少しでもご興味をお持ちいただけましたら、ぜひ下のリンクよりご応募ください。

カジュアル面談でお話しいただくことで、あなたのバックグラウンドに応じたより的確な情報をお伝えできればと思います:

jobs.m3.com

*1: 2019 年 1 月の会社説明資料 p25 より引用

*2:また、CTO という単語の由来の説の一つとして、軍組織における技術面の意思決定を行う将校というものもあるそうです: https://en.wikipedia.org/wiki/Chief_technology_officer

*3:この表現は私が使っているフレーズですが、社内のシステムの技術的な実態としても microservice 的な構成が多いです。そのようなシステム構成自体が企業文化を反映しているのではないかとも個人的には思っております。

*4:このフレーズは創業時からある 3 つの行動規範のうちの一つです。クライアント・いい仕事に対する執着心、社長意識を持って仕事に臨む、みなをプロフェッショナルとして尊重、の 3 つが掲げられています

どこでもKotlin #7 〜Kotlin MPP特集〜 を開催しました

こんにちは、エムスリー エンジニアリングGの大和です。

3/27 (水) にCrowdWorksさん *1 のオフィスをお借りして、「どこでもKotlin #7 〜Kotlin MPP特集〜」を開催しました。

m3-engineer.connpass.com

発表内容

発表順に内容および資料を紹介します (敬称略)。

KotlinAndroid/iOS両対応事始めのつまづきポイント -- yashims85(モバイルファクトリー)

yashims85さんからは、Kotlin/MPPでクロスプラットフォーム対応する場合のつまずきポイントをご共有いただきました。 Vue Router InspiredなライブラリKoRouter *2 も開発されているそうなので、是非チェックしてみてください!

続きを読む

スプレッドシートライブラリHandsontableの1セルで構造化されたデータを扱う

エンジニアリンググループでアンケートを作るためのシステムを開発している岩本です。

エムスリーが実施するアンケートでは、薬剤ごとの処方数や患者数などを入力してもらうために、下記のように表形式で数値入力を大量に入力してもらうことが頻発します。 f:id:cpw:20190328103315p:plain

上図のように5 * 10程度の表となることも珍しくありませんし、それが1アンケート中に複数ページでてきます。 また、入力値のバリデーションを定義しますが、全て同一ではなく、少しだけ異なっているため、全て同一の定義とすることもできません。

アンケートを作成する人は、このバリデーションの定義をしないといけないのですが、普通のWebシステムのインタフェースだとかなり辛いものがあります。 マウスでぽちぽち5 * 10もの定義をひたすら繰り返すことも現実的ではありません。

そこで、スプレッドシートUIライブラリのHandsontableで大量のバリデーション定義を効率化したので、その紹介をします。

続きを読む