ジャンキーなスクリプトを直すために事業の半分をリファクタリングした話
「コードが難しい部分」というのは実は誤解で、真の課題はコードの変更が組織やプロセス、人間関係に与える影響を管理することだと解説。あるジャンキーなスクリプトを修正するために、ビジネスロジックの半分をリファクタリングした経験をもとに、技術的負債と向き合う際の意思決定やトレードオフについて考察する。
背景メモ
- データエンジニアリングの世界では「本番データを直接変更するスクリプト」が現場に蔓延しがち。一時的な楽さの代償として、監査不能・再現不能・エラー時の影響範囲が甚大になる「ジャンキースクリプト」問題が業界で繰り返し話題になっている。
- 著者Swizec Tellerはフルスタックエンジニア兼技術作家。この記事では、1つの使い捨てスクリプトを修正するために、結果的にビジネスロジックの半分をリファクタリングした事例を詳述。
- 根本原因は「SQLダンプの手動ダウンロード→ローカルでPython処理→結果を本番DBに書き戻す」という非構造化パイプライン。テスト不能、冪等性ゼロ、エラー時にロールバック不可という古典的アンチパターン。
- 解決策として、同僚と組んで（1）既存のバックエンドAPI/DB構造を学習し、（2）ダッシュボードUIと管理画面を整備し、（3）すべてのデータ操作を関数化・テスト可能にした。結果として、コード行数は増えたが「本番を直書きしない」文化と保守性を手に入れた。
- 「コードを書くことより、正しいアーキテクチャを選ぶことの方が難しい」という主張がこの記事の核心。エンジニア組織の技術的負債に対する現実的な向き合い方を示すケーススタディとして読める。