リファクタは始まる前に終わっている

この記事が語ること

構造改善活動を含む広義の"リファクタ"という営みの哲学を示す。
工程を分解し、その重心がどこにあるのかを提示する。
個別技法の列挙ではなく、工程全体の構造を対象とする。

リファクタという営みの立ち位置

「リファクタ」と呼ばれるものは、大抵、時間を割き、計画を立てて解決していかねばならない。
リファクタは、他の業務要素の延長ではない。
独立して取り扱うべき概念だ。

例えば、リファクタと新規開発はまったく違う営みだ。

新規開発：「未知を作る」=相対的に予見性が低い
リファクタ：「既知を再編する」=相対的に予見性が高い

予見性が高い理由は構造的に明確だ。

• 既に動いている
• 仕様が存在している
• ログがある
• 事故履歴がある
• 依存が観測できる
• 触って壊して確認できる
• 動機が組織内部にある

ここに新規開発のエンジニアリングパターンを持ち込んでも意味がない。
相応のやり方があるのだ。

筆者の「リファクタの6フェーズ」

● 調査
現状を把握し、目的を定義し、患部を特定する。
依存関係、事故履歴、暗黙知、ログ、仕様を棚卸しし、前提条件を明らかにする。

● 整地
ゴールを共有し、優先度を調整し、境界を確定する。
合意を形成し、判断過程を記録可能な状態に整える。

● 剪定
不要要素を除去し、複雑性を削減する。
依存の性質に応じて切り分け、再編可能な形へと単純化する。

● 再編
リファクタ本編として、責務・境界・依存を再配置する。
構造を再設計し、整合的な形へ組み直す。

● 検証
保証範囲を確定し、回帰テストと効果測定を行う。
挙動が保持されていることを確認し、復旧手段を準備する。

● 収束
変更をリリースし、作業を閉じる。
監視、記録更新、後処理を完了させ、状態を安定化させる。

リファクタの重心はどこか

リファクタは実装が本番ではない。
調査・整地・剪定の段階が本番だ。

• 患部の特定
• 境界の確定（触る／触らない）
• 順序設計（どこから触るか）
• 保証範囲の決定
• 合意と停止条件の明確化

これらはすべて、実装前に決まるべき“設計判断”。

リファクタ本編は、設計で決めた順序を淡々と実行するだけ。

リファクタの失敗はどこで生まれるか

失敗の多くは、経験上、再編フェーズのミスではない。
調査と剪定の不足による『予期せぬ依存』の存在が悪さをするものだ。

したがって、規模にもよるが、リカバリをどうするかを考えるのは後半の工程でよい。
失敗を未然に防ぐための調査フェーズに優先して取り組むことを勧める。

リファクタのフェーズ1.調査

リファクタを明示的な単位として扱うための一歩目は、現状を正確に把握することだ。

• 何を解決したいのか
• 患部はどこか
• 原因は何か
• 完了の見通しは立つか

リファクタをしたいという動機の裏には必ず、何らかの事実があるはずだ。
ログや監視データ、データレコード、テストの結果、コードの複雑性。
そういったものを可視化し、説明可能な状態にしておくこと。
このフェーズでは調査を完結させることが求められる。

データが訴える「死に筋」

100通りの分岐があるクラスが対象となる例を考える。
しかし、実データまで見てみると、「生きている分岐は3通り」と特定できることもある。
こうなると、リファクタの方針が根本から変わる。
調査とは、現状を正確に把握することだ。
そこに見えているコードを眺めることだけではない。

リファクタのフェーズ2.整地

ここが最重要と言っても過言ではない。

整地は、マクロな整地とミクロな整地に分けられる。

マクロな整地

マクロな整地とは、組織的なコンセンサスを得るための手続きだ。

リファクタの目的、つまり「その行為で何が得られるのか」、「どういう動機があるのか」をチームや上長に発信すること。
必要なのはメリットとモチベーションの提示だ。
場合によっては、チーム内でリファクタの機運を高めることも必要になってくるだろう。
工数の見積もりや必要な人的リソースの見通しを立てられるとなおよい。

この手続きを疎かにすると、リファクタしたいという意思は組織のどこかで跳ね返される。
大抵の現場では保守への投資に割く枠が足りていないからだ。

ミクロな整地

ミクロな整地とは、作業環境の整備と境界の設定だ。

前者は言うまでもなく、作業に専念できる環境を手元に作ること。
そして、工程のトレーサビリティを確保する方法を定めておくこと。

後者は、具体的にどこまでをリファクタ対象とするのかを決めること。
この際、影響範囲の正確な把握が極めて重要になる。
改修範囲はどこまで閉じているのか、あるいはドメインをまたぐのか、自分単独で解決可能な範疇なのか、といったラインを見定めること。

この手続きを疎かにすると、作業途中で想定漏れが起きやすく、結果、行き詰まる。

ここまで整えると、自ずと説明責任も浮かび上がってくる。
ここでいう説明責任とは、なぜその順序で進めたのかを後から説明できる状態にしておくことだ。

リファクタのフェーズ3.剪定

ここで言う剪定とは、コードそのものの露払いだ。
リファクタしたいものには必ずと言っていいほど邪魔なツタが絡まっている。
これは先に処分するに限る。

理由は単純で、複雑性が減らせるからだ。
リファクタの核を浮き彫りにすることで、作業ミスも抑制される。

使用していないプロパティ・メソッド・その他は、削除する。
依存関係がないものは、切り離す。
少ない依存は、整理して限りなく疎結合にする。
依存が多い場合は、段階的に剥離する。

特にこの剪定のフェーズでは、細分化デプロイ戦略が使える。

細分化デプロイ

後のフェーズでも使える“横断戦術”だが、ここで解説する。
その名の通り、作業過程でデプロイを複数回に分割することだ。
その狙いは、リスクの分割払いだ。

デプロイのパターン

• 削除だけ出す
• 局所変更だけ出す
• 段階的剥離の途中段階を出す
• サブリファクタを先に出す
• 本体リファクタは後で出す

修正もテストもその最小単位で実施していく。
この工程では、本体は細分化の結果として削り出される。
リファクタだからこそ成立する手法だ。

“小さければ小さいほど良い”という哲学

リファクタは小さくデプロイしていくこと。
理由は構造的に明確だ。

小さい変更は、

• 壊れにくい
• 観測しやすい
• ロールバックしやすい
• 説明しやすい
• 合意形成しやすい

結合度低減、凝集度向上、可読性向上といった効果は、この積み重ねで顕在化させていく。

リファクタのフェーズ4.再編

ここにきてようやくリファクタ本編に取り掛かる。
このフェーズに入る頃には、リファクタは9割方完了していると言っていい。

本来やりたかった再編をぶつけるだけ。
責務・境界・依存の再配置、構造の再構築、クラス分割、IF分離、命名変更といった作業はここで行う。

リファクタのフェーズ5.検証

総合的なテストのフェーズとなる。

必須となるのは回帰テスト。
挙動が変わってしまっていないかの確認。

それ以外はケースに応じて変わってくる。

「どこを保証するか／しないか」の判断。
事故抑止であれば、怪しいポイントの重点確認。
速度改善が目的なら効果検証。
ドメインをまたぐ場合はIFの確認。

また、失敗した際のリカバリ、ロールバック方法はこのフェーズで考えるのが効率がよい。

リファクタのフェーズ6.収束

変更のリリースを実施。
問題が出なければこれで完了だ。

後始末として、ドキュメントの更新が必要か、などは確認しておくべきだろう。

トレーサビリティの意義

トレーサビリティとは、リファクタにおける意思決定の外部化である。
道具はIssueでもチケットでも構わない。

例えば、剪定の粒度に合わせてチケットを分割発行する。
すると、依存剥離の順序、判断根拠、合意履歴を可視化できる。

これにより、

• 説明コストは下がる
• 合意形成は容易になる
• 有事の際の判断が速くなる

コードに残らない設計判断を記録すること。
それがリファクタの価値を可視化し、後から辿れる「地形図」となる。
特にリファクタは成果が理解されにくい営みである。
したがって、手順の外部化は組織的に必須となる。

リファクタ哲学の核心

以下の2つに集約される。

リファクタは調査・整地・剪定で決まる。
リファクタ本体のリリースは、小さければ小さいほど良い。

つまり、リファクタは始まる前に終わっているのだ。

---

エンジニア達の「完全に理解した」Talk #77 にて本記事のLTを行いました。