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