■ マスターって？

「マスターってなんですか？」
と質問されたとき何と答えますか？

「マスターはマスターだよ。」なって冗談があるほど、言葉では説明が難しいのも事実です。


そこで、Copilotに聞いてみました。
こな回答が返ってきました。
「ビジネスの運営に必要な基本的なデータを指します。例えば、顧客の詳細、製品の詳細、従業員の情報などが含まれます。これらのデータは、トランザクションデータ（売上、購入など）とは異なり、頻繁に変更されることはありません。」

なんか、ピンｯときませんね。


で、よっぱおじさん🍶が考えるマスターデータを自分なりに説明します。
「実務上で関連するデータを転記したい場合、関連するデータを参照して活用される参照元の情報。」

例えば、納品書に書かれる「顧客情報」「販売社情報」「品目情報」「消費税」などが挙げられます。

ただ、更新頻度が多い情報は、マスターとしては不向きな情報になります。その点は、Copilotさんと同じ意見ですね。

■ マスターとなる情報を整理する

前にこんな感じで情報を整理しました、的な記事を上げています。

ここで、ある程度のマスターとなりえる情報整理は完了しています。
しかし、不足はないか？をもう一度見直ししてみます。

基幹システムから情報が勝手に落ちてくるので、面倒なマスターはほぼ無いですが、運賃関係のマスターが複雑になりそうです。

これで運賃計算が可能かを、何度も何度も検証を行います。

その為に、宅配の送料計算について、先生レベル（人に教える事が出来るくらい）になる必要があります。

■ 宅配の送料計算方法とは？

個人で宅配を依頼する時、荷物を持参していきますよね。
その時、宅配業者様は、３つの情報をもって、送料を決定しています。

１．重量（Kg）
２．縦＋横＋高の和（cm）※ 以下サイズと言います
３．配達先の地域

ただ、ここで判断が入ります。

例えば、佐川急便様の料金表。
縦軸は、サイズと重量になって、横軸に地域の料金表になっています。

あれ？縦軸、なんで２列なの？ってなります。

実は、このようなロジックになっています。

例えば、北東北に荷物を送ると想定します。
そして、サイズは125、重量が25Kg とします。

サイズ的には、140以下 100より大きい為、料金は、「2,310円」になりますが、重量的には、25Kgより大きく30Kg以下になるので、「2,570円」になります。

この場合、金額が高い方が適用され、送料としては、「2,570円」が適用されるのです。

これが送料の計算方法になります。
ヤマト運輸様も同じような考えで送料が決定されます。

■ マスター情報の欠陥を洗い出す

現時点のＥＲ図でも送料の計算は可能かもしれない。

しかし、「あんな時、こんな時、そんな時、が起きた時、今のままで耐えられるか？」を本気で考えます。

また、実際にオペレーションする人のＩＴスキルを見極めします。

で、以下の可能性について自問自答していきます。

１．将来変更がある要素
２．メンテナンス方法
３．マスターをメンテナンスする人のＩＴスキル

１．将来変更がある要素

かなり重要なポイントになります。

マスターのテーブル設計をミスすると、プログラムを全部見直し・修正する地獄を経験する羽目に会います。

ですので、「・・・かもしれない」の思考で考えます。
今は不要と思ったら「必要」と判断することが重要になります。

「必要」って判断した結果、プログラムが複雑になることは当たり前です。
いわば、保険みたいなものです。
後々の面倒が減らすことが出来ます。

| 変更になる要素

• 送料（値上げ、値下げ）

• 地域と都道府県の組み合わせ（配達の多様化）

• 箱の種類と名称（取り扱い梱包の変化）

• 宅配業者の増減（配達業者の多様化）

• サイズの増減（料金の細分化）

• 重量の増減（料金の細分化）

これらを考慮すると、考えているマスターテーブルの設計が不十分なのが明らかです。

２．メンテナンス方法

どのような画面でメンテナンスできれば良いかを考えます。
一番簡単なのは、テーブルを直接開いてもらい、データの変更・追加・削除をしてもらえれば簡単な話ですが、そんな簡単な話はありません。

そこで同時に「３．マスターをメンテナンスする人のＩＴスキル」も考慮します。

今回のシステムを利用するのは、実際に荷物を梱包する作業者で、キーボードをあまり触らない人が対象になります。

当然、ＰＣには詳しくないことが前提条件になります。

そんな人に対して「送料を直したいなら、テーブルを直接開いて、データを追加、変更してね」って言っても、出来るわけがありません。

もし、毎日ＰＣ作業の業務が数時間ある人なら、メンテ画面は少し手抜きします。

なぜ、こんな「利用者のＩＴスキル」を判断基準を設けるか。

それは、作成するアプリはそもそも売り物ではないからです。

さらに、業務中の合間時間でアプリを作成する必要がある為、手抜きできる所は手抜きします。
そう、メインの実務は、アプリ作成じゃないからです。

しかし、今回のアプリの利用者は、ＰＣスキル皆無が前提。

そうすると、送料のメンテナンスも佐川急便様、ヤマト運輸様のｗｅｂの画面と同じくしないとダメになります。

なぜなら、送料改定の場合、ｗｅｂ画面と同じ書面で通達されるからです。

ｗｅｂと同じＵＩを作り、その画面をＥｘｃｅｌチックにメンテできるようにする必要がありそうです。

■ マスターテーブル設計の見直し

将来性を考慮した場合、項目を追加したり、テーブルを追加する必要があると判断しました。

| 追加した項目
送料には、「有効開始日」の項目を追加して、時間軸で送料が変化するように作り込む必要があります。

| 追加したマスターテーブル
・地域変換テーブル
・宅配業者テーブル

結果、下図のようにしました。

■ まとめ

簡単に書いてしまいましたが、実は、システム（アプリ）を作る時、一番脳みそフル回転させて決めるのは、「マスターテーブル」になります。

処理系、保存系のテーブルの変更があった時のアプリのメンテは、なんとかできるものです。

しかし、運用を開始した後で、マスターテーブルの設計をミスに気付いたり、環境の変化で、マスターテーブルの設計をしなければならない場合、
これは、本当に地獄です。

その為、「今は必要ないけれど、１０年後のかもしないを想定して」を意識してマスターテーブルの設計を欲しいと思います。

テーブルの設計も残り１回（次回でひと段落）になります。
ここまで、読んでいただいてありがとうございます。
もう、感謝感激でございます。

何も落ちが無くて、ﾎﾝﾄｽﾏﾝｶｯﾀｯ!

■ よっぱおじさん🍶の独り言

実は、システムを作るって、作ろうとしている業務を熟知することも意味しています。
システムを作る初めは、初心者🔰レベルの知識ですが、システムを作る過程で、実務を理解できるようになり、システムが完成する頃には、人に教えられるレベルに達します。

しかし、その代償に時間を失いますが、失った時間は、無駄になりません。

社内のシステムを作る行為は、実は、社内のコンサルを行っていると同じです。
これは、他人がマネできることではありません。
けっして、損しない経験が体験できます。

未来の市民開発者に栄光あれ。