運用に入ってから気づいたこと・苦労したこと
Scalaの採用を決めて約4か月後の9月、ついに弊社初のScalaによるプロダクトがリリースされました。Appilvの海外版です。
運用を開始してからも新たな問題が見つかりました。Scalaで実装したアプリケーションは、実行時にはJavaプログラムとして動くことになりますが、それまでPHPでシステムを構築・運用してきた弊社には、サーバーでJavaを動かすノウハウがありませんでした。そのため当初は、サービスの永続化に困ったり、そもそもサーバーに必要なスペックを見積もれなかったり、といった問題にぶつかりました。
また、半年近く開発してきてわかったこととして、Scala本体やライブラリのバージョンアップペースが早く、キャッチアップするのが大変なことでした。しかも、ライブラリの実装がScala本体の特定のバージョンに依存していることが多く、気軽にはバージョンを上げられないのです。結果として、Scala 2.10に依存するライブラリと、Scala 2.11に依存するライブラリが併存することになってしまい、サービスがうまく動かなくなったり、時間をかけてバージョンアップに追従せざるを得なかったりしました。
そして、これらの作業すべてにおいて情報が少なく、あったとしても英語で書かれており情報収集が難しい、という問題がついて回りました。
最初から考慮できていたらよかったこと
思った以上に苦労させられたScalaへの移行とマイクロサービス化ですが、振り返ってみると、もっと準備はできたのではないかと思います。もう少し早い段階で学んでおけばよかったこととしては、まず「ドメイン駆動設計」に対する理解です。ドメインをきちんと理解しないまま開発をスタートさせたため、ただ細かく分かれただけの、変更が難しいサービスになっている部分がありました。ドメイン駆動設計の理解を事前に深めておけば、変更に強い構成にできたでしょう。
また、完成させるものではなく育て続けるものと認識して、設計変更時に押さえるべきポイントや流れをあらかじめ考えておけば、もっとスムーズに作業が進んだはずです。どこかで「作りきったらおしまい」と、完成させることだけを考えていたような気がしますが、これではせっかくのマイクロサービス化の旨味も薄れてしまいます。
そして最後に、自分たちでは完結しないことを自覚し、関連する別プロジェクトチームとの連絡・共有手段をもっと洗練させておく必要性を感じました。どうしても自分の関わった部分とそうではない部分には理解度に差があります。また、今後各プロジェクトがそれぞれに機能追加や改修が必要になることを考えれば、それを見越した連絡・情報共有手段は今後も絶対に必要となってくるでしょう。
Scalaといえば真っ先に思い浮かぶ会社になることを目指して
様々な問題にぶつかったものの、結果としては導入決定から1年を待たずに、すでに社内の半数のプロジェクトがScalaに移行することができました。まだPHPで動いているものもありますが、メンテナンスは続けつつ順次置き換えていくことができるでしょう。
実際に業務で使うことで、Scalaを書けるエンジニアも育ってきました。しかし、その習熟度にはばらつきがあることが今のところ課題です。中でも、PHP以外の言語にも触れてきたエンジニアほど習熟が早い一方、PHPしかやってこなかったエンジニアにどうやって学習してもらうか、あるいは新卒エンジニアをどう教育していくかは、今後の課題になるだろうと思っています。
また、これから先、Scalaでプログラムを書けるだけでなく、Scalaについて情報発信ができるような体制を整えていきたいと考えています。Ruby on Railsといえばクックパッドさんが真っ先に思い浮かぶように、「Scalaといえばナイル」と呼ばれる存在になることが、Scala採用の大きな目標の1つです。先行してScalaを使っている他社様にはない、ナイルならではの差別化点を見つけて伸ばしたいと思います。
