同じ言葉が三つのシステムで違う意味になる

一言でいうと

「アクティブ顧客は何人ですか」という質問に3人が3つの数字を答え、3つとも正しいことがあります。用語を識別子に結びつけておかないと、その後のすべての数字が静かに食い違います。

なぜ必要なのか

現場に入って2日目ごろには、会議に呼ばれます。誰かが「先月のアクティブ顧客は何人でしたか」と尋ね、営業担当が34,000と言い、請求担当が31,000と言い、運用担当が26,000と言います。3人は互いに不思議そうに顔を見合わせます。

誰も間違っていません。営業システムは顧客テーブルの状態文字がAの行を数え、請求システムは請求可能なアカウントを数え、運用システムは直近30日以内にログインした人を数えました。3つの定義は、それぞれの業務ではすべて正しいものです。間違っているのは、1つの言葉が3つの定義をすべて含んでいると信じたことです。

この食い違いが怖いのは、エラーとして表れないからです。クエリは成功し、ダッシュボードは数字を描き、レポートは印刷されます。表に出るのは、たいていその数字で何かを決めたあとです。

どう動くのか

直し方は、言葉を禁止することではありません。人々はこれからも「顧客」と言い続けるでしょうし、そうあるべきです。代わりに、言葉と識別子を結ぶ表を作ります。用語1つについて、システムごとにどのテーブルのどのカラムをどんな条件で選んだものなのかを1行ずつ書けば、そのときから、数字が食い違っても説明がつきます。

対照表の1行に入れるのは4つです。システム、テーブル、識別子カラム、そして条件です。条件が抜けると、表は半分しか役に立ちません。「アクティブ」の違いは、テーブルではなく条件にあるからです。

表を作ったあとは、数字で確認します。同じ名前の集合がシステムごとにどれだけの大きさなのか、2つの集合がどれだけ重なっているのかを測ります。重なりは積集合と差集合で見て、1つの数字に絞りたいときはジャッカード係数を使います。

자카드 계수 = |A 교집합 B| / |A 합집합 B|

1.0  두 집합이 완전히 같다        — 이름이 같아도 괜찮다
0.8  대체로 같고 한쪽이 조금 넓다  — 경계 조건을 확인한다
0.0  겹치는 것이 없다             — 같은 이름을 쓰면 안 되는 관계다

ここで、ほとんどの人がつまずく場所がもう1つあります。2つの集合を比べるには、「同じもの」とは何かを先に決めなければなりません。人をメールアドレスで結ぶとします。営業システムにはUser07@Example.comが、請求システムにはuser07@EXAMPLE.COMが、運用システムには末尾に空白が付いたuser07@example.com が入っています。この3つを同じものとみなすのでしょうか。

RFC 5321の2.4節は、この問いに正確な答えを出しています。メールアドレスのローカルパート(@の前)は大文字小文字を区別します(MUST BE treated as case sensitive)。一方、ドメインはDNSのルールに従うので区別しません。規格どおりなら、User07@Example.comとuser07@example.comは別のアドレスです。同じ節は続けて、ローカルパートの大文字小文字を実際に区別して使うことは相互運用を損なうので勧めないとも書いています。

現場で使う正規化は、次のどちらかです。

規格に従う正規化: 空白を取り除き、ドメインだけを小文字にします。ローカルパートには手を付けません。
システムの実際の動作に従う正規化: すべて小文字にします。大半の社内システムはこのように動作します。

どちらが正しいかは、文書ではなくその顧客のシステムが決めてくれます。大切なのは選ぶこと自体ではなく、選んだルールを書いておき、すべての集計に同じルールを使うことです。ルールを変えると、重なりがまるごと変わります。上の3つのシステムは、規格どおりに見れば重なる人が1人もおらず、すべて小文字にそろえればほとんど全部が重なります。

現場での姿

1つ目に、名前が同じで中身が違うものより、名前が違って中身が同じもののほうが多く見られます。営業はemail、請求はbilling_email、運用はlogin_emailと呼びますが、3つとも同じ人を指しています。名前が違うので誰も照合せず、3つのシステムに同じ人が3回入っていることを誰も知りません。

2つ目に、まったく違うものに同じ名前が付くこともあります。倉庫運用チームは「注文」という言葉を倉庫の作業指示という意味で使います。営業の注文300件と運用の注文180件は、重なるものが1つもありません。こうした関係は、ジャッカードが0になってすぐに表れます。表さえあれば5分でわかることを、知らないために2週間さまようことになります。

3つ目に、対照表を議事録に書くと消えてしまいます。ファイルとして置いて、集計ツールがそのファイルを読むようにしなければなりません。そうすれば、用語の定義が変わるときに数字も一緒に変わり、変わらなければ誰かが対照表を直していないという意味です。

4つ目に、衝突を見つけたからといって、すぐに直そうとしてはいけません。3つのシステムの「アクティブ」の定義を1つに統一しようという提案は、3つのチームの業務を同時に変えようという話です。最初の週にすべきことは統一ではなく、レポートごとにどの定義を使ったかを書くことです。

実務で本当に大切なこと

言葉を禁止せず、識別子に結びつけます。人々はこれからも自分の言葉を使います。
条件まで書きます。アクティブの違いはテーブルではなく条件にあります。
正規化ルールを先に決めて、すべての集計に同じものを使います。ルールが変われば答えが変わります。
数字で確認します。用語の衝突は、意見ではなく集合の大きさと重なりで証明します。

次のラボですること

(架空の)ハナ流通のシステム3台を1つのファイルにまとめたスナップショットを手にします。3つのシステムが「顧客」「アクティブ」「注文」をそれぞれどのテーブルのどのカラムをどんな条件で呼んでいるかを対照表に書き、集合の大きさを測り、2つのシステムずつ比べて重なりを出します。そのあと、識別子の正規化を規格どおりに1回、システムの実際の動作どおりに1回適用して、答えがまるごと変わることを見ます。採点ツールは、毎回違うテーブルと値で作ったデータベースで、作成した集計ツールを実際に動かして数字を照合します。最後に、名前が同じで集合が違うものと、名前が違って集合が同じものを分けて、レポートにして出します。