Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
カミナシでの技術的負債返済プロジェクトとその決断 / Beyond tech debts at...
Search
Tori Hara
PRO
September 01, 2022
Technology
47
20k
カミナシでの技術的負債返済プロジェクトとその決断 / Beyond tech debts at Kaminashi
Talked at 「スタートアップと技術的負債」 #SELECKLIVE
https://yumemi.connpass.com/event/255925/
Tori Hara
PRO
September 01, 2022
Tweet
Share
More Decks by Tori Hara
See All by Tori Hara
アプリケーション開発者は Amazon ECS あるいは Kubernetes をどこまで知るべきか #AWSDevDay / You build it, you run it
toricls
PRO
55
19k
永続複数ブランチ運用は『単一のコードベース』と言えるのか / What are your justifications for the multi-branches?
toricls
PRO
17
6k
緩やかに死んでいくシステム / You won't be in the team forever
toricls
PRO
23
14k
技術的負債とステークホルダと説明責任と / The Debt
toricls
PRO
76
35k
Securing your Amazon ECS applications: Best practices
toricls
PRO
0
770
第2回 AWS Fargate かんたんデプロイ選手権 #AWSDevDay / The Easiest Deployment Championship 2020 - Find your winner for AWS Fargate!
toricls
PRO
18
22k
独りよがりのプラットフォーム / For Whom that Platform Runs
toricls
PRO
98
33k
Containers + EC2 Spot: 特性と実装パターンに学ぶ低コスト & 高可用アーキテクチャ / Practical Guide for Amazon EC2 Spot with Containers
toricls
PRO
13
5.2k
違いから見る Kubernetes #k8sjp / See Kubernetes through an Amazon ECS Lens
toricls
PRO
10
4.1k
Other Decks in Technology
See All in Technology
総会員数1,500万人のレストランWeb予約サービスにおけるRustの活用
kymmt90
3
2.8k
.NET のUnified AI Building Blocks 入門...!
okazuki
0
170
My Generation 年配者がこの先生きのこるには (Developers CAREER Boost 2024 Edition)/My Generation How elder engineers can survive
kwappa
3
110
Reliability Engineering at Studist
katsuhisa91
PRO
0
110
【CNDW2024】SIerで200人クラウドネイティブのファンを増やした話
yuta1979
1
330
Empowering Customer Decisions with Elasticsearch: From Search to Answer Generation
hinatades
PRO
0
280
高品質と高スピードを両立させるソフトウェアQA/Software QA that Supports Agility and Quality
goyoki
8
1.2k
[GDG DevFest Bangkok 2024] - The Future of Retail E-commerce with Gemini AI
punsiriboo
0
290
開発者向けツールを魔改造してセキュリティ診断ツールを作っている話 - 第1回 セキュリティ若手の会 LT
pizzacat83
0
340
ゆるSRE勉強会 #8 組織的にSREが始まる中で意識したこと
abnoumaru
2
990
マルチプロダクト、マルチデータ基盤での Looker活用事例 〜BQじゃなくてもLookerはいいぞ〜
gappy50
0
130
システムリプレイスプロジェクト発足から7年、改めてコスト最適化に向き合う / replace and cost optimization
takumi
1
440
Featured
See All Featured
Building Your Own Lightsaber
phodgson
103
6.1k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
330
21k
Measuring & Analyzing Core Web Vitals
bluesmoon
4
150
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
9.1k
How to Ace a Technical Interview
jacobian
276
23k
4 Signs Your Business is Dying
shpigford
181
21k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
29
2k
Building an army of robots
kneath
302
43k
The Cost Of JavaScript in 2023
addyosmani
45
6.9k
Raft: Consensus for Rubyists
vanstee
136
6.7k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
356
29k
Designing Experiences People Love
moore
138
23k
Transcript
Twitter.com/Toricls カミナシでの 技術的負債返済プロジェクトと その決断 Tori Sep. 1, 2022 めぇ (で、具体的に何をやっているのか)
twitter.com/toricls Tori Hara / CTO at Kaminashi ❤ Come build
with us! ❤ toricls • Meety - https://meety.net/matches/wlbIxlejLKXn • ࠾༻ใ - https://careers.kaminashi.jp/
Twitter.com/Toricls Agenda ▶︎ カミナシという会社 ▶︎ そもそも「技術的負債」とはなんだったか ▶︎ カミナシの技術的負債返済プロジェクト ▶︎ まとめ
twitter.com/toricls カミナシ
Twitter.com/Toricls
Twitter.com/Toricls 現場 DX プラットフォーム『カミナシ』 https://note.com/toricls/n/nf3d205c1777c https://kaminashi.jp/
twitter.com/toricls そもそも「技術的負債」とはなんだったか
Twitter.com/Toricls 「技術的負債」とはなにか?の共通認識 https://speakerdeck.com/toricls/the-debt
Twitter.com/Toricls 「技術的負債」とはなにか?の共通認識 https://speakerdeck.com/toricls/the-debt
Twitter.com/Toricls 「技術的負債」とはなにか?の共通認識 - まとめ 1 ▶︎ 主にエンジニアリングの⽣産性を低下させ、システムの継続的改善を前提としたビジネスモデルを リスクに晒している技術的要因 ▶︎ ⼈間、技術、ビジネス環境、ビジネスそのもの、すべてが時間の経過とともに変化する
▶︎ その変化の結果と最適の差分が技術的負債 ▶︎ 継続的改善前提でシステムを作る限り、優秀な⼈材を集めても(程度の差はあれど)必ず技術的負債は発⽣する ▶︎ なぜならシステムの周りが変化していくから ▶︎ ドメイン知識やスキル、市場理解が不⾜したままプロダクトや機能を作る必要性 ▶︎ 逆説的だが、だからこそ「継続的改善」が前提になる
Twitter.com/Toricls 「技術的負債」とはなにか?の共通認識 - まとめ 2 ▶︎ 技術的負債を⽣み出しているのはエンジニアリングだけではない ▶︎ 技術的負債は、不確実性をシステム側に押し付けた結果でもある ▶︎
ビジネスモデルそのもの、プロダクトのバリュープロポジション、⼀つ⼀つの機能要件、仕様… ▶︎ いたるところに不確実性が潜んでいる / SWE ⼭⽥さん(仮名)「最初から分かってたら?そりゃこうは作らないですよ〜」 ▶︎ 不確実性を他で飲み込めないとき、実⾏フェーズにあるエンジニアリングが未来の⾃分たちから「技術的 借⾦」をしてビジネスを前に進めている ▶︎ 顧客に価値を届けることに真剣なエンジニアリングであればあるほど、こうなりがち ▶︎ 当時は借⾦でビジネスを加速できたが、その利息が複利で今の⽣産性に悪影響を与えている ▶︎ 「技術的負債」は⼿抜きの結果ではない ▶︎ (そもそも過去時点でのドメイン知識不⾜やスキル不⾜を⼿抜きと評するのはあまりフェアではないですよね?)
Twitter.com/Toricls なぜ技術的負債を返済するのか https://speakerdeck.com/toricls/the-debt
Twitter.com/Toricls カミナシの技術的負債返済プロジェクトの話に進む前に… 技術的負債は(本来は)通常の開発プロセスの中で 継続的に返済し続けなければならない プロジェクト化が必要になってしまうような タイミングまで放置すること⾃体が誤り
twitter.com/toricls 技術的負債返済プロジェクト の
Twitter.com/Toricls カミナシの技術的負債返済プロジェクト - タイムライン Jun Aug Sep May Apr 検討開始
2022.04 下旬 負債返済プロジェクト 第1弾 2022.05.23 - 2022.06.30 負債返済プロジェクト 第2弾 2022.07.01 - 2022.12.31 経営意思決定・全社説明 2022.05 中旬 Oct Nov Jul 👆 イマココ 何を意思決定したの? 何を説明したの? 具体的な中⾝は? 具体的なn(ry 何を検討したの? この辺は何を?
Twitter.com/Toricls カミナシの技術的負債返済プロジェクト - 検討開始 ▶︎ SWE ⼭⽥さん(仮名)「コードを触るのが怖い😱」 ▶︎ 僕のカミナシ⼊社(4⽉)よりも前に EM
と会話した時点で技術的負債っぽい話は出ていた ▶︎ 当時は「データベースやばい」「モノリスが(ry」のようなフワッとした課題認識だった (実際にはもうちょっと具体的) ▶︎ 技術的負債と認識しているものをアクションに繋げられる粒度でチームメンバーにリスト化してもらった ▶︎ 各アイテムを放置した際の技術・ビジネス両⾯での想定リスクや返済で期待される効果について⾔語化 ▶︎ 返済によって New Hire 戦⼒化までの期間短縮に貢献するかもざっくりと5段階評価で書いてもらった ▶︎ リストの中の「退職リスク度」というユニークなカラムが⾯⽩かった (⾯⽩かった) ▶︎ 各アイテムのヤバさや⼼の⾟さ、対応コストなど複合的な要素をもとにまずはざっくり優先順位を決めた ▶︎ リストをもとに4⽉末から技術的負債の返済プランを検討開始 ▶︎ 何を、どういう順番で、どう⽚付けていくか ▶︎ 優先順位だけではなく、アイテム間には当然依存関係が ▶︎ 通常業務と並⾏して⽚付けられるか? ≒ プロジェクト化の必要があるか? ≒ 機能開発を⽌める必要があるか? ▶︎ 5⽉下旬から6⽉末までの5週間、機能開発を⽌めてビジネスロジックを触らないリファクタリングを⼀気に⾏うことで決定 (僕の中で) ▶︎ 経営、投資家、社内のステークホルダにどう説明するか? Apr 検討開始 2022.04 下旬
Twitter.com/Toricls カミナシの技術的負債返済プロジェクト - 経営意思決定 ▶︎ 「過去数ヶ⽉間で純粋な機能開発に使った時間」というファクトをもとに説明 ▶︎ エンジニアリングのほとんどの時間が顧客問合せに基づく調査や不具合修正などの対応に使われていたという事実 ▶︎ 「ここのところ⼤きな新機能出せてないね」という認識は当然経営メンバーも持っていた
▶︎ メンバーへの開発プロセスについてのヒアリング結果やシステム状況を根拠として「中⻑期的な視点での要件定義や設計 という観点が⾜りていない」「よりサステナブルなシステムとエンジニアリング組織にならなくてはいけない」というイ ンプットを経営の中で継続的に⾏っていたことも効果的だったのかもしれない ▶︎ 6⽉末までの5週間、機能開発と不具合修正をすべて⽌めて、負債返済プロジェクトにリソースを充てることで経営で合意 ▶︎ 顧客業務を⽌めてしまうクリティカルな不具合の修正と、障害発⽣時の対応は例外 ▶︎ システムやエンジニアリングは苦しかったが、ビジネスそのものはちゃんと伸びてきていたことが CEO/COO/CTO の三者で 合意・意思決定できた最⼤の理由かもしれない ▶︎ 他にも残キャッシュや次の調達を⾒据えた話など、いろんな要素が複合的に(いい感じに)絡み合って意思決定まで持って いけた ▶︎ ラッキー✌ May 経営意思決定 2022.05 中旬 検討開始 2022.04 下旬
Twitter.com/Toricls カミナシの技術的負債返済プロジェクト - 全社向けの説明 May 検討開始 経営意思決定 全社説明 2022.04 下旬
2022.05 中旬 ▶︎ 全社集会で概要、必要性、返済後の未来について説明したスライドから⼀部抜粋 (権利関係と社内都合で残念ながら⼀部モザイクをかけています) ▶︎ いきなり全社向けに説明したわけではなく、特に影響が⼤きい Customer Success チームには事前に説明を実施 ▶︎ 想定される影響についての説明や、どうしてもお客様との関係性の都合から対応してほしい改修が⽣まれたときにどうするか の例外的プロセスについての定義などなど ▶︎ PM や CS といった距離の近いステークホルダが理解を⽰してくれたことも、意思決定できた⼤きな理由の⼀つ
Twitter.com/Toricls 経営意思決定 全社説明 カミナシの技術的負債返済プロジェクト - 負債返済 PRJ 第1弾 ▶︎ やること
▶︎ アプリケーション(フロントエンド & バックエンド)コードの必要以上の複雑さを取り除き、負債返済 PRJ 第2弾以降でよりディープな技術的負債の返済に取り組むためのリファクタリング ▶︎ やらないこと ▶︎ ビジネスロジックは今は触らない ▶︎ インフラも今は触らない ▶︎ システム運⽤も今は特に変えない ▶︎ 結果、いくつかの⼩さな例外を除き、機能開発や不具合修正を完全に⽌めて負債返済にフォーカスできた ▶︎ コード全体の認知負荷が⼀定程度下がり、触るのがちょっと怖くなくなった ▶︎ New Hire のオンボーディングコストも下がりそう ▶︎ エンジニアリングメンバーの精神衛⽣がよろしくなった ▶︎ (フロントエンド側の負債はより重みがあることもクリアになった) 負債返済プロジェクト 第1弾 2022.05.23 - 2022.06.30 2022.05 中旬
Twitter.com/Toricls 負債返済プロジェクト 第1弾 カミナシの技術的負債返済プロジェクト - 負債返済 PRJ 第2弾(イマココ) ▶︎ 第1弾との違い
▶︎ 機能開発のような通常業務と並⾏して負債返済を実施する ▶︎ 通常業務(機能開発、不具合修正、問い合わせ対応、システム運⽤など)と、負債返済(incl. 運⽤改善)の時間の⽐率は 5:5 というルール ▶︎ 事前に定めた「優先度の⾼い重要な技術的負債群」が⽚付き次第、通常業務の時間を増やしていく(というルール) ▶︎ 第2弾期間のエンジニアリング組織としてのゴール ▶︎ 『中⻑期的な価値を犠牲にせずに業務の6割の時間を純粋な機能開発に充てられるチームへ』 ▶︎ 7⽉からやってきた(やっている)こと ▶︎ アプリケーション側 ▶︎ フロントエンド側はビジネスロジックまで含めた(重厚な)リファクタリングを実施中 ▶︎ バックエンド側では機能・⾮機能要件の想定不⾜を補う負債返済に取り組み中。パフォーマンスイシューとかも。 ▶︎ 駆動していない OpenAPI を駆動させたい ▶︎ 9⽉以降新たに着⼿すること ▶︎ インフラや運⽤やあれやこれや ▶︎ AWS 上のインフラやそのデリバリプロセスを整え、加えて「運⽤」を適切に定義して信頼性が⾼い運⽤モデルを⽬指す ▶︎ これに着⼿するために、AWS アクセス権限を適切に従業員に渡す仕組みは整備済み (AWS SSO, Control Tower, Organizations … ) 負債返済プロジェクト 第2弾 2022.07.01 - 2022.12.31 - 2022.06.30
twitter.com/toricls まとめ
Twitter.com/Toricls 本⽇のまとめ ▶︎ 技術的負債は継続的改善を前提としたシステムでは時間の経過とともに必ず⽣まれる ▶︎ 当時は全⼒を尽くしたが、時間の経過とともに最適ではなくなってしまったものが技術的負債 ▶︎ SWE ⼭⽥さん(仮名)「最初から分かってたら?そりゃこうは作らないですよ〜」 ▶︎
⼿抜きの結果ではない ▶︎ ビジネスやプロダクトマネジメントのフェーズで存在した不確実性を、実⾏フェーズであるエンジニアリングでカバーした 結果でもある ▶︎ ステークホルダ全員が真剣に向き合い、⾃分ごと化して取り組むことが必須。エンジニアリングだけの話にしない。 ▶︎ だからこそ、技術的負債も機能開発などと同じリストのバックログアイテムとして管理し、その着⼿の優先順位をフェアに 決めなければならない ▶︎ アクション可能なレベルで技術的負債の詳細と対応案をバックログアイテムに落とし込み、放置による影響や、対応で期待される 効果、そして可能な限りその測定⽅法を⾔語化し切ることが、エンジニアリングの責任として⾮常に重要 👋