シェア
はてブ
新しい技術を採用する際、多くの企業は実績や情報量の豊富さを優先します。特に基幹システムの刷新においては、保守的な選択が一般的です。しかし、時にチャレンジングな選択が組織に変革をもたらすこともあります。
フルカイテン株式会社は2020年、在庫分析SaaSのシステム刷新にあたって、まだ日本での採用事例が少なかったRustを選択しました。静的型付け言語の中でもGoのような実績あるものではなく、当時情報も少なかったRustを選んだ理由には、「せっかくなら楽しい言語を選ぼう」「失敗を恐れるな」という価値観があったといいます。
本記事では、この技術選定に関わったプロダクト開発部部長 横田氏にインタビュー。Rust採用の背景や4年間の成果、スタートアップならではの技術選定の考え方を伺いました。
2020年、新システム構築を決断した背景
――まず、フルカイテン株式会社の事業と、2020年当時のシステムについて教えてください。
フルカイテンでは、小売企業向けに在庫分析SaaSを提供しています。具体的には、商品の売れ行きや在庫回転率、季節性などのデータを分析して「この商品は過剰在庫になっている」「あの商品は欠品リスクがある」といった在庫の問題点を可視化するシステムです。その分析結果をもとに、店間移動する在庫の調整や価格改定などの具体的なアクションにつなげられるよう支援しています。
2020年は、規模の大きな企業からの利用が増え、ビジネス面では順調に成長していた一方で、システムがその成長に追いつけなくなっていた時期です。データ量の急増によりリアルタイム集計処理が重くなり、日次バッチが日中に終わらなかったり、画面表示に5分ほどかかったりする場面も出てきました。リアルタイム性が求められる在庫分析系システムとしては見過ごせない問題です。
――どのような技術で構築されていたのですか？
当時のバックエンドはPython、フロントは一部PHPで書かれていました。技術的には一般的な選択だったと思うのですが、アーキテクチャの設計上、大量のデータをリアルタイムに処理するには限界が来ていました。
その状況を見て、「もうこれはコンセプトから見直してアーキテクチャも全部やり直した方がいいんじゃないか」ということになりました。小手先の対応ではなく、根本的に設計を見直す必要があったんです。
具体的には、リアルタイムに集計するのではなく、事前に集計処理をしておいて、その結果を画面に表示する方針にしました。これにより、画面表示のレスポンスを大幅に改善できると考えたんです。
そこで、システムを1から刷新し、半年後をめどに新システムを構築することになりました。時間的な余裕はなかったのですが、お客様のためにも早急に対応する必要がありました。
なぜ、情報も採用事例も少なかったRustを選んだのか
――新システムの技術選定では、どのような議論があったのでしょうか？
技術選定の基準としては、まず静的型付け言語であることを重視しました。以前はPythonでしたが、新システムでは静的型付け言語の恩恵を受けて生産性を高めたいと考えました。それからメンバー数も多くなかったので、将来的にCLIツールなどのサーバー保守も同じ言語でできるものが欲しかったんです。もちろんWebアプリケーションとして問題なく動くこと、そしてエコシステムが整っていることも重要な基準でした。
――そこからRustを選択したのはなぜですか？
最初はTypeScriptも候補に上がったのですが、型がやや緩いと感じたので、もう少し硬めの言語がいいという話になりました。そこでGoかRustで迷ったんです。
最終的には、他のメンバーが趣味でRustを書いていたことや、「どちらがワクワクするか」を考え、Rustに決まりました。
正直なところ、GoとRustどちらでも良かったと思います。Goのほうがシンプルで、Webアプリケーションとしても多くの実績があり、パフォーマンス的にも十分でしょう。
――「せっかくなら楽しい言語を選ぼう」という考え方があったんですね
また、決め手というほどではありませんでしたが、採用面での狙いもありました。将来的に組織がスケールした際、エンジニアを追加採用する必要が出てきます。そのときにRustのような少しとがった技術を採用していることが、差別化要因になるんじゃないかという考えがありました。
例えば、kubell（旧Chatwork）さんがScalaという技術を選んだことで、エンジニア採用がうまくいったという話があります。こうした事例が、我々のようなスタートアップにも当てはまるんじゃないかと思ったんです。
当時のRust学習環境――意外と低かった導入のハードル
――Rustは学習コストが高いと言われていますが、2020年当時のRustの学習リソースはどのような状況でしたか？
当時は本当に限られていました。『The Book』と呼ばれるRustの公式ガイドと、Qiitaの一部記事、書籍も数冊しかなかったという記憶があります。
基本的には、それらのリソースを参考にしながら、コンパイラと戦っていくという形でした。Rustのコンパイラは非常に親切で、エラーが出た時に「こうしたらどうですか」という指示をくれます。その指示に従って修正していく中で、どういう言語なのかを学んでいきました。
ですが、思ったほど大変ではなかったというのが正直な感想です。私自身がSwiftやKotlinなどのモダンな言語を経験していたので、Rustの文法はそれらと似ている部分も多く、そこまで学習コストは高くなかったんです。
確かに借用やライフタイムといった概念は他の言語にはない大きな違いですが、それ以外の部分はそれほど難しくありませんでした。新しくフルカイテンにジョインしてくれたエンジニアに聞いても「そんなに苦労していない」という反応が多かったので、世間で思われているほど学習コストが高くないのかもしれません。
これまでにどんな言語に触れてきたかで、感じ方が違うのではないでしょうか。PythonやRubyなどの動的言語をメインで使ってきた方がRustに挑戦すると、静的型付けの概念自体に慣れる必要があるので、ハードルは高く感じるでしょう。
一方、JavaやKotlin、Swiftなど静的型付け言語を触ったことがある人なら「Swiftのあそこと一緒だ」といった具合に知識を繋げやすいので、比較的身につけやすいのではないでしょうか。我々のチームはたまたまそういったバックグラウンドを持つメンバーが多かったのかもしれません。
――チーム内ではどのように学習を進めていったのでしょうか？
特別な取り組みはあまりなく、わからないところはペアプロでやったり、お互いにアドバイスし合ったりする程度でした。「こういう書き方の方がいいよ」というノウハウを共有するぐらいです。
それでも「やってみたら意外といけちゃった」という感覚です。正直、想定していたよりも導入のハードルは低かったというのが実感です。
この4年で感じたRustのメリットとデメリット
――4年間Rustを使ってきて、技術面でのメリットを教えてください。
まず一番大きいのはコードの品質が上げやすいという点です。静的型付け言語の恩恵ももちろんありますが、Rustの場合は他の言語では見つけられないような不具合もコンパイル時に検出してくれます。コンパイルが通れば、そのままうまく動作することが多いので、安心感がありますね。
次にリファクタリングのしやすさです。コンパイラが厳格にチェックしてくれるので、大規模な変更も比較的安全に行えます。さらに言語のバージョンアップも非常にスムーズです。通常、バージョンアップは「今動いているから後回しにしよう」となりがちですが、Rustの場合はその怖さがあまりないんです。どんどん最新バージョンに追従していっても問題が少なく、小さな差分で済むことが多いですね。
また、RustのLinterであるClippyも進化していて、コーディングスタイルの改善提案をしてくれるようになりました。中長期的な開発の生産性という意味では、かなり良かったと思います。
加えて、処理性能でも良かった点があります。フルカイテンのシステムではAWS Lambda上で大規模なCSV生成処理を行っていますが、起動の速さとメモリ効率の良さから高パフォーマンスを実現できています。最近も数GiBのCSVを生成する要件に対し、ストリーム処理を導入することで、安定した高速処理が可能になりました。
――逆に技術面で苦労したことはありますか？
非同期処理の扱いには苦労しました。特に我々の場合、WebアプリケーションとAWS Lambdaで同じソースコードを使っているので、非同期ライブラリであるTokioのバージョンを両方で合わせる必要があり、一気にバージョンアップしにくい状況がありました。
エコシステムの変化への対応も大変でした。例えばAWSのSDKとして使っていたrusotoの開発が止まり、新しいSDKに移行する必要が出てきました。こういったライブラリの移行作業は避けられませんでした。
また、4年前は情報も少なく、ベストプラクティスがわかりにくかったんです。マクロというRust特有の機能を過剰に使ったり、無駄に抽象化したりして、技術的負債になってしまった部分もあります。マクロはボイラープレートコードの削減には便利ですが、普通にメソッドで実現できるようなことまでマクロで書いてしまうと、後の人が読みにくくなりますね。最近は「用法用量を守りましょう」という意識で、適切に使うよう心がけています。
――4年たった今、当時の技術選定をどう評価していますか？
結果的には良い選択だったと思います。最初はWebフレームワークも少なく、今から思えば大変な時期にチャレンジしましたが、言語自体の進化とともに我々のコードも成長してきました。
リファクタリングのしやすさは本当に価値があります。情報がなかった当時、Javaライクにコードを書いたり、過度に抽象化したりした部分もありますが、そういった技術的負債も随時返済していけるのはRustの強みだと感じています。
現在ではベストプラクティスも多く出てきていて、Webアプリケーションの構築方法も確立されてきました。4年の間に書籍も増え、情報も豊富になっていますので、今なら当時よりずっと楽に開発できるでしょう。
挑戦できたのは組織文化のおかげ。技術選定で大事なこと
――フルカイテンの企業文化について教えてください。どのような考え方を大切にされていますか？
そうですね。代表の瀬川は「みんなを笑顔にする」という思いから創業していて、社員も楽しく仕事をしようという考えが強いと思います。会社として大切にしている3つのバリューのうちの1つに「失敗を恐れるな」があります。これは、成功しようが失敗しようが挑戦すれば必ず気づきがあり、挑戦しなければ得るものがないという考え方です。
リスクを最小限に抑えることは大事ですが、挑戦することを大切にしたいという価値観が会社にはあります。「楽しい言語を選ぼう」という判断ができたのも、この文化があったからこそだと思います。
――現在のRustの活用状況と今後の展望を教えてください。
現在はAPIレイヤーでRustを使用していますが、今後はデータ基盤の集計部分にもRustの活用を検討しています。
具体的には、PolarsというRust製のデータフレームを使った逐次集計処理をPythonで実装しているのですが、この部分をRust化できればパフォーマンス向上が見込めると考えています。ただし、データ分析全体をRustに移行するわけではなく、Pythonのライブラリが強い部分は引き続きPythonを使うという「適材適所」の考え方で検討しています。
フルカイテンは4年前と比べて大きく成長し、プロダクトの機能数も増えました。特にデータ基盤の集計速度は大幅に改善。Rustの部分はコアとなるAPIとして安定して動作しています。
――最後に、技術選定において大切にしたいことは何ですか？
私は以前の職場で技術選定に関わった際、かなり保守的な判断をして後悔した経験があります。既存の言語を選んでしまい、後になって「もっと別の選択肢があったのでは」と感じました。
スタートアップだからこそ提供できる価値もあると思います。大手企業で100人規模のエンジニアを採用する必要があれば、当時のRustは選べなかったでしょう。しかし小規模組織だからこそ、エンジニアの「ワクワク感」を優先した選択ができました。
リスクと向き合いながら、組織の規模や文化に合った「挑戦」をする。そのバランス感覚が、技術選定では重要ではないでしょうか。
取材：Findy Engineer Lab編集部
執筆：河原崎 亜矢
