自己紹介とアジェンダ
森田郷一氏：LINE Fukuokaの森田と申します。今日は「新規サービスでKotlinを採用してみて」というタイトルでお話しします。
あらためて自己紹介します。私は福岡・博多に拠点を構える、LINE Fukuokaに所属しているサーバーサイドのエンジニアです。現在は、2021年2月にローンチした「LINEスキマニ」という、比較的できて間も無いサービスに関わっています。
サービスのローンチまでは、開発リードとして、チームのマネジメントやタスク管理、実装まで手広くやってましたが、現在は一般の開発者、俗にいうIndividual Contributorとして開発業務を行なっています。
本日はLINEスキマニでKotlinを採用した事例をお話しします。よろしくお願いします。
今日のアジェンダですが、始めにプロダクトの紹介をし、次にLINEスキマニで採用してる技術スタックとそれらを選定した背景を、そして最後に、実際にKotlinをサーバーサイドで使ってみての感想を発表したいと思います。感想については、事前にチームメンバーにヒアリングした生の声となっています。
「LINEスキマニ」は単発の求人の紹介・マッチングサービス
まず、私たちのプロダクトであるLINEスキマニについて紹介させてください。LINEスキマニは、数時間だけ（という方）や、明日すぐに働きたい方に向けて、単発の求人を紹介・マッチングするサービスです。いわゆる、ギグワークサービスと呼ばれる領域になります。
LINEでは、これまで「LINEバイト」という、数週間から数ヶ月のような長いスパンの一般的なアルバイト求人を紹介するサービスを長く提供してきましたが、それとは異なる、働きたい時にすぐに働けるような世界観を目指し、2021年2月からサービスを開始しました。
すぐに仕事を探せて、気に入った求人に応募することで、すぐにマッチング（できる）。そして、働いた後はすぐに給与が受け取れる。このようなポイントがサービスの特徴となっています。
システム概観
次に、ごく簡単ではありますが、システムの概観について説明します。LINEスキマニでは、大きく3つのシステムを開発・運営しており、スライドでは点線で囲まれた四角の部分がそれに当たります。それぞれユーザー向け、法人向け、運用・管理向けのシステムがあり、すべてWebアプリケーションで提供しています。
ユーザー向けのシステムはスマートフォンからの利用を想定しています。法人向けシステムは求人や応募者の管理機能を提供しており、PCおよびスマートフォンからの利用を想定しています。
また、ユーザーの本人確認や口座への給与振込、そして法人への請求など、いくつかサードパーティのサービスと連携することで、事業を実現しています。
技術スタックと選定の背景
次に、アジェンダの2つ目である、技術スタックと選定の背景についてお話しします。
まずはLINEスキマニで採用している技術スタックですが、（スライドを指して）左がサーバーサイド、右側がフロントエンドになります。本日はサーバーサイドにフォーカスしてお話しします。
言語は今日のテーマであるKotlinです。それからテスト周りでJUnit5と、KotlinのMockライブラリであるMockK。それからSpringBoot。フレームワーク部分はSpring MVCを使っています。後ほど選定理由について言及します。
永続化のレイヤーはMyBatisで、ミドルウェアはMySQL、Elasticsearch、Redis、Kafkaなどを使っています。最後に、オーケストレーションの部分ではKubernetesを採用しています。
（スライドを指して）赤い印がついてるものに関しては、社内にVerdaというプライベートクラウド環境があり、そこでマネージドなミドルウェアが提供されているので、LINEではそれを利用することが多いです。
次に、技術選定についてです。LINEでは技術選定は開発チームに基本的に委ねられている文化となっており、サービスの特性や、チームメンバーのスキルセット、会社としての方向性などを考慮して開発チーム内で決めることができます。
続いて、Kotlin採用の背景です。Kotlinがよいという話は多方面から聞いてたり、独学で学んでいたり、「Kotlinを使ってみたい」という一部のメンバーの声もあったりという状況でした。また、社内の他のプロジェクトで採用実績もあるという状況でした。ただ、立ち上げ当初のメンバーにKotlinに精通してる人がいない状況でもありました。
Kotlinに詳しい人、実開発で利用してるメンバーがいない不安はありましたが、社内にそれなりの実績などがあり「問題があっても自分たちで解決できるだろう」というところで、最後は勢いで「もうKotlinやっちゃいますか」みたいな感じで採用を決めました。
運用面でいうと、最終的にはJVM（Java Virtual Machine）の上で動く。Javaの経験者も多かったので、そこまで不安はなかったと記憶しています。
今日はKotlinがメインテーマになるので少し余談になるかもしれませんが、チームでKotlin以外のチャレンジであった、Kubernetesの採用についても少し触れさせてください。
LINEスキマニでは、オーケストレーションにKubernetesを採用しています。それまで、LINEでは多くのプロジェクトが、内製のデプロイツールを利用していました。そして、先ほど紹介したプライベートクラウドVerdaで、マネージドなKubernetesのクラスタが提供され始めた時期でもありました。
このような状況の中、内製ツールは運用実績も十分でメリットもあったのですが、時代に乗るかたちでKubernetesを採用しました。Kubernetesのクラスタの構築・運用はとても大変だという話も聞くので、もしマネージドなクラスタがなければ、判断は変わっていたかもしれません。
続いて、Spring MVC採用の背景です。ここは「なぜWeb Fluxじゃないの？」という問いに対する回答になります。
先ほども少し登場しましたが、LINEには「LINEバイト」という同じ事業部が運営しているプロダクトがあり、そのプロダクトはJavaベースでSpring MVCが採用されていました。
立ち上げ当初のスキマニ開発チームは、この「LINEバイト」の経験者で構成されておりSprig MVCの扱いにこなれていたこと、また、KotlinやKubernetesという新しい技術への挑戦もあり、少し詰め込み過ぎなリスクを感じたため、今回はSpring MVCを採用しました。
次に、検討されたものの採用されなかった技術についてです。（スライドを指して）ここではマイクロサービスを挙げています。LINEスキマニでもマイクロサービスアーキテクチャを採用しようかという議論はありましたが、ギグワークサービスという業界がまだ未成熟な事業領域で、今後システムがどのような形になるか見通すことが難しく、サービスを分割する単位に不安があったため、まずはモノリスで作ろうという話になりました。
現在ではだいぶビジネスのかたちも見えてきたため、もしかしたら今後サービス分割をしていくかもしれません。
Kotlinを使用した感想：ポジティブ編
それではアジェンダの最後のトピックの、Kotlinを使ってみての感想です。今回このセッションで話すのに当たり、開発メンバーに、Kotlinについてポジティブな面とネガティブな面それぞれをヒアリングしてきました。その内容を発表したいと思います。
まず、ポジティブな面についてです。チームからいろいろな意見があがりましたが、大きく分けると、「苦労せずキャッチアップできた」「簡潔に書ける」「Null 安全」「Javaの資産が利用できる」という4つに集約される内容でした。あらためて整理してみると、Kotlinの特徴がきれいに出ていて興味深いな、という感想でした。次に、それぞれについて深掘りしていきましょう。
まず、「苦労せずキャッチアップできた」という意見ですが、「Javaを触ってる人であれば問題なく移行できた印象」「Kotlinの経験者はいなかったものの、ローンチまで特に大きな問題もなかった」などの感想がありました。
これは本当に実感していて、勢いでKotlin採用を決めてしまったところもありましたが、Javaを触ってきたエンジニア集団であれば、大きなコストやリスクを払わず採用できるんだなと実感しました。また、他の言語のほうが得意なメンバーもいましたが、そういったメンバーも、特に問題無く開発をこなした印象があります。
次に、「簡潔に書ける」という感想ですが、この項目はポジティブな感想として一番多くありました。「名前つきの引数、Trailing commaや、String template。複数行文字列などの文字列系とか、ifが戻り値を持てる」とか、「比較が『==』でできる」とか、「data classが便利」とか。
「Javaでよく使われるLombokが不要」「メソッドの引数にデフォルト値が入れられる」「lambdaが書きやすい」など（の感想）がありました。
次に、「Null 安全」ですが、「コンパイル時に保証され、Kotlinの世界ではNullPointerExceptionが発生しない」「Javaのようにアノテーションやチェック処理が不要」「たとえnullableでもあっても『:?』演算子などがKotlinで提供されており、迷わず対処できる」などの感想がありました。
最後に、「Javaの資産が利用できる」ですが、Javaのライブラリが呼び出せる。既存のライブラリ、フレームワークが使えるということで、Kotlinのキャッチアップに苦労しなかったと感じさせた要因かもしれません。
IDE、IntelliJ IDEAがJavaのコードをKotlinコードに変換してくれるということもあります。このコード変換ですが、LINEではGitHub上で他のプロジェクトのコードを閲覧できるので、他のプロジェクトのコードを参考にすることがよくあります。要件を満たすコードはすでにJavaコードとして存在する場合があるので、その際にコード変換が便利だったりします。
Kotlinを使用した感想：ネガティブ編
次にネガティブ編の紹介です。ネガティブな感想もいくつかあがったので、特徴的だったものを一部紹介します。
まずScope関数について、これはKotlinあるあるなのかもしれませんが、使い始めた当初はみんなKotlinに慣れてないこともあり、また、Scope関数の自由度の高さから、書きっぷりに統一感がないなどの問題がありました。現在はコーディングルールとして指針を整理して、統一を図っています。
次はライブラリ呼び出しについてです。KotlinではJavaのライブラリが呼び出されることはよく知られています。この発表内でも言及しましたが、その際に、制約や注意点があるというものです。
例えば、名前つき引数が使えない。ライブラリの戻り値をnon-nullに定義しても、Javaのではそれが担保できないため、nullが返る場合がある。この場合「実行時エラー」になります。
最後に、「ライブラリ内でvalで定義したフィールドの値が書き換えられてしまう」ということがあげられました。これは、データクラスのフィールドをvalで定義したにもかかわらず、利用したJavaライブラリのほうで書き換えられた経験からの感想でした。
ネガティブ編の最後ですが、「バリデーションを定義する際に『@field』を忘れがち」というものがありました。
JavaのアプリケーションではよくJava EEのBean Validationを使ってバリデーションを実装すると思いますが、Kotlinの場合、@fieldをつける必要があります。これをよく忘れて、動作しないということがあったので、「このあたりがJavaと同じ書き方だったらなあ」というような意見でした。
最後におまけとして、その他の声もまとめてみました。Coroutineについてです。LINEスキマニでは、現在Coroutineを使ってるコードはない状態です。非同期部分についてはSpringの@Asyncを使っており、現状だとこれで困っていない状態です。ただ、今後ユーザーの増加数を見越して、Coroutineで効率的なコードにしていきたいとは思っています。
最後は以前Android開発をしていたエンジニアからの意見でしたが、「AndroidだとうれしいSAM変換は、サーバーサイドだと威力を感じなかった」というものがありました。Androidエンジニアとサーバーサイドエンジニアで感じる違いがあって、興味深かったです。
LINEの開発や「LINEスキマニ」に興味がある方はぜひ応募を
最後にまとめです。今日はLINEスキマニというプロダクトの紹介、そのLINEスキマニで採用している技術スタックと選定の背景、Kotlinを使ってみての感想という内容でお話ししました。
最後にもう少しだけお時間をください。LINEではエンジニアのみなさんを募集しています。
LINEでは、1つのプロジェクトを複数の拠点にまたがって運営することがよくあります。例えば、本日紹介したLINEスキマニの開発チームも、東京と福岡の2拠点のエンジニアが、1つの開発チームとして機能しています。
現在はコロナの影響もあり、ほとんどのメンバーがリモートワークで物理的な距離は離れていますが、フラットなチーム作りができていると感じています。また、我々開発者は企画・営業・CSなど、ビジネスサイドのメンバーやテストをしてくれるQAチームのメンバーとも、日々コミュニケーションを取りながら開発業務を行なっています。これらのチームとも物理的には離れていますが、さまざまな工夫をしながら効率的なプロダクト開発をしています。
もし、LINEでの開発やLINEスキマニ、また他のサービスに興味を持ってもらえたら、ご応募を検討してもらえればと思います。
以上です。ありがとうございました。
