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
pdm_vibe_coding_fail.pdf
Search
hiroaki
August 08, 2025
Technology
200
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
pdm_vibe_coding_fail.pdf
hiroaki
August 08, 2025
More Decks by hiroaki
See All by hiroaki
leadership-that-endures-book-lt
hiroaki_u
0
26
プロダクト負債に立ち向かう
hiroaki_u
2
1.9k
Communication with Ubiquitous Language
hiroaki_u
0
110
how to determine architecture
hiroaki_u
1
280
the-concept-of-product-creation-learned-in-startup-science
hiroaki_u
0
180
what-is-container
hiroaki_u
1
110
difference-between-nginx-and-apache
hiroaki_u
0
87
CI_CD_by_Code_Brothers_by_AWS
hiroaki_u
0
57
think of study
hiroaki_u
1
120
Other Decks in Technology
See All in Technology
インフラ寄りSREでも 開発に踏み出せる〜境界を越えてユーザー体験に向き合いたい〜
sansantech
PRO
2
3.8k
ゼロをイチにする仕事が終わったあと
smasato
0
340
貴方はどのエンジニアリングを磨くのか
hatyibei
0
130
世界、断片、モデル。そして理解
ardbeg1958
1
110
穢れた技術選定について
watany
4
430
DMM.com 購入改善推進チーム におけるCodeRabbitを用いた レビューフロー改善の一例
ysknsid25
2
620
「最後に責任を取るのはチーム」— 人間のPRレビューを最小化してアップデートしたメンタルモデル
jnishime_dresscode
0
600
AI Agent SaaS を支える自社仮想化基盤への挑戦と実運用 / ai-agent-saas-virtualization
flatt_security
2
3.8k
Amazon EVS で VCF 9.0 / 9.1 のサポート開始まとめ
mtoyoda
0
290
シンガポールで登壇してきます
yama3133
0
120
事業価値を⽣み出すSREへ SREが担うべき意思決定の5層
kenta_hi
2
3.6k
SRE Lounge Hiroshimaへの招待
grimoh
0
640
Featured
See All Featured
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
234
17k
Writing Fast Ruby
sferik
630
63k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
27k
Sam Torres - BigQuery for SEOs
techseoconnect
PRO
0
300
The SEO Collaboration Effect
kristinabergwall1
1
500
Intergalactic Javascript Robots from Outer Space
tanoku
273
27k
The Invisible Side of Design
smashingmag
301
52k
How to Get Subject Matter Experts Bought In and Actively Contributing to SEO & PR Initiatives.
livdayseo
0
150
Building a Scalable Design System with Sketch
lauravandoore
463
34k
The AI Revolution Will Not Be Monopolized: How open-source beats economies of scale, even for LLMs
inesmontani
PRO
3
3.6k
The Director’s Chair: Orchestrating AI for Truly Effective Learning
tmiket
1
210
Discover your Explorer Soul
emna__ayadi
2
1.2k
Transcript
package main import "fmt" func VibeCoding(pdm *ProductManager) (Output, error) {
// AI を活用してコードを生成 code := generateCodeWithAI() // 軽いテストで機能確認 if simpleTesting(code) { return deployToProduction(code) } return nil, fmt.Errorf("test failed") } // 生産性は本当に上がるのか? // システム全体への影響は? // エンジニアの役割とは? 2025 年8 月8 日 上田裕耀 PdM がVibe Coding したら 生産性が下がった話
package main import "fmt" func main() { fmt.Println("Hello, I'm a
Server-Side Engineer!") } 自己紹介 PdM@CastingONE キャリアパス 最近の興味 筋トレ 95% サウナ 90% AI 活用 80% 顧客理解 80% 冷食リサーチャー 美味しい餃子とは何か?とか調査してました。 サーバーサイドエンジニア(Go/GCP ) クリーンアーキテクチャとかモジュラーモノリスとか興味あります。 プロダクトマネージャー 1 人PdM 。組織全体で顧客解像度を高められるように日々奮闘しています。
func calculateProductivity(outcome float64, timeSpent float64) float64 { return outcome /
timeSpent } // 生産性は成果を時間で割ったもの // 同じ時間でより大きな成果を出せるか // または同じ成果をより短時間で出せるか 生産性とは? Outcome Time かけた時間に対してどれだけ価値を出せたか? 小さいインプットで大きなアウトカムが出せるかどうか 同じ時間でより大きな成果を出す・同じ成果をより短時間で出す
func HandleProductDevelopment(team, pdm, tasks []Task) []Outcome { // チームは大きなタスクに集中 majorOutcomes
:= team.FocusOn(tasks.Filter(ByPriority("high"))) // PdM は小さいけど価値のあるタスクを実行 minorOutcomes := pdm.VibeCoding(tasks.Filter(ByValueToEffortRatio("high"))) // 全体の成果 return append(majorOutcomes, minorOutcomes...) } なぜPdM がVibe Coding したのか? プロダクト開発 = やりたいことが無限大 重要な機能A 優先度高UI 改善 バグ修正 小さな改善X 軽微な修正Y 内部改善Z 重要な機能B 緊急修正 UX 改善 マイナー改修 新機能C チームの主な取り組み 大きな価値を生む重要な開発に集中 PdM のVibe Coding 素早い改善で価値を素早く提供
func handleIncident(report *IncidentReport) error { // 想定外の動作が報告された if report.Source ==
"customer_support" { incident := investigateIssue(report.Description) if incident.RootCause == "unintended_side_effect" { // 他機能への影響を見落としていた fixUnintendedSideEffect(incident) } } return nil } そして失敗しました 他の機能に対する影響 実装した機能自体は意図通り動作していたが他の機能との連携を考慮できていなかった 関連機能への副作用を事前に予測できず、想定外の動作を引き起こした 顧客に迷惑 マイナスの価値提供 + エンジニアの追加工数 リソース圧迫 結果的に生産性が 大幅に低下 リリース 自分の実装でリリース Vibe Coding で実装 簡易的なテスト PR 機能自体は意図通り動作 1 ヶ月後 CS からの問い合わせ 「◦◦◦ の部分が想定と違う動作をしているようです」 自分の実装で起こしたインシデント
func ensureQuality(code *SourceCode) (Product, error) { if !isAccessible(code) { return
nil, errors.New("accessibility standards not met") } if !isSecure(code) { return nil, errors.New("security requirements not met") } if !isPerformant(code) { return nil, errors.New("performance benchmarks not met") } // 他の品質チェックも同様 ... return buildProduct(code), nil } エンジニアの仕事って複雑 品質を保った上でアウトカムを生み出すために、 エンジニアはあらゆる要素を考慮した複雑な意思決定を行っている 直感性 クリーンコード 自動化 多言語対応 脆弱性検査 メモリ最適化 モジュール化 レビュー UX データ保護 スケーラビリティ 一貫性 品質保証 アクセシビリティ バグ対策 速度最適化 拡張性 CI/CD 使いやすさ セキュリティ パフォーマンス 保守性 テスト 品質
func makeEngineeringDecisions(requirements *ProjectRequirements) *Solution { // 技術的な深い理解が必要 knowledge := acquireTechnicalKnowledge()
experience := reflectOnPastProjects() // トレードオフの意思決定 decision := balanceTradeOffs( requirements.Performance, requirements.Maintainability, requirements.Security, requirements.DeliverySpeed, ) // AI フレンドリーな環境構築 workspace := prepareAIFriendlyEnvironment() workspace.AddStructuredDocumentation() workspace.OrganizeCodeArchitecture() return &Solution{ Quality: knowledge.Combined(experience), TradeOffs: decision, AIReady: workspace.IsReady(), } } AI 時代だからこそ求められる専門性 技術の深い理解 「複雑なシステムの相互作用を把握する力」 学びのサイクル 「過去の失敗と成功から学び続ける姿勢」 トレードオフの意思決定力 「相反する要素の最適なバランスを見極める」 AI フレンドリーな開発体制 「人間とAI の両方が理解しやすい環境が生産性を高める」 構造化ドキュメント 明確なアーキテクチャ 一貫性のあるコード規約 ユビキタス言語
func humanResponsibility(capabilities []Capability) Value { // AI ができるからやるのではなく // 価値提供を高速で行うために使う
var totalValue Value for _, capability := range capabilities { if judgement := evaluateRealValue(capability); judgement.IsValuable() { totalValue += implementWithResponsibility(capability) } } return totalValue } 最後に 「できるからやる」ではなく、 「価値提供を高速で行うために使う」ことが大切 価値提供は(まだ)プロフェッショナルな領域しかできない(と思っている) AI によって多くが自動化される時代だからこそ、 人が担うべき価値に対しては、責任を持ち続ける必要がある
package main import "fmt" func main() { // 発表終了 fmt.Println("
ご清聴ありがとうございました ") // 質問があればお気軽に questions := []string{ "AI との協働について ", "Vibe Coding の可能性 ", " エンジニアの役割 ", } for _, q := range questions { listenAndRespond(q) } } func listenAndRespond(question string) { // 質疑応答の時間 fmt.Printf("Q: %s\n", question) // 回答準備 ... } ご清聴ありがとうございました