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 コードレビューが面倒すぎるのでテスト駆動開発で解決しようとして読んだら、根本的に俺の勘違...
Search
Mutz
July 28, 2025
Technology
1.1k
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
AI コードレビューが面倒すぎるのでテスト駆動開発で解決しようとして読んだら、根本的に俺の勘違いだった
読書シェア会 vol.7
Mutz
July 28, 2025
More Decks by Mutz
See All by Mutz
AI時代になぜ書くのか
mutsumix
0
530
『アキハバラ電脳組』から考える、場所がコミュニティを生む理由
mutsumix
0
330
AndroidにBluetoothでいろいろつなげてみた
mutsumix
0
33
AIでAndroid→iOS アプリ移植をやってみた
mutsumix
0
56
2025年 AIに助けられたこと
mutsumix
0
150
あなたに水耕栽培を愛していないとは言わせない
mutsumix
1
360
地域コミュニティを活かす市民開発の可能性
mutsumix
0
240
社員のスキルチェックのためにスマホアプリを作った話
mutsumix
0
94
軽率に資料をスライド化しよう
mutsumix
0
85
Other Decks in Technology
See All in Technology
最適な自走を最小限の支援で — M&Aで拡大する組織で少人数SREが挑んだ1年 / SRE NEXT 2026
genda
0
1k
Oracle Base Database Service 技術詳細
oracle4engineer
PRO
15
110k
Docker Desktop不要の時代が来る? WSL標準の「wslc」で Linuxコンテナを動かしてみた.
ueponx
0
930
AIと共生する開発者プラットフォーム:バクラクのモノレポ×マイクロサービス基盤
sakajunquality
2
3.4k
CSに"SLO"は要らない、経営層に"99.9%"は伝わらない - SREを全社に"翻訳"する3原則
cscengineer
PRO
1
4.4k
しくみを学んで使いこなそう GitHub Copilot app
torumakabe
1
210
ポストモーテム! DDoSからサイトは守れた。 でもビジネスは守れなかった。
bengo4com
0
2.7k
なぜ人は自分のプロジェクトを 「なんちゃってアジャイル」と 自嘲するのか
kozotaira
0
280
関数型の考えを TypeScript に持ち込んで、テストしやすい純粋関数を増やす / Pure at the Core, Effects at the Edge: Bringing Functional Thinking into TypeScript
kaminashi
1
100
インフラ寄りSREでも 開発に踏み出せる〜境界を越えてユーザー体験に向き合いたい〜
sansantech
PRO
2
3.6k
地域 SRE コミュニティ最前線 / SRE NEXT 2026 Discussion Night Track C
muziyoshiz
0
210
DMM.com 購入改善推進チーム におけるCodeRabbitを用いた レビューフロー改善の一例
ysknsid25
2
610
Featured
See All Featured
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
17k
How to optimise 3,500 product descriptions for ecommerce in one day using ChatGPT
katarinadahlin
PRO
1
3.7k
How to Talk to Developers About Accessibility
jct
2
320
Everyday Curiosity
cassininazir
0
250
Building a Scalable Design System with Sketch
lauravandoore
463
34k
WENDY [Excerpt]
tessaabrams
11
38k
A Tale of Four Properties
chriscoyier
163
24k
Building an army of robots
kneath
306
46k
Efficient Content Optimization with Google Search Console & Apps Script
katarinadahlin
PRO
1
680
Believing is Seeing
oripsolob
1
170
My Coaching Mixtape
mlcsv
0
170
Color Theory Basics | Prateek | Gurzu
gurzu
0
390
Transcript
1
梶原 睦 / かじはら むつみ 株式会社 シスマック DX ソリューション事業部 部長
Twitter(現 X): @Mutsumix_dev Voicy: Mutsumix の進捗どう? 技術書典: 自宅水耕栽培で毎日サラダ生活 最近は受託開発の提案やったり営業やったり研修講師やったり総務やったり 自己紹介 2
AI コーディング、やってますか? AI コーディング、やってますか? 3
AIにコード書かせる チャット形式でのコーディング補助からCLIやIDE統合を使った実装が今や主流 任せられる範囲は広がり、人間の方がCopilot(副操縦士)になっていく 人間の役割はコーディング結果のチェック めちゃくちゃ楽になってるはずだけど... AI コーディング、やってますか? 読書シェア会 vol.7 |
AI コードチェックが面倒すぎるのでテスト駆動開発で解決しようとして読んだら、根本的に俺の勘違いだった 4
自走させると最初は順調 だんだん方向性がずれてくる 気づいたら修正不可能な状態 AI コーディングの現実 読書シェア会 vol.7 | AI コードチェックが面倒すぎるのでテスト駆動開発で解決しようとして読んだら、根本的に俺の勘違いだった
5
目 Grep は面倒だし... 成果物に対してテストをさせれば、ずれを修正できるのでは? よし、AI にテストを書かせよう プロンプト: まずテストを書いて、それを突破するように実装して 何か良い方法はないものか? 読書シェア会
vol.7 | AI コードチェックが面倒すぎるのでテスト駆動開発で解決しようとして読んだら、根本的に俺の勘違いだった 6
AI「テスト完了しました! 」 describe("UserService", () => { it("should create user", ()
=> { const mockDb = jest.fn(); const mockValidator = jest.fn(); // TODO: implement this test expect(true).toBe(true); // とりあえず通る }); }); モックだらけ、都合悪いところがコメントアウトされている、何をテストしているか 意味不明 こんなの受け入れていいのか?? 結果 読書シェア会 vol.7 | AI コードチェックが面倒すぎるのでテスト駆動開発で解決しようとして読んだら、根本的に俺の勘違いだった 7
AIにテストをさせる方法自体は悪くないはずだ AIにテストをさせる方法自体は悪くないはずだ 読書シェア会 vol.7 | AI コードチェックが面倒すぎるのでテスト駆動開発で解決しようとして読んだら、根本的に俺の勘違いだった 8
テストについての本を読もう テストについての本を読もう 読書シェア会 vol.7 | AI コードチェックが面倒すぎるのでテスト駆動開発で解決しようとして読んだら、根本的に俺の勘違いだった 9
「テストについてちゃんと学んで、効果的なテス トの書き方を学ぶぞ」 3 部構成: 第 1 部:テスト駆動開発(TDD)を使った実装 ある金融システムの多国通貨対応 第 2
部:xUnit の例 テスティングフレームワーク構築 第 3 部:TDDパターンとリファクタリングについて ケント・ベック『テスト駆動開発』 読書シェア会 vol.7 | AI コードチェックが面倒すぎるのでテスト駆動開発で解決しようとして読んだら、根本的に 俺の勘違いだった 10
わかる 印象に残ったページ 不安はためらいを生む。 不安はコミュニケーションを減らす。 不安はフィードバックから逃げ腰にさせる。 不安はイライラさせる。 読書シェア会 vol.7 | AI
コードチェックが面倒すぎるのでテスト駆動開発で解決しようとして読んだら、根本的に俺の勘違いだった 11 「テスト駆動開発は、プログラミング中の不安をコントロールする手法だ。...
TDDは品質担保にとどまらず、開発者の不安を軽減する開発手法のことらしい 読書シェア会 vol.7 | AI コードチェックが面倒すぎるのでテスト駆動開発で解決しようとして読んだら、根本的に俺の勘違いだった 12 TDDはテスト技法ではない。 TDDは分析技法であり、設計技法であり、実際には 開発の全てのアクティビティを構造化する技法なのだ。
TDD においてテストは目的を達成するための手段であり、その目的は、大いなる 自信を伴うコードだ。
1. まずはテストを一つ書く 2. 全てのテストを走らせ、新しいテスト の失敗を確認する 3. 小さな変更を行う 4. 全てのテストを走らせ、全て成功する ことを確認する
5. リファクタリングを行なって重複を除 去する テスト駆動開発の流れ 読書シェア会 vol.7 | AI コードチェックが面倒すぎるのでテスト駆動開発で解決し ようとして読んだら、根本的に俺の勘違いだった 13
「あれ、これテストの書き方の本じゃない...?」 TDD の本質: テスト設計手法 プログラミング中の不安を取り除く開発手法 読んでみた結果 読書シェア会 vol.7 | AI
コードチェックが面倒すぎるのでテスト駆動開発で解決しようとして読んだら、根本的に俺の勘違いだった 14
核心は 心理的安全性 小さなステップで確実に前進 常に動作するコードを維持 複雑さをコントロール プログラミング中の開発者の不安を軽減 TDD の真の価値 読書シェア会 vol.7
| AI コードチェックが面倒すぎるのでテスト駆動開発で解決しようとして読んだら、根本的に俺の勘違いだった 15
根本的に俺の勘違いだった 根本的に俺の勘違いだった 読書シェア会 vol.7 | AI コードチェックが面倒すぎるのでテスト駆動開発で解決しようとして読んだら、根本的に俺の勘違いだった 16
Before (勘違い) 問題: AI コードのチェックが面倒 試み: AI にテストを書かせる → 失敗
期待: テストで品質担保 After (理解) 実際の TDD: 開発プロセス自体の改善 根本的な勘違いに気づいた 読書シェア会 vol.7 | AI コードチェックが面倒すぎるのでテスト駆動開発で解決しようとして読んだら、根本的に俺の勘違いだった 17
これからのAIコーディングへの応用可能性は? これからのAIコーディングへの応用可能性は? 読書シェア会 vol.7 | AI コードチェックが面倒すぎるのでテスト駆動開発で解決しようとして読んだら、根本的に俺の勘違いだった 18
https://newsletter.pragmaticengineer.com/p/tdd-ai-agents-and-coding-with- kent 最近のKent Beck氏のポッドキャストでの発言 読書シェア会 vol.7 | AI コードチェックが面倒すぎるのでテスト駆動開発で解決しようとして読んだら、根本的に俺の勘違いだった 19
「開発者の役割は、コードを書く人から、AIに良いコードとは何かを教える人へ と変わっている。テストがその教育プログラムなのだ。 」
AI時代のソフトウェア開発を考える(2025/07版) TDDの翻訳者、和田卓人(t-wada)さんの発言 Vibe Coding をはじめとした AIの開発生産性により、開発規模が大きくなる と発生する諸問題が、ごく短期間で発生するようになった 問題の構造は変わらず、顕在化までの時間が圧倒的に短くなっただけ 仕様や設計を見つけるよくしていく過程がTDD 細部を作りながら、全体の設計にフィードバックしていく過程が重要
読書シェア会 vol.7 | AI コードチェックが面倒すぎるのでテスト駆動開発で解決しようとして読んだら、根本的に俺の勘違いだった 20
間違ったアプローチ いい感じにテストを作って とAIに指示 指示する本人も何をテストされるかよくわからない TDD を AI コーディングに応用するなら 読書シェア会 vol.7
| AI コードチェックが面倒すぎるのでテスト駆動開発で解決しようとして読んだら、根本的に俺の勘違いだった 21
正しいアプローチ 「タスクを小さな実装に分解 → 逐次消化 → リファクタリング」 とAIに指示 方向性のずれを小さなうちに修正 ゴールに向けた一歩ずつの前進 最初から大きななゴールを目指さないアプローチ
(バイブコーディングの醍醐味は 失われるが) 読書シェア会 vol.7 | AI コードチェックが面倒すぎるのでテスト駆動開発で解決しようとして読んだら、根本的に俺の勘違いだった 22
1. 最終ゴールを明確にする: 要件ヒアリングと設計文書(README.md、DESIGN.md)作成 2. 現在の状態から次の小さなステップを定義: TODO.mdで進行状況確認し、作業対象を決定 3. そのステップだけを実装: RED(失敗テスト)→GREEN(最小実装)→REFACTOR(改善)を順次実行 4.
動作確認: 各段階でテスト実行とコミットによる確認 5. 次のTODOを提示: FEEDBACK段階で設計文書更新と新しいタスクの発見・追加 6. 2-5を繰り返し: 実際のプロンプト例 読書シェア会 vol.7 | AI コードチェックが面倒すぎるのでテスト駆動開発で解決しようとして読んだら、根本的に俺の勘違いだった 23
Claude Code のカスタムスラッシュコマンドとして登録してみた Mutsumix/ore-tdd.md https://gist.github.com/Mutsumix/75a6c162d83580ad6b9d1b134892213d 実際のプロンプト例 読書シェア会 vol.7 | AI
コードチェックが面倒すぎるのでテスト駆動開発で解決しようとして読んだら、根本的に俺の勘違いだった 24
サイクルの図解 読書シェア会 vol.7 | AI コードチェックが面倒すぎるのでテスト駆動開発で解決しようとして読んだら、根本的に俺の勘違いだった 25
学んだこと TDD は「テスト手法」ではなく開発者の不安を軽減する開発手法 AIコーディング にもこの開発プロセスを適用できる可能性 読む前の思い込みに気をつける 自分の理解を超えた優れた概念はまだまだある 次のアクション この手法で実際にプロジェクトを試して効果を検証 xUnit
の実装の章を書籍に従って写経 『ソフトウェアエンジニアリング』を読む 継続的にソフトウェアを開発していくための考え方を学ぶ 学んだこと + 次のアクション 読書シェア会 vol.7 | AI コードチェックが面倒すぎるのでテスト駆動開発で解決しようとして読んだら、根本的に俺の勘違いだった 26
ありがとうございました! 読書シェア会 vol.7 | AI コードチェックが面倒すぎるのでテスト駆動開発で解決しようとして読んだら、根本的に俺の勘違いだった 27