Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
事業フェーズの変化に対応する 開発生産性向上のゼロイチ
Search
Masato Inoue
September 06, 2024
Programming
0
490
事業フェーズの変化に対応する 開発生産性向上のゼロイチ
Masato Inoue
September 06, 2024
Tweet
Share
More Decks by Masato Inoue
See All by Masato Inoue
GoでTCPサーバーの GracefulShutdownをシンプルにやる
masaygggg
0
63
CTOとしてどのように役割を変えてきたか / 4年間を振り返ってみた
masaygggg
0
4k
Startup CTO of The Year 2023 株式会社tacoms井上将斗
masaygggg
0
130
Other Decks in Programming
See All in Programming
Webの外へ飛び出せ NativePHPが切り拓くPHPの未来
takuyakatsusa
2
430
Cursor AI Agentと伴走する アプリケーションの高速リプレイス
daisuketakeda
1
130
「ElixirでIoT!!」のこれまでとこれから
takasehideki
0
370
WebViewの現在地 - SwiftUI時代のWebKit - / The Current State Of WebView
marcy731
0
100
PHP 8.4の新機能「プロパティフック」から学ぶオブジェクト指向設計とリスコフの置換原則
kentaroutakeda
2
650
ニーリーにおけるプロダクトエンジニア
nealle
0
570
AIプログラマーDevinは PHPerの夢を見るか?
shinyasaita
1
170
設計やレビューに悩んでいるPHPerに贈る、クリーンなオブジェクト設計の指針たち
panda_program
6
1.6k
AWS CDKの推しポイント 〜CloudFormationと比較してみた〜
akihisaikeda
3
320
C++20 射影変換
faithandbrave
0
540
#kanrk08 / 公開版 PicoRubyとマイコンでの自作トレーニング計測装置を用いたワークアウトの理想と現実
bash0c7
1
540
今ならAmazon ECSのサービス間通信をどう選ぶか / Selection of ECS Interservice Communication 2025
tkikuc
20
3.7k
Featured
See All Featured
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.7k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
4 Signs Your Business is Dying
shpigford
184
22k
Side Projects
sachag
455
42k
Rails Girls Zürich Keynote
gr2m
94
14k
Mobile First: as difficult as doing things right
swwweet
223
9.7k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
45
7.5k
Java REST API Framework Comparison - PWX 2021
mraible
31
8.6k
How STYLIGHT went responsive
nonsquared
100
5.6k
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
32
2.3k
The Cult of Friendly URLs
andyhume
79
6.5k
Transcript
2024/09/11 成⻑フェーズスタートアップでの開発⽣産性向上の取組み 株式会社tacoms CTO 井上将⽃ 事業フェーズの変化に対応する 開発⽣産性向上のゼロイチ
井上将⽃ ⼤学在学中からスタートアップに興味 複数社でビジネス&エンジニアインターン ⼤学4年の春にtacomsへ⼀⼈⽬エンジニアで参画しCTO 野球/スターウォーズ/お笑いが好き☺ @masa1934yg ⾃⼰紹介
tacomsについて ⼤学⽣向けデリバリーサービスの開発→失敗 学⽣起業‧シードラウンド資⾦調達 プレシリーズA資⾦調達調達 シリーズA資⾦調達 Camel正式リリース デリバリー注⽂⼀元管理サービス β版リリース 2019年 2020年
2021年 2022年 2023年 創業者の3名がForbes 30 Under 30 Asiaに選出 すごいベンチャー100に選出
会社概要 飲⾷業界向けSaaS 「Camel シリーズ」の提供 ⾃社店舗/ブランドオリジナルの テイクアウトデリバリーサイト ⽴ち上げ 受け渡し⽇時指定〜商品選択〜 決済‧購⼊まで対応 複数デリバリーサービスの
受注⼀元化 店舗営業状況などのサイト側 反映 POSや本部システムとの連携 BtoB プロダクト BtoC プロダクト
全国8000店舗以上の飲⾷店で導⼊ 🎉 実際のお客様マップ!!
今⽇お伝えしたいこと スタートアップにおいて開発⽣産性が 課題になったタイミングの事例 ⽣産性を改善するプロジェクトの ゼロイチについて
事業成⻑に伴う開発⽣産性の課題 ⽬次 ⽣産性指標を可視化し改善の運⽤を始める まとめ‧今後へ向けて
事業成⻑に伴う開発⽣産性の課題
Uberや出前館など複数サービスを ⼀元管理するためデータ量が多い 飲⾷店向けということもあり 24時間365⽇稼働が求められるシステム デリバリーという特性上から リアルタイム性が重要 外部連携に依存してる機能が多く 不確実性⾼い フードデリバリー各社 前提‧tacomsが向き合う事業特性
2023年7⽉時点 2チーム 計7名 SREチーム 2024年7⽉時点 3チーム計15名 昨年⽐ 2倍 事業成⻑〜組織規模の拡⼤〜 Camel
Order チーム Camel チーム SREチーム Camel チーム
2023年7⽉時点 デプロイ回数 4〜7 / weekly 減少😭 事業成⻑に伴いデプロイ頻度が低下 2024年7⽉時点 デプロイ回数 2〜3
/ weekly
2023年7⽉時点 デプロイ回数 4〜6 / weekly 減少😭 事業成⻑に伴いデプロイ頻度が低下 2024年7⽉時点 デプロイ回数 2〜3
/ weekly WHY!?
リリースの負担が増えデプロイ頻度が減少傾向に ‧事業成⻑に伴い⼤⼿企業のクライアントも増加しリリース作業失敗時の影響範囲も拡⼤ ‧リリース作業失敗時の影響範囲が拡⼤するにつれてリリース作業前の確認フローが増加 ‧E2Eテストは⼿動で⾏っているためメンバーの⼯数が圧迫 ‧結果としてリリース頻度が減少傾向に リリース作業 失敗時の 影響範囲 リリース プロセス時間
QA/CI/CD..etc リリース頻度 が減少傾向に リリース担当 エンジニアの 作業⼯数
リリースの負担が増えデプロイ頻度が減少傾向に ‧事業成⻑に伴い⼤⼿企業のクライアントも増加しリリース作業失敗時の影響範囲も拡⼤ ‧リリース作業失敗時の影響範囲が拡⼤するにつれてリリース作業前の確認フローが増加 ‧E2Eテストは⼿動で⾏っているためメンバーの⼯数が圧迫 ‧結果としてリリース頻度が減少傾向に リリース作業 失敗時の 影響範囲 リリース プロセス時間
QA/CI/CD..etc リリース頻度 が減少傾向に リリース担当 エンジニアの 作業⼯数 このままだと事業成⻑とデプロイ頻度が反⽐例に 事業規模が⼩さかった時のアジリティを取り戻し 最速で顧客価値を届けたい
⽣産性指標を可視化し改善の運⽤を始める
改善へ踏み出す前にまず⽬的を明確にする 確実に‧効率良く‧⾼速に 顧客価値を届け続ける 開発チームであるため ⽣産性向上 の ⽬的 ‧経営管理‧評価制度‧エンジニアチームのオンボーディングなど様々な⽤途は考えられるが、 マネジメントにおいて活⽤することはスコープに含めない ‧開発⽣産性を改善する⽬的はあくまで顧客価値を最速で届けるチームになるためと定義する
課題理解を深めるために指標を可視化する ‧SPACEなどメトリクスの種類は様々あるがまずは愚直にFourKeysを採⽤ ‧変更失敗率と変更復旧時間については課題感がないため⼀旦やらない⽅針 スループット指標の2つをスコープに 変更時の 障害率 デプロイ 失敗時の 復旧まで の時間
デプロイ 頻度 変更の リードタ イム
変更のリードタイムは内訳をきちんと可視化する ファーストコミットからデプロイまでのプロセスを細分化 どのプロセス時間がボトルネックなのかを明確にする
ダッシュボードを作って現状の指標を可視化する ⽣産性可視化ツールについてはOSSや有料 ツールなど様々な⼿段がある 「チームのプロセスを変更したくなかった」 「ローコストで始めたかった」 という2つの理由からツールを⾃作 Github APIを活⽤しPullRequestや ReviewCommentのデータを取得しGoogle スプレッドシートへ出⼒。出⼒されたデータ
を元にLockerStudioで可視化。 ※ 時間の関係上ツールの詳細は割愛します
現状と理想のギャップを確認する 理想 48〜60 / h デプロイ頻度 現状 1〜3 / daily
理想状態についてはFourKeysの指標を参照しつつ、DORAのレポートで定義されているパ フォーマンス レベルの話はあえてしていない。(Eliteクラスターになることが⽬的になること を避けるため) 24 / h 変更の リードタイム 2 / weekly
開発⽣産性に取り組む背景‧⽅向性をチームに⽰す ‧現状の組織においてどのような課題があるのか、なぜ開発⽣産性に取り組むべきなのか ‧現状と理想にどのようなギャップがあるのかを⾔語化してチームに⽰す
有志メンバーでWG発⾜ WGオーナー CTO EM WGメンバー 有志 有志 SRE SRE ‧開発⽣産性を改善していくにはチームメンバーの理解や取り組みへの協⼒が不可⽋
‧ボトムアップで進めるためにもアプリケーションチームのメンバーから有志メンバーを募る ‧有志メンバーに加えWGのタスクに関わる可能性があるSREチームのメンバーは適宜参加
WGのマイルストーンを定めてプロジェクトを推進する ‧WGのゴールとして期⽇や⽬標指標を定める ‧⽬標指標を達成するためにQごとにマイルストーンを定めてタスクロードマップを作成 ‧タスクロードマップはアプリケーション開発‧QA‧SREの3チームにおいて作成していく ‧Qごとの⽬標から⽉間⽬標を策定。隔週でMTGしてプロジェクト推進
まとめ 事業フェーズの変化に伴いデプロイ頻度が落ちて きたら“⻩⾊信号” と捉え課題を探索する ⽣産性を改善する⽬的を明確化し 現状と理想のギャップを⽰した上でチームが⾃律的 に改善出来る仕組みを作る
おわりに 〜今後へ向けて〜 改善の運⽤を始められたものの、まだまだプロジェクトは始まったばかりでこれから改善が 動き出すところです! 飲⾷業界向けプロダクトであり求められる信頼性が⾼い業界だからこそ、今後事業成⻑して いく中でもスピードが落ちないような開発組織にしていきたいと考えています。 こんな挑戦をしているtacomsに少しでもご興味持ってくれた⽅は是⾮カジュアルにお話しし ましょう👏 QAエンジニア含めた エンジニア各ポジション 絶賛募集中です👏👏👏
採⽤HP テックブログ https://zenn.dev/p/tacoms https://tacoms-inc.com/#block-cddb 337d21b847408a45f9ee69b14077