数字で振り返るアセンドプロダクトチームのシリーズAまで
みなさんこんにちは。アセンド株式会社のプロダクトエンジニア増谷です。
アセンドは「物流業界の価値を最大化する」をミッションに掲げる物流系スタートアップです。先日発表させていただいたとおり、おかげさまでこのたび資金を調達し、シリーズAを迎えることができました。
ミッションの実現に向けた道はまだまだ始まったばかり、まさにここからが本番と気を引き締めているところですが、シリーズA到達は一つの区切りとなります。
ここで、アセンドが提供する運送管理SaaS「ロジックス」の開発について、シリーズAに至るまでの道のりを数字で振り返っていきます。
なお、会社全体におけるシリーズAまでの道のりについては、弊社代表の日下が以下のNoteにまとめております。よろしければご覧ください。
開発生産性と開発量
開発生産性(4keys)
アセンドのプロダクトチームでは、開発生産性を測る指標として Google の DevOps Research and Assessment（DORA）が提唱する 4 keys を採用しています。
早速ですが、最新の開発状況に基づく指標は以下のとおりでした。
いずれに指標も高い水準を保っており、 Googleによる State of DevOps(2023)の報告に照らすと、Eliteレベルにあたります。
各指標における算出の方針と背景について補足します。
デプロイ頻度(6.6 deploys/day)
2023年の総デプロイ数を営業日で割って算出しています。なお、ピーク時期のデプロイ数は1日平均12.8回でした。on-demand なリリースを可能とする技術的な仕組みと、適時リリースに積極的な組織文化により、高速デプロイを実現しています。
アセンドでは、SlackとGithubを連携させることでスラッシュコマンド一つでリリース用PRを生成する仕組みを用意しているほか、未リリースのコミットが溜まった際に自動でリリース用のPRが作られる仕組みを構築しています。
変更リードタイム(2.6 hours)
アセンドではトランクベース開発を採用しています。develop ブランチから feature ブランチを切り出し、なるべく小さなバッチで高速に改善を進めていきます。本指標はfeature が develop ブランチへマージされるまでの作業平均時間を算出しています。改善に着手してから数時間オーダーで作業が完了するタイムラインで日々の開発を実行しています。
平均修復時間(42 minutes)
障害を引き起こすコミットがリリースされてから解消されるまでの時間を平均したものです。アセンドでは、Kubernetes上にアプリケーションを展開しており、Argo CD と組み合わせたGitOpsの仕組みを活用しています。不具合を含むコミットがリリースされた後も、数秒でアプリケーションをロールバックすることが可能な体制を構築しており、ダウンタイムの縮減と、開発者の心理的安全性の向上に寄与しています。
変更失敗率(1.8%)
2023年には累計 1,570回の本番リリースを行い、発生した障害は28件でした。これらの比を変更失敗率としています。トランクベース開発によって改修範囲を小さく持ち、一つ一つの変更をチームが許容する認知負荷未満に下げることで品質を保てているものと分析しています。
開発量
開発生産性の高さはお見せしたとおりとなりますが、実際の開発量はどれほどでしょうか。こちらは全期間(2年半)で集計した数値となります。
developブランチへの累積コミット・マージされたPR数はそれぞれ 8,488 commits, 7,608 PRs の結果が出ました。また、通算デプロイ数 2,574 deploys に対し、Four Keys で述べたとおり、2023年に 1,570 回のデプロイを実施していることから、ここ一年でリリース頻度が向上していることが伺えます。
エンジニア一人当たり・1日あたりの平均PRマージ数についても計測してみました。この指標は、開発生産性モニタリング・改善ツール Findy Team+ を提供するFindyさんでも重要な指標として扱われているものです（詳しくは以下の記事をご参照ください）。
さて、アセンドのプロダクトチームの1日あたりの平均PRマージ数はどれほどでしょう。
チームで平均すると実に 3.45 PR/day/person の頻度で開発を推進していることがわかりました。これは上記のFindyさんの記事にある参考数値 3.94 PR/day/person に迫る数値であり、より高い生産性を求めて今後も改善を続けていきたいと思います。
以下、5人のプロダクトエンジニアの動向を解説してみます。
CTO 丹羽 (4.80 PR/day)
CTOを務めつつリードエンジニアロールも受け持ち、価値創出の最前線を走り続ける背中はメンバー全員から尊敬を集めています。コンスタントに高いパフォーマンスを発揮しています。
プロダクトエンジニア 宮津 (2.53 PR/day)
2023年はデータモデルの大幅な見直しを担当していたこともあり、新規開発・改善への寄与は控えめだったかもしれません。8月に見直しが無事に着地し、年間通じて最大のパフォーマンスを発揮していました。
プロダクトエンジニア 松本 (2.33 PR/day)
プロダクトにおいて新たな領域の構想・設計を担当することが多い彼女の場合、1PRあたりのバッチサイズは比較的大きくなる傾向があります。他メンバーと比較して必ずしもPR数は高くないものの、担当領域の改善をフットワーク軽く回し、コンスタントに価値を発揮しています。
プロダクトエンジニア 増谷 (4.93 PR/day)
本年の下期(9月〜)においては、ビジネスチーム側からの要請を受けてクイックで小さい改善や対応に取り組むことが多い状況でした。結果的に波も大きく、チームでは最多のPR数となりました。
プロダクトエンジニア 柗村 (3.06 PR/day)
柗村は比較的新しいメンバーで、副業としてアセンドと関わりを持った後、8月に正式ジョインした経緯があります。ジョイン後1ヶ月でこれほどの生産性を発揮し、成果を創出できていることは特筆できる点かと思います。
機能の開発量
ここまで、開発生産性・開発量における指標を見てきました。ここで、より具体的な機能レベルの開発量を見ていきます。
機能領域別のコンポーネント
「ロジックス」は運送管理業務のDXを支援するオールインワンのプロダクトで、現時点では以下の5つの領域が開発されています。
配車管理：お客様が受注した運送案件の情報を管理し、車両やドライバーの割り当て（配車）を支援する領域
請求・支払管理：実行済みの案件に対し、依頼元への請求と、依頼先業者がある場合の支払いを管理し、請求書や支払明細書の発行まで受け持つ領域
車両管理：所有する車両の情報を車両台帳として集約し、車検・法定点検のスケジュールやかかる費用を原価を管理する領域
労務管理：ドライバーの勤怠状況やシフト管理機能をもち、各種法令が定める労働時間の制限を越えることのないよう管理する領域
データ分析：案件に関するデータを一元的に蓄積し、取引先や車両別など様々な観点でドリルダウン可能な指標をダッシュボードとして提供する領域
各領域における機能の概要と、その機能を支えるDBテーブル数、API数、画面数の分布を調べてみました。
上記の図に表れていないマスター管理領域と合わせると、139のDBテーブル、381のAPI、87の画面を提供していることがわかりました。5人のエンジニアがこれらの領域を受け持っていることから、一人当たり28 のDBテーブルのメンテナンスを受け持っていることになります。
お客様へのお知らせ数
既存機能の改善や新規機能の提供に際しては、お客様向けにお知らせを掲示しています。この頻度を計測してみましょう。
週あたりに 2.2件 のお知らせを掲示していることがわかりました。SaaSプロダクトとして、お客様に日々改善を報告できていることを嬉しく思います。
2023/10 にお知らせ数が多かったのは、上述の大幅なデータモデル変更の結果、機能改善を実行する土台が整い、その恩恵を受けた月だったというのが理由でした。
プロダクト活用状況
最後に、実際にロジックス上で取り扱われているデータの様子を軽く探ってみます。ロジックスのコアデータである案件情報について見てみましょう。
案件数に関しては 38万件 の結果が出ました。プロダクト開発が進み、セールス・マーケ活動が活発化した結果、ありがたいことに多くの引き合い・契約を頂き、伴ってデータ量の伸びが観測されています。
終わりに
一つの節目を迎え、定量的な指標をもとにシリーズAまでの道のりを振り返ってみました。一定の生産性をもとにプロダクトを開発し、プロダクトを通じて社会課題の解決に取り組んでいます。
我々が捉えられている物流の世界は一端でしかありません。「物流業界の価値最大化」を実現すべく、今後もロジックスを中心に価値を提供し続け、業界の変革に寄与していきたいと思います。
最後にはなりますが、アセンドでは一緒に業界変革に挑戦する仲間を大募集中です！生産性高くパフォーマンスを発揮できる環境で開発したい方、プロダクト志向で顧客課題を中心に開発したい方、カジュアル面談からお気軽に是非お話ししましょう。
エンジニア向けエントランスブックはこちら
エンジニア含むすべてのポジションに向けてのエントランスブックはこちら
この記事が気に入ったらサポートをしてみませんか？