📖 はじめに — 「どこを直すか」の前に「どこを見るか」
序章は「LLM コーディングは増幅であり、リファクタリングしなければ負債が増幅されるだけ」と論じた。では、いざリファクタリングに挑むとして — どこを見ればいいのか。
「気になったところから直す」は最悪の戦略だ。目につく負債（命名・重複）ばかり返済され、目につかない負債（計測の盲点・境界の越境・検査されていない検査）が残る。CTS-EC が本番前の総点検で使ったのは、7 つの観点の固定リストである。これは机上のフレームワークではなく、AI との壁打ちと実際の一掃作業を往復しながら固まった実戦の地図で、実践編の各章（実録）と 1:1 で対応している。
本章はその地図と、観点をどう回すかの「進め方の型」をまとめた、実践編の扉である。
🗺️ 7 つの観点マップ
| # | 観点 | 典型的な負債 | 機械ガードの例 | 拠り所とする手法 | 実録 |
|---|---|---|---|---|---|
| 1 | DDD / SOLID / BC（バックエンド構造） | god class・BC 越境・互換コード残置・書込境界の無秩序 | 越境 default-deny arch-test・行数ゲート・SAGA 契約検査 | DDD / SOLID / CQRS | 第3章・第4章 |
| 2 | フロントエンド構造（Atomic / Storybook / レスポンシブ / ダークモード / UI ドメインロジック） | DI・ドメインロジックの UI 混入・部品階層の汚染・dark ペア欠落 | grep 9 ゲート + pre-push（AT-1/7/18 等） | Atomic Design | 第5章 |
| 3 | a11y 実機（test-storybook） | コントラスト不足・aria 欠落・「検査してるつもり」の無スタイル検査 | axe を全 story に BLOCKING（既存 52 件は完済済み・全違反 fail） | WCAG 2.x AA | 第6章 |
| 4 | テスト品質・網羅性 | 計測の盲点・偽の穴（DTO 0%）・実装都合テスト・隠れコピペ | カバレッジゲート + ratchet・別エージェントの test-reviewer | TDD / テスト技法 | 第7章 |
| 5 | Python ジョブ群（バッチ・非同期処理） | スタブ残置・except 握り潰し・enum/ロジックのコピペ増殖 | 精密 3 パターンの grep ガード（AST/複数行対応） | 例外設計・SAGA 契約 | 第8章 |
| 6 | パフォーマンス | 全件マテリアライズ・N+1・「正しい最適化の間違った置き場所」 | NFR 明文化・実行コンテキスト規約（C-1/C-8）の機械検査 | 計測駆動（推測しない） | 第9章 |
| 7 | セキュリティ | 秘匿情報のログ混入・呼ばれない認可コード・dev 用設定の本番残留 | 秘匿ログ禁止の arch-test・CI ゲート | 多層防御 / YAGNI | 第10章 |
この表の使い方は 2 通りある。総点検なら 7 行を上から順に棚卸しする。日常のリファクタなら、いま触っている変更がどの行に触れるかを確認し、その行の機械ガードが緑のままかを見る。
3 点、表の設計意図を補足しておく。
- 観点は「負債が溜まる場所」で切る。 「開発手法」を観点に立てたくなるが、DDD や TDD は場所ではなく判定基準だ。だから手法は各観点の「拠り所」列に配線した — 観点が「どこを見るか」、手法が「何を良しとするか」を担当し、レイヤーを混ぜない
- 観点リストは固定だが、成長する。 CTS-EC も当初は観点 1〜5 で始め、パフォーマンス・セキュリティ・a11y は総点検の途中から追加した。追加の判断基準は「その観点に、機械ガードで固定できる負債が実在するか」
- SAGA のような新アーキテクチャは観点 1 の一部として扱うが、発散の density が高いため実録は独立章にした。挑戦的なアーキテクチャほど、観点としては早めに独立させる価値がある
🔁 進め方の型 — 安全網 → 棚卸し → 1 観点 1 ステアリング → 機械固定
観点の地図があっても、回し方を誤ると総点検は破綻する。CTS-EC の実績から抽出した進め方は 5 ステップだ。
0. 安全網を先に張る
コードに触る前に、現行挙動を固定する特性化テストとカバレッジ基盤を整える（第7章）。「安全網なしにコードへ触れない状態」を作ってから始める — リファクタの恐怖の正体はリグレッションであり、恐怖があると返済は先送りされる。
1. 観点ごとに定量棚卸しする
感覚でなく数で始める。god class の行数、越境 inject の件数、参照 page 数、カバレッジ実測、Fix 率 — 実践編の全章が「数字が起票を正当化する」ところから始まっている。そしてこの全量調査は必ず台帳にない兄弟負債を炙り出す（except 握り潰し 3 → 8 箇所、隠れコピペ 1,124 行）。棚卸し自体が監査だ。
2. 1 観点 = 1 ステアリングで切る
7 観点をまとめて 1 つの巨大リファクタにしない。観点ごとに性質（レビュー軸・完了基準）が違うため、混ぜるとレビュー精度が落ち、作業が XL 化してリリースを圧迫する。a11y を FE 整理から分離し、Write 越境を専用ステアリングに切り出したのはこの規律による。
3. 「根本解消」か「理由つき台帳」かの二択で裁く
見つけた負債の処遇は 2 つしかない。今根本解消する（「allowlist で逃がすな」）か、解消できない理由ごと台帳に載せて追跡する（Write 越境 = 実質 SAGA の分離）。黙って残す・見なかったことにする、という第三の選択肢を制度的に消す。
4. 機械ガードで固定し、ratchet で締める
返済した負債は default-deny のガード（arch-test / grep / CI）で再発を封じ、閾値は「実測 − 誤検知余裕」から始めて段階的に引き上げる。ガードの敵は甘さではなく狼少年化 — 既存違反は todo 化して新規だけ止める（a11y 52 件方式）。
この 5 ステップを貫くのが、第3章冒頭で宣言する横串 4 つの型（default-deny + 全量列挙 / ゼロベースラインが兄弟負債を炙り出す / 定量起票 / 実態調査が過剰設計を殺す）である。
🌉 この地図の先 — 検証エンジンと再測
7 観点の総点検を一巡すると、2 つの宿題が残る。機械ガードでは拾えない残余（transitive な依存・実行時型・将来の型）と、検査そのものの真正性（無スタイル DOM を検査していた・ローカル緑が実挙動を保証しない）だ。この 2 つに答えるのが応用編: クロスファミリー検証 — 機械の網の外を実装役とは異なるファミリーの AI がレビューし、レビューの実行証跡まで機械で強制する検証エンジンである。
そして観点も、ガードも、モデルの世代が変われば前提が動く。この地図は一度きりのチェックリストではなく、増築のたび・世代更新のたびに回し直す運用資産として扱ってほしい。その「回し直し」を体感や善意でなく自分の運用データで駆動できるようになるまで — 検証エンジン自身に計測層をはめてループを閉じるまで — の顛末は、シリーズ終章で完結する。
📚 シリーズ記事（ステアリング駆動開発・実践編）
序章
ドメイン別の実録（全 9 章）
- リファクタリング総点検ガイド — 7 つの観点と進め方
- DDD/SOLID/BC 編 — god class 一掃と境界の機械ガード
- SAGA 編 — 新アーキテクチャ挑戦と再発ゲート
- Atomic Design リファクタ編 — 47 page 新規移植
- Storybook × a11y 実機編
- テスト品質・網羅性編
- Python ジョブ群編
- パフォーマンス編
- セキュリティ編
続編
関連記事
- ステアリング駆動開発とは — 進め方の土台（壁打ち・規模判定・品質ゲート）
- 開発手法ガイド: 概要 — 「拠り所」列の全体系（DDD・SOLID・TDD ほか全 10 本）