先に
システム開発は今も元気にやってます
この"クローズ作業"は大体は案件開発と並行作業でやってたものです
まとめ
・クローズ作業からシステム設計について考えることもあるよね
・クローズをネガティヴなまま終わらせたくないね
本文
ここ1年半くらいで、たまたまではあるのだけどサービスクローズやらシステム刷新やらで、アプリケーションをクローズする作業がちょくちょくあった(そして今もちょっと片手間だがやってる)
こういうことをやってると、「いかにクローズしやすいと嬉しいか」を考えたりする。
勿論開発をしている中でその視点で考えることなんて殆どないだろう。
「開発をする」ということは、何らかのニーズを満たすためのポジティブな資産の生産を行なってるので、"クローズ"というネガティブな発想はしないよなと。
「サービス終了なので、もうアクセスをばっさり切って良いですよ」とかなら何も考えなくても良いかもしれない。
ただ、機能や一部アプリケーションが不要になりますということであれば、全体の整合性も考えないといけないことがある。
こういうクローズ作業をいくつかやってきた中で思ったのは
・ここの機能をクローズすると、別の機能にも影響がありそうで怖い
・システム構成が不明瞭なところがあって、全て必要なクローズができているか不安。 (※途中参画故に完全な全体像を把握せずやってきてた自分の横着もある)
・クローズ作業は必要なことだけど、時間をかけすぎてると何も生み出せてないのでは。(というジレンマ)
・などなど
というのがあるわけで、
"どんなサービスにせよ機能にせよいつか終わりが来るよ"ということを意識するだけでも、いわゆる「疎結合にやろう」とか「DRYにやりたいね」みたいな、保守性等々を語る上でのアーキテクチャの観点にも、もう一歩踏み込んで考えられるのかなーと思ったり。
まぁこういうのは大体自戒です(?)
上司とかにも言われたけど、こういうクローズ作業自体はある種中々経験できないので、良い経験だったねという学びとして認識しておきたい。