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
280
事業フェーズの変化に対応する 開発生産性向上のゼロイチ
Masato Inoue
September 06, 2024
Tweet
Share
More Decks by Masato Inoue
See All by Masato Inoue
GoでTCPサーバーの GracefulShutdownをシンプルにやる
masaygggg
0
50
CTOとしてどのように役割を変えてきたか / 4年間を振り返ってみた
masaygggg
0
3.6k
Startup CTO of The Year 2023 株式会社tacoms井上将斗
masaygggg
0
27
Other Decks in Programming
See All in Programming
Micro Frontends for Java Microservices - dev2next 2024
mraible
PRO
0
210
PHPを書く理由、PHPを書いていて良い理由 / Reasons to write PHP and why it is good to write PHP
seike460
PRO
5
470
GitHub Copilot Workspace で我々のアプリ開発がどう変わるのか?
shuyakinjo
0
950
Memory API: Patterns, Use Cases, and Performance
josepaumard
1
170
データマイグレーションの成功戦略~サービスリニューアルで失敗しないための実践ガイド~
tkzwtks
8
720
CSC509 Lecture 02
javiergs
PRO
0
160
もう実家に手頃な情シス娘は不要!Bedrockでもう一人の娘を作る
komakichi
0
110
Competitionsだけじゃない! Kaggle Notebooks Grandmasterのすすめ
corochann
2
480
[PHPカンファレンス沖縄2024]「無理なくできるだけ安全に」テストもないレガシーコードをリファクタリングするテクニック
ikezoemakoto
3
130
Progressive Web Apps for Rails developers
siaw23
2
550
クラウドサービスの 利用コストを削減する技術 - 円安の真南風を感じて -
pyama86
3
400
ビット演算の話 / Let's play with bit operations
kaityo256
PRO
4
180
Featured
See All Featured
Designing for humans not robots
tammielis
249
25k
Fantastic passwords and where to find them - at NoRuKo
philnash
50
2.8k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
26
4.1k
Into the Great Unknown - MozCon
thekraken
31
1.4k
Clear Off the Table
cherdarchuk
91
320k
Gamification - CAS2011
davidbonilla
80
5k
Optimizing for Happiness
mojombo
375
69k
Writing Fast Ruby
sferik
626
60k
Embracing the Ebb and Flow
colly
84
4.4k
WebSockets: Embracing the real-time Web
robhawkes
59
7.3k
Building a Scalable Design System with Sketch
lauravandoore
459
33k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
1
290
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