AI駆動開発を妨げる技術的負債の解消アプローチ / ai-refactoring-approach

こちらの登壇資料です。

AI駆動開発を妨げる技術的負債の解消アプローチ
https://levtechlab.connpass.com/event/395968/

Transcript

1. © DMM © DMM AI駆動開発を妨げる 技術的負債の 解消アプローチ 2026/06/30 レバテックLAB 合同会社DMM.com ミノ駆動
2. © DMM 自己紹介 ミノ駆動 ( @MinoDriven ) 合同会社DMM.com プラットフォーム開発本部 第3開発部 • コード品質チーム • PF-AX戦略グループ（兼務） 2
3. © DMM 著書紹介 『改訂新版 良いコード／悪いコードで学ぶ設計入門』 変更容易性の高い設計を学ぶ、 初級〜中級向け入門書 初版は12刷重版 初版：ITエンジニア本大賞2023大賞受賞 改訂版：ITエンジニア本大賞2026ベスト10入り 台湾版、韓国語版でも翻訳出版 3
4. © DMM 4 技術的負債　とは 開発上の何らかの都合による、将来の追加作業コストの総称。 • ドキュメント不足 • 複雑で混乱したコード etc.. 負債が蓄積している状態だと調査に時間がかかったり、 コードを正しく変更できるまでに時間がかかったりします。 同じ規模の機能を開発するにしても、 新規開発と比べて開発コストが増大します。 負債はAIにも悪影響を及ぼします。混乱して正確にコード変更できなく なったり、既存コードの破壊的変更をするケースもあります。
5. © DMM 変更容易性　とは バグをなるべく埋め込まず、素早く正確にコード変更できる度合い。 ソフトウェア品質特性の一種です。 複雑で混乱したコードは、変更容易性の低いコードです。 些細な変更でもバグを埋め込みやすい構造です。 バグを埋め込まないために慎重な検討が必要になり、 正確にコード変更できるまで多大な時間と労力を要します。 つまり技術的負債に対処するには変更容易性を高める設計が必要です。 5
6. © DMM ところでみなさんは 変更容易性の低いコードがどんなコードか 具体的に明瞭に説明できますか？
7. © DMM 7 変更容易性 現状構造 変更容易性の高い 理想構造 現状と理想のギャップが 技術的負債 バグをなるべく埋め込まず 素早く正確にコード変更できる度合い
8. © DMM 8 変更容易性 現状構造 変更容易性の高い 理想構造 理想構造を知らないとギャップを 認識できない！ 技術的負債を認識できない！ 「このコードの一体どこが負債な んですか？これが普通でしょ？」 バグをなるべく埋め込まず 素早く正確にコード変更できる度合い
9. © DMM 9 変更容易性の知識が薄いとどうなるか • そもそも負債を認知できない 「このコードの一体どこが負債なんですか？」となる • リファクタリングしても中途半端になる • 逆にコード品質が悪化してしまうことも • AIにリファクタリングさせても、 結果良くなったのか悪くなったのか判断できなくなる
10. © DMM つまりAIの有無に関係なく 正しくリファクタリングするには 変更容易性の設計スキルが どうやっても必要になります
11. © DMM しかし本セッション約30分で 変更容易性の設計全てを語りきれないですし 習得には実際手を動かす必要があります！
12. © DMM そこで本セッションでは 変更容易性の設計に関する基本的な考え方を踏まえつつ AIを絡めた負債解消の効果的な方法を紹介します
13. © DMM 設計、リファクタリングにおける重要観点 それは「 目的」です
14. © DMM 目的、目標、手段の定義 14 一般的な定義 目的 目指すべき状態、行動のねらい、目当て 目標 目的達成に必要な個々の評価基準、具体条件 手段 目的を達成するための方法や道具
15. © DMM 目的と手段 私たちの活動には、なんらかの目的があります。 そして目的を達成するための手段（行動や方法）を用います。 あらゆる活動が目的−手段の関係で成り立っています。 15 目的 手段 ダイエットしたい 有酸素運動 美味しいものを食べたい 寿司 髪を乾かしたい ドライヤー
16. © DMM 目的と目標 目的の達成について考えてみます。 たとえば「ダイエットしたい」という目的は、 どうしたら達成したと言えるでしょうか。自己満足して終わりですか？ そうではなく体重や体脂肪率について 具体的な条件や基準を定めるはずです。 この具体条件や基準が目標です。 16 目的 目標 ダイエットしたい ・体重を60kgまで減らすこと ・体脂肪率を17%まで減らすこと
17. © DMM 目的−目標−手段 そして目標を満たすために 適切な手段を用います。 目的、目標、手段の関係が右図となります。 17 【目的】 ダイエットしたい 【目標】 ・体重60kgまで減らすこと ・体脂肪率を17%まで減らすこと 【手段】 ・有酸素運動 ・バランスの取れた食事
18. © DMM 目的、目標、手段は、 私たちが開発するソフトウェアでも同じことが言えます。 顧客の要求（目的）を叶えるための手段として、 私たちはソフトウェアを開発しているのです。 18 目的 手段 商品を売買したい ショッピングサイト 動画を視聴したい 動画投稿サイト 遊びたい ゲームソフト 効率良く勉強したい 学習サイト 私たちは「手段」を開発している
19. © DMM 「目標」は要件や仕様に相当する 19 【目的】 注文数を正しく表現したい 【目標】 注文数は1〜200であること 【手段】 目的を満たすソースコード システムを不具合なく的確に機能させるには、 仕様を決める必要があります。 例えば注文数が負数だと不具合になりますし、 5000兆個といった非現実的な数量も 問題があります。 注文数については 出荷業務の都合などを考慮し仕様を決めます。 こうした要件や仕様が目標に相当します。 目標を満たすようにコードを実施します。
20. © DMM 目的、目標、手段は、ソフトウェア開発では次の位置付けと言えます 20 一般的な定義 ソフトウェア開発における位置付け 目的 目指すべき状態、 行動のねらい （顧客の）要求 目標 目的達成の具体条件 機能要件、仕様、制約 手段 目的達成に用いる 方法や道具 ソースコード
21. © DMM 変更容易性を高めるには この「目的−目標−手段」の枠組みで 一貫性のある構造を設計する必要があります どういうことでしょう？
22. © DMM 22 // 注文明細クラス class OrderItem { int orderItemId; int orderId; int productId; int unitPrice; int quantity; // 注文数 } たとえばショッピングサイトにおける「注文」を考えてみます。 注文明細クラスを次のように実装したとします。 quantityは注文数です。
23. © DMM 23 orderItem.quantity = -1; この構造には問題があります。 マイナス注文数といった不正な値を代入できてしまいます。
24. © DMM 24 class Validator { boolean isValidQuantity(OrderItem orderItem) { return 1 <= orderItem.quantity && orderItem.quantity <= 200; } } 正しい注文数だけを受け付けられるよう、 次のようなバリデーションをどこかに実装するかもしれません。 しかしこの実装では、以下のような問題が生じる可能性があります。 • バリデーションを呼び忘れるとバグになる • 別の箇所に重複したコードが実装される可能性 • 注文数の仕様変更時、あちこち探し回らなければならない
25. © DMM 25 【目的】 注文数を正しく表現したい 【目標】 注文数は1〜200であること 【手段】 OrderItem.quantity 【手段】 Validator.isValidQuantityメソッド 目的に対して手段がバラバラになっているのが原因 家電に例えるとドライヤーがバラバラに提供されているような状態
26. © DMM 26 【目的】 注文数を正しく表現したい 【目標】 注文数は1〜200であること 【手段】 Quantityクラス バラバラにしない 目的を一貫して達成できるようひとまとめにする それがカプセル化
27. © DMM 27 class Quantity { private static final int MIN = 1; private static final int MAX = 200; final int value; Quantity(final int value) { if (value < MIN || MAX < value) { throw new IllegalArgumentException("注文数は1以上200以下で指定してください"); } this.value = value; } Quantity add(final Quantity other) { return new Quantity(value + other.value); } } カプセル化とはデータとそのデータを操作するロジックをひとま とめにすること。これで正しい注文数を確実に表現できる。
28. © DMM 28 【目的】 今すぐ注文したい 【目的】 予約したい 【目的】 商品の抽選に応募したい 【手段】 注文クラス 【目標】 即時注文に関する要件 【目標】 予約注文に関する要件 【目標】 抽選注文に関する要件 さまざまな目的のコードがひとつのクラスに混在している状態
29. © DMM 29 【目的】 今すぐ注文したい 【目的】 予約したい 【目的】 商品の抽選に応募したい 【手段】 即時注文クラス 【目標】 即時注文に関する要件 【目標】 予約注文に関する要件 【目標】 抽選注文に関する要件 手段（クラス）に対して目的がひとつになるよう設計する 【手段】 予約注文クラス 【手段】 抽選注文クラス
30. © DMM 目的と手段（クラス）に一貫性のある構造が 変更容易性の高い構造と言えます 逆に一貫性に問題のある構造が負債と言えます
31. © DMM つまり技術的負債を解消するには コードの目的を理解する必要があります
32. © DMM AIはコードリーディングが得意 可読性の悪いコードを人間が理解するのは非常に骨が折れます。 一方でAIはパターン認識が得意。 多少可読性が悪いコードであっても高速に意図を推論します。 「このコード（ファイル）の目的を分析して」 とAIに指示しましょう。 なぜならコードそれぞれには目的があるからです。 目的観点で意味を推論してくれます。 対象コードに関して何か知っていることやドキュメントがあるなら、 それらを渡した上で指示するとさらに分析精度が高まります。 32
33. © DMM 名前の改善をAIに提案させよう 可読性に問題のあるコードは、変数やメソッドの名前に問題があります。 放置しておくと人間にもAIにも良くありません。 「より目的が明確な名前を提案して」とAI指示しましょう。 目的がより分かる可読性の高い名前を提案してくれます。 ただし名前変更をAIにやらせてはいけません。 依存箇所の探索にトークンと時間を爆発的に浪費します。 エディタやIDEのリファクタリング機能で名前変更しましょう。 静的型付け言語であれば正確かつ一瞬で変更できます。 33
34. © DMM このようにコードの目的を分析しながら 名前改善して可読性を高めていき 少しずつ理解を深めていきます
35. © DMM AIにテストコードを実装させよう 安全にリファクタリングする上でテストコードは必須です。 AIはパターン認識が得意なので、テストコードの実装も得意です。 AIに次のように指示することで、 網羅性のあるテストコードを高精度で実装してくれます。 agent skill化して再利用できるようにするのが良いでしょう。 35 以下「## 要件」を満たすようにテストコードを実装せよ ## 要件 - 事前条件、事後条件、不変条件を検証するテストであること - Given-When-Then構文で記述すること
36. © DMM 純粋関数を抽出しよう 関数の副作用とは、関数外部の状態を変更することです （I/O操作、インスタンス変数の変更など）。 副作用があると実行のたびに結果が異なる、 予測が困難といった弊害が生じます。 副作用があるコードとないコードの分離隔離が重要です。 入力を受け取り結果を戻り値として返すだけの副作用のない関数を 純粋関数と呼びます。 AIはパターン認識が得意なので、 純粋関数として抽出可能なロジックの候補を分析させることができます。 36
37. © DMM 純粋関数を抽出しよう 次のように指示します。 ただし抽出はAIではなく、エディタやIDEのリファクタリング機能「メソッド 抽出」でやりましょう。正確かつ一瞬で抽出できます。 抽出した関数に対してAIでテストコードを書きましょう。 抽出した関数の戻り値がドメインロジックの値である場合、 Value Objectなどのドメインオブジェクトへ関数を統合できます。 37 純粋関数として抽出可能なロジックの候補を列挙してください。 どんな関数として抽出できるか提案してください。 関数名は目的が分かる名前であること。
38. © DMM 38 【目的】 今すぐ注文したい 【目的】 予約したい 【目的】 商品の抽選に応募したい 【手段】 注文クラス 【目標】 即時注文に関する要件 【目標】 予約注文に関する要件 【目標】 抽選注文に関する要件 目的（関心）が混在したクラスを
39. © DMM 39 【目的】 今すぐ注文したい 【目的】 予約したい 【目的】 商品の抽選に応募したい 【手段】 即時注文クラス 【目標】 即時注文に関する要件 【目標】 予約注文に関する要件 【目標】 抽選注文に関する要件 各目的ごとに分離するにはどうすればいいか 【手段】 予約注文クラス 【手段】 抽選注文クラス
40. © DMM 40 注文クラス 即時注文用の処理 全注文共通処理 全注文共通処理 即時注文用の処理 予約注文用の処理 抽選注文用の処理 全注文共通処理 抽選注文用の処理 予約注文用の処理 複数の目的のコードが混在するクラスは、この図のように 共通処理と各目的専用の処理が入り乱れています。
41. © DMM 41 予約注文クラス 即時注文用の処理 全注文共通処理 全注文共通処理 即時注文用の処理 予約注文用の処理 抽選注文用の処理 全注文共通処理 抽選注文用の処理 予約注文用の処理 即時注文、予約注文、抽選注文の各目的ごとのクラスを作ります。 これらに元の注文クラスのコードを全コピーします。 即時注文クラス 即時注文用の処理 全注文共通処理 全注文共通処理 即時注文用の処理 予約注文用の処理 抽選注文用の処理 全注文共通処理 抽選注文用の処理 予約注文用の処理 抽選注文クラス 即時注文用の処理 全注文共通処理 全注文共通処理 即時注文用の処理 予約注文用の処理 抽選注文用の処理 全注文共通処理 抽選注文用の処理 予約注文用の処理
42. © DMM 42 予約注文クラス 全注文共通処理 全注文共通処理 予約注文用の処理 全注文共通処理 予約注文用の処理 目的とは無関係な処理を削除します。 例えば即時注文クラスからは予約注文と抽選注文の処理を削除します。 即時注文クラス 即時注文用の処理 全注文共通処理 全注文共通処理 即時注文用の処理 削除 全注文共通処理 抽選注文クラス 全注文共通処理 全注文共通処理 抽選注文用の処理 全注文共通処理 抽選注文用の処理 削除 削除 削除 削除 削除 削除 削除 削除 削除 削除 削除
43. © DMM 43 予約注文クラス 即時注文クラス 抽選注文クラス 共通処理A用クラス 共通処理B用クラス この手法では元々共通で実行していた処理が重複します。 共通化可能なものはクラスとして抽出し、呼び出す形にします。 ただし、共通化して良いのは目的が同じコードだけです。 見た目同じでも目的が違うコードを共通化すると変更に弱くなります。
44. © DMM この「コピーして不要なコードを削除する」リファクタリング、 シンプルながら無茶苦茶強力です 弊社DMMでも実績があります 負債の酷いプロダクトには 必ずこの手の巨大クラスがいます ぜひ試してみてほしいです
45. © DMM 45 ドメインモデリング 変更容易性に問題のあるプロダクトでは、 ドメインモデルを設計していないケースがとても多いです。 変更容易性の高い構造がリファクタリングのゴールです。 ゴールとなる構造がどういう構造か見定めるためにも、 ドメインモデリングが有効です。
46. © DMM イベントストーミング モデリング手法のひとつ。 出来事の流れを整理することで、集約（ドメインモデル）を導出します。 リファクタリング対象の機能に関し、PRDやユースケースをinputにして、 イベントストーミングで出来事を整理し集約を導出しましょう。 （※詳しいやり方は割愛します） 46 https://www.qlerify.com/post/event-storming-the-complete-guide より引用
47. © DMM ドメインモデリングでは必ず制約を設計すること ドメインモデルは一貫性や整合性のあ るデータを作成/更新するのに使う「更 新モデル」です。 制約がないと「マイナス注文数」といっ た不整合が発生し不具合となります。 箱とデータだけ作って満足せず、制約 を必ず設計してください。 47 https://logmi.jp/main/technology/322835 より引用 制約
48. © DMM 効率良く制約を洗い出す方法については ミノ駆動の過去のスライド 『破壊せよ！データ破壊駆動で考えるドメインモデリング』 が役立ちます https://speakerdeck.com/minodriven/data-destroy-driven
49. © DMM ちなみに弊社DMMでは イベントストーミングもドメインモデリングも agent skill化しております （他さまざまな設計工程も）
50. © DMM ストラングラーフィグパターン 旧モジュールを新モジュールに段階的に置き換える方法。 複雑なコードを変更するより、新規にコードを書く方がAIは得意です。 複雑な既存コードを無理に変更するリファクタリングではなく、 クリーンなモジュールへ段階的に置き換えていくのが効率的でしょう。 ドメインモデリングと併せて実施するのが有効です。 50 old module new module old module new module old module new module
51. © DMM 51 本セッションで解説した内容だけが設計ではありません 拙著『良いコード／悪いコードで学ぶ設計入門』などで 設計の学びを深めていきましょう
52. © DMM 52 今月発売されたこちらの書籍は ドメイン駆動設計の観点でリファクタリングするテクニックを解説！ ぜひお手にとってはいかがでしょうか
53. © DMM ご清聴ありがとうございました