AIによる偏った”痛み”が 和らぎますように

「生成AIとともに叶えた・叶えたい願い Vol.2」LT会 〜七夕エディション〜 にて使用した資料になります！
https://optim.connpass.com/event/397915/

参考文献：
・Kent Beck 著、和田 卓人 訳（2017）『テスト駆動開発』：https://www.ohmsha.co.jp/book/9784274217883/
・【 CoLab Conf 2026│株式会社ジーニー】「AI時代のエンジニアが 相対的プレゼンスを上げる方法」（2026/06/27） ：https://speakerdeck.com/geniee_inc/27
・James A. Wondrasek (2025年) 「Why AI Coding Speed Gains Disappear in Code Reviews」：https://www.softwareseni.com/why-ai-coding-speed-gains-disappear-in-code-reviews/
・lberto Bacchelli, Christian Bird, (2013年) 「Expectations, Outcomes, and Challenges
of Modern Code Review」：https://sback.it/publications/icse2013.pdf
・Peter Naur, (1985年) 「Programming as Theory Building」：https://pablo.rauzy.name/dev/naur1985programming.pdf
・miyuki (2025年) 「速く気持ちよくレビューサイクルを回すNOT A HOTELオーナーアプリWebチームの文化と仕組み」：https://note.com/walkaround/n/n0cbd1dd4f861
・Robert C.Martin 著、 角 征典 訳 (2026年)『我ら、プログラマー』：https://zen.ac.jp/press/books/b_0013
・野中 郁次郎 著, 竹内 弘高 著, 梅本 勝博 訳 (2020年)『知識創造企業(新装版)』：https://amzn.asia/d/0dkHVyNs

Transcript

1. AIによる偏った "痛み"が 和らぎますように
2. 自己紹介 • 名前：TDD野郎 (𝕏：@LetsDoTDD) ◦ SIer 7年目 ▪ 2020~ 組み込み関連開発 ▪ 2023~ フロントエンド開発 • 好きなもの：TDD • 嫌いなもの：痛いこと 2
3. 痛みってなに？ • 痛み ＝ 危険信号 ◦ 開発中の不安、無駄な労力、ストレス などなど TDDの不安をさらに広げたような概念(?) ◦ 痛みは嫌なので減らしたい ▪ → 改善するきっかけに繋がる (不安とは)「これは困難な問題なので、最初からすべてを見通せるわけではな い」という真っ当な感覚のことだ。もしも痛みが身体からの「止まれ」というサイ ンならば、不安は「気をつけろ」というサイン だ。 Kent Beck 著、和田 卓人 訳（2017年）『テスト駆動開発』まえがきxiページ https://www.ohmsha.co.jp/book/9784274217883/
4. エンジニアは「痛がり」であれ • 痛みを検知することが改善の第一歩 ◦ 改善を積み重ねることの到達点が「自動化」と「仕組み化」 エンジニアの本質は「自動化」と「仕組み化」 【 CoLab Conf 2026│株式会社ジーニー】「AI時代のエンジニアが 相対的プレゼンスを上げる方法」（2026/06/27） 24p https://speakerdeck.com/geniee_inc/27?slide=24
5. AI時代の痛みってなに？
6. AI時代の痛みってなに？ 1. レビューがボトルネックに 2. 若手育成の課題（ジュニアエンジニア不要論）
7. AI時代の痛みってなに？ 1. レビューがボトルネックに 2. 若手育成の課題（ジュニアエンジニア不要論）
8. AI時代の労力の変化 • 参考：https://www.softwareseni.com/why-ai-coding-speed-gains-disappear-in-code-reviews/ 従来 コーディング レビュー 91%増加 AI時代 ※図はイメージです。数値は参考とした記事から参照
9. レビューの本質は「理解」 • レビューでのバグ検出の前提として深い理解が不可欠 ◦ 参考：Expectations, Outcomes, and Challenges of Modern Code Review
10. レビューの本質は「理解」 • レビューでのバグ検出の前提として深い理解が不可欠 ◦ 参考：Expectations, Outcomes, and Challenges of Modern Code Review ※調査対象のシニアエンジニア談 (レビューには)他にも多くの有益な効果があります。 (1)自分の書いたコードに執着しなくなる、 (2)他の人がコードの内容を把握できるため、 (3)チーム内での情報共有が促進される、 (4)チーム内でのコーディング規約の遵守を助ける、そして…… (5)全体的なプロセスとコードの品質向上に役立つ、という点です。」 Expectations, Outcomes, and Challenges of Modern Code Review https://sback.it/publications/icse2013.pdf
11. レビューの本質は「理解」 • レビューでのバグ検出の前提として深い理解が不可欠 ◦ 参考：Expectations, Outcomes, and Challenges of Modern Code Review ※調査対象のシニアエンジニア談 レビューの自動化は どこまでの効果を担保する？ (レビューには)他にも多くの有益な効果があります。 (1)自分の書いたコードに執着しなくなる、 (2)他の人がコードの内容を把握できるため、 (3)チーム内での情報共有が促進される、 (4)チーム内でのコーディング規約の遵守を助ける、そして…… (5)全体的なプロセスとコードの品質向上に役立つ、という点です。」 Expectations, Outcomes, and Challenges of Modern Code Review https://sback.it/publications/icse2013.pdf
12. レビューの目的とは？ • プログラミングの成果物は「理論」 ◦ 参考：Programming as Theory Building • 「理論」の共有がレビューの目的の 1つでは？ ◦ → レビューのボトルネックは「理解に至るまでの時間」 理論 レビュー (理論共有 ) 理論
13. なぜ痛みは偏るのか？ • 理解のコストがレビュアーに押し付けられているから • エンジニアなら、自分の痛みだけでなく、 周りのメンバーやチームの痛みをも検知すべき では？
14. 理解のコストは誰が払う？ AI時代 理想 理解サポート
15. 理解のコストは誰が払う？ 負担が軽い方が 歩み寄るべきでは？ つまりはレビュイー AI時代 理想 理解サポート
16. 具体案：コア変更とパターン適用
17. レビューの理解支援を考える • 参考：速く気持ちよくレビューサイクルを回すNOT A HOTELオーナーアプリWebチームの文化と仕組み • コア変更とパターン適用の切り分け ◦ 同じ変更内容が複数箇所に及ぶ場合にPRを分けて修正する ▪ コア変更：1つだけお試しで修正 ▪ パターン適用：コア変更を他の箇所に適用
18. コア変更・パターン適用のイメージ
19. コア変更・パターン適用のメリット • 初回レビュータイミングを早められる ◦ コア変更で差分＋動作確認範囲を絞れる ◦ → レビュアーも見る範囲が減少！ • コア変更・パターン適用で担当を分散できる ◦ タスク自体をコア変更を有識者、 パターン適用を他の担当へ引き継ぎできる！ ◦ レビュアーもコア変更/パターン適用を分散できる！ ◦ → 変更内容の周知・理論共有としてもより広い範囲で可能！
20. 終わりに
21. プログラマーはなぜ必要？ 我々(プログラマー)はなぜ必要とされるのか？なぜならば、社会には詳細のこと を気にかけずにはいられない人々が必要だからだ。 (中略) 大多数の人々が詳細から逃げ出す限り、詳細に向かっ て走る我々のことを必要とするだろう。 (中略) 我々は全世界のための詳細の管理者である。 Robert C.Martin 著、 角 征典 訳 (2026年)『我ら、プログラマー』35p https://zen.ac.jp/press/books/b_0013
22. 俺たち、エンジニア エンジニアの本質は「自動化」と「仕組み化」 【 CoLab Conf 2026│株式会社ジーニー】「AI時代のエンジニアが 相対的プレゼンスを上げる方法」（2026/06/27） 24p https://speakerdeck.com/geniee_inc/27?slide=24 • 詳細を知らずに自動化に走るのはプログラマー足り得ない • 安易な自動化 は本質を削ぎ落としうる ◦ そうならないために痛みを直視し続けろ
23. 俺たち、エンジニア エンジニアの本質は「自動化」と「仕組み化」 【 CoLab Conf 2026│株式会社ジーニー】「AI時代のエンジニアが 相対的プレゼンスを上げる方法」（2026/06/27） 24p https://speakerdeck.com/geniee_inc/27?slide=24 "痛み"に向かって走り続けろ！ • 詳細を知らずに自動化に走るのはプログラマー足り得ない • 安易な自動化 は本質を削ぎ落としうる ◦ そうならないために痛みを直視し続けろ
24. AIによる偏った"痛み"が和らぎますように • AIによる偏った痛みを検知するのも、 解消できるのもエンジニア ◦ 「誰かや何かのプロセスに、偏った痛みがなくなること」が 自分の理想 ◦ それに気づいて直そうと動いていけるといいな • AIとは切り離せない世界になってしまったからこそ、 エンジニアはそうあれかし
25. あなたの「レビュー」 お待ちしてます！
26. Appendix
27. 仮説：レビューが育成に、育成が競争力に繋がる • レビューの本質は理解 ◦ レビューを通してお互いの理解が深まる・広がる＝知識移転 → これこそが育成の機会なのでは？ 知識は陳腐化する ので、組織は今日の知識に満足していてはいけない。 (中略) 知識を絶え間なく作り続けるそのような能力こそが、 知識社会における競争力の源泉なのだ。 野中 郁次郎 著, 竹内 弘高 著, 梅本 勝博 訳 (2020年)『知識創造企業(新装版)』157p https://amzn.asia/d/0dkHVyNs
28. 競争力をどう設計するか？ • レビューの痛みを育成/競争力の成長痛と捉えるか • それともレビューを避けて、より良い仕組みを作るか 個人は知識の「創造者 (クリエイター )」であり、 組織は知識の「増幅器 (アンプリファイヤー )」である。 野中 郁次郎 著, 竹内 弘高 著, 梅本 勝博 訳 (2020年)『知識創造企業(新装版)』415p https://amzn.asia/d/0dkHVyNs • 個人✖組織✖AIの最大化の設計が課題 ◦ レビューでもそれ以外でも 知識創出の場をどう設ける？どう効率化する？
29. 競争力をどう設計するか？ • レビューの痛みを育成/競争力の成長痛と捉えるか • それともレビューを避けて、より良い仕組みを作るか まずは痛みと向き合い、 個人は知識の「創造者 (クリエイター )」であり、 組織は知識の「増幅器 (アンプリファイヤー )」である。 詳細・本質を掴む所から 野中 郁次郎 著, 竹内 弘高 著, 梅本 勝博 訳 (2020年)『知識創造企業(新装版)』415p https://amzn.asia/d/0dkHVyNs • 個人✖組織✖AIの最大化の設計が課題 ◦ レビューでもそれ以外でも 知識創出の場をどう設ける？どう効率化する？ つまりは痛みから逃げるな
30. 参考文献 • • • • • • • Kent Beck 著、和田 卓人 訳（2017）『テスト駆動開発』： https://www.ohmsha.co.jp/book/9784274217883/ 【 CoLab Conf 2026│株式会社ジーニー】「 AI時代のエンジニアが 相対的プレゼンスを上げる方法」 （2026/06/27） ： https://speakerdeck.com/geniee_inc/27 lberto Bacchelli, Christian Bird, (2013年)： Expectations, Outcomes, and Challenges of Modern Code Review Peter Naur, (1985年)：Programming as Theory Building miyuki (2025年)： 速く気持ちよくレビューサイクルを回す NOT A HOTELオーナーアプリ Webチームの文化と仕組み Robert C.Martin 著、 角 征典 訳 (2026年)『我ら、プログラマー』： https://zen.ac.jp/press/books/b_0013 野中 郁次郎 著, 竹内 弘高 著, 梅本 勝博 訳 (2020年)『知識創造企業 (新装版)』： https://amzn.asia/d/0dkHVyNs