プロダクトの成長を支える生成AI時代のエンジニアリングプラクティス

お客様の社内講演の資料です

Tidy First? ―個人で実践する経験主義的ソフトウェア設計
  • 著者／訳者：Kent Beck、 吉羽 龍太郎、 永瀬 美穂、 細澤 あゆみ
  • 出版社：オライリー・ジャパン
  • 発売日：2024-12-25
  • 単行本（ソフトカバー）：164ページ
  • ISBN-13：9784814400911
  • ASIN：4814400918
脳に収まるコードの書き方 ―複雑さを避け持続可能にするための経験則とテクニック
  • 著者／訳者：Mark Seemann、 吉羽 龍太郎、 原田 騎郎、 Robert C. Martin
  • 出版社：オライリー・ジャパン
  • 発売日：2024-06-18
  • 単行本（ソフトカバー）：312ページ
  • ISBN-13：9784814400799
  • ASIN：4814400799

Transcript

1. プロダクトの成長を支える 生成AI時代の エンジニアリングプラクティス 2025/11/14 fi 株式会社アトラクタ / Certi ed Scrum Trainer （CST） 吉羽 龍太郎 （@ryuzee）
2. 自己紹介 吉羽龍太郎 / Ryutaro YOSHIBA / ryuzee ▸ 株式会社アトラクタCTO /アジャイルコーチ / 翻訳者 ▸ Scrum Alliance 認定スクラムトレーナー （CST） 認定チームコーチ (CTC) ▸ Microsoft MVP （DevOps） ▸ X（Twitter）: @ryuzee ブログ: https://www.ryuzee.com/ 2
3. 自己紹介 最新書籍紹介（買ってください!!） 3
4. プロダクトの成長を支える生成AI時代のエンジニアリングプラクティス Tidy First? ▸ Kent Beck 16年ぶりの書籍 ▸ エクストリーム・プログラミング（XP）の父 ▸ 3巻シリーズの1冊目 ▸ 想定読者：プログラマー、リード開発者、 現場にでるソフトウェアアーキテクト、技術マネージャー ▸ 一般的なプログラミングの経験がそこそこある人 ▸ コードの整頓について書いている ▸ 2巻めの『Tidy Together』が2026年1月に刊行!! 4
5. プロダクトの成長を支える生成AI時代のエンジニアリングプラクティス 生成AI時代のエンジニアリングプラクティスというタイトルだが…… ▸ 疑問 ▸ AI時代より前に特に重要だったエンジニアリングプラクティスは？（A: 整頓、リファクタリング） ▸ そもそも整頓って何か？リファクタリングとの違いは何か？ ▸ いつ整頓やリファクタリングをするのか？どんな判断基準があるのか？ ▸ AIを使うようになると、整頓やリファクタリングは不要になるのか？ ▸ AIを使うようになると、新しいエンジニアリングプラクティスが必要になるのか？ まずはAIの文脈をいったん脇において、整頓やリファクタリングを見ていきましょう。 5
6. プロダクトの成長を支える生成AI時代のエンジニアリングプラクティス 6 リファクタリングと整頓 ▸ リファクタリング: ふるまいを変えずに構造を変更すること ▸ 整頓: リファクタリングのサブセット。1人で短時間でできるもののこと 『Tidy First』 p.7より引用
7. プロダクトの成長を支える生成AI時代のエンジニアリングプラクティス いつリファクタリングや整頓をするのか？ ▸ 先にやる ▸ あとにやる ▸ 改めてやる ▸ やらない どれを選ぶか？ 整頓とリファクタリングのどちらなのかによって違うのか？ どんな判断ロジックがあるのか？ 7 開発チームのメンバーから 「リファクタリングしたい」と言われると 判断に悩みますよね？
8. プロダクトの成長を支える生成AI時代のエンジニアリングプラクティス 8 3Xモデル (Explore、Expand、Extract) ケント・ベックが提唱しているモデル。 フェーズごとに時間の性質、リスク・リターンプロファイル、重視する 価値観などが異なる。 ▸ Explore (探索): さまざまなことを試し、実験のコストを減らし、学習を迅速に応用するフェーズ ▸ Expand (拡大): 「大当たり」を見つけ、急成長するフェーズ。予測不可能なボトルネックが次々と発生し、 瞬時の判断が求められる ▸ Extract (抽出): 安定したプロダクトから価値を引き出すフェーズ。タスク見積もりが可能で、時間は直 線的に感じられる
9. プロダクトの成長を支える生成AI時代のエンジニアリングプラクティス Explore（探索） ▸ 目的：アイデアの価値を検証すること ▸ 「どうせ捨てるコード」。この段階では品質よりスピードを重視 ▸ プロトタイプや実験用のコードにリファクタリングの価値はほぼない ▸ 試行錯誤が目的のフェーズ ※ プロトタイプをそのまま本番に持っていこうとする判断がいかに暴挙かがわかるはず 9
10. プロダクトの成長を支える生成AI時代のエンジニアリングプラクティス Expand（拡大） ▸ 大当たりを見つけ、急成長するフェーズ ▸ つまり、使われるソフトウェア ▸ 同時にカオスの中心： ▸ やりたいこと、やらなければいけないことがとても多い ▸ 時間も人も足りない ▸ バグも増える ▸ コードはレガシー ▸ 「先にリリースして稼いでから直す」 vs 「先に整えてあとで楽をする」 のせめぎあい 10
11. プロダクトの成長を支える生成AI時代のエンジニアリングプラクティス Extract（抽出） ▸ 安定し、価値を継続的に引き出すフェーズ ▸ コードの整頓・テスト・設計改善は主要な投資対象に ▸ 整頓やリファクタリングは利益を守るための「予防保全」 11
12. プロダクトの成長を支える生成AI時代のエンジニアリングプラクティス ありがちなシナリオ ▸ お金を稼がないとプロダクトは持続できない ▸ そこでまずは収益を優先する（お金が稼げたら変更容易性を上げよう） ▸ お金を稼げるようになった頃には身動きが取れなくなっている どう考えたらいいんだろうか？ 12
13. プロダクトの成長を支える生成AI時代のエンジニアリングプラクティス ソフトウェアの経済的価値 ▸ 『Tidy First?』ではソフトウェアの経済的価値を次の2軸で捉える ▸ お金の時間価値 ▸ ソフトウェアのオプション価値 ▸ この2つはときに衝突する ▸ 目先の収益性（短期） vs 将来の変更容易性（長期） 13
14. プロダクトの成長を支える生成AI時代のエンジニアリングプラクティス お金の時間価値 ▸ 明日の1ドルより今日の1ドルのほうが価値が高い ▸ 先に貰えば投資できるし、手に入らないリスクもない ▸ 将来もらう予定の1ドルの現在価値は、1ドルより少ない額になる（割り引かれる） ▸ 例えば、3か月後に決済される手形を今現金化すると、額面より安くなる ▸ 現在の価値を考慮するときは、将来手に入る金額を割引いた金額で評価する ▸ ディスカウントキャッシュフロー 14
15. プロダクトの成長を支える生成AI時代のエンジニアリングプラクティス お金の時間価値を考えると… ▸ お金の時間価値が推奨するのは、先に整頓するよりもあとに整頓する ▸ お金を生む振る舞いの変更を今すぐ実装して、あとから整頓する ▸ すぐにお金が手に入り、あとでお金を使う 15
16. プロダクトの成長を支える生成AI時代のエンジニアリングプラクティス 16 オプション ▸ Kent Beckは金融の「オプション取引」をもとにソフトウェアの経済性を検討した ▸ 「あらかじめ定められた価格と期日に取引できる権利」を売買する取引のこと ▸ 買う権利（コール・オプション）の売買 （※Tidy First?はこちら）と売る権利（プット・オプション）の売買 ▸ 権利を手に入れるときにプレミアムと呼ばれる料金を払う ▸ 期日には種類がある ▸ アメリカンタイプ: 満期日までの期間中いつでも権利行使できる ▸ ヨーロピアンタイプ: 満期日のみ権利行使できる ▸ 義務ではないので、権利を行使しないこともできる ▸ 行使しない場合に失うのはプレミアムだけなので、リスクは限定的になる
17. プロダクトの成長を支える生成AI時代のエンジニアリングプラクティス オプションの価値 ▸ オプションの価値を最も左右する要因は価格変動の大きさ（ボラティリティ） ▸ 価格が上がるだけでなく、価格が下がることも含め全て ▸ 将来の振る舞いの変更から得られる価値が不明確であればあるほど、オプションの価値が上がる ▸ つまりプレミアム（＝整頓にかかる時間）を払う合理性が増える ▸ どの機能が価値を生むかわからないという状況においては、将来の選択肢は多いほうがよい ▸ その選択肢を持っていること自体に価値がある ▸ オプションの価値だけを踏まえれば「先に使って、あとで稼ぐ」ほうが得ということになる 17
18. プロダクトの成長を支える生成AI時代のエンジニアリングプラクティス 結局キャッシュフローとオプションは対立する ▸ 経済的な綱引き ▸ ディスカウントキャッシュフロー: 先に稼いであとで使う ▸ オプション: 先に使ってあとで稼ぐ ▸ 両方の選択肢がありえる、ということになる 18
19. プロダクトの成長を支える生成AI時代のエンジニアリングプラクティス 判断軸は？ ▸ 経済性を決めるのはプロダクトのコンテキスト。つまり3Xをもとに考える 19
20. プロダクトの成長を支える生成AI時代のエンジニアリングプラクティス 20 フェーズの推移による関心度の変化 フェーズ 主な目的 支配的リスク Explore（探索） 新しい価値の発見 Expand（拡大） Extract（収益化） 意思決定の軸 目先の収益 （スピード） 変更容易性 （整頓・設計） 「何が当たるかわか 学習と発見を最速 らない」 で回す 最優先（速く試して 速く失敗） 低優先（どうせ捨て るコード） 急成長・市場シェア の獲得 「スピードを失うリス 時間との戦い／生 ク」 き残り 高優先（機会損失を 局所的に優先（整頓 避ける） は小さな投資として 判断） 安定化・効率化・利 益最大化 「硬直性と維持コス ト」 低優先（新機能より 効率重視） 安定と持続性の最 適化 最優先（整頓・設計 が収益を守る）
21. プロダクトの成長を支える生成AI時代のエンジニアリングプラクティス 21 最初から整頓やリファクタリングが不要にできないのか？ ▸ 当時は知らなかったことがあとからわかる ▸ 最初にすべてを予見することは不可能 ▸ なので、整頓やリファクタリングを不要にはできない ▸ 書く時点で良い設計にしたり、注意をしたり、レビューをしたり、ツールを使ったりすることで、減らすこと はできる
22. プロダクトの成長を支える生成AI時代のエンジニアリングプラクティス 使われるソフトウェアという軸 「使われるソフトウェアの多くは変更が必要になる。 必要な変更をすべて予測するのは無理。 よって変更可能に書くべき」 （『レガシーコードからの脱却』） 22
23. プロダクトの成長を支える生成AI時代のエンジニアリングプラクティス コンスタンチンの等価性 ソフトウェアのコストは、それを変更するコストとほぼ等しい ▸ cost(ソフトウェア) ≒ cost(変更) ≒ cost(大きな変更) ≒ 結合 ▸ 結合が増えるほど、変更コストがべき乗的に上がる ▸ ソフトウェアのコストを下げるには、結合を減らす設計判断が必要 23
24. プロダクトの成長を支える生成AI時代のエンジニアリングプラクティス 結合を減らす ▸ 結合を減らすとは、変更の影響範囲を小さくすること ▸ 同時に「人の脳に収まる単位」で設計を分割することでもある ▸ 「1つのコードの中で7を超えることをしてはいけない」 （『脳に収まるコードの書き方』） 24
25. プロダクトの成長を支える生成AI時代のエンジニアリングプラクティス SOLID原則（ROBERT C. MARTIN） ▸ 1.単一責任の原則 (SRP) — モジュールは1つの理由でのみ変更されるべき ▸ 2.開放閉鎖の原則 (OCP) — 拡張に開かれ、変更に閉じているべき ▸ 3.リスコフ置換原則 (LSP) — サブタイプはスーパータイプとして置き換え可能であるべき ▸ 4.インターフェース分離の原則 (ISP) — 不必要な依存を強制しない ▸ 5.依存関係逆転の原則 (DIP) — 具象ではなく抽象に依存すべき 25
26. プロダクトの成長を支える生成AI時代のエンジニアリングプラクティス CLEANコード 高凝集で疎結合な構造を維持することで、テスト容易性と変更容易性が上がる ▸ Cohesive (凝集性) ▸ Loosely Coupled (疎結合) ▸ Encapsulated (カ セル化) ▸ Assertive (断定的) プ ▸ Non redundant (非冗長) 26
27. プロダクトの成長を支える生成AI時代のエンジニアリングプラクティス 27 CLEANのメリット ▸ (C) 凝集性 あれ 、理解も を見つけるのも簡単 ▸ (L) 結合度 低けれ 、副作用 減り、テストや再利用、拡張 簡単 ▸ (E) カ セル化されていれ 、呼 出し元 実装の詳細を知らなくてもよいように維持 きる。あとか ら変更するのも簡単 ▸ (A) 断定的 あることは、ふるまいを配置する場所が依存 ータ ある場所 あることを示す で よい で が ば が デ だ で が び グ 修正や変更は1箇所 1回 けやれ が バ ば グ バ ば ば が で が で プ ▸ (N) 冗長 なければ、
28. プロダクトの成長を支える生成AI時代のエンジニアリングプラクティス 自動テスト ▸ テストは「振る舞いを固定する」 ▸ それによって、構造を変更する自由が得られる ▸ この「安全に変える力」は、「生成AI時代」に直結する 28
29. プロダクトの成長を支える生成AI時代のエンジニアリングプラクティス AIの影響 ここまで見てきたのは、生成AI登場以前の「人の手による開発」の原則でした。 ここからは、それらの原則が生成AI時代にどう再構成されるのかを見ていきます。 29
30. プロダクトの成長を支える生成AI時代のエンジニアリングプラクティス 生成AI以前: 実装作業に時間がかかる ▸ 実装にいちばん時間がかかる ▸ 全体の速度を律速するのは「実装」にかかる時間 ▸ 「誰がどれだけ書けるか」を鍵だと考える ▸ 実装作業を効率化すべくさまざまな取り組みをする ▸ 設計や計画の段階で「実装効率」を目指す ▸ 並列作業でスループット最大化しようとする ▸ 一方で実装に時間を使うために、他のものを犠牲にしがち 30
31. プロダクトの成長を支える生成AI時代のエンジニアリングプラクティス 生成AIの普及 ▸ LLMベースの支援が実務レベルで利用可能になった ▸ 調査、実装、テスト支援、ドキュメント生成など ▸ 調査 ▸ ChatGPT、Gemini、Claudeなど ▸ API/ライブラリ探索の時短 ▸ 実装 ▸ GitHub Copilot、Claude Code、Cursorなど ▸ 実装スピードの桁違いの短縮 ▸ プロトタイピングの高速化 ▸ すでに多くの現場で導入が進み、標準ツールに近づく State of AI-assisted Software Development 2025, p.27 31
32. プロダクトの成長を支える生成AI時代のエンジニアリングプラクティス 32 生成AIによって何が変わったか ▸ 色々あるが…… ▸ 技術的な調査の時間と実装作業の時間が劇的に減少 ▸ 実装がもはや「時間的な」ボトルネックではなくなる ▸ こんな話も ▸ 「今後3〜6カ月以内にソフトウェアエンジニアのコードの90％をAIが書くようになり、今後1年以内に はすべての行をAIが書くようになる」（Anthropic CEO Dario Amodei） ▸ 「技術スキルのないPdMがVibe Codingで作れた！もうエンジニアはいらない」 ▸ 「主語が大きい」事案。3Xで考えるべき
33. プロダクトの成長を支える生成AI時代のエンジニアリングプラクティス 生成AIが作ったコードは変更に耐えられるか？ ▸ 答えはYesでもありNoでもある 33
34. プロダクトの成長を支える生成AI時代のエンジニアリングプラクティス 生成AIが書くコードと「結合」の問題 ▸ 生成AIは局所的最適化を得意とする ▸ → 目の前の関数やクラスを「一貫して動くように」整える ▸ → しかし、システム全体の依存関係や境界の整合性は考慮しない ▸ 結果として以下のようなことが起こりやすい ▸ 似た構造の関数やクラスが横に増える ▸ 局所的に便利な呼び出しが増え、モジュール間の結合が密になる ▸ 依存方向が入り乱れ、修正時の影響範囲が読めなくなる ▸ 元のコードの結合度が高いと、生成AIによって結合がさらに加速する 34
35. プロダクトの成長を支える生成AI時代のエンジニアリングプラクティス （再）生成AIが作ったコードは変更に耐えられるか？ ▸ コードベースのアーキテクチャーがしっかりしていて、SOLIDでCLEANならYes ▸ そうでないならNo 35
36. プロダクトの成長を支える生成AI時代のエンジニアリングプラクティス 生成AIは良くも悪くも加速装置 ▸ 良いアーキテクチャーや良いコードベースであれば、機能開発の効率が加速する ▸ 良くないアーキテクチャーや良くないコードベースであれば、破綻までの速度が加速する 36
37. プロダクトの成長を支える生成AI時代のエンジニアリングプラクティス 身も蓋もない推奨事項 ▸ 生成AIは自身が持つ知識をもとに確率論的にコードを書く ▸ つまり、知識を多く持っている状況をコードベースで作ればよい ▸ ベストプラクティスやフレームワークの採用が優位 ▸ アーキテクチャーパターン、フレームワーク、コーディング規約などを定番に寄せると効果が大きい ▸ コンテキストを圧縮する効果もある ▸ 個人レベルの整頓もチームレベルのリファクタリングもどちらも必要 ▸ モブプログラミングを活用してリアルタイムにレビューする ▸ すなわち「変更容易性」を維持する 37
38. プロダクトの成長を支える生成AI時代のエンジニアリングプラクティス 説明責任は残り続ける ▸ 「AIに作業させたのが原因で問題が起きました」では説明責任は果たせない ▸ 自分たちが作ったものがなぜそうなっているのか、チームは知らなければいけない ▸ 人間が読んで理解できるコードでなければいけない ▸ 何か修正をするときに、なぜその箇所を変更するのか説明できなければいけない ▸ ＝ 手の内化しておかないと、将来のリスクがわからない 38
39. プロダクトの成長を支える生成AI時代のエンジニアリングプラクティス 結局、整頓するのか？リファクタリングするのか？ ▸ 整頓 ▸ 1人で行うもの。開発にAIが使えるようになって、整頓に要する時間がさらに減った ▸ 先に整頓もしくはあとに整頓が圧倒的に優勢に。後回しもしくはやらない理由自体が激減 ▸ ただしテストでガードされていないと無理。とはいえ、テストも生成AIで先に書ける ▸ リファクタリング ▸ チームで取り組むもの。AIで効率化されるものの影響範囲は大きいかもしれない ▸ 影響範囲が大きいほどキャッシュフローとオプションのせめぎあい ▸ 3XのExpandなのかExtractなのかは大きな判断軸 39
40. プロダクトの成長を支える生成AI時代のエンジニアリングプラクティス 時間の使い方を変える ▸ AIから望む結果を得るための 事前作業（コンテキスト整備） の時間を増やす ▸ AIが間違いなく実装できるように、事前のコードの整頓の時間を増やす ▸ （実装の時間は減る） ▸ AIの出力を検証・調整する 事後作業（品質や持続性の維持） の時間を増やす 40
41. プロダクトの成長を支える生成AI時代のエンジニアリングプラクティス 時間が増える要素 ▸ ドキュメントの作成 ▸ アーキテクチャーの設計 ▸ 結合を減らす。SOLID / CLEAN ▸ テストの設計 ▸ コードの整頓やリファクタリング ▸ レビュー（持続可能かどうかを検証し、説明責任を果たす） ▸ そして学習 AIがコードを書く時代において、設計はチームの知性そのもの 41
42. プロダクトの成長を支える生成AI時代のエンジニアリングプラクティス （参考）スクラムの場合のプラクティスの変化 42
43. プロダクトの成長を支える生成AI時代のエンジニアリングプラクティス モブプログラミングによって持続性を維持する 「モブプログラミング = 究極の1個流し」 ▸ 全員で同じ画面を見て作業することで、知識と判断を同期化 ▸ AIへの入力、AIからの出力を全員でレビューし、即座に修正と学習を繰り返す ▸ AIの出力をレビューする人間の脳にも限界がある。結合を減らす理由になる ▸ これによって、品質を作り込み、破綻への加速を防ぐ 43
44. プロダクトの成長を支える生成AI時代のエンジニアリングプラクティス 学習への投資 ▸ 良いアーキテクチャーやドキュメントを生むには、基礎的なコーディング力が欠かせない ▸ しかしAIの進化により、実装経験を通じた学習機会が減少 ▸ 「レビューできる人材をどう育てるか」 が新たな課題 ▸ 組織として、学習と実験のための時間を明示的に確保する必要がある ▸ AIがスピードを上げる一方で、人は方向と構造を学び続ける ▸ 短期の生産性ではなく、長期の知性の持続性こそが競争力になる 44
45. プロダクトの成長を支える生成AI時代のエンジニアリングプラクティス まとめ ▸ 3Xモデルのどの段階かによって、行動原理は異なる ▸ お金の時間価値と変更可能性というオプションは対立する要素になる ▸ 整頓やリファクタリングをなくすことはできない ▸ 使われるソフトウェアにはかならず変更が入る ▸ 変更の支配的なコストは結合。SOLIDやCLEANで結合を避ける ▸ AIの出力はアーキテクチャー（設計）に依存する ▸ その設計力こそがチームの知性の一部であり、投資が必要 ▸ 持続性を確保するためには、AIが出力するコードでも整頓やリファクタリングが必要 45
46. プロダクトの成長を支える生成AI時代のエンジニアリングプラクティス 46 まとめ2 生成AIによって「実装」は加速したが、「設計」「整頓やリファクタリング」「説明」の重要性はむしろ高まった。 プロダクトの持続性を支えるのは、AIの性能ではなく、チームの知性である。

Comment

No comments...