はじめまして・こんにちは、M3 CTO の矢崎です。
7/1 より業務執行役員も拝命いたしました。
とはいえ、引き続き M3 における CTO - 権威ではなくロールとしての CTO にあります通り、あくまで対等・フラットなエンジニアとして、テクノロジーの力を適正なバランス感・全体感で利用することによって インターネットを活用し、健康で楽しく長生きする人を一人でも増やし、不必要な医療コストを一円でも減らすこと に努めております。
ところで、先日 "垂直スケールの果ての db.r4.16xlarge で得た教訓" を Database Lounge Tokyo #6 の LT にて発表いたしました。
こちらの発表内容は弊社のプロダクトにおいて、実際に開発チーム複数名がさまざまな苦労や紆余曲折を経て得た知見を短時間に凝縮したものでございます。
続きを読む人事の友永です。先日エンジニア採用について記事を書きましたが、エムスリー ではデザイナーの採用も積極的に行なっています！というお話を本日はしたいと思います。
以前ご紹介した通り、2019年度エンジニアグループの採用数は26名、在籍人数は約90名になりました。デザイナーについても在籍人数を確認したところ、現時点で10名という状況でした。エンジニアが増えたことによりプロダクト開発のスピードが上がっていく一方でデザイナー不足が顕著になっておりバランスが悪い状態になりつつありました。そのため2020年度はデザイナー採用10名を目標に積極的に採用活動を進めていきます！
デザイナー不足という課題を解決するため、まずはデザイナー採用の知見がある人に話を聞こうと思い、当時ビズリーチのデザインマネージャーであった古結@ryusukekogetsuに会いに行きました。
続きを読むこんにちは、人事の友永です。エムスリーのエンジニアリンググループでは2020年度末に120名体制を目指し、引き続き積極採用をしています！この記事では2019年度の採用振り返りと2020年度の採用についてお伝えいたします。
2017年12月にVPoE制を導入するなど、エンジニアの採用を強化してきました。2017年度〜2019年度の中途採用承諾実績は以下の通りです。そして2020年度は34名を採用目標にしています。
2017年度と比較し2019年度は2倍以上の承諾数に至りました！ここに至るまでの具体的な取り組みはVPoE山崎の記事ご覧ください。
次に2019年度はどのような方がエムスリー に入社を決めてくれたのか、少し紹介したいと思います。
続きを読むエムスリーの山本です。趣味で作っていたダイヤ可視化ツールの技術的な側面の話をします。
ダイヤ可視化ツールです。時刻表ではありません。鉄道路線を比較するにあたって、本数の多寡や速達列車の比率とか本数の減り方とかが一発で分かるように可視化するものです。何のために必要かというと、鉄オタがダイヤ知見を深めるのに使います。つまりそういうやつです。
たとえばこれは小田急の昼頃の1時間に運行されている列車なんですが、
などが分かります。実際、新宿駅の利用者数の次に多い駅は町田駅だったりして、相当に長距離の利用者が多いのが特徴の路線です。
また、鉄オタならみんな架空鉄とか想像するのに使ったりするだろうとおもって、誰でも自由にデータ作れるようにしてみました。 最終的なレンダリングはコンピュータ側で扱うのが容易なJSONからレンダリングするのでJSONを作る必要がありますが、人間がJSONを直接書くのは面倒くさいので、CSVからJSONに変換するツールを別途用意しています。JSONファイルはWebで公開されているものであれば大体そのまま表示できます。内部的にはSVGでレンダリングしているので、そのままSVGをファイルに保存することができます。
実際のサイトは以下です。
https://ponkotuy.github.io/diagram-svg/menu.html
特にSPAを目指してなくてページ毎にTypeScriptをビルドしています。ページは3つあります。
作ったもののコアな部分はindex.tsで、JSONを読み込んでSVGレンダリングを行っています。
csv2json.tsはそのJSONを作るのが地味に面倒くさい、GoogleSpreadsheetからJSONを作成したい、となったので作りました。昔はExcel馬鹿にしてたんですが、表計算ソフトはデータ作成のUIが非常に優れているという認識に改めました。CSVなので特にGoogle Spreadsheetに限定はしてないです。(余談なんですがGoogleSpreadsheetのCSV出力、更新が遅いのですが何とかなりませんかね?)
フレームワークとしてVue.jsを使っています。一番大きな理由は慣れていたからですが、このような小さなツールだとあまり重厚長大なフレームワークを使いたくはないという理由もあります。
言語は基本的にTypeScriptです。JavaScriptあんまり好きではないんですが、型があるとだいぶん書きやすくなります。型システム的にもなかなか興味深いです。リテラル型とか。リテラル型を活用すると、以下のような1-10の値のみ許容する型、みたいなのが作れます。(Union Typeとのあわせ技です)
export type Speed = 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10
ビルドはWebpack。本当はgulp使いたかったけどシェアがWebpackの方が圧倒的に高いという話を聞いておそるおそる使ってみました。複雑なことはしてないので評価しづらいですが、不都合はないです。
このツールは、作った本人も沢山JSON作って公開しているので、JSONを追加したらmenuにも自動で追加して、git pushするだけでGitHub Pagesに反映される仕組みをGitHub Actionsで作りました。
GitHub PagesはGitHubにあるものをWebページとして公開できる仕組みで、色々なやりかたはありますが、gh-pagesブランチにHTMLを置く方法で使っています。
GitHub Actionsは他の人が作ったものをplugin的に使う機能があり、gh-pagesブランチに成果物をcommitするものもあります。
https://github.com/peaceiris/actions-gh-pages
実は最初は自前でそのためのスクリプトを作っていたんですが、GitHub Actionsの実行権限ではGitHub Pagesの中身を変更することができないらしく、GitHub Actionsだとgh-pagesは更新されるのにサイトは更新されない仕様があって、特に理由がないならこれを使った方がいいです。
という流れになっています。
SVGのレンダリングはライブラリ使っています。当初snapsvgでレンダリングしてたんですが、webpackかTypeScriptと相性が悪い感じなのか動かなかったので、途中でRaphaelに変更しました。大天使の名前を冠する厨二病感がすごい。snapsvgと違って@typesが入ってて型の補完効くのが良いです。
実際にSVGをレンダリングしている部分はひたすら配置に合わせてレンダリング位置を調整していくだけです。調整が退屈な上に気を抜くとすぐ読めなくなるほど複雑化します。今まであんま経験ないプログラミングなので結構苦戦しました。新機能入れるたびにリファクタしてます。あと綺麗なJSONを前提に作っているので、変なJSON食わせると簡単に鼻から悪魔が出てきそうです…。
おきまりですが、エムスリーでは技術に自信があるとか、ビジネスをまわしていける、というエンジニアを募集しています。見ていってください。
こんにちは。 エムスリーエンジニアリンググループ、プロダクトマネージャーの岩田です。
今回はユーザーインタビューを通じてリーン顧客開発を実践した話を書きます。
MVPの要件が全くミニマムでなくなってしまう、PDCAのサイクルが遅すぎる、といった（ありがちな）お悩みをお持ちのプロダクトマネージャーの皆様に役に立てるような情報を発信できればと思います。
続きを読む
