プロダクト思考 × 基盤思考を AIで実現する Compound Engineering

2026/09/05(土)の登壇資料です。
https://product-engineering.jp/2026/

Transcript

1. プロダクト思考 × 基盤思考を AIで実現する Compound Engineering 2026年09⽉05⽇ Product Engineering Conference 2026 1
3. About Me Buzz | Takeshi Watanabe @buzz_tkc Company 株式会社エウレカ Role Senior Backend Engineer Hobbies トライアスロン, スノボ, サッカー 3
4. AIの使用で開発は 速くなっていますか？ 未来の開発を速くする投資 は できていますか？ 4
5. 今届けるべき価値と 未来への投資を同時にやる そんな話をしたいと思います 5
6. Agenda １ 複利が生まれる基盤とは ２ ⼩さくても改善を積み上げる ３ 積み重ねる改善を選ぶ ４ 改善をAIで加速させる ５ 改善をチームや組織全体に広げる ６ まとめ 6
7. 複利が生まれる基盤とは 7
8. Compound Engineering とは compound interest ＝ 複利。増えた分が次に増える⼒になります。 複利 ITの⽂脈で置き換えると 単利 Compound Engineeringは 今の開発を、次の開発を 加速させる資産に変えること 価値 開発回数 8
9. プロダクト思考 × 基盤思考 単利と複利のグラフ、この差を生むのが『今の開発を、次の開発を加速させる資 産に変える 』という発想です。ではその資産をどう作るのか。エンジニアの思考を 2つに分けて考えてみます。 プロダクト思考 基盤思考 問い 誰に、何の価値を、どのように 届けるか 次の開発をどう速くするか 対象 ユーザー理解、ニーズ、体験 コード、テスト、ルール、CI、Docs 範囲 今回のリリース 次回以降の開発 9
10. 投資が価値を生み、価値が余力を生み、 余力が次の投資を生む 基盤に投資 ＝ 未来への投資 顧客へ価値を 速く届けられる 余力を基盤投資と 顧客価値提供に回す ＝ 今の価値提供 時間が浮く 余力が生まれる 10
11. 小さくても改善を積み上げる 11 11
12. 小さく始めて積み上げる 基盤への投資は、数週間かかる大仕事だけではありません。数時間で終わるも のから全サービスに効くものまで、粒度には幅があります。小さくても効果がある ということがポイントです。 粒度 基盤の例 作成コスト 効果範囲 小 ドキュメントを更新 数時間 単一レポジトリ 中 テスト基盤の改善 数日 単一レポジトリ 大 共通レポジトリの整備 数週間 全サービス 12
13. 小：ドキュメントを更新 コーディング規約を更新する 誰でもできるドキュメントの更新作業ですが、こういった小さな改善も大きな効 果を生みます。 • ⼈に聞いたり、聞かれた⼈が答える時間が減る • 知識の属⼈化を防げる 13
14. 中：テスト基盤の改善 ペアーズの Global展開が本格的に始まる前にテスト基盤の改善を実施 前提として、ペアーズでは1つのコードベースで多国展開をしています。 課題として、以下の表のような同じ機能でも国ごとに振る舞いを変えたい場面が 増え、それを手元で確認することが困難でした。 国 期待値 󰏦日本󰏦 機能Aを公開⭕ 󰑐台湾󰑐 機能Aを非公開❎ 󰏮韓国󰏮 機能Aを非公開❎ 14
15. 中：テスト基盤の改善 ペアーズの Global展開が本格的に始まる前にテスト基盤の改善を実施 展開国ごとに期待する振る舞いを定義できるローカルテスト基盤を整備。 以降、多国展開するコストを大幅にカットできる状態へ。 使用可能⭕ 󰏦日本󰏦 使用不可❎ 󰑐台湾󰑐 使用不可❎ 󰏮韓国󰏮 15
16. 大：共通リポジトリの整備 共通する Goの汎用処理を共通リポジトリで管理する 前提として、ペアーズのBackendはGo言語で書かれています。 課題として、マイクロサービスで複数のレポジトリで同じような実装を0から書くこ とに課題を感じていました。 サービスA サービスB サービスC Observability Observability Observability Infra layer Infra layer Infra layer etc etc etc 16
17. 大：共通リポジトリの整備 共通する Goの汎用処理を共通リポジトリで管理する 共通の汎用的な実装は共通のレポジトリにまとめ、1箇所を直せば全サービスに 反映できる基盤を構築しました。 サービスA サービスB サービスC 共通レポジトリ(Observability, Infra layer) 17
18. 積み重ねる改善を選ぶ 25 18
19. AIが木こりのジレンマを壊した これまで（⽊こりのジレンマ） いま（AI時代） 1. 技術負債がネックで価値提 供が遅れる。 2. 技術負債の解消には機能開 発を⽌める必要がある。 3. 納期優先で技術負債解消が 後回しにされる。 AIが作る‧直すコストを下げたた め、技術負債を解消しながら、 機能開発も同時に進められる。 19
20. 積み重ねる改善を選ぶ • 繰り返す・・・同じ課題に２回以上ぶつかる • 静かに間違える・・・前提知識がないと気づかず間違える • すぐ直せる・・・リリースを遅らせない範囲で直せる 辺りが目の前の開発をこなしつつ、改善を行う１つの目安になる。 20
21. 見つけた瞬間が一番安い ボーイスカウトルール：自分がいまさわろうとしているコードを、触る前より少 しだけ良い状態にして残す これまで AI時代 • 来たときより少し良くする • 改善コストが⾼いと後回し になりやすい • その場で直すのが1番安い 場⾯が増えた • ⾒つけた瞬間に直す 21
22. 改善をAIで加速させる 25 22
23. AIを迷わずに⾛らせる AIは作るのは速いが、簡単に意図せず動く。 目的地に向けて迷わず走る基盤を整備する。 【ハーネス】 AIを走らせる基盤全体 【道】 AIが走る場所を規約で固定 【ガードレール】 逸脱を機械で⾃動で弾く 【装備】 ⼿順と道具を渡す 23
24. ハーネスの中⾝：道‧ガードレール‧装備 要素 役割 具体例 道 AIが走る場所を規約で固定 • • 規約 AGENTS.md ガードレール 逸脱を機械で⾃動で弾く • • テスト・型・lint CI・Hooks 装備 ⼿順と道具を渡す • • • Skill（手順書） MCP（ツール接続） 検証ループ 上記のAIを走らせる基盤全体をまとめて「ハーネス」 と呼ぶ。 ハーネスを一度整えれば、以降の改善はAIが速く正確にこなす。改善を積み 重ねるほど、開発速度は加速していく。 24
25. 改善をチームや組織全体に広げる 30 25
26. 個人は足し算、チームは掛け算 改善を一人で行うだけでなく、チーム全員でできる状態にします。 個⼈の改善 • 本⼈だけが速くなる • 属⼈的な知識が増える チームの改善 • ⾃分だけでなく、他のメン バーにも効く • 改善が次の改善を速くする 26
27. 「やる人だけがやる改善」から脱却する 改善をやる気がある人だけで行わず、チーム全員でできる仕組みを作る。 書いている途中 ⼿を⽌めた瞬間 実装をマージしたあと 保存したら、 レビューが⾛る 指摘が、 直っている 触った層を検出してレビュー ルールになる format と検査が⾛る が走る 採⽤されたレビューから docs‧rules‧lint の 改善PRが⽴つ 27
28. 投資が価値を生み、価値が余力を生み、 余力が次の投資を生む 基盤に投資 ＝ 未来への投資 顧客へ価値を 速く届けられる 余力を基盤投資と 顧客価値提供に回す ＝ 今の価値提供 時間が浮く 余力が生まれる 28
29. まとめ 30 29
30. まとめ 1. プロダクト思考×基盤思考を組み合わせて開発をする 顧客に価値を提供しながらも、未来の開発へ投資する 2. ⾒つけた瞬間が⼀番安く直せる時代 レビュー指摘やプロンプトが上⼿くいかなかった時にその場で直し、改善を積み重ねる 3. チームや組織全体で回す仕組み整備しよう ⼈のやる気に左右されない仕組みを整備し、改善をチームや組織全体で回す 30
31. ⽬の前の価値提供 未来への投資 プロダクト思考 基盤思考 両⽅同時に回していこう 31
32. We’re hiring! Career Site 32