システムの話であり、開発者目線の話。
世の中のシステムというのは大抵壊れながら動いているので、まぁ、どこでも運用改善、ソフトウェアの改善みたいな話がある。
往々にして、規模が大きくなりすぎて、全面的なリプレイスみたいなのが難しいというのもある。
それはわかる。
が、できることなら式年遷宮として、隣に新しいものを作って、古いものから移行させたほうが良い。
そうやって開発者体験を良くしていきましょう。
1. 改善や整理整頓はあまり評価されない
悲しいかな、会社という組織で、改善や整理整頓が評価されることは稀である。
評価されたとしても、それはマネージャーが理解があるとか個別の事情に寄ることが多いのではないだろうか。
一般論として、改善より何かを新規導入したほうが評価されやすい。
資本主義の犬としては、評価されない(報酬に結びつきにくい)ことをやってもしょうがない。
2. 改善には限度がある
改善してなにかが多少良くなったとしても、新しいものに伍する状態にはならないのが常である。
現代的な開発者体験を得るためには、現代的な技術で作り直す必要がある。
3. 改善するな、ではない
ここまで書いておいてなんだけど、改善するな、ではない。
パワー(ヒト、モノ、カネ)というのは有限なので、改善に力を割きすぎるな、ということ。
とりあえずの改善をして、新しい仕組みに移行するまでの時間をかせぐ、などはやる必要がある場面もある。
といっても、規模が大きすぎて
みたいな話があると思うが、そういう場合は、現代的なやり方としてはマイクロサービス化みたいなものがあって、切り出せるところから切り出していく、みたいな思想もある。
大きな問題は小さく分割して、倒していこう。
上が認めてくれないんです
RuntimeのEOLでも、ハードウェアの保守切れでもなんでも良いから機会を利用しよう。
手を尽くしてもだめならその職場を諦めた方が良い。
式年遷宮で一番大事なのは古い建物を壊すところまでやること
旧システムの停止までコミットメントする。それがいちばん大事。
新しい建物をつくるスケジュールを建てるだけでなく、古い建物を壊すこともスケジューリングするのが大事だし、ヒトモノカネの予算も積んでおこう。
そうしないと古い家と新しい家2つをメンテナンスする羽目になる。