Rails+Vue.js+TSを採用。Go+Reactの導入も見据える。産業廃棄物業界SaaSを支える技術

ファンファーレ株式会社は、持続可能な社会の実現に貢献するエッセンシャルテック企業です。廃棄物回収の配車計画を自動作成するSaaS事業「配車頭（ハイシャガシラ）*」を運営しています。そして、ファンファーレでは開発効率向上やサービスの品質向上のため、採用する技術スタックや開発体制を工夫しています。

技術についての詳細や産業廃棄物業界の課題を解決する醍醐味について、フロントエンドエンジニアの中山太雅（写真中央）とバックエンドエンジニアの安部秀基（写真左）、フロントエンドエンジニア・プロダクトマネージャーのガーワル・ロビン（写真右）に語ってもらいました。

*…「配車頭」は、産業廃棄物業界に特化した配車表作成サービスです。産業廃棄物の収集運搬のための配車計画を自動作成することで、今いる乗務員でより多くの配車を実現し、複雑で手間だった配車計画作成に必要な作業時間の大幅な短縮や、労働負荷の軽減を実現します。

「配車頭」で用いられている技術スタック

――「配車頭」で用いているプログラミング言語やフレームワーク、インフラなどの内訳を教えてください。

中山：私はファンファーレの黎明期からエンジニアとして働いているため、技術選定の経緯などは主に私のほうから解説させてください。「配車頭」はシングルページアプリケーション（SPA）の設計で構築されたWebアプリケーションです。フロントエンドから説明をすると、言語はTypeScriptを、フレームワークはVue.jsとNuxt.jsを使用しています。UIライブラリがVuetifyで、サーバーサイドとの通信にはGraphQL、一部でRESTを活用しています。

TypeScriptの採用には、私の個人的な思いが強く影響しています。スタートアップでプロダクト開発を行う場合には、仕様が頻繁に変わる可能性があります。コードを修正したときに「どの箇所に影響があるのか」をなるべく早期に検知できるほうが良いため、TypeScriptの導入は必須だと考えました。最近参画したエンジニアなどからも、「TypeScriptによって型安全性が担保されているからこそ、フロンドエンドのコードを修正しやすかった」と言われています。

GraphQLについてもお話しすると、技術選定をした当時は通信手段としてRESTやGraphQL、gRPC-Webなどの選択肢がありました。GraphQLを選んだ理由は利用者側がクエリの内容を柔軟に組み立てられるため、今後サービスが成長していく過程でその特徴がプラスに働くと考えたからです。さらに、現在はまだ利用していないのですが、プロダクトの使い勝手を向上させるためにGraphQLのSubscription処理なども将来的に活用したいという構想もあります。

gRPC-Webでも近いことができた可能性はありますが、サービスを立ち上げた2年半くらい前の時期には、あまりgRPC-Webのクライアントライブラリの機能が充実していませんでした。そのため、開発に支障が出るかもしれないと考えてGraphQLを採用したという経緯があります。

フロントエンドエンジニア 中山太雅

ロビン：私は2021年にファンファーレに参画して、中山さんが構築したフロントエンドのコードを触るようになりました。確かに、TypeScriptの恩恵はたくさんありますね。型情報があることでコード修正の安全性が高まるだけではなく、各種データが事業ドメインの何の情報を指しているのかがわかりやすいです。型情報がドキュメントのような役割を担っており、アプリケーションの仕様のキャッチアップがあとから参画したメンバーにとっても容易です。

――次にバックエンドやインフラもお願いします。

安部：先ほど中山さんが話したフロントエンドのファイルはAmazon S3に配置されています。サーバーサイドではRuby on Railsで書かれたAPIがAmazon ECS on AWS Fargate上で動いており、ジョブ管理にはDelayed Jobを活用しています。

このAPIサーバーのさらに後段には、配車表作成などの“最適化”と呼ばれるロジックを担う別のAPIがありますが、その話は別のインタビューで担当者が解説する予定です。データベースはAmazon Aurora MySQLを使っており、さらにAmazon ElastiCache for Redisをセッション管理のために用いています。また、これらのインフラの構成はすべてTerraformで管理しています。

クリーンアーキテクチャ・スキーマ駆動開発を導入

――システムの設計としてはどのような手法を取り入れていますか？

中山：フロントエンド側は、クリーンアーキテクチャの思想を一部取り入れた設計になっています。前提情報として、過去から現在までの開発体制の変遷について説明させてください。2年半ほど前にプロダクトを開発し始めた時期には、CEOとCTO、私、副業のバックエンドエンジニアという4名体制からスタートしました。そして、開発リソースがフロントエンド偏重になっていたため、本来であればバックエンド側で実装したほうが良い処理を、フロントエンド側で巻き取っている箇所がいくつもありました。

これを、あるタイミングでリファクタリングし、フロントエンドで担っていた処理の一部をバックエンド側に移しました。そのときに、先ほど述べたクリーンアーキテクチャの設計を取り入れたんです。モジュールを複数のレイヤーに分けてテスタビリティを向上させ、ある程度の大きさのサブドメインごとにディレクトリを分けて構造を整理しました。

他に、設計手法として取り入れているのはスキーマ駆動開発です。前提として、私たちの開発チームではフロントエンドとバックエンドを別々のエンジニアが担当します。各々のエンジニアが事前にGraphQLのスキーマで合意形成した上で開発を行うことによって、両者の意思疎通がかなりやりやすくなっています。

また、バックエンドエンジニアが別のタスクで忙しくてバックエンド開発をなかなか進められないとか、その逆のパターンは必ず起こり得ます。そんな場合でも、スキーマの情報さえ定義できていれば、フロントエンドまたはバックエンドどちらかの開発が完了するまで待つ必要がないため、開発効率が良くなります。たとえば、フロントエンドでstubの実装を用意しておけば、バックエンドのAPIが完成するのを待つ必要がありません。

ロビン：ファンファーレは副業や業務委託で開発に携わっているエンジニアが多いので、各メンバーの作業ペースは異なりますし、非同期でのコミュニケーションが基本になります。そんな場合でも、スキーマさえ決めてしまえば問題なく各々のペースで開発ができるのは、スキーマ駆動開発の利点ですね。

フロントエンドエンジニア・プロダクトマネージャー ガーワル・ロビン

業界特化型のSaaS“ならでは”の面白さ

――ファンファーレが扱っている「配車頭」は産業廃棄物業界に特化したVertical SaaSです。産業廃棄物業界をエンジニアリングで解決する大変さや面白さはどのような点にあると思いますか？

ロビン：大変さと面白さがセットになっていると感じています。前提として、「配車頭」は産業廃棄物業界に特化した配車表作成サービスで、産業廃棄物の収集運搬のための配車計画を自動作成します。そして、「どのような場合に、産業廃棄物収集運搬事業者が配車依頼を受注できるのか」という条件が、事業者ごとに全く異なっています。

たとえば、「ある排出場（廃棄物が出る場所）は○○のトラックを使用できるけれど、別の排出場は使用できない」とか「ある排出場ならばトラックが高速道路を使用可能だけれど、別の排出場は使用不可能」といったように、各々の産業廃棄物排出事業者が独自のルールや制約を持っており、収集運搬を受注した産業廃棄物収集運搬事業者はそれらに細かく対応する必要があります。

そのため、会社ごとの制約の差分を吸収できるように、データの設計を考えなければなりません。この際に、ある程度は汎用化しなければ個社対応になってしまいますし、ある程度は個社対応できなければすべてのユースケースを賄いきれません。そのバランスが難しいです。こうした複数の制約を考慮しながら利便性の高いプロダクトを作っていくことは、エンジニアとして充実感があります。

安部：私はよくユーザー企業のところに伺って、トラックのドライバーや配車担当者、営業など私たちエンジニアが普段なかなか会えない方々と話をします。彼らは決してITリテラシーが高くないものの、産業廃棄物業界に長くいるのでサービスにおける機能の有益性について的確な意見をもらえます。そうした方々に向けて使いやすいプロダクトを届けることが、私にとって一番面白いと感じている部分です。

バックエンドエンジニア 安部秀基

中山：産業廃棄物業界では、各種の法律や規制を遵守する必要があります。禁止されている行為や、文書に記載しなければならない項目が明確に決まっています。そうしたドメイン知識を学んだうえでプロダクトを作らなければならないのは大変ですね。ただ、各種の制約をクリアしつつ良いプロダクトを作るのは、業界に特化したSaaSの面白さでもあります。

「自分たちの生活を支える人々への恩返し」のような仕事

――これから使用技術やアーキテクチャをどのように改善していきたいですか？

安部：これは開発のインフラ環境の話ですが、現在「配車頭」にはステージングとプロダクションの2環境だけが存在しています。以前はこのシンプルな構成で問題なかったのですが、最近はエンジニアの数が増えてきたことと複数プロジェクトが並行して走るようになってきたため、「他の人がステージング環境を使っているため、QAテストを実施できない」などの課題が発生するようになりました。そのため、今後は環境の数を柔軟に増やせる仕組みを構築していきたいです。

中山：先ほど、「ある時期にフロントエンドの設計を見直してリファクタリングした」という話をしましたが、本当はまだ直したいと思っている箇所がいくつかあります。例を挙げると、フロントエンドで扱っているエンティティが、多種多様な情報を持ちすぎているんです。画面全体のリアクティビティに配慮した結果でしたが、今となってはもう少しそこを妥協して部分ごとに分割統治するようなやり方でもよかったかなと考えています。

また、今後も産業廃棄物業界のさまざまな課題を解決するために、「配車頭」以外にも順次サービスを立ち上げていくと思います。そうした場合、現在の技術スタックであるRuby on Rails+Vue.js+TypeScriptではなく、GoやReactなどを用いる可能性も出てくるはずですし、社内でもそうした検討をしています。

だからこそ、「今はRuby on RailsやVue.jsの経験しかないけれど、今後は別の技術にも触れてみたい」と考えているエンジニアが、自分の持っているスキルを生かしつつ新しいチャレンジができる環境になっていくはずです。

――これからの展開が非常に楽しみですね。結びとして、将来的にファンファーレへ転職するかもしれないエンジニアの読者にメッセージをお願いします。

中山：ファンファーレはこれからも、産業廃棄物業界で働く方々に向けてソリューションを提供していきます。「現場の人たちはこんな悩みを抱えているから、こんな機能を提供しよう」とか「少しでも、業界で働く人々のペインを理解したい」という気持ちを持てる人ならば、ファンファーレで働くことをきっと楽しめるはず。そういった日々の喜びを糧に頑張れる人と、私たちは一緒に働きたいです。

ロビン：私はこの仕事が、自分たちの生活を支えている人々への恩返しだと思っています。ゴミを収集してくれる人がいなければ、私たちの生活は成り立ちません。産業廃棄物業界は社会インフラです。そんな人たちの仕事をソフトウェアの力で支援するというのは、自分にとってはやりがいのある仕事です。社会の根本的な課題を技術で解決したい人にとって、充実感を持って働ける職場です。

安部：私はこれまでのキャリアのなかで、ほとんど使われないまま自分の作ったサービスが終了するとか、プロジェクトそのものが途中で中断することが何回もありました。だからこそ、「使ってくれる人が世の中に確実にいる」というのは、大きなモチベーションにつながっています。それも、人々の生活にとって必要不可欠な領域を支えるサービスですから、余計にやりがいは大きいです。

ファンファーレでは、一緒に働くメンバーを募集しています！
CTO候補、エンジニア、UI/UXデザイナー、カスタマーサクセス、セールスなど、幅広い職種で採用強化中です。この記事を読んで少しでもご興味をお持ちいただけたら、ぜひご応募ください。
★採用ページ（https://fanfare-kk.com/career/）
まずは、選考ではなく ”会社の雰囲気” や ”気になる職種の業務内容” について話を聞きたいという方向けにカジュアル面談も実施しています。
「気になるけれど選考に進むか悩んでいる」という方にオススメです。
★カジュアル面談申し込み用（https://herp.careers/v1/fanfare/RTPE3NsIZm-y）