🗓

2022年の Luup 技術組織を振り返る

2022/12/25に公開

※この記事は、Luup Advent Calendar の25日目(最終日)の記事です。

こんにちは、株式会社Luup CTO の岡田(@7omich)です。
弊社では今年が初の試みとして始まったアドベントカレンダーですが、1日目の記事を書いてから早いものでもう4週間近くが経過し、今年も終わりに差し掛かっています。

私は2記事目の執筆として最終日の枠を任されたわけですが、これまで公開された記事を振り返ってみると、非常に読み応えのある良い記事が揃っているなぁと思います。
今まで継続的に技術関連の発信ができていなかった我々にとって、アドベントカレンダーはとにかく完走できれば上出来、緩い内容でも出すことそれ自体を大事にしていこう、というくらいの考えで始めました。
しかし実際には LUUP の事業的な特徴やそこに紐づく面白さが伝わる記事であったり、そのような特徴に根ざしたユニークな技術的取り組みを発信した記事がたくさん集まり、ここまでちゃんとしたものが(抜けや遅延もなく)完成するとは!と驚いています。

それだけの発信体力がついている Luup の現在の技術組織のことを喜ばしく思いつつ、昨年はこのようにはいかなかった(実はアドベントカレンダーやりませんか!?という話はあったが、その時はメンバーの負荷が高すぎるとなり断念)ため、その点はこの1年で大きく変わったと感じています。
本記事では、そのような組織キャパシティの向上も含めて、2022年の間に Luup の技術組織にどのような変化・成長があったかを振り返ってみようと思います。

月ごとに時系列的に追っていくことも考えましたが、杓子定規的かつ長くなりそうなので、要素ごとにピックアップして書いてみようと思います。
また、ソフトウェアエンジニアリングや技術組織の体制まわりの話題を中心に触れていきます。事業やプロダクトの展開にフォーカスした今年の振り返りは、Luup公式noteから以下の記事が出ているので是非ご覧ください!
Software Development 部のメンバーや、17日目の記事を書いてくれたプロダクトマネージャーの石田さんも記事に出ています。

https://note.com/luup/n/nbbc3dad02a2e

組織規模の拡大

2020年5月のローンチ以来、今年で3年目に突入した LUUP のサービスですが、利用していただいているユーザーの皆様のお陰で、今年1年間我々の事業は拡大傾向にありました。
具体的なユーザー数やライド数などの事業数値を詳しく書くことはできないですが、ある種公開情報とも言えるポートの設置箇所についてお話しすると、21年12月時点で700箇所程であったポート数が現在は2,400箇所以上となっており、それだけでも単純に3倍以上の事業規模の拡大といえます。
そのような状況下で、後述する要件の複雑化に対応しつつ品質の高いソフトウェアを維持するため、Software Development 部のメンバーはこの1年間で大きく増加しています。

具体的には、

  • 2022年1月時点: 正社員3名、業務委託20名程度
  • 2022年12月時点: 正社員7名、業務委託30名程度

と、全体としておよそ倍近い規模になっています。
(※ 12月時点での各チームの人数感は以下の記事にまとまっています)
https://zenn.dev/luup/articles/etc-okada-20221201#各チームの説明

単純に全体として倍近い人数になったというだけでなく、6つあるチームごとに見てみると、1チームあたり 3-4 人だったものが 7-8 人になるというのは大きな変化です。また、その中でも特に事業戦略に対する一段階高い理解をもってコアロジックに触れる機会の多い正社員のメンバーが倍以上になってるため、チーム内の業務上のコラボレーションのあり方は大きく変化しました。

これまでは少数精鋭チームであることを生かし、正社員や中核メンバーに関して属人性の高い状態であってもDeliveryが高速に行えるというメリットを享受してスムーズに開発ができていました。ただし関わる人数が多い状態で開発のスループットを高く維持するためには、実装理解の共有や仕様にまつわるコミュニケーションコストの低減が求められるようになります。
そのため今年はとりわけ、タスク管理方式の見直しや定例等会議体の整備、Notion/GitHub Wiki上での仕様ドキュメントの作成といった取り組みが各チームで行われるようになりました。

※ 人数が多くなったというのは決して採用観点で満たされている状態にあるという意味ではなく、上で触れたような事業開発の中核になる正社員や、今後のより大きなサービス展開を見越した技術的意思決定ができるメンバーなど、今後の LUUP に必要な技術人材を継続的に温度感高く採よ…(以下略)

複雑化するサービス要件に対応する

サービス2年目となる2021年は東京以外のエリアに初めて本格展開(大阪)したり、電動キックボードのサービス提供が開始したりと、新規ローンチをたくさん行うドラスティックな時期でした。2022年は、その上で様々な要件でのサービス拡張であったり、大きな機能追加(予約機能・モビリティ別フィルター機能・領収書発行機能・etc...)が行われたりするような、いわばサービスの複雑化が印象的な1年間となっていました。

例えば、こちらの記事にあるように、2月にはサービスロゴの刷新と同時に新しい車両が電動キックボード・電動アシスト自転車ともに紹介され、その後数ヶ月間で各エリアに導入されていきました。
この新車両の導入には様々なチームが連携して開発を進めていましたが、特に車両とバックエンド間の通信の仕組みを作っているIoTチームでは、車両の種類が増えるに伴い通信部の複雑性がかなり上がったため、アーキテクチャの見直しを行いました。以下のIoTチームの記事に、周辺のアーキテクチャの概況が記載されています。
https://zenn.dev/luup/articles/iot-okaya-20220608

また、乗り放題ウィーク「LUUPでワープ!」キャンペーンなど、ライド料金が割引or無料になる大型キャンペーンを複数回実施する過程で、料金算定ロジックやクーポン付与機能にも様々なアップデートが行われました。
対象エリアや対象ポート、利用時間帯など様々な条件でキャンペーン毎に異なる内容の割引が付与されるため、これらのロジックを整理したり、マーケターなどの非開発者でも設定ができるよう管理画面の要件に落とし込むなどの改修を Server チーム主導で実行しました。

こういった複雑化するサービス要件を整理して抽象化された要件にまとめることは、現在の実装や将来の変更可能性について深い理解と検討が可能なエンジニアならではの仕事なので、優秀な技術メンバーにとって難しく面白い挑戦が多かったと思います。

サービスの品質・信頼性の向上

サービスの規模が大きくなるにつれて、ソフトウェアの品質を高めたり、サービスの信頼性を上げることで既存のユーザーの顧客体験を高く保つことの重要度が相対的に増していきます。
LUUP のサービスにおいても、エリアや車両にまつわる新規ローンチやアグレッシブな機能開発をハイペースに進めていった結果、不具合の発生が顧客体験を損なったり、カスタマーサポートやオペレーションチームの運用負荷に繋がったりするケースが時たま目立ってきました。

そこで、Software Development 部では2022年の後半、部門目標の上位に品質・信頼性にまつわる指標を複数設定し、クライアント/サーバー/インフラそれぞれのレイヤーでサービス品質の改善やブロッカーとなりうる技術負債の解消に取り組んできました。

例えば iOS, Android チームではユーザー向けアプリのクラッシュ率(7日間での Crash-free Rate)をメトリクスとし、機能開発とのリソース配分バランスを調整しながら原因の特定に取り組んでいましたが、その結果、現在は両OSとも安定して 99% 以上の水準を達成しています。
特に改善幅の大きかったiOSアプリでは、マップ画面におけるメモリーの逼迫により起きていたクラッシュの割合が大きく改善着手前は 95% 未満であった 7days Crash-free Rate が、現在では 99.8-99.9% 程度の水準を安定するほどになりました

luup-ios-crash-free-rate
iOSアプリの7日間 Crash-free Rate(3ヶ月前までしかログが遡れませんでした)

また、もう少し前の時期からではありますが、インフラエンジニアと Site Reliability Engineer が協働する SRE チームを立ち上げ、SLI/SLO の策定と運用、監視項目の洗い出しや Playbook の作成、Terraform によるインフラの IaC 化、負荷試験とキャパシティプランニング…等々、サービスの信頼性の向上に繋がる様々な取り組みを実施しています。
この記事にて詳しく説明されていますが、LUUP のライド数が10倍になってもスケール可能なインフラを構築しましょうという目的の Project 10X を定義し、今後の事業拡大に備えたアクションを前もって実行しています。

新技術導入や開発者体験に関わる挑戦

ここまで述べたような様々な要求を満たしながらソフトウェアプロダクトを作り、それをなるべく早いリードタイムでユーザーに届けていくためには、アーキテクチャや開発環境の見通しが良く、関わるエンジニアの開発者体験がよい状態を一定以上維持できていることが重要です。開発者体験は開発生産性と必ずしも一致しないですが、強い相関があると考えています。
そのためには、採用する言語やフレームワーク、ライブラリやミドルウェア等の選定において定期的に新しい技術を取り入れ、(あるいは取り入れるための検討をして)開発上の要求や組織フェーズに合わせて技術スタックの見直しを図っていくことが必要です。これは開発者にとっても技術的な挑戦を続ける機会になり、モチベーションの維持にも繋がります。

特に、開発対象のモバイルOSが頻繁にアップデートされ、周辺を取り巻く 3rd-party ライブラリのエコシステムの移り変わりも激しい iOS, Android 開発においては、新技術を取り入れていくニーズも相対的に高くなります。
例えば、Luup では今年からネイティブアプリのUI実装において iOS では SwiftUI、Android では Jetpack Compose を導入し、新規に実装する画面を中心に少しずつ置き換えを行っています。
他にも iOS アプリの CI を GitHub Actions から Xcode Cloud に置き換えたり、パッケージマネージャーを Cocoapods から Swift Package Manager に移行したりしています。それぞれアドベントカレンダー内の記事で紹介しているので、是非ご覧ください。

https://zenn.dev/luup/articles/ios-ohtaki-20221213

https://zenn.dev/luup/articles/ios-tarunon-20221219

まとめ

Luup の技術組織においては、これまではとにかくアグレッシブに新規開発していくことをずっと続けてきたのに対し、サービスの初期ローンチから2年が経過した今年は品質の改善や今後の拡大に向けた準備、開発者体験の向上にも注力する余裕ができてきました。
技術的負債の返済も各チームごとバランスをみて少しずつ進めており、チームの安定感も上がってきたと感じているため、このまま「街じゅうを「駅前化」するインフラをつくる」ミッションファーストのカルチャーを失うことなく、技術組織の強みを事業の強みに転換できるような状態を目指して進んでいければと考えています。来年以降の展望や具体的な取り組みは、またどこかの機会で発信できればと思います。

中段でも触れたような気がしますが…、Luup ではエンジニアを現在もほぼ全方位、温度感高く募集しています。
これまでの内容を読んで、今のフェーズの Luup が面白そう、話を聞いてみたいと少しでも思った方がいらっしゃいましたら、お気軽にご連絡ください。
冒頭に掲載した私の Twitter も DM 解放されているので、是非よろしくお願いします。

https://recruit.luup.sc/

来年も、Luup をよろしくお願いします。
Advent Calendar 完走!!

Luup Developers Blog

Discussion