AI時代を コンピュータ・アーキテクチャ視点で 取り組み 開発生産性をあげた話

2025.12.10 CTO+VPoE話さナイト @Findy 登壇資料

Transcript

1. AI時代を コンピュータ・アーキテクチャ視点で 取り組み 開発生産性をあげた話 CTO+VPoE話さナイト @Findy Recustomer, Inc. Shugo Manabe
2. Profile : 眞鍋 秀悟 ( X: @curekoshimizu ) 略歴 • 京都大学 / 大学院 ◦ 入試一位合格 ◦ 数学系 (高精度計算論) • Fixstars ◦ Executive Engineer • Mujin ◦ Architect • Preferred Networks ◦ Engineering Mananger • Hacobu ◦ 研究開発部部長・CTO室室長 • [Now] Recustomer ◦ CTO 2
3. 昨年 CTO として Recustomer に入社 3
4. 入社当時の状況
5. 燃え続けるお金 5
6. 午前2時に行われる 失敗率50%の 祈りのデプロイ 6
7. たっ大変だー
8. 安心してください
9. これら問題は 既に解決済みです
10. これら問題の解決が 2024 年の成果
11. 11 ピッチ登壇
12. さて2025年は どんな年？ 12
13. 開発生産性 という結果が出た 年であった 13
14. そもそも Recustomerは どんな規模の会社 なのか？
15. 15 シリーズA 調達直後 エンジニア数 7人 (ちょうど1年前)
16. どんな 組織になったのか？
17. 17 開発生産性の賞を2年連続受賞 元々は採用力が 全然なかった会社 採用を妥協 することなく エンジニア組織 11名に増えました
18. 18 開発生産性の賞を2年連続受賞
19. 1年前はエンジニアに 刺さるメッセージ (武器) がなかった 19
20. 20 着任当時 1回 / 1週間 着任3ヶ月 2回 / 1日 次の1年 5回 / 1日 x25 開発生産性メトリクス : デプロイ頻度
21. 開発生産性という メトリクスが わかりやすく伸びて 体外的に アピールしやすくなった 21
22. 開発生産性を 高めるために 頑張った？ 22
23. そうではなく 副次的な効果として 開発生産性の 結果が出た 23
24. 何をやったから 開発生産性が 高まったのか？ (今日の本題)
25. 1. 生成AI普及
26. 1. 生成AI普及 どこの会社でもやっている ことなので 少し厳しい目線のお話
27. 27 AI により 一部の工程を 0%→95% の 達成率が 速くなった
28. しかし 95%から100%にする 工程の難しさは 解決していない 28
29. これは DeepLearning時代の 何でもNNによる 苦しみの圧倒的既視感 29
30. AIに任せるのが適した 問題と そうでない問題の 判断の見極め力が 求められる時代 30 DeepLearning時代と 大体同じ課題だけど よりいっそう境界が難しい
31. また、AI待ちという アイドル時間が 発生する 31
32. 生成AIの並列化による アイドル時間を 別の業務に割り当て 仕事の高速化 をする必要がある 32
33. 33 パイプライン処理的に 一部の仕事が回り始めた
34. 34 アジャイル開発 というのは 予期しない「待ち」や「変化」 が起こりやすい 開発スタイルだと思っている
35. 35 それって パイプラインハザードでは？
36. 36 そもそも スクラムで管理している タスクは 複雑な小タスクの 積み上げである CISCっぽさ があり ハザードのペナル ティも大きい
37. 37 パイプラインハザードを Out of order 実行を 考慮した 開発計画案が 求められるようになった そんなに並列に 効く仕事ばかり なのだろうか問題 + マネージメント負荷の増大
38. 別の見方をすると？ 38
39. 39 Web開発のスクラム開発 って 協力という エンジニア間の Sync処理が多い
40. 40 GPU計算はとんでもなく 速いのに GPUとCPU間のメモリー転送に 時間がかかるのと既視感
41. AI 駆動開発によって • ある工程がとても高速になった • 個人の仕事スピードを活かし、 全体最適化 を行うには 「タスクの粒度」・「協力による SYNC」 をどうするかとても大事であり、ここを速くすることが 全体最適化 としては大事だと思っている 41 コンピュータ アーキテクチャっぽい
42. そこで取り組んだこと 42
43. そこで取り組んだこと 43 DevOps ドメイン駆動化
44. 2. DevOpsを きちんとまわす文化
45. 45 Dev組織とOps組織 を分割すると 組織としての 「SYNC」イベント が多くなりがち SYNCイベントが 全体最適化効率を 下げている
46. 46 弊社は QAエンジニアを 雇わず エンジニアが 一気通貫でここを 進める組織化も行った SYNC コストを 下げる施策
47. 開発者が Opsを経験する ことにより 47
48. 汚い設計や 乱雑なコードは 後でチームを苦しませる という体験 48
49. Opsの時間を 楽にするための 開発コードも整備された Opsにかかる時間が減った 49
50. そして デプロイ頻度が 圧倒的に高まった 50
51. 51 着任当時 1回 / 1週間 着任3ヶ月 2回 / 1日 次の1年 5回 / 1日 x25 開発生産性メトリクス : デプロイ頻度
52. それはなぜ？ 52
53. 今回のデプロイで 影響のある箇所は 〇〇と一目瞭然になった 53
54. 色々なものが まざると 検証コストが高くなり どんどん デプロイされる文化に 54
55. 結果 デプロイ頻度が とても高まった 55
56. 3. ドメイン駆動開発 を真面目に取り組む
57. 「UIを軸にDBの設計 をしてはいけないよ」 「DBだけは本質だか ら全員でレビュー会」 … 57
58. DDDにより、 仕事をする上で やらなくては いけないこと の「常識」の確立 58
59. 集約やリポジトリなど Web開発として共通の 意味のあるタスクに 落としてくれて、 ハザードが起こりづらい単位にな りAIが効きやすい側面が生まれた 59
60. 副次的に 粒度もAIレビュー フレンドリーになり PRの単位も わかりやすくなっていった 60
61. そうした取り組みが 結果的に
62. 62 開発生産性の賞を2年連続受賞
63. また、 人柄を大事にした採用により 「協力」という「SYNC」イベントを 軽量なLOCKに変えた 63
64. 仲良く・挑戦的な 人材が揃ったからこそ 64
65. 65 全エンジニア数 = 9人ながら
66. 現在は アドカレ2025 2本を この組織規模で 走ってます！ 66
67. 67 アドカレ2025 Zenn の トレンドに2本
68. こうして Recustomerは 開発生産性をあげた そんな2025でした