レガシーシステム攻略のプロセスを読んで

TL;DR

ソフトウェアデザインのZOZOTOWNの特集記事、すごく良かった。

"レガシーシステム攻略のプロセス"を読んだ

https://x.com/masayuki5160/status/1796681963522367538?s=46&t=g7ZdrjOCHFQoMzGwzoIsIA

数年前の僕だったら、これ読んで表面的な大変さだけわかった気になって読み捨ててたと思う。もちろん技術的な大変さはあるのはわかるんだけど、さらっと各ステークホルダーに向けてせつめいの仕方を変えてリプレイスプロジェクトへの理解を得てきた、というのが目についた。引用すると長いので割愛するけど、綺麗に書いてあるけどこりゃむちゃくちゃ大変だったろうなと思った。すごい。

Xで他の誰かも言ってた気がするけど、これからこういうリプレイスを乗り越えられるとこと、失敗するとこがどんどん出てくるんだろうなと僕も思う。技術的な難しさはもちろんある。でも意外にそのHowの部分はZOZOTOWNのこの記事の例のように実践例として報告が増えてきてる。だから、苦労はするだろうけど手はあるんだろうな。Managing Technical Debtの本も以前読んである程度体系的になってきてはいるのかなと感じた。とはいえ大変なのはそう。

Managing Technical Debt: Reducing Friction in Software Development (SEI Series in Software Engineering)

作者:Kruchten, Philippe,Nord, Robert,Nord, Robert,Ozkaya, Ipek
Addison-Wesley Professional

Amazon

でもステークホルダーへの説明というか、理解を求めて組織全体でまとまってリプレイスしていくことができるか、てのはなかなかうまくいくイメージがわかない。説明の仕方の簡単な例はこの記事にも書いてあるけど、人が相手なのでやっぱり一筋縄ではいかないはず。

まとめと感想

おじさんになったからか、こういうの最近は僕も嫌いではない。好きな技術や新しい技術使って、ドカーンとかっこいいプロダクト作るのもいいけど、こういうめんどくさくて、大変だけど、わちゃわちゃしてるレガシーなシステムをよくしていくのもソフトウェア開発のおもしろいとかだなと思う。大変だからあれなんだけど、やっぱりおもしろさはある、ていう。

次の号にも続きの話あるみたいなので楽しみ。おわり。