どっちかもいうとこっちが本題。
さて、ソフトウェア考古学の目的としては、
- レガシーシステムの保守開発の効率化
- システムの仕様理解の補助
の他にも、poorly-documentedなレガシーシステムのソースコードから、その仕様（あるいは意図）を読み解き復元し、システム再構築のインプットにするというケースが考えられます。
システムの技術的負債の解消や開発者の技術継承などを目的としてシステムを再構築する考え方としては、Fowler(2014)による犠牲的アーキテクチャ*1、および高橋 (2017)による式年遷宮アーキテクチャ*2が提案されています。 システム再構築にあたっては、セカンドシステム症候群を避けるためにも、まずは欲張らない（つまり、現行システムと同程度の）機能をカバーするよう開発を行うわけですが、その際これまで現行システムが本番環境で踏みつけてきた様々なコーナーケースの地雷を避けるには、現行システムの処理がなぜ現在のようになっているのかの理解が欠かせません。
ここで「システム再構築のインプットとなる設計思想の復元」を目的としたソフトウェア考古学的活動が必要になると思うのですが、そのような論文は見当たりません。とすると、
- アジャイルソフトウェア開発における知識の保存は成功を収めた。犠牲的アーキテクチャに基づくシステム再構築に耐え得るだけの知識を保存することができた（≒問題にならなかった）
- 犠牲的アーキテクチャに基づくシステム再構築は、ソフトウェア考古学的活動を伴っていない。十分な業務知識に基づくトップダウンの再設計だけで、刷新前のシステムと同程度の機能を実装できている（≒やっぱり問題にならなかった）
- ソフトウェア考古学的活動による設計思想の復元に成功した例はない。システム再構築は単純なストレートコンバージョンで行われている（≒成功していないので何も書けない）
のどれかなのかなぁと思うのですが、どうなんでしょうね？（3に一票入れたいのですが、悲観的に過ぎるかな？）
