マスタメンテナンス機能をスクラッチで新規システムを開発する時に開発することがあるかと思います。一般的に、マスターメンテナンスの開発工数は、総開発工数の15～20％発生する（当社の過去のシステム開発実績より）と思いますが、仮に3,000万円程度のシステム開発の場合、450万～600万円がマスターメンテナンスの開発コストになると想定できます。
また、ユーザ登録機能なども広義のマスターメンテナンス機能にあたりますが、こういった機能は頻度高く使うことが想定されるため、機能として作り込むことも多いでしょう。しかし、例えばユーザの部署をマスター管理したとして、部署名の変更機能まで作ることはあるでしょうか？

1 マスタメンテナンス機能についての実際の現場感について
2 マスタメンテナンス機能を運用でカバーする問題点
3 まとめ

マスタメンテナンス機能についての実際の現場感について

上記機能は、もちろん場合によっては作るあると思います。
ただ一般的には部署名変更は頻度が低いため、機能として作り込まれることは稀です。
実際に変更が必要になった際には、エンジニアがSQLでDBをいじればいい（いわゆる、運用でなんとかする）という話になることが多いかと思います。

そうなってしまう原因として、マスターメンテナンス機能がシステムの本質的な機能ではないととらえられがちだからです。
そのため、予算に制約がある場合には、まず最初に削減が検討される機能です。
また、マスターメンテナンスを実行する頻度がそれほど高くない場合、社内や外注先のエンジニアが対応する、という代替手段があるゆえに、開発工数を削減してしまうことが通常かと思います。
ただエンジニアからすると、後で運用の際に毎回手作業で実行するのは手間です。
ただ嫌なことではあるのですが、コスト削減の方針にはなかなか逆らえません。

マスタメンテナンス機能を運用でカバーする問題点

しかしながら、エンジニアがSQLでDBを触るというのは、
・　エンジニア不足の時代において、エンジニアに付加価値の低い仕事をさせることになる
・　証跡が残らず、コンプライアンス上問題になることがある
・　手作業のためミスを誘発しやすい
・　意図しないセキュリティ上の抜け道を作ってしまうことがある
・　外注の場合運用コストが結局高くなる
など、様々な問題があるのも事実です。

必ず必要な機能だけれども、どこまで作るべきか。
悩ましい機能であるのがマスターメンテナンス機能です。
作る／運用に逃げるの境目をどう判断するべきかは議論の余地があるかもしれません。

まとめ

マスターメンテナンスは必要な機能だし考えれば考えるほど工数がかかってしまう、、、
しかしながら本質的な価値は低い。
そんな「マスターメンテナンス機能は必要だが、コストは抑えて実現したい」
という課題の解決策が、SMOOZです。無料ではじめられるSMOOZをぜひお試しください。