こんにちは。株式会社Luup CTOの岡田(@7omich)です。
私たち Luup は "街じゅうを「駅前化」するインフラをつくる" というミッションを掲げ、電動マイクロモビリティのシェアリングサービス「LUUP」を開発・運営しています。
このサービスは、現実世界の街中に配置された数万台規模の車両やポートを管理し、大量のユーザーが適切に利用できる状態を維持しなければならない、難易度の高い技術的要求を伴う事業でもあります。
この記事では、Luup のプロダクト開発においてどのような技術選定がなされており、その裏側にはどんな考え方があるのかについて少しお話ししようかと思います。
全体像
まず、私たちが採用している技術構成については、アーキテクチャ図も含めて以下の記事に詳細に掲載しています。
リンク先の記事は2023年12月末時点のものですが、大きなところは今もそこまで変わっておらず、ざっくりまとめると以下のような特徴があります。
- ユーザー向けのモバイルアプリは Swift, Kotlin ネイティブで開発しつつ、社内業務管理用のモバイルアプリには Flutter を採用
- バックエンドには Node.js を、フロントエンドには Nuxt.js をメインで採用し、いずれも TypeScript で開発
- インフラは GCP + Firebase に、回線側も SORACOM のマネージドサービスを幅広く統合
- データ基盤は Airflow, dbt, Monte Carlo 等の活用により運用工数を効率化しつつ、地理空間データの活用に注力
全体としてすごく尖った選定をしているわけではなく、その分野ごとのトレンドに沿った、なるべく効率のよい技術採用ができることを大事にしています。
技術選定の方針
チームやアプリケーションごとに経緯や理由に差はあるものの、技術選定の段階で概ね以下のようなことを意識しています。
（※ LUUP はユーザー目線では現状単一プロダクトの事業ですが、開発しているアプリケーション単位でみるとユーザー向けモバイルアプリだけでなく社内用の管理システムが Web とモバイルそれぞれ存在したり、IoT 制御関連システムや他部署の業務支援システムなど様々なサービスを開発しています）
持続可能性と一般性
およそ技術選択の際には一般的に重視されるべきことですが、その時点で一定以上成熟したコミュニティーや、周辺ライブラリ・フレームワーク等エコシステムの充実が観測できるかどうかは必須条件です。
例えば、社内向けの管理用モバイルアプリに採用している Flutter についても少し前から採用する考えやユーザーアプリに使えるか？といった議論もありましたが、公式のリポジトリーがどれくらい活発に更新されているかウォッチしつつ、プロダクションでの運用事例がある程度世の中に貯まるまで慎重に検討してから採用を決めました。
Web 側の開発に全面的に採用している TypeScript についても、2010年代後半くらいからの静的型付け言語のトレンドを鑑み、幅広い開発者が触れてきているであろう JavaScript の技術経験を転用しやすいことから採用しています。
2025年現在もそのトレンドは衰えておらず、盛り上がっている技術コミュニティーの恩恵を受けられる状態になっており良い感じです。
フロントエンドとバックエンドで一貫した言語選定をできることも、少人数で開発する必要があるスタートアップのチーム組成の上では大きなメリットになりました。
また、市場トレンドとマッチした技術選択をすることで、新しい人材を採用するハードルも下がりますし、いま在籍しているメンバーがどこかに転職した後も効率的にキャリアを歩みやすくなります。
組織内で育成に掛けるリソースの余裕が少なく、即戦力となるメンバーを次々採用しながらビジネス上の要求に合わせてプロダクト開発を進めていかねばならないスタートアップでは、この人材流動性の高さは業界全体のメリットになると考えています。
開発規模の初速とスケーラビリティ
LUUP はプロダクトの機能向上やユーザー獲得のマーケティングだけでなく、新しい都市・エリアへの展開であったり、ポートや車両の増加によっても急速に拡大していく性質のサービスです。
サービスの拡大にシステムがついていけるよう、とにかく迅速に開発→リリースを繰り返すことのできる環境を作る必要がありました。
そのため、初期から Firebase を広く採用し、Cloud Functions によるサーバーレス API の構築、メインのデータベースとしてスキーマレスな Firestore を利用することで柔軟でスピーディな開発を実現してきました。
Firebase, GCP の基盤の上に最初から乗っておくことで、その後のスケールもお金さえ払えば比較的容易に実現できています。
開発人員が増え、システムの規模も大きくなってきてからは少しずつ Cost-efficient な構成に移行したり、ある程度土台が整ってきた現在は、部分的なスキーマ定義やRDBへの移行検討も進めています。
車両との通信を担う IoT 周辺アーキテクチャについても、回線レイヤーには SORACOM のマネージドサービスを組み合わせ、ゲートウェイには AWS IoT Core を採用することで信頼性が高くスケーラビリティも担保できる狙いの構成となっています。
ビジネスのグロースの道中でソフトウェアがつまずいてしまっては勿体ないので、サービスや開発組織の規模がついてくるまではクラウドサービスのマネージドなソリューションを生かしています。
運用コストの最小化
1つ前の点と少し被りますが、マネージドサービスをフル活用することでサービスの運用・保守に掛かる手間が少なくなり、本筋の機能開発へ集中できるようになるのも大事なポイントです。
例えば Luup ではデータ基盤の構築においても、Airflow や dbt の採用で管理工数を削減しつつ、Monte Carlo の監視によって Data Reliability も担保しており、社内でのデータ活用のためのBI基盤整備や地理空間データの収集および可視化に力を入れられるようにしています。
ユニットテストや UI テストの自動化 Terraform を用いた IaC 化にも力を入れており、早いうちから一定のイニシャル工数を支払うことで将来の運用コストや品質の面で有利になるような最適化を、先々の開発規模や要件をできる限り想像しながら適切なペースで取り組むようにしています。
番外編: 技術へのモチベーション
総じてビジネスを成長させるためのプロダクト要件を柔軟に、将来に亘っても持続的に実現し続けられることを意識した技術選定をその場その場で繰り返していますが、最適と思われる選択はその時の事業フェーズやチームメンバーによって変化していくものです。
Luup は「技術は事業を成長させ、会社のミッション実現を助けるための手段である」という考えをもっています。これは経営において技術を軽視するということでは決してなく、むしろ適切な技術選択を常に続け、時には他社に対する技術的な強みを作っていきながら、事業および会社の成長の一軸として支えていくことだと思っています。
現状の Luup ではなるべく一貫した技術スタックを意識していますが、どの技術を使わなくなったり別の技術に移行したりすることがあっても、新しく習得したり周囲の経験者のサポートを受けたりしながらキャッチアップしていける姿勢を重要視していますし、そのようなモチベーションのメンバーが集まっています。
最後に
Luup では、組織と個人の技術面での成長をどちらも大事にしながら、未来のモビリティインフラを一緒に創っていけるソフトウェアエンジニアを積極的に募集しています。
私自身や、各開発チームのリーダーともカジュアル面談で直接話せる応募フォームも掲載しておりますので、ぜひお気軽にお声掛けください！
Discussion