形態の解体

硬直化したシステム構造の制御された解体を行う — 石灰化したアーキテクチャ、蓄積された技術的負債、組織の硬直性を解体しながら、新しい形態の種となる本質的な能力（「イマジナルディスク」）を保持する。

使用タイミング

• 形態評価（assess-form参照）がシステムをPREPAREまたはCRITICAL（直接変換には硬すぎる）と分類した時
• システムが石灰化しすぎて漸進的変更が不可能な時
• 技術的負債が蓄積してすべての前進を阻む地点に達した時
• 組織構造が硬直化して新しい要件に適応できなくなった時
• adapt-architectureの前に現在の形態を軟化させる必要がある時
• 価値を抽出してからシャットダウンするレガシーシステムの廃止時

入力

• 必須: 高い硬直性を示す形態評価（assess-formから）
• 必須: 保持すべき本質的能力（イマジナルディスク）の特定
• 任意: 目標形態（解体後に出現すべきもの、不明の場合あり）
• 任意: 解体タイムラインと制約
• 任意: 特定のコンポーネントに対するステークホルダーの懸念
• 任意: 以前の解体試行とその結果

手順

ステップ1: イマジナルディスクの特定

生物学的変態において、イマジナルディスクは溶解を生き延び蝶の器官となる毛虫内の細胞群である。生き残るべき本質的な能力を特定する。

1. 現在のシステムが提供するすべての能力をカタログ化する：
   • ユーザー向け機能
   • データ処理機能
   • 外部システムとの統合ポイント
   • コード/プロセスに埋め込まれた組織的知識
   • ビジネスルール（暗黙的で文書化されていないことが多い）
2. 各能力を分類する：
   • イマジナルディスク（生存必須）：コアビジネスロジック、重要な統合、代替不可能なデータ
   • 置換可能な組織（再構築可能）：UI、インフラ、標準的なアルゴリズム
   • 死んだ組織（生存すべきでない）：もう存在しないバグへのワークアラウンド、廃止システムとの互換シム、誰も使っていない機能
3. イマジナルディスクをポータブルな形式に抽出する：
   • ビジネスルールを明示的に文書化する（コードコメントや口伝としてのみ存在する場合がある）
   • 重要なアルゴリズムをスタンドアロンのテスト済みモジュールに抽出する
   • 本質的なデータをフォーマット非依存の表現にエクスポートする
   • 統合契約とその実際の（文書化されたものではなく）動作を記録する

期待結果: 本質的（保持）、置換可能（再構築）、死んでいる（破棄）に分類された能力の明確なインベントリ。解体開始前に本質的な能力がポータブルな形式に抽出されている。

失敗時: イマジナルディスクの特定が不確実な場合（何が本質的かについてステークホルダーが意見を異にする場合）、保持側に寄って判断する。必要と思うよりも多くの能力を抽出する — 解体後の破棄は容易だが、失われた知識の回復は多くの場合不可能。

ステップ2: 解体シーケンスのマッピング

構造要素が解体される順序を決定する — 外層から先に、コアは最後。

1. 依存関係の深さで順序付ける：
   • レイヤー1（最外層）：依存するものがないコンポーネント — 除去しても何も壊れない
   • レイヤー2：依存するものがレイヤー1の項目（すでに解体済み）のみのコンポーネント
   • レイヤー3：より深い依存関係を持つコンポーネント — 除去には慎重なインターフェース管理が必要
   • レイヤーN（コア）：すべてが依存する荷重支持コンポーネント — 最後に解体
2. 各レイヤーについて定義する：
   • 何が解体されるか（除去、廃止、アーカイブ）
   • 何がそれを置き換えるか（新コンポーネント、なし、または一時的なスタブ）
   • 残りのレイヤーのためにどのインターフェースを維持する必要があるか
   • このレイヤーの解体後にシステムが依然として機能することをどう検証するか
3. 解体チェックポイントを作成する：
   • 各レイヤーの後、残りのシステムがテストされ稼働可能であることを確認する
   • 各チェックポイントは解体を一時停止できる安定状態である
   • レイヤーの解体が予期しない破損を引き起こした場合、前のチェックポイントから復元する

Dissolution Sequence (outside in):
┌─────────────────────────────────────────────────────────────────┐
│ Layer 1: Dead features, unused integrations, orphaned code      │
│          → Remove. Nothing depends on these.                    │
│                                                                 │
│ Layer 2: Replaceable UI, standard infrastructure                │
│          → Replace with modern equivalents or stubs             │
│                                                                 │
│ Layer 3: Business logic wrappers, data access layers            │
│          → Extract imaginal discs, then dissolve                │
│                                                                 │
│ Layer 4 (core): Load-bearing structures, data stores            │
│          → Dissolve last, with full replacement ready           │
└─────────────────────────────────────────────────────────────────┘

期待結果: 各ステップが安全（チェックポイントで検証済み）かつ可逆的（前のチェックポイントが復元可能）なレイヤー順序の解体シーケンス。最も重要なコンポーネントは、チームが最も経験と自信を持った時に最後に解体される。

失敗時: 依存関係マッピングが循環依存（AがBに依存しBがAに依存）を明らかにした場合、シーケンス解体が可能になる前にこれらのサイクルを断ち切る必要がある。AとBの間にインターフェースを導入し、サイクルを断ち切ってからシーケンスを進める。

ステップ3: インターフェース考古学の実施

硬直した構造を解体する前に、その実際のインターフェースを発掘して文書化する — 文書化されたものではなく、実際に使用されているもの。

1. 現在のインターフェースを計装する：
   • 各インターフェースでのすべての呼び出し、メッセージ、データ交換をログする
   • 少なくとも1つの完全なビジネスサイクル（日次、週次、月次 — 関連するものに応じて）実行する
   • 文書化されたスキーマだけでなく、実際のペイロード形状をキャプチャする
2. 実際の動作と文書化された動作を比較する：
   • 文書化されたインターフェースのうち呼び出されないものは何か？（レイヤー1解体の候補）
   • 文書化されていないが活発に使用されているインターフェースは何か？（隠れた依存関係 — 保持または明示的に置換する必要がある）
   • 実際のトラフィックが明らかにする、文書化されていないエッジケースは何か？
3. 実際の動作からインターフェース契約を構築する：
   • この契約が置換の仕様になる
   • 入出力の実例を含める
   • エラー処理の動作を文書化する（起こるべきことではなく、実際に何が起こるか）

期待結果: 文書化されていない動作や隠れた依存関係を含む、システムが実際にどのように通信するかを正確に表す経験的に導出されたインターフェース契約。

失敗時: 計装が侵襲的すぎる場合（パフォーマンスに影響またはコード変更が必要）、すべてをキャプチャする代わりにトラフィックをサンプリングする。ビジネスサイクルの待機期間が長すぎる場合、「どの状況で何が何を呼ぶか」に関するステークホルダーインタビューで補完された利用可能なデータを使用する。

ステップ4: 制御された解体の実行

イマジナルディスクの生存能力を維持しながら、構造要素を体系的に除去する。

1. レイヤー1（最外層、依存なし）から開始する：
   • 死んだ機能と未使用コードを除去する
   • 参照用にアーカイブする（削除しない）
   • 検証：システムが依然としてすべてのテストに合格し、ランタイムエラーがない
2. 各レイヤーを順に進める：
   • 解体される各コンポーネントについて： a. イマジナルディスクが抽出済みであることを確認する（ステップ1） b. 置換またはスタブをインストールする（依存するものが残る場合） c. コンポーネントを除去する d. バリデーションスイートを実行する e. 予期しない副作用を監視する
   • 各チェックポイントで：現在のシステム状態を文書化し、稼働状態を確認する
3. 解体抵抗に対処する：
   • 一部のコンポーネントは解体に抵抗する（隠れた依存関係が表面化）
   • 除去が予期しない破損を引き起こした場合： a. チェックポイントから復元する b. 隠れた依存関係を調査する c. インターフェース考古学（ステップ3）に追加する d. 依存関係に対する明示的なスタブを作成する e. 解体を再試行する
4. 解体の進捗を追跡する：
   • 残存 vs. 解体済みのコンポーネント
   • 抽出されポータブルであることが確認されたイマジナルディスク
   • 発見され対処された予期しない依存関係

期待結果: 非本質的構造の体系的で検証済みの解体。各レイヤーの後、残りのシステムはより小さく、よりシンプルで、依然として稼働可能。イマジナルディスクはポータブルな形式で保持されている。

失敗時: 解体がカスケード障害を引き起こす場合、レイヤー順序が間違っている — 予想より深い隠れた依存関係がある。停止し、復元し、依存関係を再マッピングし、シーケンスを再設定する。解体が「イマジナルディスク」が予想より複雑であることを明らかにした場合、その能力の抽出により多くの時間を割り当てる。

ステップ5: 再構築のための基盤準備

解体後、残りのシステムは最小限の稼働可能なコアと再構築のために準備された抽出済みイマジナルディスクであるべきである。

1. 解体後の状態を評価する：
   • 何が残っているか？（最小限の稼働コア + 抽出された能力）
   • 残りのシステムは保守可能か？（チームが理解し修正できるか）
   • すべてのイマジナルディスクがアクセス可能で検証済みか？（ポータブル、テスト済み、文書化済み）
2. 再構築マニフェストを作成する：
   • 各イマジナルディスクをその契約、データ、テストスイートと共にリストする
   • 再構築のターゲットアーキテクチャを指定する（または「未定」と記す）
   • ギャップを特定する：部分的に抽出された、または品質に懸念のある能力
3. 再構築への引き継ぎ：
   • ターゲット形態が判明している場合：最小限のコアを出発点としてadapt-architectureに進む
   • ターゲット形態が不明な場合：ターゲットが設計される間、最小限のコアで運用する
   • いずれの場合も：システムは再形成できるほど柔軟になった

期待結果: 明確に文書化された抽出済み能力を持つ最小限で保守可能なシステム。基盤はクリーンで、選択されたどの形態での再構築にも準備ができている。

失敗時: 解体後のシステムが予想より保守性が低い場合、保持すべき本質的な構造が解体された。イマジナルディスクのインベントリを確認する — 重要な能力が欠けている場合、アーカイブから回復可能かもしれない。最小限のコアが運用するには最小限すぎる場合、「置換可能な組織」の一部が実際には本質的だった — チェックポイントから復元する。

バリデーション

• イマジナルディスクが特定、抽出され、ポータブルな形式で検証されている
• 解体シーケンスが最外層（依存なし）からコアまでレイヤー化されている
• インターフェース考古学が実際の（文書化されたものだけでなく）動作をキャプチャしている
• 各解体レイヤーに検証済みチェックポイントがある
• 解体中に本質的な能力が失われていない
• 解体後のシステムが最小限で保守可能で稼働可能
• 再構築マニフェストが抽出された能力とギャップを文書化している

よくある落とし穴

• 抽出なしの解体: 本質的な能力が抽出される前に硬直したコンポーネントを除去すると、代替不可能な知識が破壊される。常にイマジナルディスクを先に抽出する
• 観察より文書化を信頼する: 文書化されたインターフェースは実際の動作から乖離していることが多い。インターフェース考古学（ステップ3）が真実を明らかにする；文書化は意図を示す
• コアを先に解体する: 依存するものが解体される前に荷重支持構造を除去するとカスケード障害を引き起こす。常に外側から内側に作業する
• 完全な解体: すべてを解体してゼロから始めることはクリーンに聞こえるが、組織的知識、実戦で鍛えられたエッジケース処理、運用の継続性を失う。イマジナルディスクを保持する
• 罰としての解体: 再構築計画なしに「悪いから」システムを解体すると真空が生まれる。解体は再構築の準備であり、それ自体が目的ではない

関連スキル

• assess-form — 硬直性を特定し解体をトリガーする前提条件の評価
• adapt-architecture — 解体に続く再構築スキル
• repair-damage — 完全な解体ではなく的を絞った修復が必要なシステム向け
• build-consensus — 大規模な解体前のコンセンサスがチームの分裂を防ぐ
• decommission-validated-system — 規制対象システムの正式な廃止プロセス
• conduct-post-mortem — ポストモーテム分析は解体の調査的厳密さを共有する