「『届けてくれる』にもっと価値を。」のビジョンのもと、配送プラットフォーム「PickGo（ピックゴー）」や物流の現場を支援する新たな DX システム「SmaRyu（スマリュー）」を提供する CBcloud株式会社。配送パートナーの価値が正当に評価される仕組み作りと、配送現場の生産性改善に取り組んでいます。

同社は AWS を用いてシステムのアーキテクチャを構築しています。また、開発・運用体制を改善するための取り組みを継続的に行っていることも特徴です。今回は CBcloud 社の開発組織を支えるエンジニアである、エンジニアマネージャー 徳盛 太一朗 氏とリードエンジニア 新垣 雄志 氏にお話を伺いました。

今回の取材はインタビューをリモートで実施した後、徳盛 氏は CBcloud 社の東京オフィス、新垣 氏は CBcloud 社の沖縄オフィスでそれぞれ写真撮影を行いました。

物流業界に存在する大きな課題

――CBcloud 社の事業概要や提供されているサービスの概要を教えてください。

新垣：CBcloud は物流業界の課題を解決し、テクノロジーの力で配送現場をエンパワーするプロダクトを提供しています。物流業界にはさまざまな課題がありますが、私たちがフォーカスしているのは大きく分けて 2 つです。

1 つ目の課題は多重下請け構造です。物流業界では配送を依頼する荷主が 1 次請けの運送会社に依頼をし、その会社が賄いきれない分が 2 次請け、3 次請け、4 次請け、最終的には末端のフリーランスのドライバーに渡っています。

これにより、荷主側は「いつ誰が荷物を配送するのかわからない」「価格の透明性がない」などの問題が発生します。一方、運送会社やドライバーの側は「いつ仕事が来るのかわからない」「下請けは立場が弱いため安い金額で受注せざるを得ず、依頼を断れない」という問題があります。

もう 1 つの課題は、配送の現場でアナログかつ非効率な業務が行われていることです。たとえば、その日の配送をどのような経路にするかを、ベテランのドライバーが経験と勘を頼りに考え、運用しています。他にも各種書類が手書きであるなど、デジタル化が遅れています。

こういった課題を解決するために、CBcloud では配送プラットフォーム「PickGo」や、物流の現場を支援する新たなDXシステム「SmaRyuトラック」「SmaRyuポスト」の提供を通し、配送パートナーの価値が正当に評価される仕組みづくりと配送現場の生産性改善に取り組んでいます。

「PickGo」は荷物を運んでほしいユーザーと荷物を届けてくれる配送パートナーとを直接つなげる配送プラットフォームです。多様化する荷主の配送ニーズに安定的に応えるとともに、運送会社・ドライバーの付加価値と生産性を高め、適切な対価を支払うことで、双方が win-win となる持続可能な配送プラットフォームを構築します。「SmaRyuトラック」は大型の運送トラックを用いて配送業務を行う運送会社のアナログな業務を効率化する SaaS で、「SmaRyuポスト」は宅配事業者の業務を効率化する SaaS になっています。

「PickGo」を支えるアーキテクチャ

――各プロダクトのアーキテクチャを教えてください。

新垣：まずは「PickGo」から解説させてください。「PickGo」本体は Ruby on Rails で作られた Web アプリケーションであり、AWS Elastic Beanstalk 上にホスティングされています。メインのデータベースは Amazon Aurora を使っており、キャッシュ情報や非同期処理のキューを扱うために Amazon ElastiCache for Redis を用いています。他にも、一部の処理では Amazon DynamoDB にアクセスしています。

Amazon SQS や Amazon SNS なども使用しています。配送依頼への申し込みや案件と配送パートナーとのマッチング、運行開始などが行われたタイミングで「PickGo」本体から Amazon SNS へとメッセージを送信し、Amazon SQS から AWS Lambda を経由して連携先のシステムにリクエストを送ります。

「PickGo」には他にも、「PickGo配送API®」というシステムがあります。これは連携先の企業に配送依頼をしたり、配送のステータス情報を返却したりするための API です。この 「PickGo配送API®」はAmazon API Gateway と AWS Lambda で構築されており、処理実行後は Amazon DynamoDB にデータを書き込んだり、「PickGo」本体のアプリケーションにリクエストを投げたりする構造になっています。

また、「PickGo」だけではなく他のサービスでも共通的に活用しているシステムとして、アプリケーション本体とは別にデータ分析基盤を構築しています。データベースマイグレーションサービスを用いて各種のデータを Amazon S3 に置き、その情報をデータウェアハウスに取り込んで、Metabase によってメトリクスの可視化をしています。

リードエンジニア 新垣 雄志 氏

――「PickGo配送API®」をアプリケーション本体から切り離した意図やその利点を伺いたいです。

新垣：まず、「PickGo配送API®」を作り始めた時期に、「PickGo」本体の開発チームとは別のチームを組成して、並行して開発可能にすることを目指しました。さらに、「PickGo配送API®」では提携先企業とのシステム連携が発生するため、機能開発時にはウォーターフォールに近い重厚な開発プロセスを用いて、かつ長いテスト期間を設ける必要があります。

「PickGo配送API®」と「PickGo」本体とを分離させたことで、前者のシステムで重厚な開発プロセスを用いつつも、後者はアジャイル的な開発スタイルで頻繁に機能を改善できる状態を実現しました。また、「PickGo配送API®」を本体のシステムとは別にしていることで、連携先企業からの「API の IP アドレスを固定してほしい」といったリクエストにも柔軟に対応しやすくなっています。

「SmaRyuポスト」を支えるアーキテクチャ

――次に「SmaRyuトラック」「SmaRyuポスト」についてもお聞きします。

徳盛： 「SmaRyuポスト」も本体の API サーバーは「PickGo」と同様、Ruby on Rails 製のアプリケーションを AWS Elastic Beanstalk 上にホスティングしています。

ただ、「SmaRyuポスト」を利用するにあたっては、宅配事業者側のシステムとのデータ連携が必ず必要になります。事業者毎にその連携仕様やデータ量が違うことがほとんどで、本体の API サーバーに個別に実装するには少し難しさがありました。そこで、事業者別に AWS Lambda を利用した処理層を設置して、改修しやすいようにしています。

一例をあげると、膨大な量のデータをファイルベースでやりとりをしたい事業者向けには、Amazon EventBridge で AWS Lambda を定期的に動かしてそのファイルを取得し、データを専用の Amazon DynamoDB に格納する処理を構築しました。データの件数は非常に膨大かつ処理完了までの時間にも制約がありましたが、AWS Lambda は複数プロセスが並列で起動して処理を行うことができたため、個別仕様を満たすことができました。そうした点からもユースケースに沿ったアーキテクチャになっています。

また、「SmaRyuポスト」には経路を自動作成する機能があるのですが、これを実現するために一部の処理で他社のシステムと連携しています。経路算出のリクエストを出してから完了するまでにある程度の時間がかかるため、この処理は非同期で動かしています。ジョブの管理には Amazon SQS を使っており、定期的に他社システムの処理状況を確認したうえで、完了していなければ Amazon SQS の機能でポーリングを行います。

他にも「SmaRyuポスト」には配送のステータスを確認できる仕組みがあるのですが、その情報をデータ連携元である宅配事業者のシステムに返す必要があります。この処理においては、私たちのシステムで Webhook の API を用意し、ステータス情報を Amazon DynamoDB に蓄積したうえで定期的に TSV ファイルへと変換して、宅配事業者側のファイルサーバーに配置しています。

エンジニアマネージャー 徳盛 太一朗 氏

運用改善の事例 – データベース移行

――ここからは、話題を変更させてください。御社ではこれまで、開発・運用体制を改善するための取り組みを継続的に実施してきたと伺っています。施策をいくつかピックアップしていただき、実施した内容やその成果についてご説明ください。

新垣：まずは、他クラウドの RDB から Amazon Aurora MySQL へとデータベース移行した事例についてご説明します。「PickGo」のシステムを立ち上げた頃、私たちは他のクラウドでサービスを構築しており、バックエンドは Scala で開発していました。ですが、より多くのエンジニアを採用して開発効率を向上させるために、アプリケーションを Ruby on Rails で書き換え、クラウドも AWS に変更する判断をしました。

しかし、アプリケーションサーバーは AWS Elastic Beanstalk に変更したものの、データベースをなかなか移行しきれず他クラウドの RDB を使い続けていました。ある時期に一念発起し、このデータベースを Amazon Aurora MySQL へと移行したという事例になります。

これにより複数の利点がもたらされました。まず、複数種類のクラウドを跨がなくなるため通信のレイテンシーが抑えられ、かつ Amazon Aurora MySQL は通常の MySQL よりも処理性能が良いため、アプリケーションのパフォーマンスが改善しました。

また、MySQL5.6 の InnoDB では空間インデックスが使えませんが、Amazon Aurora MySQL ならば使うことができます。アプリケーション内で、空間インデックスを活用することで実現できる機能があったため、非常に重宝しました。

さらに、Amazon Aurora は簡単にレプリカを増やせます。かつ、カスタムエンドポイントを用いることで「○○のシステムではメインのデータベースを使用し、○○のシステムではレプリカを使用する」などの施策が実現しやすいです。こうした複数の利点が、Amazon Aurora にはあります。

運用改善の事例 – アドホックなリリースからデイリーリリースへ

――他の事例についてもお聞かせください。

新垣：プロダクト開発のサイクルを、アドホックなリリースからウィークリーリリースへ、そしてウィークリーリリースからデイリーリリースへと変化・改善してきました。私が入社した 2 年前くらいの頃は、リリースは 1 週間か 2 週間に 1 度できれば良い方で、かつリリース後に障害が発生して切り戻すことがよくありました。

その原因は、アプリケーションのユニットテストが書かれていないとか、ドキュメントがないためメンバーが仕様をキャッチアップできないなどの点にありました。さらには、QA テストの体制が整っていない、モニタリングができていないといった課題もあり、安全性の低いリリースを続けていました。

そこで、私が他のメンバーを巻き込み、まずはテストコードを書く文化を作りました。新機能を作る場合には必ずテストコードを書き、そのついでに既存の処理にもテストコードを追加するという作業をコツコツと続けていきました。それによって、2 年前ではテストコードがほぼゼロだった状態から、現在（取材時点）ではテストカバレッジが 73％ まで向上し、システム改修の安全度が格段に高くなっています。

さらにドキュメントを書く文化も醸成してきました。機能を追加する際には、その詳細をドキュメントに残し、Pull Request にもドキュメントへのリンクを貼るようにしたのです。加えて、バグ修正や機能追加をする際に調べた内容もドキュメントに残し、メンバーが情報へアクセスしやすくしました。他にも QA チームを発足させたり、New Relic によるモニタリングを導入したりといった改善も行いました。こうした取り組みの結果、現在では 1 日に 3 ～ 4 回のリリースが当たり前になっています。

リードエンジニア 新垣 雄志 氏

物流業界にとっての“インフラ”のようなシステムになりたい

――今後、サービスやアーキテクチャをどのように発展させたいですか。

徳盛：私たちはこれからも物流業界をより良くするためのプラットフォームを提供していきますし、他社とのシステム連携も積極的に行います。それに伴い、私たちのプラットフォームは物流業界にとっての“インフラ”のような存在になりますから、システムを決して止めることなく安定稼働し続ける必要があります。それを実現できるようなアーキテクチャを、常に模索していきたいです。

新垣：今回お話しした通り、私たちは「PickGo」「SmaRyuポスト」「SmaRyuトラック」などのプロダクトを提供しています。そして、それぞれが独立した Ruby on Rails のアプリケーションであるため、似たような機能をすべてのシステムで実装しなければならないケースがあります。これでは無駄な工数が発生しますし、メンテナンスも大変です。

そこで将来的には、各アプリケーションで共通して必要になる処理を切り出して、共通基盤的なシステムを構築したいです。それによって、開発効率やメンテナンス性を向上させたいと考えています。

――どのようなスキルやマインドのエンジニアに参画してほしいですか。

徳盛：新垣さんのような人ですかね。実施する施策を自分で発案して、その目標に向かって一直線に進めるエンジニアは貴重な存在だと思います。

エンジニアマネージャー 徳盛 太一朗 氏

新垣：そう言ってもらえると嬉しいです（笑）。

――新垣さんはいかがですか。

新垣：弊社には「プロダクトを使う現場の人々を、何より大切にする」という価値観があります。荷主や配送パートナーの方々がどのようにシステムを利用しているのかを、営業やカスタマーサポートを経由して把握するだけではなく、エンジニア自身が現場に足を運んで情報収集しています。

自らユーザーのところに行って、直接得た情報をもとに良いプロダクトを作りたいという方は私たちの開発組織にマッチするはずです。また、先ほど「物流業界にとっての“インフラ”になっていく」という言葉がありましたが、それを実現するには高い技術力が必要になります。だからこそ、より良いアーキテクチャを構築したいという技術志向の方にも、ぜひ参画していただきたいです。

――物流業界をより良くする、意義のある仕事ですね。今回はありがとうございました。

導入支援・お見積り・資料請求等に関するご質問、ご相談に日本担当チームがお答えします。平日 10:00〜17:00 はチャットでもお問い合わせいただけます。お問い合わせはこちら