Scala選定の理由と移行の方針

発端は(食べられる方の)カリーうどん

弊社では、クラウド会計のA-SaaSがシリーズCで3億円を調達、システム刷新へという記事にもあるように、Javaで書かれているサーバーサイドのアプリケーションを、Scalaに移行していくことにしています。アドベントカレンダーの最後のエントリーでは、Scalaに決めた経緯というか、背景を述べて行こうと思います

今から約1年前の2016年の初頭、とある同じ会計関連ベンチャーのCTOが弊社オフィスのある白金高輪にランチに来てくれました。白金高輪は、他のオフィス地域、たとえば渋谷や新宿と比べて、ほんとにfuckなレベルで選択肢が少なく、特にランチ時間に人とゆっくり会える場所は、数えるほどしかありません。その一つが、[食べられる方の]カリー[/食べられる方の]うどんの美味しいおしゃれな群馬県料理の店なので、そこに行ったのでした。

当時、私は弊社の主要言語であるJavaの限界に苦しんでおりました。ちなみに技術的な限界ではなく、人間に関する限界です。(弊社もJavaで長いですが、「Javaだから技術的に出来なかった」ことは一度もありません。そりゃそうですよね)
まず問題は、「採用」でした。ベンチャーに来たがるようなエンジニアにJavaをやりたがる人がすくない。もっと具体的に言うと、採用担当者が「うちがRubyだったらもっと人を送れるとかエージェントさんに言われました〜(泣)」とか、言ってくるとかそんなことです。そんなエージェントやめちまえという言葉(を含む２０個くらいの反論)をぐっと飲み込んで、もやもやしていたわけです。それと近い問題ですが、「からっからに枯れている」「トラップや隠し部屋だらけの老舗旅館みたい」な、Java だけ だと、僕ら社内のエンジニアの知的好奇心、知的熱量も維持しにくいな、とも思っていました。

その会計系のベンチャーCTOと、ランチにいって、[食べられる方の]カリー[/食べられる方の]うどんを食べながら、このあたりの悩みをけっこうじっくり話したんです。

勉強会開催から採用、最初のサービス開発まで

同じ業界のCTOだったこともあり、ユーザー要件や，プログラミングの中身に関する悩みが共通だったこと、彼の方がコンピューターサイエンス出身で、かつ関数型含むプログラミング言語や数学に非常に造詣が深いこともあり、話がめちゃくちゃ弾んだことを覚えています。

その時に印象に残っているのは、やはり、「副作用を排除するスタイル」「高階関数によるボイラープレートの抑制」「型と大規模開発」あたりです。実はこの日彼と話した後で、僕の頭の中では「うちには絶対Scalaしかないな」という直観がありました。が、いかんせん、実証もされていないし、賛同者もいない、知識もない、自分を含めて社内に経験者いない、という状態です。
この直観を証明するためにはある程度時間をかけて勉強し、採用もしていくしかない、と考えました。
CTOなんて、いわば技術を理解する高性能雑用BOT ですが、ある程度の熟慮の上で「うちはこの技術でいくべきだ」と、言い続けると、社内であまり無視はされません。

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

そして、今年の5月から9月の間で、A-SaaSコネクトという弊社の完全な新サービスのサーバーサイドAPIを、Scala & PlayFramework で開発してみました。(フロントエンドは Sencha ExtJsです)。現在は、弊社の税務クラウドのいくつかの新機能をマイクロサービス的に切りだして、Scalaで開発しています。

現在３つのScalaのプロジェクトが進行中で、それぞれ、規模は小さいですが弊社のユーザーから強く要望されている機能なので、プロトタイプなどではなく「本気モードで」作っています。同時に、税務本体や会計本体といった弊社のJava基幹アプリケーションを置き換えるプロジェクトを走らせている、そんな状況です。

Scalaが良い理由

先ほど、[言いたいだけ][食べられる方の]カリー[/食べられる方の][/言いたいだけ]うどんを食べながら、プログラミング言語談義をした際に、「Scalaだ」と思ったと書きました。その後、勉強や実証を経て、ある程度言語化できるようになったので、「我々にとってScalaが良いと思った理由」を簡単に述べてみたいと思います。

• 絶対にバグを少なくできる(確信)
• Javaと地続きである
• Play FrameworkやAkkaなど、実用的で実績のあるフレームワークが揃っている
• 関数型プログラミングは楽しい

絶対にバグを少なくできる(確信)

バグのないソフトウェアをつくるための銀の弾丸はありません。プログラミング言語を変えたからといって、バグは減りません。しかし、同じ大きさのソフトウェアを一定期間作り続けたら、Scala(を含む静的型あり関数型言語)ではバグやバグと戦う労力が確実に減ると感じます。たとえば、上記で述べた、「副作用を排除するスタイル」や「高階関数」。これらをうまく用いると、とにかく、書く量が減り、コードがシンプルになります。文章でも、同じことを少ない単語数で述べることができたら、誤字脱字が紛れ込む可能性も、誤字脱字を発見する労力もゼロに向かって減るはずです。プログラミングにおいても、まったく同じようにシンプルで量が少ないコードのほうが、バグが作り込まれる可能性を確実に減らすことができます。
そして「静的な型」です。ある一定の規模のゴールにむけて、よーいどんでサービスの開発を始めたら、多くの場合、Railsなどでの開発したほうが確実に早くローンチできると思います。しかし、ローンチ後の規模拡大、メンテナンス、リファクリングなどにまで視野に入れると、実行時まで問題が見過ごされるかもしれない言語よりも、「型」でコンパイル時にガチガチに守られたプログラミング言語のほうがはるかに安定的です。

上述のA-SaaSコネクトにおいて、書かれたScalaコードは6000行くらいです。思考した量にくらべての最終的なコード量はやはり少ないと思います(主観)。Scala自体や、Play, DDDについてもさぐりさぐりだったので、何度も何度も盛大にリファクタリングをしていますが、堅牢な型システムのおかげでコンパイルまで頑張ればまったく問題が出ません。
また、副作用を排除したコードは、大変読みやすい。保守しやすい。「あれ？この変数がnullになるケースが見つけられない。とりあえず、if (xx != null) 分岐か、NullPoキャッチ」から解放されるだけで、人類の魂のレベルは上がると思います。

関数型プログラミングは楽しい

もちろん、関数型プログラミング以外のプログラミングだって楽しいし、個人差はあります。
ただ、より数学に近い自然な感覚でロジックを組み立てられるから、関数型プログラミングで頭を絞って考えるのは非常に楽しいです。
また、JavaやC++などのオブジェクト指向だけど手続き型な言語に慣れ親しんできた大多数のプログラマーにとっては、「副作用を使わない」プログラミングは、非常に新鮮で、ここで頭を徹底的に切り替えてみるのも、チャレンジングで面白いことだと思います。

Javaと地続きである

われわれのように、Javaで動いているシステムをもち、Javaのエンジニアが何人もいる環境においては特に、JVM上で動く言語を選ぶことはメリットが大きいです。しかし、そういったレガシーのシステムとの関連はなくとも、長年全世界中で積み重ねられてきた膨大なJavaの資産を簡単に使えるということはScalaの大きなメリットです。もしも、事前に見通せないような複雑な問題が起こったとしても、Javaの世界でそれが解決できているなら、Scalaからもそれを使えます。
これは、実際に技術的な恩恵を受けることも多々あるし、新しいことを始める時に必ずある「今見通せないだけで、何か重要なことができなかったらその時どうする？」という不安に対して、さらっと「その時はJavaでやります」と返せるのはやはり大きいです。

Play FrameworkやAkkaなど、実用的で実績のあるフレームワークが揃っている

この点については、あまり述べることはありません。基本的には、実用レベルにおいて、フレームワークやミドルウェアで困ることはあません。ちなみに我々はPlay Frameworkを使っていますが、Akkaも状況に応じてしっかり使っていこうと考えています。

Scalaへの移行方針

弊社では、すでにJavaで動いている基幹業務があります。これらのサービスは基本的には細分化されており、複数の機能が同居しているモノリシックな場所はあまりありません(なくはない)。
上記で、新機能についてはScalaでサービスを新しく作っている、と述べましたが、このように、今後、サービスとして分割できる新しい機能は基本的にはScalaで書いていくことになると思います。
そこで、ノウハウを溜め、エンジニアを育て、税務や会計、給与といったばりばりの基幹業務についての移行を「検討」していくことにになります。税務については、現在Javaで動いている税務のサーバーサイドを代替することを目指す基盤を作っていますが、すべての税目をScalaで更新すると決めてるわけではありません。規模の小さい税務アプリケーションから徐々に載せ替えるかもしれませんし、追加の税目については新基盤でつくっていくかもしれません。現在きちんと動いているものをわざわざ移行する必要はないのではないか？という問いは非常に重要なので、これはきちんと問いかけ続けます。
一番冒頭で引用した記事に書いてありますが、われわれにとって最も大きなレガシーは、Adobe/AIRで書かれた会計アプリケーションの部分です。これを、モダンなSPAに移行していく予定なのですが、この時に、現在、Javaで動いてるサーバーサイドのAPIを、同じくモダンな形で書き直すべきと思っています。なので当然ここにはScalaを使うことになります。

最後に

こうして、弊社ではScalaでの開発がスタートして、軌道にのりつつあります。われわれの移行や進捗や、開発の過程で得た知識などは、随時更新していこうと思います。
なお、いっしょに [言いたいだけ]カリー[/言いたいだけ]うどん を食べた同じ業界のCTOは、現在はわれわれにジョインしてくれていっしょに働いています。A-SaaSでは、いっしょにこの大規模移行を成功させてくれるScala/Javaエンジニアと、フロントエンドエンジニアこれからも募集しております！