レガシーについて

Buriを勉強してまして、その中で「Buriは基本的にレガシーを相手にしてないよ」なんて話を聞いたりしまして、さてレガシーをどうするのが良いんだろう？等と考えておりました。
まだ全然まとまっていないので、メモ。

まず、レガシーとは何かと言うと「古い仕組み」というのが適切かな、と。
「古い」＝「悪い」ではないのですが、これは対象をきちんと見極めてからでないと良し悪しは判断できない筈なのですが、一部には「古い」＝「悪い」＝「これがレガシー」という表現をされていたりして違和感を感じます。

古い仕組みが良いか悪いかを見極めるには、その古い仕組みの「使われ方」を見る事が必須となる筈です。

ここから、業務システムに特化した話になるのですが、「古い」仕組みが「悪い」仕組みになるには「現在の業務と乖離していないか」という点がまず何よりも重要。次いで、「現在の業務との乖離を埋める為のコストが大きい」となるかな、と。

この「現在の業務」が、そもそもずっと同じである保障もないし、その必要性もない訳です。業務を遂行している人がやり易いように、または業務を遂行する環境に適応していく為に、変わっていくものです。

なので、第一の「現在の業務と乖離していないか」という点は、事前に予測できるもの、予測できないものも含めて、必ず発生するものだと考えた方が自然です。仮に、将来の変化を見込んで業務のシステム化に取り組んだ場合でも、「現在の業務」との乖離は避けられませんし。

続いて「現在の業務との乖離を埋める為のコストが大きい」という点ですが、これは率直に言って「作りなおす」とした場合に「今あるものを直す」より安上がりに済めば、無理して今あるものを直す必要性はなくなります。

最も典型的なのが、過去の業務で存在していた「hoge区分」とか「foo分類」「barフラグ」を現在はもう使っていないというのに、ERの再設計をしないのでずっと今も残っているというケースかな、と思います。当時はnullを許容していなかったので、今も使われていないのにnullではない何かをセットしている。何かセットする上で業務的に意義のある値を割り当てられないので（だってnullの代わりですからね）、「99999」なんてコードを割り当てていたりする、とかですね。

このデータがお客様のビジネス上価値ある資源かと考えると、システムが表向きは問題なく動くようにする為の仕様調整の産物であって、業務遂行上の価値はほとんどないんじゃないかな、等と思えてくる訳です。これを後生大事に残していく意味って本当にあるの？とか。

ついでに言うと、こういう「仕様の為の仕様」みたいなものでも立派に仕様なので、使われない無意味なコードを割り当てていたとしても、テストの対象にはしっかり乗せないとダメですよね。で、そういったコストは人月商売をやっていると「オイシイ」と思うのかも知れないのですが、そこでまたバグが出る可能性が増えてしかもデバッグして他の箇所に影響を与えない可能性も考慮して、などリスクを意識すると恐ろしく非効率、非合理的ではないかいな、と。

等と考えて、「既存のものを直すより、作りなおした方が早い」なんて仕組みを考えないといけないんだなぁ、とぼんやりと思っております。