テーブルの設計 その５”マスター"
■ マスターって？
「マスターってなんですか？」
と質問されたとき何と答えますか？
「マスターはマスターだよ。」なって冗談があるほど、言葉では説明が難しいのも事実です。
そこで、Copilotに聞いてみました。
こな回答が返ってきました。
「ビジネスの運営に必要な基本的なデータを指します。例えば、顧客の詳細、製品の詳細、従業員の情報などが含まれます。これらのデータは、トランザクションデータ（売上、購入など）とは異なり、頻繁に変更されることはありません。」
なんか、ピンｯときませんね。
で、よっぱおじさん🍶が考えるマスターデータを自分なりに説明します。
「実務上で関連するデータを転記したい場合、関連するデータを参照して活用される参照元の情報。」
例えば、納品書に書かれる「顧客情報」「販売社情報」「品目情報」「消費税」などが挙げられます。
ただ、更新頻度が多い情報は、マスターとしては不向きな情報になります。その点は、Copilotさんと同じ意見ですね。
■ マスターとなる情報を整理する
前にこんな感じで情報を整理しました、的な記事を上げています。
ここで、ある程度のマスターとなりえる情報整理は完了しています。
しかし、不足はないか？をもう一度見直ししてみます。
基幹システムから情報が勝手に落ちてくるので、面倒なマスターはほぼ無いですが、運賃関係のマスターが複雑になりそうです。
これで運賃計算が可能かを、何度も何度も検証を行います。
その為に、宅配の送料計算について、先生レベル（人に教える事が出来るくらい）になる必要があります。
■ 宅配の送料計算方法とは？
個人で宅配を依頼する時、荷物を持参していきますよね。
その時、宅配業者様は、３つの情報をもって、送料を決定しています。
１．重量（Kg）
２．縦＋横＋高の和（cm）※ 以下サイズと言います
３．配達先の地域
ただ、ここで判断が入ります。
例えば、佐川急便様の料金表。
縦軸は、サイズと重量になって、横軸に地域の料金表になっています。
あれ？縦軸、なんで２列なの？ってなります。
実は、このようなロジックになっています。
例えば、北東北に荷物を送ると想定します。
そして、サイズは125、重量が25Kg とします。
サイズ的には、140以下 100より大きい為、料金は、「2,310円」になりますが、重量的には、25Kgより大きく30Kg以下になるので、「2,570円」になります。
この場合、金額が高い方が適用され、送料としては、「2,570円」が適用されるのです。
これが送料の計算方法になります。
ヤマト運輸様も同じような考えで送料が決定されます。
■ マスター情報の欠陥を洗い出す
現時点のＥＲ図でも送料の計算は可能かもしれない。
しかし、「あんな時、こんな時、そんな時、が起きた時、今のままで耐えられるか？」を本気で考えます。
また、実際にオペレーションする人のＩＴスキルを見極めします。
で、以下の可能性について自問自答していきます。
１．将来変更がある要素
２．メンテナンス方法
３．マスターをメンテナンスする人のＩＴスキル
１．将来変更がある要素
かなり重要なポイントになります。
マスターのテーブル設計をミスすると、プログラムを全部見直し・修正する地獄を経験する羽目に会います。
ですので、「・・・かもしれない」の思考で考えます。
今は不要と思ったら「必要」と判断することが重要になります。
「必要」って判断した結果、プログラムが複雑になることは当たり前です。
いわば、保険みたいなものです。
後々の面倒が減らすことが出来ます。
| 変更になる要素
送料（値上げ、値下げ）
地域と都道府県の組み合わせ（配達の多様化）
箱の種類と名称（取り扱い梱包の変化）
宅配業者の増減（配達業者の多様化）
サイズの増減（料金の細分化）
重量の増減（料金の細分化）
これらを考慮すると、考えているマスターテーブルの設計が不十分なのが明らかです。
２．メンテナンス方法
どのような画面でメンテナンスできれば良いかを考えます。
一番簡単なのは、テーブルを直接開いてもらい、データの変更・追加・削除をしてもらえれば簡単な話ですが、そんな簡単な話はありません。
そこで同時に「３．マスターをメンテナンスする人のＩＴスキル」も考慮します。
今回のシステムを利用するのは、実際に荷物を梱包する作業者で、キーボードをあまり触らない人が対象になります。
当然、ＰＣには詳しくないことが前提条件になります。
そんな人に対して「送料を直したいなら、テーブルを直接開いて、データを追加、変更してね」って言っても、出来るわけがありません。
もし、毎日ＰＣ作業の業務が数時間ある人なら、メンテ画面は少し手抜きします。
なぜ、こんな「利用者のＩＴスキル」を判断基準を設けるか。
それは、作成するアプリはそもそも売り物ではないからです。
さらに、業務中の合間時間でアプリを作成する必要がある為、手抜きできる所は手抜きします。
そう、メインの実務は、アプリ作成じゃないからです。
しかし、今回のアプリの利用者は、ＰＣスキル皆無が前提。
そうすると、送料のメンテナンスも佐川急便様、ヤマト運輸様のｗｅｂの画面と同じくしないとダメになります。
なぜなら、送料改定の場合、ｗｅｂ画面と同じ書面で通達されるからです。
ｗｅｂと同じＵＩを作り、その画面をＥｘｃｅｌチックにメンテできるようにする必要がありそうです。
■ マスターテーブル設計の見直し
将来性を考慮した場合、項目を追加したり、テーブルを追加する必要があると判断しました。
| 追加した項目
送料には、「有効開始日」の項目を追加して、時間軸で送料が変化するように作り込む必要があります。
| 追加したマスターテーブル
・地域変換テーブル
・宅配業者テーブル
結果、下図のようにしました。
■ まとめ
簡単に書いてしまいましたが、実は、システム（アプリ）を作る時、一番脳みそフル回転させて決めるのは、「マスターテーブル」になります。
処理系、保存系のテーブルの変更があった時のアプリのメンテは、なんとかできるものです。
しかし、運用を開始した後で、マスターテーブルの設計をミスに気付いたり、環境の変化で、マスターテーブルの設計をしなければならない場合、
これは、本当に地獄です。
その為、「今は必要ないけれど、１０年後のかもしないを想定して」を意識してマスターテーブルの設計を欲しいと思います。
テーブルの設計も残り１回（次回でひと段落）になります。
ここまで、読んでいただいてありがとうございます。
もう、感謝感激でございます。
何も落ちが無くて、ﾎﾝﾄｽﾏﾝｶｯﾀｯ!
■ よっぱおじさん🍶の独り言
実は、システムを作るって、作ろうとしている業務を熟知することも意味しています。
システムを作る初めは、初心者🔰レベルの知識ですが、システムを作る過程で、実務を理解できるようになり、システムが完成する頃には、人に教えられるレベルに達します。
しかし、その代償に時間を失いますが、失った時間は、無駄になりません。
社内のシステムを作る行為は、実は、社内のコンサルを行っていると同じです。
これは、他人がマネできることではありません。
けっして、損しない経験が体験できます。
未来の市民開発者に栄光あれ。
この記事が気に入ったらサポートをしてみませんか？