はじめまして、人事の友永です。エムスリーのエンジニアが日々どのようなチャレンジをしているのか、もっと皆様にお届けしたい！という思いから、インタビューシリーズを始めることになりました。
エムスリーのプロダクトは医療従事者向けのものが多く (注)、 実際にユーザーとして利用することが難しいこともあり「どんなプロダクトを作っているのかイメージしにくい」という声をいただいていました。そこで今回は、インタビューを通じてエンジニアの取り組みや普段の雰囲気もお伝えしたいと思います！
注) コンシューマ向けプロダクトもあります
第1回目は医師・薬剤師キャリアチームで行ったサーバサイドKotlin導入事例についてお話しを伺います。
写真左から滝安、鈴木、前原
友永：
まず始めにプロジェクトの生みの親である前原さん、簡単に自己紹介お願いします。
前原：
エムスリーには4年前に入社し、現在は医師・薬剤師のキャリア支援事業 のエンジニアチームリーダーを担当しています。担当している事業の事業規模は年間売上高100億円超と急成長しているのですが、一方で扱っているシステムは10年前の技術スタックをベースにしているなど老朽化が進んでおり、開発効率が落ちている点が問題でした。
これをなんとかしたいと思い、2017年4月にリニューアルプロジェクトを立ち上げました。 モノリシックなJava の独自フレームワーク で作られていたシステムを、API サーバとフロントに分離し、API サーバをKotlin(Spring Boot)・フロントをRuby on Rails とVue.js(Nuxt.js)
友永：
リニューアルプロジェクトを一緒に進めている滝安さん、鈴木さんも自己紹介をお願いします。
滝安：
2017年8月の入社です。前職はファイルストレージの開発というWeb開発とは全然違うことをしていました。エムスリーへ入社後、医師キャリアリニューアルを担当し、いきなりKotlinを使ってWeb開発を行いました。前職ではCを業務で使うことが多かったですが、Kotlin習得にあたっては特に違和感はなく便利な言語だなという印象でした。ちなみに、個人的に好きな言語はGoで、もくもく会 を開催しています。
鈴木：
2017年11月に入社しました。前職ではRuby での開発がメインでしたが、技術的に新しいことがやりたいと思っていたところ、今回のリニューアルプロジェクトで何かできそうと感じエムスリーに入社しました。入社後はサーバサイド：Kotlin、フロント：Vue.js(Nuxt.js)でサーバ側もフロント側の開発も行っています。私は薬剤師キャリア事業のリニューアルプロジェクトを担当しています。
友永：
サーバサイドにKotlinを導入した経緯など教えてください。
前原：
私達のチームでは先ほどお話したモノリシックなJava アプリケーションだけでなく、Ruby on Rails も多く利用していたので、全てRuby on Rails でリニューアルするという選択肢もあったのですが、複雑なビジネスロジック が集まるサーバーサイドは型がある言語でカッチリ書きたい という思いが以前からありました。
型がある言語として、Java 、Scala 、Goなどを複数の項目で比較検討しましたが、その中でもKotlinはRuby とsyntaxが似ていて、チームのRuby エンジニアがキャッチアップしやすそう だと感じた点がKotlinを採用した理由として大きかったです。
また、サーバサイドにKotlinを導入したという事例は当時国内ではあまり見当たらず、先駆的なチャレンジをすることで、「技術的チャレンジを好む仲間を集めたい」 という思いもありました。国内の導入事例は少ないものの、Kotlinでプロトタイプを作ってみたり、Java のフレームワーク であるSpringがKotlinを公式でサポート予定と発表しているのを見て、これはイケるぞと判断しました。
友永：
Ruby エンジニアがKotlinを触ってみてどうでしたか？
鈴木：
まず、syntaxがRuby と似ています。特にリストに対する操作は似ていたのでキャッチアップしやすかったです。 またKotlinは静的型付け言語ではありますが型推論 が効くRuby と比べても面倒臭さはなく抵抗はなかったです。
前原：
KotlinとRuby で書いたコードを並べて比べたことありますが、リスト操作のsyntaxが非常に似ており、キャッチアップしやすかったですね。
参考:10年前のレガシーシステムをサーバーサイドKotlinでフルリニューアルしている話 #jjug_ccc #ccc_g2 // Speaker Deck
滝安：
私はプライベートでRuby を使っていました。Ruby は1人で開発する分には素早く書けていい言語だけど、大規模に開発する場合は型があったほうが壊れにくいのでいいかなと。初めてKotlinでNull Safety な言語に触れたのですが、NullPointerException が発生しうる書き方をするとコンパイル エラーになってくれるので、安心して書けるなと思いました。
友永：
Kotlin導入のメリットについて教えてください。
前原：
当初の想定どおり、Ruby とKotlinはsyntaxが似ているので、Ruby エンジニアのキャッチアップが早く、かつ型やNull Safetyのおかげで堅牢に書けるというのはとてもよかったです。
また、エムスリーではRuby かJVM 系のプロジェクトが多いため、社内の共通ライブラリは基本的にRuby とJava 版が提供されています。KotlinはJVM 系の言語の為、Java のライブラリを使える。つまり、社内の共通ライブラリをKotlinから呼べる 、これもよいところでした。社内のライブラリだけでなく、オープンソース のJava ライブラリも使えるため、言語周辺のエコシステムが既に存在しているというのもよかったですね。
鈴木：
ライブラリはJava のものであれば使えるものが多い です。多少Kotlin用のモジュールを入れないと動かないというものもありますが、Kotlinをサポートしていく方針のものも多いので、あまり心配しなくていいかなと。Spring Bootも開発途中に2.0がリリースされましたが、特に問題なくアップデートできました。
前原：
数ヶ月前に第1段階目のリリースを完了させたのですが、Kotlin起因のバグはなかったですね。
滝安：
KotlinよりSpring Bootの話ですが、レイヤードアーキテクチャ にマッチしていたのが良かったですね。冗長に書かなくてもアプリケーションフレームワーク がケアしてくれるので無駄がない。その分学習コストが高いデメリットもあったけど笑 Kotlinはそこに乗っかれるのがよかったです。
鈴木：
Data Class がよかったなと思います。シンプルな記述で、コンストラクタとプロパティが記述できるので、パラメータを初期化し忘れるとかそういった単純なミスが防げるなと、Kotlinをやってから他の言語を触ると特に感じます。
今回リニューアルしているシステムは、歴史も長くDBのスキーマ は正直あまり綺麗な状態とは言えない状態でしたし、ビジネスロジック もいろんなところに散らばっている状態だったのですが、DDDの考え方を取り入れたり、レイヤーをきちんと定義した ことで、今後の変更がし易い状態になったかなと思います。
KotlinでDDDやる事例はまだなかったので、Scala で既にやられている方の資料を読んだり、実践ドメイン 駆動設計を読んだりしました。ユースケース がみんな違うので自分達はどうしていくべきなのか考えるのは難しかったですね。
前原：
Data Classは凄くよいなと思いました。Data Classのcopy()関数を使うと、既存オブジェクトのプロパティの一部だけ変更して新しいオブジェクトを作ることが出来るのですが、これを用いると、一つのテストデータの雛形から様々なテストデータを生成する、といったことが簡単にできるので、重宝しました。
友永：導入時の注意点やハマったことについても是非教えてください。
前原：
Kotlinの拡張関数 の使い所には迷いました。拡張関数は便利だけど、やたらめったら使うとぐちゃぐちゃになるので、結果として私たちのチームでは本当に必要な時以外は使わないと定めました。
鈴木：
使いどころが難しいですね。Ruby でモンキーパッチを当てて拡張していくのは、メンテナンスを考えるとなかなかカジュアルにできませんが、Kotlinの場合はコードで追えてしまうので逆に使い所に悩む。
滝安：
レイヤーで責務をまとめているのに、関係ないところで書き換えられちゃうと、その構造の意味が薄れてくる ので、あんまり使いたくなかったですね。そもそも自分らで書いているところなんだから、拡張じゃなくで大元を直しなよ、と笑
前原：
私たちは拡張関数の使い所を、テストコードで既存のテストライブラリにちょっと便利なメソッド生やしたい時に使うくらいにとどめました。MockMvcBuildersに便利な拡張関数生やしたりとか。その場合範囲がテストの中にとどまるし、メリットの方が大きいと考えました。
鈴木：
gRPCを使っていた時に、LocalDateTimeをgRPC用のフォーマットに変える時は使いどころかなと思い使ってみました。プリミティブなというか元々あるクラスを拡張する時は使いどころかもしれないですね。
拡張関数でアプリケーションのドメイン を生成していたりするのはちょっと微妙かなと思いますが、単純なフォーマット変換などコンテキストを絞って使うのはアリかなと。
滝安：
アノテーション 周りははまりどころが多かった
他にも、バリデーションをかけるのにSpring Bootのアノテーション をつけて、うまく効かないというのもありました。これは、Kotlinは一回Java に変換してからコンパイル されるので、変換した後だと思ったところにアノテーション がついていないのが原因でした。
鈴木：
バリデーションでget:をつけていないと利かない というのもありました。利かないけど何も教えてくれないとか。モック系のライブラリがKotlinのNull Safetyで落ちるとか。マニアックなやつだと、enum のクラスでメソッドをoverrideしているときだけ起きるバグを踏みました。 それくらいですかね、エッジなバグ踏んだの笑
前原：
ハマりどころがあったとしても、大概調べたら解決方法がでてくる程度のものでしたね。Java のライブラリを使う時にたまにあるくらいで。モックのやつもワークアラウンド をこうすればいいというのも調べたら出てきました。
鈴木：
情報が徐々に増えてきていて、基本的に普通のユースケース で見つかるバグは誰かが潰しているか、ワークアラウンド がすぐ見つかる状況でした。
前原：
サーバサイドでKotlinを使うケースはまだあまり聞かないけれど、Android でKotlinを使うケースはとても増えているので、知見がネットにもあがっていますね。
また、今回Kotlinを選択した大きな追い風として2017年のGoogle I/O でGoogle がKotlinをAndroid の開発言語として正式にサポートGithub のプロジェクトを調べれば色々出てくるし、どこにも情報なくて困るということは殆どありませんでした。
滝安：
Java の情報を頭の中で翻訳すればKotlinの情報になるので、そんなにそれ自体で困ることはなかったですね。あと、IDE がすごい強力というのもあります。下線がにゅーってなっているところの指摘通り書くときれいに書けます。
友永：
最後にサーバサイドKotlinを導入してよかったことをまとめてください。
前原：
私たちのプロジェクトではKotlinを使ってよかったし、正解だと思っています。また、これをきっかけに社内だけじゃなくて、社外で勉強会を開催して広がりができたのも非常によかったです。エムスリー主催で「どこでもKotlin」 という勉強会をこれまで5回開催しましたが、社外の方にも多く登壇いただいくことで、情報交換ができました。サーバーサイドKotlinをやっている人、検討している人にもたくさん会うことで、共通の悩みを共有できました。実際、鈴木さん、滝安さんもこういったチャレンジを対外的に発表していたから入社してくれたのかなと笑
鈴木：
Kotlinでサーバサイド開発を行う事例は、当時あまり聞いたことがなかったし、技術的に面白そうだと思いました。
滝安：
私は個人的にはGoが好きだけど、それ以外の言語が嫌なわけではなくて、新しいことに技術を使って挑戦できるのがいいなと思いました。Kotlinというイマドキの技術を使って抜本的なリニューアルをしていくのは、面白そうだなと。他社のエンジニアと話すときにサーバサイドKotlinやってる、と言うとびっくりされることもあって、技術だけ見ても新しさはありますかね。
前原：
冒頭に話しましたが、今回のプロジェクトでは、技術的なチャレンジをすることで、チャレンジが好きな仲間を集めたいという思いがありました。それを魅力に感じてくれたのれあればよかったです！現在では、社内の他チームでもKotlin採用事例が増えてきていますしね！
ということで、Kotlinで開発したい人、一緒に働きましょう！！！
jobs.m3.com
