AI時代の『改訂新版 良いコード／悪いコードで学ぶ設計入門』 / ai-good-code-bad-code

Transcript

1. © DMM © DMM AI時代の 『良いコード／ 　悪いコードで学ぶ設計入門』 2025/07/10(木) 合同会社DMM.com ミノ駆動

2. © DMM 自己紹介 ミノ駆動 ( @MinoDriven ) 合同会社DMM.com プラットフォーム開発本部 第3開発部

   DeveloperProductivityGroup DMMプラットフォームの設計を改善し 開発生産性向上を図るのがミッション 2

3. © DMM 著書紹介 『改訂新版 良いコード／悪いコードで学ぶ設計入門』 変更容易性の高い設計を学ぶ、 初級〜中級向け入門書 初版は12刷重版 ITエンジニア本大賞2023技術書部門大賞受賞 台湾版、韓国語版でも翻訳出版

   3

4. © DMM リファクタリングアンチパターン記事書きました Software Design 2025年8月号 『アンチパターンから学ぶ適切なリファクタリング 破壊せよ！リファクタリングの地雷原』 アンチパターンから、リファクタリングの正確性や コスト効率を高める考え方を学ぶ内容です

   2025年7月17日(木)発売 4

5. © DMM 『改訂新版　良いコード／悪いコードで学ぶ設計入門』 改訂内容の解説

6. © DMM 7つのリニューアル！ 1. 【変更】凝集度、結合度からカプセル化、関心の分離へ 2. 【加筆】インターフェースと実装の分離 3. 【変更】interfaceの解説を改善 4.

   【加筆】インターフェースと実装の分離にもとづいたinterface設計 5. 【加筆】アンカリング効果 6. 【加筆】ジョシュアツリーの法則 7. 【加筆】説明による設計スキルアップ 6

7. © DMM 【変更】凝集度、結合度からカプセル化、関心の分離へ 凝集度と結合度を一切使わない説明に書き直しました。 凝集度を高めたり、結合度を下げても、 変更容易性が高いとは言えないケースがあるからです。 凝集度、結合度で解説していた内容は、 カプセル化と関心の分離へ全面的に置き換えました。 7

8. © DMM 凝集度が高くても変更容易性が低いケース 8 class Util { // このaddメソッドは機能的凝集の構造 //

   しかしMoneyクラスに定義されていないので変更容易性は低い static Money add(Money money1, Money money2) { if (!money1.currency.equals(money2.currency)) { throw new IllegalArgumentException("通貨単位が違います。"); } Money added = new Money(); added.amount = money1.amount + money2.amount; added.currency = money1.currency; return added; } } // 金額を表現するクラス class Money { int amount; // 金額値 Currency currency; // 通貨単位 }

9. © DMM 結合度を下げると変更容易性が悪化するケース 9 DDDにおける集約構造

10. © DMM 結合度を下げると変更容易性が悪化するケース 10 杓子定規に依存を減らすと変更容易性や整合性維持に問題が生じる

11. © DMM カプセル化と関心の分離で一貫性のある解説に 強く関係し合うものどうしをカプセル化する、 関係の弱いものどうしを分離する、これで一貫性のある内容に改善！ 11

12. © DMM 【加筆】インターフェースと実装の分離 関心の分離に関する追加コンテンツです。 トランザクションスクリプトパターンで書かれた長大なメソッドは、 多くの関心が混在しており、保守や変更が困難です。 こうした問題の解決に有用なのがインターフェイスと実装の分離。 モジュールをインターフェイスパートと実装パートに分ける考え方です。 この考え方に基づいて設計することで、関心を上手く分離できます。 12

13. © DMM 【変更】interfaceの解説を改善 switch文の弊害を解消するため interfaceをぜひ使いこなせるように なってほしいと思い、初版でinterface 設計ノウハウを記述しました。しかし反 応がイマイチだった感触。 「interfaceで機能を取り換える」とい う表現を用いて、より理解しやすい内容

    に改善しました。 13

14. © DMM 【加筆】インターフェースと実装の分離にもとづいたinterface設計 interfaceを使いこなせるようになるには、やはりイチからinterfaceを 使って機能開発できるようになるのがポイント。 interface設計でも有用なのが、前述したインターフェイスと実装の分離 です。この考え方に基づいて、イチからinterfaceを設計するノウハウを加 筆しました。 14

15. © DMM 【加筆】アンカリング効果 クラスやメソッドへの命名は可読性だけではなく、 構造も大きく左右します。 適切に名前を設計することで構造が改善します。 この名前設計のノウハウに、 アンカリング効果に関するトピックを追加しました。 アンカリング効果とは認知バイアスの一種。 思い込みによって上手く名前を改善できないケースがあります。

    アンカリング効果から抜け出し、適切な名前を設計する方法を解説します。 15

16. © DMM 【加筆】ジョシュアツリーの法則 名前設計には、ジョシュアツリーの法則についても加筆しました。 ジョシュアツリーの法則とは、名前を知って初めて存在を知覚できるよう になるという認知法則です。 名前を知っているか、知らないかで、構造はガラリと変わります。 ジョシュアツリーを踏まえた名前設計のノウハウを解説します。 16

17. © DMM 【加筆】説明による設計スキルアップ 設計スキルを高めるには、単に本を読むだけでなく、 実際に手を動かすなど試行錯誤が必要です。 こうした試行錯誤で重要なのが、人に設計を説明することです。 人に説明すると学びが深まります。 ただ闇雲に説明するのではなく、 設計スキルを効率的に高めるための説明の仕方や、 背景にある考え方を解説します。

    17

18. © DMM 生成AIと 設計品質の関係

19. © DMM 【ミノ駆動の所感】 素の状態では 多くの状況において 生成AIには設計品質の期待ができない

20. © DMM 【環境】 Cursor + Claude 4 sonnet 【以下の品質について検証】 •

    技術的負債の分析 • リファクタリング • テストコード実装 20

21. © DMM 技術的負債の分析 【指示の仕方】 「このコードの技術的負債を分析して」と雑に指示 【所感】 • 多すぎる行数やネスト、依存関係についてはそれなりに指摘。 • ミノ駆動本記載の観点のうち、10-25%程度しか検出できない。

    • 的外れな分析もそれなりにある。 21

22. © DMM リファクタリング 【指示の仕方】 「このコードをリファクタリングして」と雑に指示 【所感】 • リファクタリング対象となるのは負債分析と同様。 ミノ駆動本記載の観点の内10-25%しかリファクタリングできない。 •

    多くの実践者の報告にある通り、 リファクタリングが終わらなかったり、 正しくリファクタリングできないケースがある。 22

23. © DMM テストコード実装 【指示の仕方】 「このコードにテストコードを実装して」と雑に指示 【所感】 • テストコードの実装は得意らしく、 雑な指示でもそれなりの品質のテストコードを書いてくれる。 •

    テストケースのヌケモレはたびたび発生する。 • 複数の要件を検証するテストケースを実装することがある （このようなテストは仕様変更に脆い）。 23

24. © DMM 質の悪い内容を学習している可能性 生成AIはネット上のさまざまなコード（OSS, 技術記事 etc..）を 学習しています。 ネット上のコードには高品質なものもありますが、 一方で残念ながら品質の良くないものも存在します。 生成AIは学習内容の平均に収斂していく性質があるとのこと。

    質の良くない学習が悪影響を及ぼしている可能性が考えられます。 24

25. © DMM 言葉の汚染（意味の希薄化） 生成AIの原理は「連想」。 ある特定の単語に別の単語が強く関連付いているために、 回答が不正確になるケースがあります。 25 言葉 ハルシネーションの例 リファクタリング、

    技術的負債、 変更容易性 指示していない「責務」という観点を持ち出してくる。 AI自身もよく分かっていないようで、負債の分析や改 善提案の正確性が悪化する。 ドメイン駆動設計 非推奨なDomainServiceを頻繁に提案してくるように なる。鵜呑みにすると品質が悪化する。 このような現象を言葉の汚染とミノ駆動は呼んでいます。

26. © DMM AIの原理が劇的に変わらない限り 設計の質を手放しでAIにお任せするのは困難です 人間側が適切にコントロールする必要があります

27. © DMM 的確な指示により AIによる設計の質が上がります いくつか例を紹介します

28. © DMM 負債分析プロンプト「バグサーチャー」 静的解析ツールでは分析困難な技術的負債を高精度で分析する、 AIエージェント用のプロンプト群。 変更容易性に関するさまざまな観点をプロンプトとして実装。 私の思考を模倣するようなプロンプトとなっています。 現状は Cursor +

    claude-4 で動作。 今後どのAIエージェントでも汎用的に使えることを目指しています。 （近いうちにMCPサーバー化する予定） 28

29. © DMM 29 競争力に影響するのでプロンプトは企業秘密です。 ですが参考情報として、このあたりの書籍の知見が ベースになっています。

30. © DMM 30 分析結果（一部抜粋）

31. © DMM 31 静的解析ツールとの負債分析観点比較 静的解析ツールは「コードの意図」がわかりません。 一方、生成AIは意図を推論できます。 生成AIだからこそ可能な負債分析です。 一般的な静的解析ツールの分析観点 コード行数 サイクロマチック複雑度

    コード重複 引数の数 etc.. バグサーチャーの分析観点 カプセル化 ドメインロジックの関心の分離 ドメインモデル完全性 技術レイヤ間の関心の分離 各設計パターン毎の設計要件 interface設計 etc..

32. © DMM スケールする負債分析の質と量 例えば約400行ほどのソースコードの負債を洗いざらい分析する場合 • ミノ駆動の目視 : 約15〜30分（ドメイン知識に依存） • バグサーチャー

    : 約1分 私は変更容易性やリファクタリングを専門としていますが、 私とほぼ同等の精度で、かつ10倍以上の生産性で分析できています。 しかも誰でもバグサーチャーを使えるので、 お手軽に「ミノ駆動の分身」を増やせる体制に。 変更容易性の専門知識のおかげで実現できたと言えます。 32

33. © DMM 契約による設計とテストコード 契約による設計とは、正確性の向上を目的に バートランド・メイヤー氏が考案した設計の方法論。 以下の3条件から構成されます。 • 事前条件：メソッド開始時に保証されるべき条件 • 事後条件：メソッド終了時に保証されるべき条件

    • 不変条件：常に維持されるべき条件 モジュールの機能適合性を保証するテストはこの3条件の検証が基本。 つまり生成AIに高品質なテストコードを実装させるには、 契約による設計を踏まえる必要があります。 33

34. © DMM 契約による設計に基づくプロンプト実装 34 # 役割 あなたは以下の専門家である - テストコード -

    契約による設計（事前条件、事後条件、不変条件） # 目的 テストコード実装 # 制約 - メソッドの事前条件、事後条件、不変条件を検証するテストであること - Given-When-Thenパターンに基づいて実装すること # テスト対象 （ここにテスト対象のメソッドを指定する）

35. © DMM 動作結果の一例 35 Cursor + claude-3.7-sonnet 『改訂新版　良いコード／悪いコードで学ぶ設計入門』記載のコードに対し実施

36. © DMM スケールするテストコード実装の質と量 約100行のコードにテストを書く場合、分析も含めて • ミノ駆動の実装 : 20-60分??（ドメイン知識に依存） • 前述のプロンプト:

    1分以内 数十倍のオーダーで高速化！ 抜け漏れもなく、テストと検証対象が1:1になっているので、 テストコードの品質も良好。 36

37. © DMM AI時代もソフトウェア設計の原理原則しか勝たん AIは迷走や暴走しがちだし、 品質面のノウハウが確立されているとは言い難い。 AIによる開発高速化に伴い負債の加速度的増加が懸念される。 ソフトウェアエンジニアリングの手綱を握るのは人間。 ソフトウェア設計の原理原則を学び、 AI駆動開発に活かす必要がある。 AI時代であってもそうでなくとも、

    ソフトウェア設計の原理原則の重要性はなんら変わらない。 37

38. © DMM ご清聴ありがとうございました