技術的負債で生じる「クラフト」を管理せよ！ ケーススタディで学ぶ4分類とその対処法 - Agile Journey

はじめまして。流しのアーキテクトを生業としている、株式会社ウルフチーフの川島（@kawasima）です。私はSIerで20年、主にアーキテクトとしてさまざまなプロジェクトに関わってきました。現在は独立し、データモデリングを中心に、多くの企業の設計や技術者育成を支援しています。 数多くの現場を渡り歩く中で、プロジェクトを停滞させる「ある共通項」が見えてきました。それが、技術的負債に伴って静かに蓄積する「クラフト」です。本稿ではこの「クラフト」の正体を突き止め、パターンごとの対処法を具体的に紐解いていきます。 メンテナンスコストを増加させる「クラフト」 クラフトは計画的なリファクタリングによってのみ解消できる なぜクラフトが溜まる？ 欠けているのは「整えるフェーズ」 【ケーススタディ】 技術的負債に伴って発生するクラフトの4分類と対処法 【1】混在：異なる概念が同じ場所に置かれる 【2】分散：

[mohri]

リファクタリングと技術的負債とADRとDRY原則とそのほかいくつかの考え方がつながりをもって解説されてる

[masa8aurum]

・内部品質の問題をクラフト（cruft）と呼ぶ ・「整えるフェーズ」が必要。速く動きつつも意思決定の痕跡を残す ・ADR（Architectural Decision Record、アーキテクチャ決定記録）で意思決定の透明性を保つ。会計帳簿のように

[Goriot]

“その「戻せる構造」を制度的に支えるのが「意思決定の記録」です。どのような仮説のもとにどんな妥協を選択したのか、どのリスクを受け入れ、どの技術的負債を意図的に残したのかを明文化しておく必要があります”