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
AI時代のYAGNI:「爆速で無駄になった機能」からの学び / 20260720 Naoki ...
Search
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
SHIFT EVOLVE
PRO
July 17, 2026
Technology
10
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
AI時代のYAGNI:「爆速で無駄になった機能」からの学び / 20260720 Naoki Takahashi
2026/7/20 PHP Conference Japan 2026
https://phpcon.php.gr.jp/
株式会社SHIFT
製造ソリューションサービス部
髙橋 直規
SHIFT EVOLVE
PRO
July 17, 2026
More Decks by SHIFT EVOLVE
See All by SHIFT EVOLVE
AWS DevOps AgentでCDKメンテナンスは楽になるのか ~検証から見えた最適解~ / 20260718 Masaki Okuda
shift_evolve
PRO
0
2
AIが変えるDevSecOps―開発速度とセキュリティの両立へ / 20260714 Mitsutoshi Matsuo
shift_evolve
PRO
1
52
生成AI活用によるODC欠陥分析の分類高速化の実践と導入効果 / 20260703 Suguru Ishii
shift_evolve
PRO
2
130
次世代ランサムウェア対策の考察 / 20260704 Mitsutoshi Matsuo
shift_evolve
PRO
5
1.8k
40代で“やっとエンジニアになれた”――閉じた学びを開き、空の青さを知る / 20260628 Naoki Takahashi
shift_evolve
PRO
4
2.5k
フロントエンドイチゲキ実装 ― Figmaデザインと画面設計書からAIに実装・テストを書かせるための”下ごしらえ” / 20260627 Yusuke Mazuka
shift_evolve
PRO
0
170
高速な品質フィードバックを実現するAIテスト設計エージェント構築の要点 / 20260529 Suguru Ishii
shift_evolve
PRO
0
81
SREの仕事は「壊さないこと」ではなくなった 〜自律化していくシステムに、責任と判断を与えるという価値〜 / 20260515 Naoki Shimada
shift_evolve
PRO
1
310
ボトムアップの改善の火を灯し続けろ!〜支援現場で学んだ、消えないための3つの打ち手〜 / 20260509 Kazuki Mori
shift_evolve
PRO
2
1.2k
Other Decks in Technology
See All in Technology
kintone の AI コワーカーを、 Anthropic にエージェントを"ホストさせて"作った話 #devkinmeetup
sugimomoto
0
100
世界、断片、モデル。そして理解
ardbeg1958
1
110
人を動かすのは時間ではなく、納得感 〜新任EMが入社3ヶ月、組織を2回変えた話〜
kakehashi
PRO
3
220
貴方はどのエンジニアリングを磨くのか
hatyibei
0
120
ボーイスカウトルールでメモリやスキルを改善しよう
azukiazusa1
1
680
Empower GenAI with Agile - あなたのアジャイルが生成AIのバフになる仕組み
hageyahhoo
1
170
AICoEでAIネイティブ組織への進化
yukiogawa
0
160
しぶいSRE: サーバから見えない障害にどう向き合うか。ラストワンマイルのデバッグ実践 / Shibui SRE
kanny
13
6k
Road to SRE NEXTの今までとこれから
hiroyaonoe
0
310
Claude Codeとハーネスについて考えてみる
oikon48
18
9.3k
実装だけじゃない! CCA-F取得エンジニアが教えるClaude Code開発プロセス活用術
diggymo
2
640
Oracle Exadata Database Service on Cloud@Customer X11M (ExaDB-C@C) サービス概要
oracle4engineer
PRO
2
8.4k
Featured
See All Featured
WENDY [Excerpt]
tessaabrams
11
38k
Intergalactic Javascript Robots from Outer Space
tanoku
273
27k
Lightning talk: Run Django tests with GitHub Actions
sabderemane
0
220
Why Mistakes Are the Best Teachers: Turning Failure into a Pathway for Growth
auna
0
180
We Are The Robots
honzajavorek
0
270
SEO for Brand Visibility & Recognition
aleyda
0
4.6k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.8k
Data-driven link building: lessons from a $708K investment (BrightonSEO talk)
szymonslowik
1
1.2k
How People are Using Generative and Agentic AI to Supercharge Their Products, Projects, Services and Value Streams Today
helenjbeal
1
230
Fashionably flexible responsive web design (full day workshop)
malarkey
408
67k
How to build a perfect <img>
jonoalderson
1
5.8k
Technical Leadership for Architectural Decision Making
baasie
3
440
Transcript
髙橋直規 株式会社SHIFT Copyright SHIFT Inc, All Rights Reserved. 2026.7.20 PHP
Conference Japan 2026 #phpcon AI時代のYAGNI: 「爆速で無駄になった機能」からの学び
本日お話すること https://fortee.jp/phpcon-2026/proposal/184bde2e-f907-433f-a6ca-c1637ec6d064 2
必要のないものは、必要になるまで作らない 3 YAGNI原則とは You Aren't Gonna Need It. 必要となるまで作らない。 AIで速く作れるようになった時代に、
変更が少なそうだと思った機能を 先回りして一気に作りました。 結果、すべてが使われなくなりました。
髙橋直規(幡ヶ谷亭直吉) @asagayanaoki • エンジニア歴 :19年目 • 役割 :プロジェクトマネージャー、エンジニア • 大切
:経験主義、プロダクト思考、チーム開発 • 好きな原則 :YAGNI、DRY、単一責任の原則 4 著書 主催コミュニティ Copyright Murata Manufacturing Co., / SHIFT Inc., All Rights Reserved.
この話の前提:AIで何でもできる気がしていた 5 0→1の本番運用を前提にした 新規プロダクト開発 世の中から少し遅れてのAIコーディング 人間だけの開発スピードより 1.5倍以上の加速を期待されるが、楽に達成
AI開発の熱に浮かされていた この話の前提:AIで何でもできる気がしていた 6
AI時代の新しい開発の模索 7 AIが特別なツールに思えた。 今までと違う開発の進め方に挑戦したいと考えた。 それまで1本ずつ進めていたAPI開発を、 まとめて実装できないか試した。 API1 API2 API3 API4
API5 ・・・ それまで 挑戦 API2 API3 API4 API1 API5
単純な機能での実験 8 実験対象は、シンプルな検索APIの5本に絞った。 複雑な処理や業務判断が求められるAPIは対象外にした。 ロジックが似ているAPI群と、 同じ業務フローのAPI群を分けて開発を進めた。 ロジックが似ているAPI群 マスタテーブルを検索し、 レコードを取得する処理。 同じ業務フローのAPI群
処理自体は単純だが、API同士に 業務上の関連性がある処理。
まとめて進めたことで、学びが遅れた 9 ロジックが似ているAPI群は問題なく進んだ。 同じ業務フローのAPI群では、 複数APIの設計・実装・テストを同時に並行したことで、 テーブル定義の考慮漏れという設計ミスに気づくのが遅れた。 1本目で得られるはずの学びを次のAPIに活かせなかった。 業務が不確定な機能こそ、 まず1本をテストまで通してから、 残りに横展開すべきだった。
実験としては、成功したと思っていた 10 すべてのAPIの実装を完了した まとめて作れるものと、 まず1本通すべきものの違いも見えた
成果も学びも得ることができた 実験としては、成功したと思っていた 11
12 その後、まもなく...
5本作ったAPIはすべて無駄になった 13 要件の消滅、仕様変更、既存機能での代替により、 先回りして作ったAPIは、すべて使われなくなった。 0本 5本
作れることに意識が奪われていた 14 AIで想像以上に楽に速く作れるようになった。 その結果、プロダクトにその機能が本当に必要かより、 機能を作ること自体に意識が奪われていた。 「将来必要になりそう」で先回りしたAPIは、 要件の変化によって使われなくなった。
AI時代でもYAGNI原則は変わらない 15 You Aren't Gonna Need It. 必要となるまで作らない。 速く作れるからこそ、作る前に 「本当に今必要か」を考える。
作る前に考えるべきだったこと 16 その機能は、 次のリリースでは遅いのか?
17 では、実験も 無駄になったのか?
作るためではなく、試すための速度 18 圧倒的に速く開発できるようになったからこそ、 生産量を上げるだけでなく、 より価値のある機能をつくるために、 空いた時間で何を学ぶかが重要になる。 それまで AI開発
AI時代こそ実験からの学びを 19 実験をしたからこそ、 YAGNIの重要性も追体験できた。 AI時代の速度は、 学びを増やすためにも使える。
20