エムスリーは「Kotlin Fest 2019」にことりスポンサーとして協賛＆社員が登壇します

こんにちは、エンジニアリンググループの渡辺です。

エムスリーは、8/24 (土)に開催される Kotlin Fest 2019 にことりスポンサーとして協賛いたします！当日はブースを出展し、弊社のKotlinエンジニアもブーススタッフとして参加していますので、是非お越しください。

2019-08-16

突撃！隣のキーボード M3 2019

インタビュー

こんにちは、エムスリーエンジニアリンググループ AIチームに今年の2月にジョインしました河合 (@vaaaaanquish) です。エムスリーテックブログでは今回初めての投稿で緊張しますが、お手柔らかにお願いします。

はじめに

近年、ソフトウェアエンジニアの「キーボード」への熱は高まり続けています。

昨年には、DMMさんにてキーボードをこよなく愛する人達によるイベントが開催され、250人以上が集まり、自作のキーボードやキーキャップを扱うノウハウが広く共有されました。 inside.dmm.com

また2018年を振り返ると、自作キーボード専門店である遊舎工房の実店舗がオープンしたり、Cookpadさんはインターンでも自作キーボードの作成を取り入れて話題になりました。 techlife.cookpad.com こちらのインターンは、PCBでのリバースエンジニアリングやキーボードの回路の設計など、非常に充実したインターンだったという報告のブログが参加者によって複数書かれています。*1 *2

*1:http://precure-3dprinter.hatenablog.jp/entry/2019/03/21/Cookpad_Spring_1day_Intern_%E8%87%AA%E4%BD%9C%E3%82%AD%E3%83%BC%E3%83%9C%E3%83%BC%E3%83%89%E3%82%B3%E3%83%BC%E3%82%B9%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F

*2:https://yuchi-kbd.hatenablog.com/entry/2019/03/24/013714

2019-08-15

APIのコードを自動生成させたいだけならgRPCでなくてもよくない?

こんにちは、エンジニアリンググループの福林 (@fukubaya) です。

先月から、今年の秋くらいにリリース予定の新サービスの設計、開発を始めました。せっかく新しく始めるサービスなので、まだ経験したことがない言語やフレームワーク、技術を使わないと楽しくありません。

そこで、バックエンドにGoにして、フロントのAPIまで含めてgRPCの .proto ファイルで定義を一元化し、APIコードは protoc で生成させる計画を立てていたのですが、

フロントでgRPCとなると、 gRPC-web か grpc-gateway になるが、リリースまでに使える期間では認証も含めると検証が間に合わなさそう
Goだけでなく、terraform(インフラ設計もやります) も Vue.jsも今回が初めて、というメンバーもおり、さらにRESTではなくgRPCも、となると未経験技術が多すぎてキャッチアップが追いつかなさそう

ということもあって見送りました。

それでも何かしら新しく触る言語やフレームワークは入れたいので、今回はバックエンドにSpringBoot(Kotlin)を、フロントエンドに Vue.js(Typescript)を使うことになりました*1。gRPCは見送ったので、RESTのAPI定義一元化、コード自動生成を実現するためOpenAPIを利用することにしました。

f:id:fukubaya:20190813220337j:plain — パシフィコ横浜は、横浜市にある世界最大級の国際会議場と展示ホールとホテルからなるコンベンション・センター。本文には特に関係ありません。

*1:Typescriptは前プロジェクトで諦めていたので今回入れたかった https://www.m3tech.blog/entry/2019/04/23/114832

2019-08-13

【Sansan 藤倉成太×エムスリー山崎聡】「二者択一の考え方はエンジニアのキャリアを先細りさせるだけ」（エンジニア type 対談後記）

エムスリーエンジニアリングGでVPoEをやっている山崎です。

先日、Sansan株式会社CTOの藤倉さんとエンジニアのキャリアについて対談させて頂きました。対談中に感じたことや、対談を振り返ってみて改めて感じたことについて書いてみたいと思います。

type.jp

きっかけ

f:id:yamazaki-m3:20190812174034j:plain — 先日の対談にて

藤倉さんとの出会いは、2017年12月にエムスリーの初代VPoEに就任した後、改めて他社のCTOやVPoEについて学んでいた頃にCTOミートアップでお見かけしたのが最初だったと思います。その後、機械学習関連の勉強会などでSansanさんとご一緒する機会も増え、藤倉さんと別のイベントでご一緒することもあり、ビジネス領域の課題を解決する同志として意気投合したのが今回のイベントのきっかけとなりました。

「現場」か「マネジャー」か、という議論を振り返って

これは採用活動でエンジニアのキャリア相談に乗っていると、本当によく耳にする悩みです。考えの多くは対談中に触れたとおりですが、このような二者択一の考えになってしまう原因の一つは、日本のソフトウェア産業における「現場」と「マネージャー」の報酬格差にあるのではないか、というのが、対談で触れなかった考えです。

というのも、1980年代のマイコン黎明期から始まり1990年代を経てWeb関連のビジネスが一般的になる前の2000年頃までの日本のビジネス向けのソフトウェア産業は、どちらかといえばメーカー製品にバンドルされるようなパッケージソフトウェアや、何十人何百人で作り上げる大型のソフトウェアプロジェクトなどが主流だったため、ソフトウェアを発注する側と受託する側の切れ目が比較的明確で、その中でソフトウェアを作り上げる作業もマネージャーが指示を出し、現場のエンジニアが構築するという比較的トップダウンな開発が主流だったと思います。

その結果、典型的なSI構造、つまり基本的には（一部のスーパープログラマーを除いて）マネージャーのほうが報酬が高く、現場のエンジニアが報酬が上がりにくいという構造が出来上がりました。そのような環境の中では、対談中に触れた「やりたいこと」を続けようとしても、ライフステージの変化とともに、そろそろ現場から離れてマネージャーに上がらなくては…と考えてしまうという強い力学が働くのもある意味仕方ないと思います。