AI駆動開発の時代になったのでトヨタ生産方式から見直す

2026-10-09 AI駆動開発勉強会 名古屋支部#2 の発表資料です。

Transcript

1. AI駆動開発の時代になったので トヨタ生産方式から見直す デンキヤギ株式会社 terurou
2. 自己紹介 • terurou • デンキヤギ（株） 代表取締役 • 帳票エンジン（yagisan-reports）にAIを絡めて売ってます • 2時間スプリントをたぶん5年ぐらいやってます
3. まずは現状整理から
4. AIの登場によって、 • コードの生産が超高速化、品質十分 • 手でコードを書くことはほぼなくなった
5. 上に行くほど AIの恩恵は小さい コーディング「は」高速化した システム化企画 運用・評価 要件定義 システムテスト 基本設計 結合テスト 詳細設計 単体テスト 実装 超高速化！
6. プログラマーは中間管理職や ベンダー管理者のような役回りに
7. AI以前 AI以後 リーダー リーダー AI プログラマー プログラマー プログラマー AI プログラマー プログラマー プログラマー AI AI AI AI AI AI AI AI AI
8. AIにコードを書かせて、人間はレビュー ≒ 外注にぶん投げて、納品物を検収
9. コーディングの性質は、製造業に近くなった • 製造機械のボタンを押したら、製品ができる • プロンプトを入力したら、コードができる
10. 工場制手工業 から 工場制機械工業 への転換
11. ただし、 工場制機械工業とは違う部分もある
12. 同一品種を量産するのではなく、 単一のコードベースを編集し続ける
13. では、AI時代になって、 アジャイル開発はまだ適用できるのか？
14. 現在のアジャイル開発は、 • リーンソフトウェア開発の影響が大きい • AI以前に体系立てられたものである
15. コードを生産することが重コストだった時代の 考え方を踏襲したままでいいのか？
16. だったら、原典を見直してみよう
17. https://www.diamond.co.jp/book/9784478460016.html
18. トヨタ生産方式の目的は 生産性の向上。 もっと言えば、原価の低減。
19. 生産性を上げるには 「徹底したムダの排除」が必要
20. トヨタ生産方式の2本柱 • ジャスト・イン・タイム • 自働化
21. ジャスト・イン・タイム 在庫ゼロが理想で、 必要な分だけを生産する
22. 過剰な在庫はムダ • 保管場所だけでなく、運搬と管理も増える • 時間の経過で破損、劣化などが生じる • 不良在庫（売れない・使えない） → 損失
23. 後工程が前工程に、 必要なもの（材料）を、 必要なとき、 必要な分だけ引き取りに行く
24. さらに前の工程 前工程 … 素材・部品の生産 ボディの生産 … 素材・部品の生産 シャーシの生産 … 素材・部品の生産 タイヤの生産 … 素材・部品の生産 エンジンの生産 後工程 最終 組立 最終製品 自動車
25. 必要な分だけを作れば ムダは出ない
26. ただし、大前提として、各工程は １００％良品でなければならない
27. 自働化 前工程に異常が発生したら、 生産ラインが全て自ずと停止する
28. 異常があるのに他の工程が動き続けると、 中間在庫が積みあがってしまう 前工程A 稼働中 前工程B 異常停止 前工程C 稼働中 供給なし 後工程 部品待ち Bがなく組立不可
29. まだまだ過剰在庫を生む要素はある いわゆる「作りすぎのムダ」
30. みかけの能率と必要数 • フル稼働すると、月間で１０万個生産でき、 １個当たりの製造原価は下がる • でも需要は月７万個しかなかったら？
31. 仕事の進みすぎ • 生産能力に余裕がある＝手待ちがでる • 空いているので、次の作業をやってしまう • 手待ちが隠蔽され、ムダな生産も発生
32. 少人化 カイゼンにより生産効率が向上した分は むやみに生産量を増やすのではなく、 少ない人数で済むようにする
33. 余力を生み出す • 効率化で余力が生まれたら、既存人員で 内製化や新しい取り組みを行うことができる • 社員教育に割り当ててもよい
34. 離れ小島をつくるな • 工場にポツンポツンと作業員がいるのはダメ • 一人では人間同士のチームワークが取れない • 一人だけの仕事でも複数集めてチームに
35. チームワーク、助け合い運動 • 後工程が遅れたら、前工程が手伝いに行く • 全員が熟練工ではなく、新入社員もいる
36. ソフトウェア開発に置き換えてみる
37. 目的は原価の低減
38. AIでコードを生産するスピードは上がったが 作りすぎのムダは生じていないか？
39. ジャスト・イン・タイム
40. AIによって、もはや コードを生産することは負担ではない
41. 「将来に備えて…」「拡張性を…」 「こういう使い方もするかも…」は 在庫のムダになっていないか？ 将来、そのコードは本当に使えるの？
42. AIがあるなら、必要になったときに コードを生成しても間にあうでしょ
43. AI以後、 レビューが滞留する話は 本当によく出るようになった
44. 後工程（レビュー）が対応できないのは 生産が過剰になっていないか？ これも在庫のムダ
45. AIの分だけ生産量を増やすのではなく、 少人化 or レビュー工程をカイゼン
46. AIによってできた余力を レビュー工程のカイゼンに振り分ける
47. 大前提として、各工程は １００％良品でなければならない
48. Pull Requestをぶん投げる際に ちゃんと品質は担保できてますか？
49. https://x.com/t_wada/status/2104720765895819501
50. コードをやみくもに量産するのではなく、 レビュー負担を小さくせよ これはチームによって最適解が異なるはず
51. 自動テスト、コード解析、CIの強化 • AIが機能をぶっ壊しても検知できるように → 自働化 • テストがちゃんとしていたら、レビューも楽
52. テスト設計・テスト手法の学習 • いくらテストコードの量があっても テスト内容がダメなら意味はない • AIによる余力を教育に配分
53. テスタビリティの高いコード テストしやすい設計になっていなければ、 自動テストしようと思っても無理がある
54. テストに限らず、 プログラミング言語自体の静的検証も 有効な手段の一つ
55. 離れ小島をつくるな • 一人で黙々と作業をし続けて、 最後にPull Requestをぶん投げられても困る • コードが完成する前から、要件や実装方針を すり合わせ、Pull Requestビックバンにしない
56. コーディング以外は速くなってない 上に行くほど AIの恩恵は小さい システム化企画 運用・評価 要件定義 システムテスト 基本設計 結合テスト 詳細設計 単体テスト 実装 超高速化！
57. デンキヤギでは2時間スプリントで吸収 • 常にレビューし続けていたら、 Pull Request時に確認することはほぼない • ムダな機能や要件漏れなども早期に検知
58. AIを導入することは間違いなく 生産性向上・減価低減に有効だが、 作りすぎのムダは全てを台無しにする
59. 「生産性」を誤用するな コードを速く生産できること自体が 生産性ではない。 生産性＝利益（価値）÷労働量
60. 今回は話さなかったこと • 2時間スプリントについて • スプリント期間が1-2週間とか長すぎ • 試作・検証と本開発は明確に分離する • 計画は常に変わり続けるもの
61. さいごに このスライドはトヨタ生産方式（大野耐一本）の チェリーピックなので、自分で読みましょう。 ザ・ゴールでもいいですが、ページ数が…。