最近のお客様でもこれは強く言われる。なぜかと言うと変更にかかるコストの問題で、相手がSIerであれ情シス部門であれ、キャッシュアウトや交渉の手間を嫌うから。私も経理部員だったのでわかる。
これはあまり健全だとは言えない。コードで表現すべきことはそうすべきだと思います。(続く)
昔、お客様の基幹系システムをスクラッチ開発していた頃、システム運用担当の皆様ともよく打ち合わせしたが、ビジネスルールを如何にわかりやすくコードに書くかではなく、業務上変わり得るルールならそもそもコードに書かず、ユーザー部門がテーブル登録する仕様にしてくれという話の方が普通だった。
テーブルでビジネスロジックを表現するのが難しい場合があり、担当者が3代変われば、もはやブラックボックスになります。コードで表現してある方がまだしも親切で、リーダビリティが高いと尚よい。DevOpsが実現されていて内製化されていればもっとよい。
ビジネスロジックをテーブルで実装できるとなったら、ユーザーは仕様の決定を先送りする。過度な柔軟性を持たせることを要求する。 あんまり良いことではないが、変えようもない。情シス部門は事業部門より立場が弱い。昔に比べその傾向は強い。だったらコードの部分で何とかするしかないと思います。