エンジニアリンググループの三角です。
エムスリーは、4/18(木)から4/20(土)に開催される RubyKaigi 2019 に今年もプラチナスポンサーとして協賛します! エムスリーでは、コンシューマ向け事業やキャリア事業など複数のプロダクトで Ruby を使用しており、一緒にコミュニティを盛り上げるべく協賛することにしました。 当日は弊社の Ruby エンジニアも参加し、ブース出展もしていますので、是非お越しいただけたらと思います。
続きを読むエンジニアリンググループの三角です。
エムスリーは、4/18(木)から4/20(土)に開催される RubyKaigi 2019 に今年もプラチナスポンサーとして協賛します! エムスリーでは、コンシューマ向け事業やキャリア事業など複数のプロダクトで Ruby を使用しており、一緒にコミュニティを盛り上げるべく協賛することにしました。 当日は弊社の Ruby エンジニアも参加し、ブース出展もしていますので、是非お越しいただけたらと思います。
続きを読むエンジニアリンググループの水野です。
サービスのUX改善活動の一環で、ユーザーのサービス利用頻度・利用の質と利益との関係を計測した際に気づきがあったためご紹介します。
私たちのチームでは主に、医療系ポータルサイトであるm3.comのメディア系のサービス開発を担当しています。担当しているサービスの中には直接的に収益を産むわけではないサービスもありますが、知識を得る、診療に役立つ、または楽しんでいただける価値をユーザーに提供し、収益を生む別のサービスも利用いただくことで間接的に収益を生み出しています。
古くから動いているサービスも多く、UXにはまだまだ課題が多くあります。「デザインを重視する企業の株価成長率は高い」、「ユーザーファースト」などとよく言われますが、実際にUX改善の効果を数値化し評価することは難しいと感じます。
利益を優先すると、UI/UXはしばしば後回しになりがちです。それはUI/UXの向上が利益にどう結びつくか一見分かりにくいことが原因です。つまり、UI/UXの効果を定量的に示し、他の施策と比較可能な形で説明できなければ、UI/UXの向上に取り組みにくい場合があります。
したがって、提供価値を最大化するUI/UX改善を絶えず進めるために、その効果を定量的に計測できるようにすることが重要であると考え、今回UI/UXと利益の関係を分析してみました。
チームでは、ユーザーへの提供価値を最大化しイケてるサービスにするために、ユーザーのニーズと体験、その評価を可視化すること、またそのための組織やプロセス構築、プロダクト開発を進めています。
その活動の一環で、あるサービスで、サービスの利用頻度・利用の質*1とNPS*2、利益との関係を計測した結果、次のようなことが分かりました。*3
またヘビーユーザーへのアンケートで次のことが分かりました。
上記結果から次の仮説が考えられます。
一見当たり前の事であるように思えますが、特に直接収益を生まないサービスにおいては実際に可視化されていないことも多くあります。本当にそうなのか、そしてどの程度そうであるのかを示していくことが大切だと考えています。
私たちのチームでは、これまで以上にUX改善に力を入れていきます。 プロダクトの改善だけではなく、UX指標の定量的な計測手法・計測環境の構築、ブランディング強化などにも取り組んでいきます。
エムスリーでは、フロントエンドエンジニア、UI/UXデザイナー、プロダクトマネージャー等の採用も強化しています。
m3.comは、既に国内の相当数の医療従事者に利用いただいていますが、ユーザー体験・サービスの質の向上による伸び代はとても大きいと感じています。巨大でレガシーな医療業界は変革の可能性に満ち溢れており、社会貢献度の大きい業界でユーザー体験をよりベターなものに、一緒に変えていける仲間を募集しています。
こんにちは、エムスリー・エンジニアリングG・基盤開発チーム小本です。
SQLAlchemyはPythonのSQLライブラリのデファクトスタンダードで、エムスリーでも使っていますが、意外と導入の障壁が高い。そこで、とりあえずSQLAlchemyを使い始めるのに必要な情報を調べました。
具体的には生の(文字列の)SELECT文を組み立て、クエリする方法を説明します。
SQLAlchemy の入門記事をググると、
SQLAlchemy は ORM です DBに接続しメタデータを取得します ベースモデルを継承し、モデルを定義し、テーブルと関連づけます
といった、 「重い」使い方の記事ばかりがヒットします。そのせいか、
という誤解をしている人も中にはいるようです(これについてはPlaySQLAlchemy: SQLAlchemy入門というスライドが秀逸です)。
しかし、実際にはエムスリーでは(多分他の現場でも)、SELECT文を組み立てクエリするだけの「軽い」使い方がむしろメインです。そこで、新入社員や他部署から異動してきた新メンバー用に「軽い」使い方の入門とした書いたのがこの記事です。
続きを読むエンジニアリンググループの松原@ma2geです。
先日、株式会社日本経済新聞社のエンジニアの方々にお越しいただき、Kotlin 座談会を開きましたのでその様子を報告します。
日本経済新聞社様からは、長島様、浦野様、野口様の御三方が、弊社からは滝安、松原と技術フェローの前原が参加しました。 長島様が課金周りを、浦野様、野口様が認証周りのシステムを担当されているとのことです。
続きを読む
2019 年度から M3 (日本)の CTO を Global CTO の Brian から引き継いだ矢崎(id:Saiya)です。
...とは言いましたものの、CTO という単語は幅広い解釈が可能であり、M3 の CTO がどのようなものかというのも自明ではないように思われます。
そこで、弊社の特性・魅力の宣伝も兼ねて、M3 における CTO が(現時点で)どのようなことを目指しているのか、を記してみました。
弊社は2000年の創業から 19 年弱を経ている企業です。
「インターネットを活用し、健康で楽しく長生きする人を一人でも増やし、不必要な医療コストを一円でも減らすこと」をビジョンに、インターネット・コンピューティング技術を活かしたビジネスを展開しております。
19 年という歴史はありますが、しかし会社説明資料*1の背景画像の建設中のサグラダファミリアが暗示しておりますように、事業の新規拡大・成長余地はまだまだ存在する、というのが弊社の考えです。
そのような中で、技術的側面を中心にエンジニアリングを補佐する意味合いで CTO を拝命いたしました。
CTO と言いましたものの、企業によってニュアンスに違いがあるのが現状であり、厳密な定義は確立されていないのではないでしょうか。そこで語義に立ち返りますと、英語の officer
は "A person holding a position of authority" すなわち階層構造上の権威を持つ人と解釈できます *2。
よって、CTO の言葉上の意味としては「エンジニア組織階層上の第一権限・権威を持っている人」が自然なように思われます。
では、M3 のエンジニアリングにおいて、 権限・権威を持っている人
が必要なのでしょうか?
私はそのようには考えませんし、業務執行役員 VPoE (VP of engineering) の山崎も同意見でした。
なぜならば、M3 のエンジニア文化の良い点として、 Microservice 的な分散・自治の文化
*3 があります。例えば特定の技術を採用するべし!といった圧はなくチームごとに自主的に採用技術を決めていますし、全社の文化的にも上意下達よりもフラットな文化が重視されています。
権限・権威に基づいて動くのではなく、お互いをプロフェッショナルとして尊重*4し対等なプロとしてロジカルに対話して物事を決めてゆくというのが弊社の文化であり良い点です。なので、その美風を維持しまた高めてゆくというのが意図するところです。
また、前掲の会社説明資料にありました通り、弊社は 2018 時点で事業タイプ数 26、展開事業数 41、売上 945 億円の規模となっております。このように多様なビジネス・サービスが存在するため、CTO という個人が全てのプロダクトやチームの状況を常時完全把握するのは不可能です。
この点を踏まえても、それぞれのプロダクトの状況を最もよく知っている各チームの判断が尊重されるべきものと私は考えております。
上記の考えに基づき、M3 における CTO としては以下を目指しております:
まだ始まったばかりでありピボットする可能性もありますが、例えば以下のような取り組みを考えております:
このような取り組みを通してエンジニアをエンパワーメントし、その結果として「インターネットを活用し、健康で楽しく長生きする人を一人でも増やし、不必要な医療コストを一円でも減らすこと」をしてゆけたらと存じます。
本記事とあわせて、事業や組織の拡大をエンジニアリング観点で担う VPoE (VP of Engineering) 山崎のインタビュー記事などもご覧いただけますと、より弊社の社風や雰囲気を感じていただけるかと存じます:
弊社のフラットかつ個々のエンジニアが活躍する文化や、あるいは技術が好きな人間が集まっている点、または 本ブログや Qiita で発信しておりますさまざまな取り組みなど、何かしらの点に少しでもご興味をお持ちいただけましたら、ぜひ下のリンクよりご応募ください。
カジュアル面談でお話しいただくことで、あなたのバックグラウンドに応じたより的確な情報をお伝えできればと思います:
*1: 2019 年 1 月の会社説明資料 p25 より引用
*2:また、CTO という単語の由来の説の一つとして、軍組織における技術面の意思決定を行う将校というものもあるそうです: https://en.wikipedia.org/wiki/Chief_technology_officer
*3:この表現は私が使っているフレーズですが、社内のシステムの技術的な実態としても microservice 的な構成が多いです。そのようなシステム構成自体が企業文化を反映しているのではないかとも個人的には思っております。
*4:このフレーズは創業時からある 3 つの行動規範のうちの一つです。クライアント・いい仕事に対する執着心、社長意識を持って仕事に臨む、みなをプロフェッショナルとして尊重、の 3 つが掲げられています
こんにちは、エムスリー エンジニアリングGの大和です。
3/27 (水) にCrowdWorksさん *1 のオフィスをお借りして、「どこでもKotlin #7 〜Kotlin MPP特集〜」を開催しました。
発表順に内容および資料を紹介します (敬称略)。
yashims85さんからは、Kotlin/MPPでクロスプラットフォーム対応する場合のつまずきポイントをご共有いただきました。 Vue Router InspiredなライブラリKoRouter *2 も開発されているそうなので、是非チェックしてみてください!
続きを読むエンジニアリンググループでアンケートを作るためのシステムを開発している岩本です。
エムスリーが実施するアンケートでは、薬剤ごとの処方数や患者数などを入力してもらうために、下記のように表形式で数値入力を大量に入力してもらうことが頻発します。
上図のように5 * 10程度の表となることも珍しくありませんし、それが1アンケート中に複数ページでてきます。 また、入力値のバリデーションを定義しますが、全て同一ではなく、少しだけ異なっているため、全て同一の定義とすることもできません。
アンケートを作成する人は、このバリデーションの定義をしないといけないのですが、普通のWebシステムのインタフェースだとかなり辛いものがあります。 マウスでぽちぽち5 * 10もの定義をひたすら繰り返すことも現実的ではありません。
そこで、スプレッドシートUIライブラリのHandsontableで大量のバリデーション定義を効率化したので、その紹介をします。
続きを読む