Scala 選定の結果と継続の方針 〜Advent Calendar 2016 Day 25 へのアンサー〜

Mikatus Advent Calendar 2019 25日目の記事です。

開発責任者の土田です。

当社が2016年に参加したアドベント・カレンダー25日目の「[Scala選定の理由と移行の方針](https://qiita.com/yuukiishikawa/items/95ad5a21514bffddb0bd)」という記事へのアンサーを書こうと思います。事前にその記事を読んでいただいた方が、この記事の内容を楽しめるかなと思います。ただ、私の記事はあくまでポエムなので、そんなに期待しないでください。

プラットフォーム移行の観点でよりきちんとした内容は「[Scala採用を決めて3年半たった、CTOの振り返り。アーキテクチャ刷新を成し遂げるために必要なこと](https://creators-note.chatwork.com/entry/scala3.5year)」がとても参考になると思いますので、そちらをオススメします。

# 発端は（食べられる方の）カリーうどん<br>→ 最近は秋葉原でスープカリー

当時は当社のオフィスが白金高輪だったので、近くにあるカリーうどんを食べてました。その後は岩本町、浅草橋と移転したので食べてるカリーはなんだろうなと考えると秋葉原でスープカリーですかねｗ移転したオフィスから遠いので最近行けてないですが、「スープカレー カムイ」が好きです。

さて、本題です。ここから引用多めで書いていこうと思います。

> 弊社では、[クラウド会計のA-SaaSがシリーズCで3億円を調達、システム刷新へ](http://jp.techcrunch.com/2016/12/06/a-saas/)という記事にもあるように、Javaで書かれているサーバーサイドのアプリケーションを、Scalaに移行していくことにしています。

ここについて言うと、Java で書かれているサーバーサイドのアプリケーションを段階的に Scala に移行しているものもあるという状況ですね。コアシステムの会計システムがまさにそれで、このシステムを Scala に移行していっているのは正解でした。今回のアドベントカレンダーの最後のエントリーは、Scala に決めて3年経つとどうなるかっていう話で、なぜ正解だったのかみたいな話もできたらなと思います。

> 今から約1年前の2016年の初頭、とある同じ会計関連ベンチャーのCTOが弊社オフィスのある白金高輪にランチに来てくれました。

ネタバレすると、この CTO が私です。当時はメリービズ株式会社で CTO を担当していました。それで、石川さんと（食べられる方の）カリーうどんを食べながら、技術談義をさせてもらったという経緯ですね。当時は Scala については全然詳しくなくて、大学院時代に Scala と Lift フレームワークの勉強会にちょっと参加したことがあるくらいでした。[Functional Thinking](https://learning.oreilly.com/videos/functional-thinking/9781449368630) を観たりしてたので面白いなぁと思ってはいたのですが、どちらかと言えば Groovy や Clojure の方が好きでしたね。メリービズで Ruby を使用してたからかもしれませんね。

> 当時、私は弊社の主要言語であるJavaの限界に苦しんでおりました。ちなみに**技術的な限界ではなく、人間に関する限界**です。(弊社もJavaで長いですが、「Javaだから技術的に出来なかった」ことは一度もありません。そりゃそうですよね)

自分が実際に採用に関わってみると Java にモチベーションを持って取り組んでいるエンジニアはたくさんいらっしゃいます。最近は、強い型付けへの回帰を感じますし、Java のリリースサイクルが高速になったことからも Java はそれなりに人気あるんじゃないかなと思っています。また、Java だから技術的にできないってことはたしかになくて、むしろ難しいアーキテクチャを実現してきた実績があると思うので Java という言語を最近は私自身だいぶ好きになってきました。

> ベンチャーに来たがるようなエンジニアにJavaをやりたがる人がすくない。

当時はそうだったのかもしれませんが、最近はそんなことないんじゃないかなぁと思う今日このごろです。

> それと近い問題ですが、「からっからに枯れている」「トラップや隠し部屋だらけの老舗旅館みたい」な、Java **だけ** だと、僕ら社内のエンジニアの知的好奇心、知的熱量も維持しにくいな、とも思っていました。

知的好奇心や知的熱量を維持しにくいのは実際にありますね。ほかの言語を知ることによって得られることは非常に多いので、Scala を会社で導入してよかったなぁと思うひとつの理由になります。あと、自分で導入しておいて言うのもあれですが、「からっからに枯れている」「トラップや隠し部屋だらけの老舗旅館みたい」な Sencha Ext JS の方が知的好奇心や知的熱量を維持しにくいという課題は抱えてますかねぇ。

# 勉強会開催から採用、最初のサービス開発まで<br>→ Scala による新サービス開発と頻繁な社内勉強会開催

最初のサービス開発から数えると小さなものも含めて5つの Scala プロジェクトをリリースしてきました。現在、アクティブに継続開発しているプロジェクトが2つ、新規開発しているプロジェクトが2つという感じで引き続き Scala での開発を継続しています。

また、社内での勉強会も最近は頻繁に開催されるようになってきていて、ここ半年で Scala 選定に関わるようなトピックで言うと「ドメイン駆動設計」「Haskell」「OCaml」あたりの勉強会がありました。また、それ以外に「Spring」「Sencha」「Docker」などの勉強会も開催されています。私が主催しなくても、勉強会が開催されるようになってきてよかったなと思います。

> **「副作用を排除するスタイル」「高階関数によるボイラープレートの抑制」「型と大規模開発」**

Scala で開発する上でこれらの利点は大きいと思います。単純に考えてみても Better Java としての Scala の意義は大きいです。背伸びし過ぎて Scala を使ってしまったかなというプロジェクトもあったりして、それなりに成長痛を感じることもありました。この成長痛はかなり前向きに作用したと感じていて、Paul Graham の [Beating the Averages](http://www.paulgraham.com/avg.html)（邦訳：[普通のやつらの上を行け](http://practical-scheme.net/trans/beating-the-averages-j.html)）にある「『ほげ言語』のパラドックス」をメンバーは体感したのではないでしょうか。Scala を知っていることによって Java の Optional や Spring の WebFlux をかなり理解しやすくなりますよね。

> **CTOなんて、いわば技術を理解する高性能雑用BOT** ですが、ある程度の熟慮の上で「うちはこの技術でいくべきだ」と、言い続けると、**社内であまり無視はされません。**

「CTO なんて、いわば技術を理解する高性能雑用 BOT」という言葉がかなり好きです。とくにアーリーステージのスタートアップの CTO はこうあるべきなんじゃないでしょうか。

現状、私は CTO というより VP Engineering としての仕事を担っていて、CTO は不在となっています。エンジニアの数も25名を数えるようになってくると、CTO と VPE を分けるのがいいのかなぁと感じます。まあ、そのあたりは「[いまなぜMikatusが CTO を募集するのか？](https://www.wantedly.com/companies/mikatus/post_articles/180247)」に書いているので、ご興味のある方は読んでみてください。

また、CTO として「うちはこの技術でいくべきだ」と言っていくのはとても大切で、巨大な業務アプリケーションをクラウドで開発しているような当社においては、CTO にアーキテクトの延長線上にある知識が求められているなぁと感じます。Scala から Haskell、圏論という理論的な方向に行くのではなく、Scala から Play、Akka、Lagom であったり、DDD、CQRS、Event Sourcing、Event Storming という実践的な方向に導かなければならないんですね。これは私自身が理論方面で盛大に迷走した経験から辿り着いた結論です。

理論的な話は、「[もう諦めない圏論入門―対象と射―](https://qiita.com/norkron/items/f90d851daf05a2efa567)」から始まる「もう諦めない圏論入門」シリーズがとてもわかりやすいです。また、「[なぜHaskell、なぜ圏論なのか](http://bitterharvest.hatenablog.com/entry/2016/10/02/151001)」から始まる「プログラマーのための圏論」シリーズもわかりやすいです。あとは、『[圏論の道案内](https://gihyo.jp/book/2019/978-4-297-10723-9)』や [Category Theory for Programmers](https://bartoszmilewski.com/2014/10/28/category-theory-for-programmers-the-preface/)、[Category Theory Applied to Functional Programming](http://www1.eafit.edu.co/asr/pubs/others/cain-screen.pdf) ですかね。

実践的な話は、[Scala Microservices](https://www.packtpub.com/application-development/scala-microservices) がオススメです。リアクティブ・システムは急進的すぎるということであれば、『[.NET のエンタープライズアプリケーションアーキテクチャ 第2版](https://shop.nikkeibp.co.jp/front/commodity/0000/P98480/)』がいいですね。あとは、まだ通読していませんが [Functional and Reactive Domain Modeling](https://www.manning.com/books/functional-and-reactive-domain-modeling) や [Domain Modeling Made Functional](https://pragprog.com/book/swdddf/domain-modeling-made-functional) は社内のエンジニアが推薦している良書です。DDD 本や IDDD 本は必読本ではありますが、最初に読む本ではなくなってきたかなと思っています。

> まず、Scala勉強会、や、Scalaでの関数型プログラミングに関する勉強会を社内で始めました。そして、Javaに加えて、Scalaもできるエンジニアを採用(まだ少数ですが)。

前述のとおり社内での勉強会が活発になってきています。すこし背伸びした技術スタックを選定したことが、この流れに繋がっているのかなと思うところです。

採用という面だと、Scala エンジニアの採用は大変で、Java エンジニアとしての採用がほとんどを占めています。採用のために Scala を選定するというのは正解ではないのが現状ですが、採用した Java エンジニアの技術力を伸長させる方向性を示すことができるという点で、Scala を採用している意味はあると思います。測定はしていませんが、端的に言えば離職率の低減には一定以上の効果があるんではないかなと感じています。

> そして、今年の5月から9月の間で、[A-SaaSコネクト](http://www.a-saas.com/fintech/index.html)という弊社の完全な新サービスのサーバーサイドAPIを、Scala & PlayFramework で開発してみました。

「A-SaaS コネクト」は引き続き開発を継続し、ユーザー数も着実に伸びているサービスとなっています。

> 現在は、弊社の税務クラウドの**いくつかの新機能をマイクロサービス的に切りだして、Scalaで開発しています。**

一方で、税務システムの既存機能については、引き続き Java での開発を継続しています。現在のコードベースを Scala に移行する利点のないシステムは、Java で継続するという判断をするようにしています。これは新機能における開発でも同様で、開発体制やフレームワークを鑑みるに Java で十分ということがあります。

Java の進化が最近は早く、Scala にあるような機能が取り込まれていることもあり、Better Java としての Scala の役目は終わりつつあるからかもしれません。ただ、リアクティブ・システムを開発するような世界では、Java だと辛いことが多いなと Lagom を試してみたりしていると思うので、Scala を使いたいところです。その分、プロジェクトに参加するエンジニアの技術力も求められるという構図になっているかと思います。

マイクロサービスと言えるほどではありませんが、当社のシステムはもともとサービスに分離されていました。そのサービスが Tomcat の乗ったアプリケーションサーバーに相乗りしている状況です。2019年はその相乗り状態を Amazon ECS 上の Docker 基盤に部分的に移行していくことができました。地道ではありますが、着実に進歩していってはいます。

> 会計本体といった弊社のJava基幹アプリケーションを置き換えるプロジェクトを走らせている

会計システムは新・会計システムという形で、既存システムと新システムを共存させながら移行を進めています。いわゆる [Strangler Pattern](https://docs.microsoft.com/en-us/azure/architecture/patterns/strangler)（邦訳：[ストラングラー・パターン](https://docs.microsoft.com/ja-jp/azure/architecture/patterns/strangler)）になりますかね。会計システムは会計事務所において利用頻度が最も高いシステムなので、そのパフォーマンスが重要になってきます。当然、サーバー側の負荷も大きくなるため、将来的なリアクティブ・システム化などを見据えたときに Scala を選定して正解と感じるところです。

# Scala が良い理由<br>→ Scala も Java も良い理由

ここでは素直に自分の言葉で下記の4つの観点から Scala と Java について言及してみます。

* 言語の力
* 入門者向けの資料
* アーキテクチャの資料
* フレームワークの選択肢

## 言語の力

「『ほげ言語』のパラドックス」で言うところの言語の力としては、Java より Scala の方が強いように思います。そもそも Java の方が強かったら後発の Scala を使う理由はないはずで、ある観点において Scala の方が強いから、みんなが Scala に興味を持って使っているんじゃないでしょうか。

で、その力の強い言語を学ぶことには利点があると思うんですよね。モナドの世界に迷い込んで Haskell の勉強したりもしましたが、そこで得られた知見は Java でプログラムを書いていく上でも有意義だなと感じています。普段 Java を書いているエンジニアも Scala を学ぶことで Java のコードを洗練することにつながるはずです。

## 入門者向けの資料

Scala はやはり学習曲線は急だと思います。入門者向けの資料も Java に比べてしまうと当然少なくなってしまいます。また、Java の知識を前提としている資料がどうしても多くなりがちです。となると、Java を知らないエンジニアはまずは Java から学ぶということになってしまうのではないかなぁと思います。とくに、未経験に近いエンジニアが当社に入ってくると最初に学ぶ言語は Java になってしまいますね。

## アーキテクチャの資料

DDD や CQRS、Event Sourcing、Clean Architecture などアーキテクチャに関わる資料は古典も含めて圧倒的に Java で書かれているものが多いです。次に C# が多いですかね。（Microservices だと Golang などもありそうですがそのあたりは詳しくないです。すみません。）関数型ドメインモデリングとなると Scala と F# が出てくるイメージです。Lightbend 社がリアクティブ・システムを強力に推進しているので、そういう側面で Scala における資料の充実は魅力的ですが、同時に Java の資料も出してくれていたりするので、Java で書かれている資料が多いことに変わりはなさそうです。

## フレームワークの選択肢

Java はデファクトスタンダードとなっている Spring を始め様々なフレームワークが存在しています。Scala で開発されているフレームワークである Play や Akka、Lagom なども Java から利用できるフレームワークになっており、Java から選択できるフレームワークは充実しています。なので、少なくとも当社においては、言語ありきというよりは、フレームワークありきで選定するという方がプロジェクトは成功しやすいんじゃないかなと思います。

# Scala への移行方針<br>→ 技術的負債の返済方針

現在は、Scala に移行していくという方針というよりは、技術的負債をどのように返済しながらプロダクトを進化させていくかということを主眼に置き、技術を選定しています。

> すでにJavaで動いている基幹業務があります。これらのサービスは基本的には細分化されており、複数の機能が同居しているモノリシックな場所はあまりありません

前述のとおり、ある程度細分化されたサービスになっているのは当社のシステムを改善していく上での大きな利点です。その一方、技術スタックが多岐に渡っていて、エンジニアをプロジェクト間でローテーションさせるのが難しく、社内に特定技術のナレッジが蓄積しづらい状況でした。そこで、疎結合なサービスは維持しつつも、新規プロダクトやリプレイスで使用する技術スタックを限定的にし、エンジニア間での技術情報を共有しやすく、社内に知識が蓄積しやすい状況にだんだんとしていっています。

> 今後、**サービスとして分割できる新しい機能は基本的にはScalaで書いていく**ことになる

実際のところ、「基本的には Scala で書いていく」ということにはなりませんでした。新規プロジェクトの開発で Java と Scala が半々といったところです。ボイラープレートを書かずに済んだりもするので、Better Java としての使い方だとしても Scala を全面的に活用したいところではあるのですが、Spring が提供する機能を使用する Java プロジェクトで開発する方が効率的だったり、参加するエンジニアの技術スタックが Java に寄っていたりするときは素直に Java を選定しています。

今後の判断基準としては、Scala を第一級オブジェクト (First-class Citizens) として捉えているフレームワークで、Scala やそのフレームワークのお作法に則って開発を進められるだけのテックリードとメンバーがいるのであれば、Scala を使うという判断でいこうと思っています。

> われわれにとって最も大きなレガシーは、Adobe/AIRで書かれた会計アプリケーション

会計システムは Scala と Sencha Ext JS で開発し、新・会計システムとしてリプレイスを進めています。また、既存プロダクトの大部分は Java での開発を継続しています。その一方、新規プロダクトでは Scala をサーバーサイドで使用しつつ、Vue.js をクライアントサイドで使用しています。

技術スタックが発散しないことを前提に置きつつ、既存システムやリプレイスは比較的保守的な技術スタックを選定し、新規システムは革新的な技術スタックを選定する方針です。新しい技術を使った方がエンジニアとして楽しいとは思うのですが、会社としては持続性のある技術で開発していかなければなりません。現時点で Vue.js がなくなるとは思ってはいないのですが、そういった可能性も考えてテクノロジーマネジメントしていく責任が開発の責任者にはあります。また、そういう感覚を持って開発に参加できるエンジニアが増えるとエンジニアチームとして強いだろうなと感じます。

# 最後に<br>→ 次の3年に向けて

3年後のアドベント・カレンダー25日目があってほしいので、次に繋がるような感じで締めたいと思います。

> 弊社ではScalaでの開発がスタートして、軌道にのりつつあります。

まだまだ道半ばではありますが、間違いなく軌道に乗って、高度を高く高くしていっている最中です。Scala については先行している各社に比べたら、当社はまだまだ未熟だなぁと思うところですが、順調に成長していっています。

> われわれの移行や進捗や、開発の過程で得た知識などは、随時更新していこうと思います。

社外へのアウトプットはまだ少なく、Scala については皆無なのでこれから露出していきたいですね。拙い英語理解で当社で Scala の入門書として使用している [Essential Scala](https://underscore.io/books/essential-scala/) の内容を日本語でまとめたので、ご興味ある方はぜひご覧ください。

[Essential Scala 輪読会](https://qiita.com/takuya0301/items/977ecd49d493e20495b7)

また、Scala 以外では下記のようなイベントで登壇しています。

[Sencha Ext JS / Sencha Testの導入についてセッションスピーカーとして登壇しました！<登壇資料付き>](https://www.wantedly.com/companies/mikatus/post_articles/147112)
[X-Tech JAWS に「帳票Tech」と冠して登壇してきました](https://www.wantedly.com/companies/mikatus/post_articles/180246)

Scala についても Mikatus のエンジニアが登壇する日がきっと来るんじゃないかなぁと思ってます。今後に期待ですね。

> なお、いっしょに [言いたいだけ]カリー[/言いたいだけ]うどん を食べた同じ業界のCTOは、現在はわれわれにジョインしてくれていっしょに働いています。A-SaaSでは、いっしょにこの大規模移行を成功させてくれるScala/Javaエンジニアと、フロントエンドエンジニアこれからも募集しております！

はい。その元 CTO がこの記事を開発責任者として書いておりますｗ社名が変わった Mikatus でも引き続き Scala / Java エンジニアを募集中です。スープ[言いたいだけ]カリー[/言いたいだけ]を食べながら、技術談義や組織談義をしてくれる方はぜひお声がけください。

3年後の2022年アドベント・カレンダー25日目を書く人がこの記事から見つかることを期待して、筆を置かせていただきます。最後まで読んでいただきありがとうございました。