事業フェーズの変化に対応する 開発生産性向上のゼロイチ

Transcript

1. 2024/09/11 成⻑フェーズスタートアップでの開発⽣産性向上の取組み 株式会社tacoms CTO 井上将⽃ 事業フェーズの変化に対応する 開発⽣産性向上のゼロイチ
2. 井上将⽃ ⼤学在学中からスタートアップに興味 複数社でビジネス&エンジニアインターン ⼤学4年の春にtacomsへ⼀⼈⽬エンジニアで参画しCTO 野球/スターウォーズ/お笑いが好き☺ @masa1934yg ⾃⼰紹介
3. tacomsについて ⼤学⽣向けデリバリーサービスの開発→失敗 学⽣起業‧シードラウンド資⾦調達 プレシリーズA資⾦調達調達 シリーズA資⾦調達 Camel正式リリース デリバリー注⽂⼀元管理サービス β版リリース 2019年 2020年 2021年 2022年 2023年 創業者の3名がForbes 30 Under 30 Asiaに選出 すごいベンチャー100に選出
4. 会社概要 飲⾷業界向けSaaS 「Camel シリーズ」の提供 ⾃社店舗/ブランドオリジナルの テイクアウトデリバリーサイト ⽴ち上げ 受け渡し⽇時指定〜商品選択〜 決済‧購⼊まで対応 複数デリバリーサービスの 受注⼀元化 店舗営業状況などのサイト側 反映 POSや本部システムとの連携 BtoB プロダクト BtoC プロダクト
5. 全国8000店舗以上の飲⾷店で導⼊ 🎉 実際のお客様マップ！！
6. 今⽇お伝えしたいこと スタートアップにおいて開発⽣産性が 課題になったタイミングの事例 ⽣産性を改善するプロジェクトの ゼロイチについて
7. 事業成⻑に伴う開発⽣産性の課題 ⽬次 ⽣産性指標を可視化し改善の運⽤を始める まとめ‧今後へ向けて
8. 事業成⻑に伴う開発⽣産性の課題
9. Uberや出前館など複数サービスを ⼀元管理するためデータ量が多い 飲⾷店向けということもあり 24時間365⽇稼働が求められるシステム デリバリーという特性上から リアルタイム性が重要 外部連携に依存してる機能が多く 不確実性⾼い フードデリバリー各社 前提‧tacomsが向き合う事業特性
10. 2023年7⽉時点 2チーム 計7名 SREチーム 2024年7⽉時点 3チーム計15名 昨年⽐ 2倍 事業成⻑〜組織規模の拡⼤〜 Camel Order チーム Camel チーム SREチーム Camel チーム
11. 2023年7⽉時点 デプロイ回数 4〜7 / weekly 減少😭 事業成⻑に伴いデプロイ頻度が低下 2024年7⽉時点 デプロイ回数 2〜3 / weekly
12. 2023年7⽉時点 デプロイ回数 4〜6 / weekly 減少😭 事業成⻑に伴いデプロイ頻度が低下 2024年7⽉時点 デプロイ回数 2〜3 / weekly WHY！？
13. リリースの負担が増えデプロイ頻度が減少傾向に ‧事業成⻑に伴い⼤⼿企業のクライアントも増加しリリース作業失敗時の影響範囲も拡⼤ ‧リリース作業失敗時の影響範囲が拡⼤するにつれてリリース作業前の確認フローが増加 ‧E2Eテストは⼿動で⾏っているためメンバーの⼯数が圧迫 ‧結果としてリリース頻度が減少傾向に リリース作業 失敗時の 影響範囲 リリース プロセス時間 QA/CI/CD..etc リリース頻度 が減少傾向に リリース担当 エンジニアの 作業⼯数
14. リリースの負担が増えデプロイ頻度が減少傾向に ‧事業成⻑に伴い⼤⼿企業のクライアントも増加しリリース作業失敗時の影響範囲も拡⼤ ‧リリース作業失敗時の影響範囲が拡⼤するにつれてリリース作業前の確認フローが増加 ‧E2Eテストは⼿動で⾏っているためメンバーの⼯数が圧迫 ‧結果としてリリース頻度が減少傾向に リリース作業 失敗時の 影響範囲 リリース プロセス時間 QA/CI/CD..etc リリース頻度 が減少傾向に リリース担当 エンジニアの 作業⼯数 このままだと事業成⻑とデプロイ頻度が反⽐例に 事業規模が⼩さかった時のアジリティを取り戻し 最速で顧客価値を届けたい
15. ⽣産性指標を可視化し改善の運⽤を始める
16. 改善へ踏み出す前にまず⽬的を明確にする 確実に‧効率良く‧⾼速に 顧客価値を届け続ける 開発チームであるため ⽣産性向上 の ⽬的 ‧経営管理‧評価制度‧エンジニアチームのオンボーディングなど様々な⽤途は考えられるが、 マネジメントにおいて活⽤することはスコープに含めない ‧開発⽣産性を改善する⽬的はあくまで顧客価値を最速で届けるチームになるためと定義する
17. 課題理解を深めるために指標を可視化する ‧SPACEなどメトリクスの種類は様々あるがまずは愚直にFourKeysを採⽤ ‧変更失敗率と変更復旧時間については課題感がないため⼀旦やらない⽅針 スループット指標の2つをスコープに 変更時の 障害率 デプロイ 失敗時の 復旧まで の時間 デプロイ 頻度 変更の リードタ イム
18. 変更のリードタイムは内訳をきちんと可視化する ファーストコミットからデプロイまでのプロセスを細分化 どのプロセス時間がボトルネックなのかを明確にする
19. ダッシュボードを作って現状の指標を可視化する ⽣産性可視化ツールについてはOSSや有料 ツールなど様々な⼿段がある 「チームのプロセスを変更したくなかった」 「ローコストで始めたかった」 という2つの理由からツールを⾃作 Github APIを活⽤しPullRequestや ReviewCommentのデータを取得しGoogle スプレッドシートへ出⼒。出⼒されたデータ を元にLockerStudioで可視化。 ※ 時間の関係上ツールの詳細は割愛します 󰢛
20. 現状と理想のギャップを確認する 理想 48〜60 / h デプロイ頻度 現状 1〜3 / daily 理想状態についてはFourKeysの指標を参照しつつ、DORAのレポートで定義されているパ フォーマンス レベルの話はあえてしていない。（Eliteクラスターになることが⽬的になること を避けるため） 24 / h 変更の リードタイム 2 / weekly
21. 開発⽣産性に取り組む背景‧⽅向性をチームに⽰す ‧現状の組織においてどのような課題があるのか、なぜ開発⽣産性に取り組むべきなのか ‧現状と理想にどのようなギャップがあるのかを⾔語化してチームに⽰す
22. 有志メンバーでWG発⾜ WGオーナー CTO EM WGメンバー 有志 有志 SRE SRE ‧開発⽣産性を改善していくにはチームメンバーの理解や取り組みへの協⼒が不可⽋ ‧ボトムアップで進めるためにもアプリケーションチームのメンバーから有志メンバーを募る ‧有志メンバーに加えWGのタスクに関わる可能性があるSREチームのメンバーは適宜参加
23. WGのマイルストーンを定めてプロジェクトを推進する ‧WGのゴールとして期⽇や⽬標指標を定める ‧⽬標指標を達成するためにQごとにマイルストーンを定めてタスクロードマップを作成 ‧タスクロードマップはアプリケーション開発‧QA‧SREの3チームにおいて作成していく ‧Qごとの⽬標から⽉間⽬標を策定。隔週でMTGしてプロジェクト推進
24. まとめ 事業フェーズの変化に伴いデプロイ頻度が落ちて きたら“⻩⾊信号” と捉え課題を探索する ⽣産性を改善する⽬的を明確化し 現状と理想のギャップを⽰した上でチームが⾃律的 に改善出来る仕組みを作る
25. おわりに 〜今後へ向けて〜 改善の運⽤を始められたものの、まだまだプロジェクトは始まったばかりでこれから改善が 動き出すところです！ 飲⾷業界向けプロダクトであり求められる信頼性が⾼い業界だからこそ、今後事業成⻑して いく中でもスピードが落ちないような開発組織にしていきたいと考えています。 こんな挑戦をしているtacomsに少しでもご興味持ってくれた⽅は是⾮カジュアルにお話しし ましょう👏 QAエンジニア含めた エンジニア各ポジション 絶賛募集中です👏👏👏 採⽤HP テックブログ https://zenn.dev/p/tacoms https://tacoms-inc.com/#block-cddb 337d21b847408a45f9ee69b14077