技術的負債の返済は、AI時代の複利で効く投資 — 経営としての意思決定とその遂行

by curekoshimizu

Embed

Start on current slide

Slide 1

Slide 1 text

TECH DEBT / CTO DECISIONS 技術的負債の返済は、 AI時代の複利で効く投資 ~ 経営としての意思決定と、その遂⾏ ~ Recustomer株式会社 CTO 眞鍋秀悟 / @curekoshimizu 1

Slide 2

Slide 2 text

Proﬁle : 眞鍋秀悟 ( X: @curekoshimizu ) 略歴京都大学 / 大学院入試一位合格 Fixstars Executive Engineer Mujin Architect Preferred Networks Engineering Manager Hacobu 研究開発部部長・CTO室室長 [Now] Recustomer (CTO) CTO of the Year 2025, Audience Award 2

Slide 3

Slide 3 text

2年程前 CTO として Recustomer に入社 3

Slide 4

Slide 4 text

入社当時を振り返る 4

Slide 5

Slide 5 text

燃え続けるお金 5

Slide 6

Slide 6 text

午前2時に行われる失敗率50%の祈りのデプロイ 6

Slide 7

Slide 7 text

もちろん現在はこれらの問題は解決済み🎉 8

Slide 8

Slide 8 text

それに加えて現在はというと？ 9

Slide 9

Slide 9 text

キャッシュポイントがたくさんのプロダクトへ 3 → 10 入社時 2年後入社前からあった機能返品・交換キャンセル配送追跡その後 Basicプランお試し購入着払い返送送料予約購入メール従量課金元払い返送送料配送追跡件数請求 10

Slide 10

Slide 10 text

多言語化・多通貨化を終え海外でも使われるプロダクトに！ 11

Slide 11

Slide 11 text

開発生産性の賞を連続受賞 12

Slide 12

Slide 12 text

問題の多い状態むしろ 2年間で大きく変化し開発が得意な会社へ新機能開発が普通にできるレベルの会社少人数でプロダクトをたくさん作れ、エンジニアが売上貢献できる会社へ 13

Slide 13

Slide 13 text

我々Recustomerは 2年間で最低限の技術負債を解消していたのか？ 14

Slide 14

Slide 14 text

実は思ったよりも進んだ改革まで踏み込んでいる 15

Slide 15

Slide 15 text

例えばこのような改革をしました 16

Slide 16

Slide 16 text

モノレポ化 MONOREPO コード設計規約 AIが、コードと設計の広い文脈を読めるように AI 依存先 16

Slide 17

Slide 17 text

マイクロサービス統合統合先DB サービスA AWS サービスC DMS サービスA DMSで移行し、サービス別スキーマで集約サービスB サービスB スキーマを分離 17

Slide 18

Slide 18 text

自社デザインシステム構築デザインライブラリ置き換え自社UIコンポーネント UIライブラリへの依存を見直し、バージョン更新の制約を解消更新容易な構造へ 18

Slide 19

Slide 19 text

フレームワークの変更 Next.js → Vite 配信サーバーのCPUが不要で全ブランチのプレビューが格安に S3 + CloudFront PR 1 PR 2 PR 3 19

Slide 20

Slide 20 text

主要実装言語の変更 (途中) Python → Rust Python Rust AIが書いたコードも厳しく検査。コンパイラ・Linterで実行前に問題を減らす 20

Slide 21

Slide 21 text

厳格なDDDの導入ドメイン：業務ルール・状態遷移どこを変えるか、何を守るか。それを人の頭の中だけに置かず、コードと設計規約化へユースケース：処理の手順 DBアダプター外部APIアダプター 21

Slide 22

Slide 22 text

CQRS/ESによる保証化請求イベントの例請求登録取消締め履歴から再構築履歴から状態を再構築できる基盤へ現在の状態 22

Slide 23

Slide 23 text

どのトピックも重たい内容 24

Slide 24

Slide 24 text

当時の問題を解決するだけならここまでの技術負債解消は、必要なかった。 25 24

Slide 25

Slide 25 text

となると、経営者としてなぜそこまで技術負債に投資をしているの？という疑問が。 26

Slide 26

Slide 26 text

ここからが本題なぜ、売上に加えて負債返済にもリソースを割いているのか？ CTOとしての投資判断と、その遂行。 27

Slide 27

Slide 27 text

なぜなら、結局のところそのほうがコスパがいいから 27

Slide 28

Slide 28 text

これまで「ちゃんとやる」の積み重ねが、組織のスピードに効いてきた自動テスト / TDD / 継続的リファクタリング CI/CD / 継続的デリバリー / 小さな変更コードレビュー / 静的解析 / 型による制約設計の文書化 / IaC / 開発環境の標準化アジャイル / DevOps / … 28 28

Slide 29

Slide 29 text

その「コツコツ」の時代はこれからも続きやっている会社とそうでない会社の差はさらに大きく 29

Slide 30

Slide 30 text

当たり前の複利の原理コーディング速度が上がれば上がる程イテレーションが増えるのでより加速改善次の仕事次の改善コード・設計規約前提として読み込むより速く積み重ねる 30

Slide 31

Slide 31 text

「コツコツ」の差が、 AI時代に広がるその差は、指数関数的に広がる。開発能力の差が広がるイメージ（模式図） 31

Slide 32

Slide 32 text

次の仕事にも効く改善へ。モノレポ AIが広い文脈を読める DDD・設計規約変える場所と守るルールが残る厳格な言語 AIのコードを実行前に厳しく検査 32

Slide 33

Slide 33 text

人が決め、AIに並行して任せる。これが同時に進む時代だからこそ投資を。推奨する経営に。製品開発負債返済売上につながる進捗開発を速くする進捗 33

Slide 34

Slide 34 text

技術負債の解消はボトムアップにボランティアのような改革や気がついた人だけが進めることなのだろうか？ 34

Slide 35

Slide 35 text

一部のチームだけがすごく改革をしても別のところと差が生まれ AIが悩む非対称性が生まれる 35

Slide 36

Slide 36 text

対称性。 36

Slide 37

Slide 37 text

対称性。それは 37

Slide 38

Slide 38 text

万物を動かすあまりにも自然な物理法則 38

Slide 39

Slide 39 text

対称性はAIにとっても自明に自然なこと 39

Slide 40

Slide 40 text

対称性を得るべく技術負債の解消はリーダーや経営者が将来の投資としてさらに AI によって大きな効果となってくる投資としてみなすとき 40

Slide 41

Slide 41 text

だからRecustomerは、この2年でここまで踏み込んだ。

Slide 42

Slide 42 text

だからRecustomerは、この2年でここまで踏み込んだ。

Slide 43

Slide 43 text

今日の売上と、明日の開発能力に投資する。技術的負債の返済は、 AI時代の複利で効く投資。以上です。 43