社内SEのライフワークと化すマスタメンテナンスの実状から目を逸らすな! | 情シスあるある

先日の「社内SEの腕の見せどころ、運用設計って何するの?」で触れた、データ管理の中でも重要なマスタメンテナンスについて詳しく紹介します。

マスタメンテナンスって何?

まず、IT業界でもインフラエンジニアの方にはほとんど縁がないでしょう。
アプリケーションエンジニアの方でも全く関わった事が無い方もいると思いますので、
簡単にマスタメンテナンスについて説明します。

マスタって何?

システム(アプリケーション)には大別して下記の2種類のデータがあります。

  1. マスタデータ → 基本情報。割と固定的(社員、顧客、製品など)
  2. トランザクションデータ → 日々更新が積み重なるデータ(注文伝票、入出金明細など)

この中で2は膨大な量になり、システム自動的に作り出してくれます。

今回は1の「割と」固定的なマスタデータを変更する作業(メンテナンス)について解説します。

メンテナンスの頻度

例えば社員マスタであれば、社員の入社/退社に伴って変更しますし、
年度初(4/1)の人事異動に合わせて部署や役職を一括で変えないといけません。

社員マスタは比較的ラクで、原則は月初1営業日変更なので、負荷を読みやすいです。
ただし、年度初に組織の大変革があると、死ぬ思いをします。

残業する人

一方、顧客マスタや製品マスタは突発で変更がやってきます。
顧客の担当者マスタなど、営業が電話したら
「担当の○○さんはもう退職しました、後任は△△です」
ってタイミングで「マスタの担当者データ変えといて」って来ます。

タイミングが読みづらい一方、一括での更新はあまり多くないのでピークは高くないです。

メンテナンスの方法

マスタのメンテナンスは大別すると下記の方法があります。

  1. 社内SEが手動でメンテナンスする
  2. システム間連携で自動でメンテナンスされる
  3. エンドユーザ自身が手動でメンテナンスする(ex.パスワードの変更)

社内SEとしては、いかに1にしないかがカギです。

なぜ社内SEのライフワークになるのか?

社内SEの立場としては、手動でのメンテナンスは創造性にかけるし、仕事のスケジュールも組みづらくなるので避けたいのは当然です。
でも、なぜそれを背負ってしまうのでしょうか?

導入フェーズでの優先度

その理由はマスタメンテナンスの優先度が低いためです。

システム開発に携わった事がある方であればわかるかと思いますが、

システムはまず動かすことが第一です。メンテナンスのしやすさは動いてから考えれば良い

パッケージやクラウドサービスも、エンドユーザに対する機能追加を優先するでしょう。
社内SEも「自分がメンテがラクだから、こっちのソリューションがいい」だなんて言えません。(エンドユーザに対するスペックが横並びであれば、言える時もあります)

でも、マスタメンテナンスは自分しかしないわけですから、キチンと意見を言うべきだと思います。

ベンダはマスタの作られ方まで関知しない

仮にマスタメンテナンスに十分な時間とコストを投入できるケースであっても、

ベンダはマスタの変更方法に注目し、変更データをどのように作るかは注目しません。それはシステムの範囲外だからです。

例えばユーザマスタのメンテナンスをラクにするため、システム間連携をしようとします。
するとベンダは、

こういうフォーマットのCSVファイルをこのフォルダに置いてくれれば連携します。CSVファイルはお客様が作成してください。

と言います。

データコピー

関連システムの変更が魔のタイミング

社内SEは「お客様が作成する」変更データも手で作成したくないため、関連システムから自動的に出力しようとします。

元々導入しようとしたシステムと、別の関連システムに出力プログラムを作って連携させます。

最悪なのはその関連システムが変更になった時です。

関連システムの代替ソリューションを選定する際に「システム間連携の為に○○データを自動出力できる」という要件を入れ忘れたら、もうお終いです。

少なくともマスタメンテナンスの為に、予算が取れて改修が入るまで、と考えますが、いつの間にかライフワークと化します。

データがうまくあわない図

ライフワークと化さないために気をつけること

改めて、マスタメンテナンスを手動で行わないための注意事項をまとめます。

  1. 可能な限りシステム間連携を目指す(あきらめない)
  2. システム選定時は(第一とは言わないまでも)マスタメンテナンスも含めて検討する
  3. システムのリプレース時には、システム間連携も含めて調査を行い、予算を確保する

以上です。