現場で役立つ技術負債の効果的な返済方法

#技術的負債con_findy

①技術的負債の何が問題か？
②限られた時間の中でどう取り組むか？
③既存のコード改善：実践編
④データベースの設計改善：効果と課題

Transcript

1. #技術的負債con_findy 現場で役立つ 技術的負債の効果的な返済方法 2026年9月17日 有限会社システム設計 増田 亨
2. 自己紹介 著書(2017) ＊１ 増田 亨（masuda220） 専門領域 訳書(2024) • 業務系アプリケーションの開発 ＊2 最近の仕事 • 大きな泥団子退治のお手伝い • エンジニアの設計スキル向上のお手伝い *1 増田 亨(2017) 『現場で役立つシステム設計の原則』技術評論社 *2 Vlad Khononov(著) 増田 亨、綿引 琢磨(訳) 2024 『ドメイン駆動設計をはじめよう』オライリージャパン 2
3. お話しする内容 ① 技術的負債の何が問題か？ ② 限られた時間の中でどう取り組むか？ ③ 既存のコード改善：実践編 ④データベースの設計改善：効果と課題 3
4. ①技術的負債の何が問題か？ 4
5. 技術的負債によって起きること ✓ どこに何が書いてあるかを理解するのがたいへん ✓ 一つの修正のために、あっちもこっちも書き直す必要 がある ✓ ちょっとした変更のはずが、本来はありえない場所に まで影響し、大幅なやりなおしになる 5
6. 何が現実的な問題か？ ✓ 変更がやっかいで危険 ✓ 変更に時間がかかる（かかりすぎる） ✓ その場しのぎの対応 ⇒ さらに状況が悪化 ✓ 変更が怖い ⇒ 変更を避ける ⇒ さらに状況が悪化 6
7. やるべきことは決まっている リファクタリング！ 既存コードの設計改善を続ける ➢ 機能追加を楽にするために設計改善を続ける ➢ 不具合を修正するために設計改善を続ける ➢ デッドコードを見つけたら削除する ➢ タイポを見つけたら修正する 7
8. やるべきことが、なぜできていないか？ できていれば、技術的負債は残らないはず • 時間が足りない • 基本的なスキルが身に付いてない • 経験不足（練度が足りない ⇒ やるのが面倒＆不安） 8
9. 時間が足りない？ 負債を残したままの作業時間 ＞ リファクタリングに使う時間 ＋ 設計改善後の作業時間 このメンタルモデルを共有する 9
10. リファクタリングに使う時間 • 基本スキルを習得すれば、時間はかかならない • 練度が上がれば、もっと時間がかからない • スキル不足 ⇒ やってみることでスキルが身に付く • 練度不足 ⇒ やり続けることで練度が上がる 10
11. 教訓① やってみること 教訓② やり続けること やらないから、基本のスキルが身に付かない 続けないから、練度があがらない 11
12. それでも時間は足りない • リファクタリングをすると効果がありそうな場所はい くらでもある • 現実のソフトウェア開発で、すべてに手をだすことは 無理 だから • 効果が大きい場所に絞り込んでリファクタリングする • 少ない時間の回数を増やす（一定の方向性を保つ） 12
13. 管理者の承認？ • リファクタリング（設計改善）をやる理由は、機能追 加や不具合修正の準備作業 • 準備作業だけを切り分けて承認を得るようなものでは ない • スキルを習得し、練度を上げる取り組みの承認？ 13
14. AIの活用 ⚫ ＡＩにコード状態の下調べや、設計改善の提案をさせ るのは役に立つことが多い ⚫ その情報を参考に、自分（たち）でコードを理解して、 実際のコード変更を行う ⚫ 数行の変更程度であれば、良いと判断できれば、ＡＩ の提案をそのまま受け入れてもよい ⚫ もっと広い範囲、複数個所に変更が及ぶ場合は、ＡＩ による一括修正は、私はやらない（やらせない） 14
15. ②限られた時間の中でどう取り組むか？ 15
16. 非効率で効果が小さいやり方 すべての機能追加、不具合修正に、一律に一定の時間を 使う設計改善（リファクタリング）は悪手 ✓ どこも十分な時間が使えない ✓ どこも本格的な改善に取り組めない ✓ どこも改善効果が小さい 16
17. 効率的で効果の大きいやり方 ➢ 技術的負債の中でも、諸悪の根源みたいになっている ところ見極めて、そこを集中的に改善する ➢ 諸悪の根源は、あちこちに悪影響が及んでいるので、 いちどに解決するのは無理筋 ➢ 改善の方向性を見定めて、実際の改善は、機能追加時、 不具合修正時に直接関係する場所に特化して進める 17
18. 準備編（初期投資） リファクタリングの基本的な知識とスキル ✓ tidy first 本とリファクタリング本を手元に置く ✓ リファクタリング本の最初の例を使って、基本のリファ クタリング（チャンキング、名前の変更、説明用変数、 メソッドの抽出、クラスの抽出）の一日研修 実験環境の構築（実験の奨励） ✓ 基本のリファクタリングを実コードで体験学習 ✓ ブランチ作って、破壊的なリファクタリングを実験 ✓ テストは不要（コンパイルOK/NGで十分） 18
19. ③既存のコード改善：実践編 19
20. 諸悪の根源の見つけ方 「区分」に焦点を合わせる 特に以下の点に注目 • どの区分か判断する区分判定ロジックが複雑 • 区分ごとに適用するビジネスルールが複雑 • 区分の要素数が多い 20
21. 区分に焦点を合わせる理由 • 複雑なロジックの記述箇所を確実に特定できる • ロジック記述の重複、散在、不整合を検出できる • 負債の具体的な姿をコードレベルで認識合わせできる • 業務の理解度が上がる 21
22. 複雑なロジックの記述箇所の特定 ✓ どの区分に該当するかを分類する区分判定ロジック ✓ 区分によって適用するビジネスルールを切り替える業 務ロジック ✓ 入出力手続きに断片的に埋め込まれていることが多い ✓ 区分判定ロジック、適用ルールの切り替えロジックが、 あちこちに散在して記述され、重複や不整合が起きて いるのが技術的負債の中心であることが多い （ここを整理すれば確実に技術的負債は減る） 22
23. 技術的負債の実際の姿の認識合わせ ✓ 時間経過とともに肥大化した区分 ✓ どの区分にあてはまるかを判断する区分判定ロジック も肥大化 ✓ 区分によって適用するビジネスルールを切り替える業 務ロジックも肥大化 ✓ 積み重なった技術的負債を目に見える形で特定できる （すでに意味がない区分、複数の関心事が無秩序に混 在した区分、読み替えられた区分、…） 23
24. 業務の理解度があがる ✓ 区分、判定ロジック、適用ルール切り替えロジックが 時間の経過とともに肥大化するのは、そこが、ビジネ スの関心が強い領域であり、かつビジネス環境やビジ ネスのやり方の変化を反映している可能性が高い ✓ なぜその区分が必要か、なぜそういうロジックで区分 を判定するか、なぜ区分ごとにビジネスルールの適用 を切り替えるかを分析し理解する効果は大きい （まちがいが減る、補完が効く、予測できる、納得感、…） 24
25. 区分整理の進化モデル 第一形態 暗黙の区分 （無名区分） 第二形態 区分定数 区分の番号化（原始的な構造化） 第三形態 区分名 区分の意味の明示、意味的構造化の第一歩 第四形態 第五形態 if文で記述された分岐構造 カプセル化 区分名の列挙、区分ごとの定数とロジックを一箇 所に集める 意味的構造化 区分名の並びの不整合、定数構造やロジック構造 の不整合 ⇒ 関心を分離し整合性を向上させる 25
26. 第一形態：暗黙の区分 if (信号が赤）｛ 止まる()； ｝else { 進む()； ｝ 26
27. 第一形態：暗黙の区分 if (信号が赤）｛ 止まる()； ｝else { 進む()； ｝ そして泥沼へ… • 黄色と緑を追加して • 黄色の点滅と赤の点滅を追加して • 点灯していない場合を追加して • 歩行者用信号（緑の点滅）を追加して • 自転車が車道走行か歩道走行かを追加して … 27
28. 第二形態：区分定数（原始的な構造化） int 信号番号; String action = switch (信号番号）｛ case 1 -> “止まる”； // 赤 case 2 -> “注意して進む”； // 黄 case 3 -> “進む”； // 緑 default -> “番号が不正”； //ここにはこないはず ｝; 28
29. 第二形態：区分定数（原始的な構造化） int 信号番号; String action = switch (信号番号）｛ case 1 -> “止まる”； // 赤 case 2 -> “注意して進む”； // 黄 case 3 -> “進む”； // 緑 default -> “番号が不正”； ｝; これが変更に強い設計だ！ 要素の追加が楽で安全 29
30. 第三形態：区分名 enum 信号 {赤,黄,緑} String action = switch (信号）｛ case 赤 -> “止まれ”； case 黄 -> “注意して進め”； case 緑 -> “進め”； ｝; 30
31. 第三形態：区分名 enum 信号 {赤,黄,緑} String action = switch (信号）｛ case 赤 -> “止まれ”； 大きな進歩 case 黄 -> “注意して進め”； case 緑 -> “進め”； ｝; データとロジックは分かれて いるが、区分定義への参照を 手がかりに、ロジックの記述 場所を特定できる 31
32. 第四形態：カプセル化（集めて整理） enum 信号 { 赤(“止まれ”）, 黄(“注意して進め”）, 緑(“進め”）; String message; String action() { return message; } } 32
33. 第四形態：カプセル化（集めて整理） enum 信号 { 赤(“止まれ”）, 黄(“注意して進め”）, 区分名を一箇所に集めて並べる 緑(“進め”）; String message; 区分ごとのリテラル（即値）を抽象化 String action() { 区分ごとのロジックを抽象化 return message; } } ロジックの散在・重複・不整合を解消する特効薬 33
34. 第四形態：カプセル化（集めて整理） enum 信号 { 赤(“止まれ”）, 黄(“注意して進め”）, 緑(“進め”）; 区分定義、定数、ロジックを一箇所に 集めて整理 散在、重複、不整合の解消の特効薬 意味的構造化の出発点 String message; String action() { return message; } } 参考図書 特に １章 小さくまとめてわかりやすく ２章 場合分けのロジックの整理 ３章 業務ロジックをわかりやすく整理 34
35. 第５形態：意味的構造化 enum 信号{ 赤、 赤の点滅、 黄、 黄の点滅、 緑、 緑の点滅、 点灯していない } if (車両), if(歩行者）, if(自転車）, … 35
36. 第５形態：意味的構造化 enum 信号{ 赤、 // ガード節 if (信号が点灯していない）｛ 赤の点滅、 黄、 黄の点滅、 緑、 return “一旦停止して、まわりに十分注意して進め”； ｝ enum 車両信号{ 緑の点滅、 点灯していない } if (車両), if(歩行者）, if(自転車）, … enum 自転車走行{ 赤、 赤、 車道、 赤の点滅、 緑の点滅、 自転車専用、 黄、 緑 歩道 黄の点滅、 緑 } enum 歩行者信号{ ＋定数とロジック } } ＋定数とロジック ＋定数とロジック 36
37. 一般的な区分と独自の区分 交通信号は「一般」ルールに基づく区分。 ロジックの複雑さはあるが、誰もが同じように判断し行 動する 競争優位を生み出すのは、企業独自の区分 技術的負債を返済するために、もっとも効果的な場所が、 企業独自の区分に関する区分判定ロジック、ビジネス ルール適用を切り替える業務ロジック 37
38. 技術的負債の効果的な返済方法 ✓ 区分判定や業務ロジックの切り替えが複雑な区分に焦 点を合わせる ✓ 区分名の列挙、区分ごとのリテラル（即値）、区分ご とのロジックを一箇所に集めて整理（カプセル化） ✓ 競争優位を生み出す、中核の区分とロジックの意味的 な構造化に取り組む（事業目的適合性の向上） 38
39. 他社と同じ 自社独自 一般の 業務領域 中核の 業務領域 基本的な 業務領域 補完的な 業務領域 ロジック の複雑さ 競合他社との差別化 39
40. 技術的負債を効果的に返済するための参考図書 ソフトウェアの実装と事業戦略を結び つけるさまざまな経験則 特に 11章 設計を進化させる 13章 現実世界のドメイン駆動設計 付録 事例研究 40
41. ④データベースの設計改善 41
42. データベースの設計改善 密結合の巣窟（大きな技術的負債、返済効果は大きい） 実際に変更するのは難しいかもしれない 最大の障壁はメンタルモデル、結果として基本スキルと 練度の不足 42
43. 教訓① やってみること 教訓② やり続けること やらないから、基本のスキルが身に付かない 続けないから、練度があがらない 43
44. データベースの設計改善で 何をやってみると効果的か？ 何を続けると効果的か？ 44
45. 基本的なアプローチ 1. 関心が分離できていないテーブルは諸悪の根源である ことを理解する 2. 関心を分離するためのテーブル設計技法を知る 3. 小さく実験 ⇒ やり方を練習する、効果の感触を得 る、問題の大きさを実測する 4. 効果を期待できるところを探し、やってみる 5. やり続ける 45
46. 関心を分離できていないテーブル群 • 目的、用途が混在しているので、テーブルやカラムの 意図が不明 • 間違った使い方、無理な使い方 • 不必要な競合、性能劣化 • 変更がやっかいで危険 • その場しのぎの積み重ね ⇒ 状況がますます悪化 46
47. テーブル設計 関心の分離 三原則 ➢ 発生時点が異なるデータは別テーブルに分ける ➢ すべてのカラムは確定データのみにする（NOT NULL) ➢ データ範囲を制限する（狭いデータ型、CHECK制約） 47
48. 技法：事実の記録と状態保持を分離する • 起きた事実を正確に記録する • 事実を記録するテーブルとは「別に」現在の状態を保 持するテーブルを作っても良い • 状態は、事実の記録から導出可能 • 状態（＝キャッシュ）があった方が便利なことは多い 48
49. 事実の記録テーブル event / history 状態の保持テーブル status / summary 増加した/減少した 残高 状態を遷移させた 有効-無効-保留などの有限状態 ToDoが発生、Doneになった 約束リスト（行動待ち） 関係の発生、関係の終了 現在の関係（担当、配属、…） 地点 現在地点 理論的には、状態は事実の記録から導出可能 49
50. どこから手をつけるか？ 競争優位を生み出す部分（中核の業務ロジック）に関連 する、データに焦点を合わせる ✓ どの区分に該当するかを判断するためのデータ ✓ 区分ごとの適用するビジネスルールを表現するデータ ✓ 区分ごとのビジネスルールを適用した結果を表現する データ 50
51. 大きなシナリオ ① テーブルの分割（発生時点、事実の記録と状態保持） ② スキーマの分割（論理的なモジュール化） ③ データベースの分割（物理的なモジュール化） 競争優位を生み出すためのデータを特定し、カプセル化する 51
52. とにかく、やってみること • このやり方をやってみよう、という発想で既存のテー ブル設計を見直すと、さまざまな選択肢を発見できる • 事実の記録と状態の保持を分けるとテーブルとその操 作が単純になることを体験学習できる • このやり方に移行する問題点がより具体的になり、問 題の大きさの見積もりと軽減策の検討が具体的になる • 調査、仮説立案、検討の仮定で、業務理解が深まる 52