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
カミナシでの技術的負債返済プロジェクトとその決断 / Beyond tech debts at...
Search
Tori Hara
PRO
September 01, 2022
Technology
47
24k
カミナシでの技術的負債返済プロジェクトとその決断 / 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
56
19k
永続複数ブランチ運用は『単一のコードベース』と言えるのか / What are your justifications for the multi-branches?
toricls
PRO
17
6.3k
緩やかに死んでいくシステム / You won't be in the team forever
toricls
PRO
23
15k
技術的負債とステークホルダと説明責任と / The Debt
toricls
PRO
76
36k
Securing your Amazon ECS applications: Best practices
toricls
PRO
0
890
第2回 AWS Fargate かんたんデプロイ選手権 #AWSDevDay / The Easiest Deployment Championship 2020 - Find your winner for AWS Fargate!
toricls
PRO
18
23k
独りよがりのプラットフォーム / For Whom that Platform Runs
toricls
PRO
99
35k
Containers + EC2 Spot: 特性と実装パターンに学ぶ低コスト & 高可用アーキテクチャ / Practical Guide for Amazon EC2 Spot with Containers
toricls
PRO
13
5.3k
違いから見る Kubernetes #k8sjp / See Kubernetes through an Amazon ECS Lens
toricls
PRO
10
4.2k
Other Decks in Technology
See All in Technology
【CEDEC2025】『ウマ娘 プリティーダービー』における映像制作のさらなる高品質化へ!~ 豊富な素材出力と制作フローの改善を実現するツールについて~
cygames
PRO
0
130
2025-07-31: GitHub Copilot Agent mode at Vibe Coding Cafe (15min)
chomado
2
300
P2P ではじめる WebRTC のつまづきどころ
tnoho
1
290
経理出身PdMがAIプロダクト開発を_ハンズオンで学んだ話.pdf
shunsukenarita
1
280
Perlアプリケーションで トレースを実装するまでの 工夫と苦労話
masayoshi
1
320
【CEDEC2025】現場を理解して実現!ゲーム開発を効率化するWebサービスの開発と、利用促進のための継続的な改善
cygames
PRO
0
610
完璧を目指さない小さく始める信頼性向上
kakehashi
PRO
0
130
製造業の課題解決に向けた機械学習の活用と、製造業特化LLM開発への挑戦
knt44kw
0
130
With Devin -AIの自律とメンバーの自立
kotanin0
2
990
【CEDEC2025】LLMを活用したゲーム開発支援と、生成AIの利活用を進める組織的な取り組み
cygames
PRO
1
2.1k
AWS re:Inforce 2025 re:Cap Update Pickup & AWS Control Tower の運用における考慮ポイント
htan
1
100
増え続ける脆弱性に立ち向かう: 事前対策と優先度づけによる 持続可能な脆弱性管理 / Confronting the Rise of Vulnerabilities: Sustainable Management Through Proactive Measures and Prioritization
nttcom
1
230
Featured
See All Featured
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.9k
A better future with KSS
kneath
238
17k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
Become a Pro
speakerdeck
PRO
29
5.5k
RailsConf 2023
tenderlove
30
1.2k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
860
StorybookのUI Testing Handbookを読んだ
zakiyama
30
5.9k
Automating Front-end Workflow
addyosmani
1370
200k
A designer walks into a library…
pauljervisheath
207
24k
Done Done
chrislema
185
16k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
How to Ace a Technical Interview
jacobian
278
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 ⼭⽥さん(仮名)「最初から分かってたら?そりゃこうは作らないですよ〜」 ▶︎
⼿抜きの結果ではない ▶︎ ビジネスやプロダクトマネジメントのフェーズで存在した不確実性を、実⾏フェーズであるエンジニアリングでカバーした 結果でもある ▶︎ ステークホルダ全員が真剣に向き合い、⾃分ごと化して取り組むことが必須。エンジニアリングだけの話にしない。 ▶︎ だからこそ、技術的負債も機能開発などと同じリストのバックログアイテムとして管理し、その着⼿の優先順位をフェアに 決めなければならない ▶︎ アクション可能なレベルで技術的負債の詳細と対応案をバックログアイテムに落とし込み、放置による影響や、対応で期待される 効果、そして可能な限りその測定⽅法を⾔語化し切ることが、エンジニアリングの責任として⾮常に重要 👋