仕事に効くコンピュータサイエンス
情報は一箇所に — データベース読了目安 10分

同じ名前を何度も書かない — 正規化とマスタ管理

取引先の住所が変わったのに、請求書には旧住所が印字されてしまった。そんな経験はないでしょうか。確認すると、担当者の手元のファイルだけが更新されておらず、共有のマスタには反映されていなかった、というのはよくある顛末です。このページでは、なぜ同じ情報を何度も書き写すと事故が起きるのか、そしてどう防げばよいのかを、「正規化」という考え方から見ていきます。

CS概念の直感

正規化とは、同じ事実を複数の場所に重複して持たないように、情報の置き方を整理することです。データベースの世界では、顧客の名前や住所のような情報を「顧客マスタ」という一つの表にまとめ、注文の記録には顧客の名前をそのまま書き写すのではなく、「どの顧客の注文か」を示す番号だけを書いておく、という設計をよく使います。名前や住所そのものは顧客マスタという一箇所だけに存在し、他の表からはその一箇所を指し示すだけにする。これが正規化の基本的な発想です。

なぜこの発想が必要なのでしょうか。仮に注文の記録一件ごとに顧客の名前と住所をすべて書き写していたとします。その顧客が引っ越して住所が変わったとき、過去の注文記録すべてを書き換える必要が出てきます。書き換え漏れが一件でもあれば、同じ顧客の住所が記録によって違うという状態が生まれます。どちらが正しいのか、後から見た人には分かりません。マスタを一つにしておけば、変更はマスタの一行を直すだけで済み、注文記録側は「その顧客を指し示している」という関係を保ったまま、最新の住所を参照できます。

正規化という言葉自体は「規則に正しく合わせる」という響きを持っていますが、本質はもっと単純です。「一つの事実は、一つの場所にだけ書く」という約束を、表の設計として徹底することです。顧客の住所という事実、注文の日付という事実、商品の価格という事実。それぞれの事実について「これを書いてよい場所はここだけ」と決めてしまえば、あとはその場所を指し示す番号や記号だけを、他の表に持たせればよいことになります。指し示す側の表がいくつ増えても、事実そのものは一箇所にしかないため、矛盾が生まれようがない、という状態を作れるのが正規化の強みです。

仕事の言葉に翻訳すると

仕事の場面に置き換えると、正規化は「マスタデータを一元化する」ことに当たります。取引先の名称・住所・担当者・連絡先といった、繰り返し使われる基本情報を、一つの台帳、あるいは一つのマスタファイルにまとめておく。見積書や請求書、契約書といった個別の書類には、取引先の情報をその都度手で入力するのではなく、マスタから呼び出して使う形にする。これにより、取引先の情報が変わったときにマスタを一箇所直すだけで、以後発行するすべての書類に最新の情報が反映されます。

この考え方は、紙の帳票文化から続く「都度手書き」の習慣とは相性が悪いことがあります。手書きや個別入力に慣れていると、マスタを参照する一手間がかえって面倒に感じられるからです。しかし、その一手間は「後で食い違いを調べて直す手間」に比べればずっと小さいものです。最初は手間に感じても、マスタを引く動作が習慣になれば、書類ごとの表記ゆれ(会社名の株式会社の位置や、住所の書き方の違いなど)も自然になくなります。表記ゆれは些細に見えて、後から検索や突き合わせをする際に思わぬ障害になるものです。

もう一つの側面は「コピーそのものを減らす」という発想です。コピーが存在すること自体が、ずれの発生源になります。コピーを完全にゼロにすることは難しくても、「本当に必要なコピーか」「参照で済ませられないか」を都度考えるだけで、ずれの起きる箇所は大きく減らせます。

ここで大事なのは、正規化が求めているのは「情報を隠すこと」ではなく、「情報の出どころを一つに揃えること」だという点です。参照先のマスタさえ見に行けば、誰でも最新の情報にたどり着ける状態こそが目指すべき形です。逆に、マスタがどこにあるのか誰も把握していない、あるいはマスタへのアクセス権限が一部の人にしかない、という状態では、正規化のメリットは半分も生かせません。一元化と同時に「誰もがそこを見に行ける」という利用のしやすさも、セットで設計する必要があります。

具体的な場面(1) 取引先マスタ

営業部と経理部がそれぞれ独自に取引先リストを持っている職場を考えてみます。営業部のリストには商談中の見込み客も含まれ、経理部のリストには請求先の情報が入っています。ある取引先の担当者が変わったとき、営業部のリストだけが更新され、経理部には伝わりません。経理部は古い担当者宛てに請求書を送ってしまい、支払いの確認が遅れます。これを防ぐには、取引先という「事実」を管理する場所を一つに決め、営業部も経理部も同じ取引先マスタを参照する運用に変えることが必要です。どちらかの部署が「マスタの管理者」になり、変更は必ずそこを通す、という取り決めが鍵になります。管理者を一人に決めることに抵抗がある場合は、「変更が発生したら必ずこの一箇所に連絡する」という窓口だけを一つに決める方法もあります。どの部署がマスタを持つかよりも、変更の入り口が一つに揃っているかどうかが本質です。入り口が複数あると、結局はどこかで更新が漏れ、最初の問題に逆戻りしてしまいます。

具体的な場面(2) 帳票のテンプレート

見積書のテンプレートに、自社の会社名や住所を毎回手で入力している職場があります。移転や電話番号の変更があったとき、過去に使ったテンプレートのコピーがあちこちに残っていると、どれが最新のテンプレートか分からなくなり、旧住所の見積書を出してしまうことがあります。テンプレートという「元になる情報」を一箇所で管理し、そこから複製せずに毎回同じファイルを使う、あるいは自動で差し込む仕組みにしておけば、情報が変わったときの修正は一箇所で完結します。

具体的な場面(3) 社内規程と手順書

社内規程や業務手順書が、部署ごとに少しずつ違う版で保管されていることもあります。本社の総務部が最新版を更新しても、支店には古い版がそのまま残っていることがあります。どちらの手順に従えばよいのか現場が迷い、支店ごとに対応が食い違う原因になります。規程という事実の置き場所を一箇所に決め、支店はそこを参照するだけにしておけば、更新のたびに全支店へ配り直す手間も、配り漏れによる食い違いもなくなります。

具体的な場面(4) 人事情報と各部署の名簿

人事部が管理する社員情報とは別に、各部署が独自の連絡網や座席表を作っていることがあります。異動や退職があったとき、人事部のデータは更新されても、部署の連絡網や座席表の更新が後回しになり、退職した人にメールが届き続けることがあります。これは悪意でも怠慢でもなく、更新すべき場所が複数に分かれていることが根本の原因です。担当者を責めても、更新すべき場所の数そのものは減らないため、問題は形を変えて再発します。部署の連絡網を、人事データを都度コピーして作るのではなく、人事データを参照して自動的に生成する形にできれば、更新漏れという事象自体が起こらなくなります。すべてを一足飛びに自動化できなくても、「まず人事部のデータを正として、他はそこから作る」という順番を決めるだけで、食い違いが起きたときにどちらを直せばよいかが明確になります。

落とし穴

正規化には、行き過ぎによる落とし穴もあります。何でもかんでも参照だけにしてしまうと、一件の情報を確認するのに複数の場所を渡り歩かないといけなくなり、かえって手間が増えることがあります。参照が何重にも連なると、一つの数字を確認するために三つも四つもファイルを開く羽目になり、「一元化したはずなのに前より遅くなった」という逆転現象すら起こり得ます。例えば、請求書を発行するたびに毎回マスタを開いて確認する運用は、確認の手間が積み重なって、逆に非効率になる場合もあります。正規化の目的は「事実の重複をなくすこと」であって、「参照の回数を増やすこと」自体が目的ではありません。頻繁に一緒に使う情報は、ある程度まとめて持っておいた方が実務では扱いやすいこともあります。どこまで一元化し、どこは多少の重複を許すかは、変更の頻度と、確認の頻度とを見比べて判断するとよいでしょう。完璧な正規化を最初から目指す必要はなく、「今いちばん困っている食い違い」から一つずつ手をつけていく方が実務では現実的です。変更がめったに起きず、確認だけが頻繁に発生する情報は、まとめて持っていても問題は起きにくいものです。逆に頻繁に変わる情報ほど、置き場所を一つに絞る効果が大きくなります。

もう一つの落とし穴は、「マスタを作った瞬間に安心してしまう」ことです。マスタを一つにまとめても、そこへの入力や更新をきちんと行う運用が伴わなければ、結局は誰かが個人のメモに正しい情報を控え、そちらを頼りにする状態に逆戻りします。マスタが実態と合っていないと分かった瞬間、人はマスタを信用しなくなり、再び各自のコピーを作り始めます。これは正規化という設計の問題ではなく、運用が続かなかったことによる崩壊です。マスタを立てるときは、誰が・いつ・どうやって更新するのかという運用の取り決めまでを、表の設計とセットで決めておく必要があります。更新の担当者が不在のときに誰も直せない、というのも典型的な失敗の形です。更新できる人を複数人に広げておくか、更新の手順自体を簡単にしておくことが、マスタを長く使い続けるための実務上の工夫になります。

持ち帰り

  • 正規化とは、同じ事実を複数の場所に重複して持たないよう情報を整理する考え方
  • マスタを一元化すれば、変更は一箇所を直すだけで全体に反映できる
  • 何でも一元化すればよいわけではなく、変更頻度と確認頻度を見て判断する
  • マスタは作った後の更新運用まで決めて初めて機能する
  • 変更の入り口を一つに揃えることが、更新漏れを防ぐ鍵になる
  • 完璧を目指さず、今いちばん困っている食い違いから手をつける

やってみる

自分の部署で使っている取引先や顧客の情報を、どのファイルが「正解」なのか一度確認してください。複数のファイルに同じ情報が書かれていたら、一つを正とし、他は正から呼び出す形に変える相談を始めてみましょう。どのファイルを正にするかを決めるだけでも、次に同じ情報を更新するときの迷いが一つ減ります。