マスターを軽視する者はマスターに泣く

タイトルを見て、「修士の話？」とか、「オラクル等の資格の話？」とか思った方、すみません、全く違う話です。

今日のお話はちょっと昨日の「型式」に関する話に近いかもしれません。

社会人になってまだすぐぐらいの時に、とあるシステムを手掛けることになりました。それもその領域に関しては全面に担当しろ、ということで。

で、その領域、っていうのが、マスターデータの用意やメンテナンス機能の構築でした。

事前にデモンストレーションをするためにアプリケーションだけは一応形ができあがっている。本番リリースに向けて更なるバージョンアップはするものの、基本構造の見直しは行わない。で、そろそろ本番展開を見据えた時に、マスターデータを利用者側で用意できるような業務基幹システムへの機能追加やメンテナンスアプリケーションがいる、ということで、本番リリースの５ヶ月前から急遽担当としてアサインされました。

これがですねぇ、色々辛かったのですよ。

まぁ、そもそも本番リリース時期が決まっている中、今からそのアプリケーションを組むための言語を習得するところから始めなくちゃいけなかった（これがプロフィールにも書いているVisual Basic 2.0なのですが）というところも大変だったのですが、それよりも、まぁ既に形のある業務部分のアプリケーションが元々デモンストレーションで「こんなんできたらいいでしょ？」系のもので、そもそもそれは確かにできればいいかもしれないけど、

・誰がそのアプリケーションを動かすためのマスターを用意するんですか？
・そのデータソースはどこから用意するんですか？

ということが全く考慮されていない状態のものだったので、まずその要件を満たすためのデータがあるのか無いのか、無いなら当然利用者側に作ってもらうしかないわけですが、そもそも何を元にして投入していくんだ？どうやったら少しでも楽になるんだ？というのをもの凄く考えて工夫せざるを得ませんでした。

結果は・・・まぁご想像できるか、と思いますが、失敗でした。つまり導入が進まなかったのです。いくつかある導入が進まなかった理由のうちの一つは、もちろん利用するまでのマスター用意の手間の部分でした。今考えても置かれた環境下では相当工夫した機能だったと自負しているんですけどね、そもそも、で受け入れられませんでした。

（個人的には我流ながらも悪戦苦闘した分だけVBの知識がついたので、未だにVBAとか組む場合に便利に利用できている、ということと、ありとあらゆるデータソースを見たので、かなりその領域には詳しくなれたんですが）

あれから10数年の月日が経ちました、会社も変わりましたが、未だに前述のような、利用機能重視だがマスターの考慮が足りない、というようなケースを実際見ることがあるし、事例としてはなかなか表には出てこないけれども、世の中結構同じような話があるような気がしてなりません。

マスターって存在は確かに地味で、ユーザーに対して目立つものでも格好良いものでも無いし、ましてやユーザーにとっては意識もされていなくて空気みたいなものと感じられていたりするので、そこにどれだけの考慮や工夫があってもそこに努力をしてもあまり脚光は浴びにくいかもしれない。

でも、システムは利用してもらってこそ初めて意味があります。利用されるためには大抵のシステムにはマスターが必要です。マスターの用意に時間がかかる、更新が大変、となると、最初は管理者の努力で何とかまかなわれるかもしれませんが、前述のようにマスターの存在が一般的には地味過ぎてその努力の解消につながる工数の確保をユーザー側の企業の中で認めてもらえないかもしれないため、結果としてマスターの更新がタイムリーには進まなくなり、システムの有効活用の阻害要因になるのではないか、と妹尾は考えています。

という意味で、ユーザー側の方々には「その機能を実現させたい、と思ったとき、マスター用意の実現性についてプランニングできてますか？」を、開発者側の方々にはユーザー側の要求があった時、そういった点考慮できてる？をきちんと要件定義する前に確認して欲しい、と思っています。多くの方にとっては「そんなの当たり前」、「何を今更？」ってことかもしれませんが。