New Relicの概要と内製開発を支えるオブザーバビリティ

下鶴：New Relicはオブザーバビリティプラットフォームを提供している会社です。日本国内でもシェア48%と日本シェアナンバーワンをいただいており、おかげさまで600社以上にご採用いただいています。ユーザーの体験からアプリケーションの監視、そしてインフラストラクチャの監視まで、すべてを一気通貫で見ることができるプラットフォームで、サービスの改善を日々行っていただいております。



もともと私自身もNew Relicのユーザーでして、データ移行時のボトルネック解消や本番環境での障害の迅速な原因特定がスピーディーに行えるというところに価値を感じていました。現在はこの価値を日本のIT業界に広めるべく、企業のデジタルトランスフォーメーションをご支援させていただいております。

内製開発を実現される企業や組織の目的は、サービスの利用者にとってより魅力的で、より使いやすいものをスピーディーに提供することかと思います。一方で、外注体制と比べて内製開発は少人数での開発になりがちですし、開発と運用の両方をこなしていかなければならないというところで、大きな壁にぶち当たるケースが多くあります。



本日は、街中を走るタクシーサービスでおなじみのS.RIDE様が、内製開発を行う上でどのような課題に直面し、それをどのように解決していったのかをお話しいただきたいと思います。それでは、S.RIDEの佐々木様、よろしくお願いいたします。

タクシー配車アプリS.RIDEの事業概要

佐々木：S.RIDEの佐々木でございます。弊社での取り組みをご紹介させていただきます。

S.RIDE株式会社は、タクシー事業者向けの配車ソフトウェア開発と、エンドユーザー向けのタクシー配車アプリの開発・運営を行っている会社です。2018年に設立し、翌2019年4月にアプリをローンチしました。ソニーグループとタクシー事業者のジョイントベンチャーであり、なるべくタクシー事業者の声を反映したいということから、タクシー事業者側の株主比率が大きい構成です。オフィスは汐留シティセンターに構えていますが、開発陣は基本的にフルリモートで働いています。



エンドユーザー向けアプリは「すぐ呼べる・確実に乗れる・快適に移動できる」というコンセプトを追求して開発しています。起動後ワンアクション、一回スライドするだけですぐにタクシーを呼べるという簡単操作が特徴です。予約機能やジャパンタクシーの車両指定、ハイヤーの手配なども可能で、快適な移動のための豊富な機能を備えています。

ドライバー向けのアプリも開発しており、見やすさと使いやすさにこだわった設計です。お客様を待たせず確実にお迎えできるようドライバー側のUXも最適化しており、車内に常設されることを想定してタブレットにも対応しています。

サービス提供エリアは東京を中心に千葉、埼玉、神奈川の関東近郊のほか、名古屋や大阪などの主要都市をカバーしています。現在20,000台以上に対応しており、半数以上が東京に集中しています。



2025年もポイント開始やランク制の導入、ハイヤーサービスの開始など様々な開発を進めつつ、営業エリアの拡大も続けてきました。首都圏や政令指定都市を中心に継続的に機能やサービスを追加し、快適な移動体験を提供し続けています。

法人向けからインバウンドまで広がるサービス展開

法人向けサービスのS.RIDE Bizは、法人のタクシー利用の利便性を高めるサービスです。請求書一括払いによる経費精算の手間を省くことができ、管理コンソールからタクシー利用履歴を一元管理できます。2024年5月のサービス開始から約1年半で、申込み社数は2,000社を突破しました。



インバウンド向けの施策としては、訪日外国人が自国のアプリから日本でS.RIDEのタクシーを配車できるS.RIDE Global Roamingを発表しています。S.RIDEを経由することでエコシステム化を実現し、タクシー事業者やドライバーの運用負荷を低減する仕組みです。

また、ソニーグループの強みを活かした移動体験事業も展開しています。ソニー・ミュージックソリューションズと組んだ「都市伝説タクシー」では、立体映像・立体音響・Sound ARの技術を活用したホラー系の移動体験を提供しました。劇場版「鬼滅の刃」無限城編とのコラボでラッピング車両が呼べるサービスなども実施しています。

こうした取り組みは完全自動運転時代を見据えたステップでもあります。創業初期からモビリティデータ取得の実証実験を行い、移動体験事業の開始、モビリティデータ事業の開始と段階的に取り組みを重ねてきました。最終的にはパートナー会社との連携による完全自動運転タクシーの商用化・アプリ配車を目指して事業を展開しています。

内製開発を選んだ理由と外注体制の限界

ここからはプロダクト開発と生まれた課題についてお話しします。今回の話はいわゆる大規模なホストシステムではなく、主にサーバーサイドの基幹である配車システムがメインになります。

2019年4月のローンチに向けて時間がないことがわかっている状況からのスタートでした。エンジニアリソースもかなり少なかったため、外部委託も検討しましたが、質の高いユーザビリティを提供するためには仮説検証に基づいて開発途中でも改善を繰り返す必要があると考え、内製開発をメインに進めることを決めました。

外注開発では、作るものがきっちり決まっていないと進められないという課題がありました。開発ベンダーは品質管理の観点からウォーターフォール方式を採用するケースが多く、要件が固まっていない段階ではかなり時間がかかってしまいます。また、要件定義を漏れなく行うこと自体が難しく、企画から開発PdM、開発PM、開発リーダー、開発エンジニアと5人ほどの人を通過していく過程で、情報量と正確さが段々薄れていってしまう「情報の溝」が生じていました。出来上がったものが思っていたものと違い、修正を繰り返すことになってしまうのです。



内製開発で目指したのは、要件が粗い状態から共に作り上げていくこと、意図や要件を企画側から漏れなくブレなく共有すること、開発と検証を繰り返して品質を徐々に高めていくこと、そして運用を意識した設計を開発途中から行うことでした。

外注体制では企画から開発エンジニアまで5人ほどを通過していた情報の流れを、リーン体制で企画・開発PdM・開発エンジニアという最小限の構成に変え、機動性を確保しながら開発できる体制にすることが、内製開発を採用した理由です。

ローンチ後6年で蓄積した技術負債と運用負荷

内製開発を推進すればすべてがうまく進むかというと、そんなことはありませんでした。定期的なメンテナンスも必要だということがわかったのです。

2019年4月のローンチに向けて、すべてをモダンに一から作り上げる時間は当然ありませんでした。様々な方に協力してもらいつつ、慣れていて開発スピードが速い手法や技術を積極的に採用して、なんとか無事にローンチを成功させました。ローンチ後も競合がいる中でどんどん開発を進める必要があり、データを基にさらなる機能拡張を続けた結果、プロダクトグロース自体は成功し、ユーザー数も配車件数も順調に伸びていきました。

ただ、良いことばかりではありませんでした。プロダクトの成長とともに、古い技術や短期間で無理をして作った部分に技術負債が積み重なり、運用への負担が増大していきました。

プロダクトグロースにはDevOpsをバランスよく回すことが重要ですが、だんだんとOpsにかかる比率が増えていく状況に陥っていたのです。内製開発ですので開発と運用を同じチームが担っていますが、運用にかかる時間がどんどん増大して、開発に割けるリソースが圧迫されていくという悪循環に陥っていました。



具体的な運用課題の一つがアラート調査です。システムが巨大化・複雑化するにつれてアラートの頻度が増え、1件ごとの調査にかかる時間もどんどん長くなっていきました。

ログを検索して中身を調査し、関連するメトリクスを確認して、さらに関連システムのログを調査して、またメトリクスを見る。こうしたログ調査とメトリクス確認のループが6年間の課題として存在していました。調査が長引くほど他の開発タスクが後回しになり、チーム全体のアウトプットに影響を及ぼしていたのです。

もう一つの運用課題がキャパシティ管理です。安定運用のためにはキャパシティの最適化が必要ですが、タクシーサービスの特性として、台風や雪、イベントなどがあると一気に需要が跳ね上がります。

予定されたイベントであればまだ対応できますが、ゲリラ豪雨や電車の人身事故など突発的な事象で急激にアクセスが集中することもあります。オートスケールは導入していますが限界もあり、キャパシティの事前調整や突発対応の手間がどんどん増えていきました。

開発に割ける時間がどんどん減ってしまったため、開発リソースをうまく配分して力強くグロースさせるために、立ち上げ当時の気持ちで新たに運用改善に取り組むことを決めました。

運用改善に向けた3つのリプレース施策

6年間でありがたいことに会社も成長し、人も増えてきました。プロダクトグロースに向けた取り組みに着手できる体制が整ってきたこともあり、適度な運用負荷で安定稼働しつつ、急なスケールにも耐えられる構成にして、DevOpsで快適な開発運用を行えるシステム構成を目指すことにしました。

1つ目はインフラのリプレースです。リリース当時から使っていたEC2をECS on Fargateに切り替えました。CI/CDを効率的に回すためにはEC2よりもECSの方が断然親和性が高いと判断しました。

EC2時代にはチェンジ史を見ながら手動デプロイが必要な部分があり、それが運用の手間になっていましたが、Dockerベースに変えたことでGitHub Actionsを使った自動デプロイが可能になり、デプロイにかかる時間を大幅に削減しています。EC2とECSを並行稼働させつつ、サービスを止めずにシームレスに移行を実施しました。



2つ目はDBのリプレースです。RDSからAuroraへの移行を現在進めています。ユーザー数が増えるにつれて参照系の処理が多くなり、雨が降ったり電車が止まったりすると多数のアプリが一斉に起動してAPIがバーストするという課題がありました。

IOPSなどのキャパシティ枯渇が発生するリスクもあり、これまではRDSのスペックを上げて頑張っていましたが、閑散時間帯にはオーバースペックになってしまいます。Auroraに変えることで横にスケールできる構成にし、最適なスペックでコストも最適化していく方針に切り替えました。



3つ目はマイクロサービス化です。時間がない中で急いで作った結果、モノリシックなアーキテクチャになってしまっていた部分があるため、サービスごとの責務を分けて他のサービスに影響を与えない構成への分割を進めています。

まずは新規開発分から着手しており、既存部分はサービスを止めないよう並行稼働を含めながら徐々に分解していく形で、少し時間をかけてゆっくり進めていく計画です。問題が発生しても被害を最小限に抑えられるよう、マイクロサービスごとに責務を明確に分離していくことを目指しています。

New Relic APM導入による配車システムの可視化

最後にオブザーバビリティサービスの導入です。先ほどお話しした通り、運用負荷の中で最も高かったのが調査タスクであり、そのアプローチとしてNew Relicを導入しました。ファーストステップとして基幹となる配車システムのサーバー群の一部にまず導入し、効果や使い勝手を検証しているところです。

可視化によっていくつか良いことがありました。まず、トランザクションタイムやエラー率、スループットといった情報が一元管理できるようになりました。AWSのサービスだけではうまくキャッチできなかった部分が、APMを入れることによって、どこに一番時間がかかっているか、スループット量がどう変化しているか、エラーの発生率がどうなっているかが画面で確認できるようになったのです。

詳細調査に入る前に当たりをつけられるようになったことで、調査の時間効率にかなり寄与しています。



さらに、トランザクションログもトレースできる形になったことで、ログの一元管理を実現しました。別のマイクロサービスにデータを取りに行ったり書きに行ったりする処理も合わせて一元的にログで取得してくれます。以前のようにあちこちのログを検索して回る必要がなくなり、ログの検索時間が大幅に短縮されました。

ボトルネックについても、たとえばDBで詰まっている、Lambdaの処理で詰まっているといった状況が視覚的にすぐわかるようになりました。ログから特定しなくても、どこに時間がかかっているかをすぐに参照できるため、問題箇所の特定が格段に速くなっています。



こうした取り組みにより、少しずつ開発にかけられる時間が増えてきたという効果が出始めています。

オブザーバビリティの活用拡大と今後の展望

今はまだAPMを導入したところですので、New Relicをまだまだ使いこなせていない部分もありますが、今後も積極的に活用していきたいと考えています。

1つ目は、開発フェーズでのAPM積極活用です。New Relicはデータ量ベースの課金のため、サーバー台数に関係なくコストをコントロールしやすく、開発環境にも導入しやすいという利点があります。開発時にもAPMを使ってエラー調査やパフォーマンスの確認をしながら開発することで、QA前の段階で品質を向上させたいと考えています。開発時にスループットを意識した検証を行うことで、QA自体の効率化にもつなげていけるのではないかと見ています。

2つ目は、APMの範囲にとどまらず、オブザーバビリティ全体の活用を広げていくことです。まずSLI/SLOを整備して会社全体で共通言語化し、運用の属人化を防ぎたいと考えています。現在は私がメインで運用を見ていますが、誰でも同じように運用できる状態を目指しています。New Relicだと機能的にもすぐに整備でき、構築に時間がかからないところはかなり助かっています。

さらに、現在は一部のサーバー群にのみ導入していますが、今後はエンドユーザー向けのフロントエンドアプリやドライバーアプリにも範囲を広げ、プロダクト全体を見える化していく方針です。サーバーに問題が起こる前の予兆を検知して事前に対策を打てるようにすることで、お客様にスムーズで快適な移動体験を提供していきたいと考えています。

目指す姿として、快適で安全な移動体験の提供に向けて全社員が同じ方向を向くことを掲げました。現在オブザーバビリティを活用しているのは開発担当の我々がメインですが、開発だけでなく営業や企画、管理部門も含めた全員が同じデータを見ながら物事を考えられるようにしていきたいと思っています。全社員が同じ目標に向かう大前提として、共通のデータを観測し、共通言語で対話できる環境が不可欠です。



我々のプロダクトに完成はありません。永遠のベータ版として、ユーザー起点で自発的にサービスを開発し続け、顧客価値を高め続けていきたいと思っています。オブザーバビリティ成熟モデルのロードマップでいうと、まだ1番・2番のステップに手がかかったところですが、今後はデータを使ってどんどん物事を考えていくフェーズに進めていければと考えています。

定期的な技術負債の解消が内製開発を力強くする

プロダクトをリリースしていく中では、時間が限られている場合に、モダンで綺麗な開発よりも最速でリリースすることを選択することが非常に重要だと考えています。

ただ、そうすると技術負債がだんだん溜まっていきます。そのままにしておくと開発や運用のスピードが著しく落ちていくということを6年間で痛感しました。内製開発を力強く推進していくためには、定期的な技術負債の解消が必要です。コードリファクタリングはもちろんのこと、運用に対する改善も非常に重要であり、最適な運用を実現するためにオブザーバビリティサービスを積極的に活用していくことが、運用負荷を下げ、開発にリソースを振り向けて品質を向上させていく好循環につながると考えています。



常に改善を繰り返し、可視化による運用の効率化を実現しつつ、開発スピードと品質の向上を目指していきます。S.RIDEは「革新的なモビリティサービスで、心動かす移動体験を創る」をモットーに開発を続けています。皆さんがタクシーを使われるときに、快適な移動体験を提供できるようにしていきたいと思っております。

なお、S.RIDEではエンジニアを募集しておりますので、ご興味のある方はぜひ採用ページをご覧ください。

アーカイブ動画・発表資料

イベント本編は、アーカイブ動画を公開しています。また、当日の発表資料も掲載しています。あわせてご覧ください。

▼動画・資料はこちら
内製開発Summit 2026
※動画の視聴にはFindyへのログインが必要です。