カテゴリー: テクノロジー

牛はペットではない」という言葉を初めて耳にしたとき、それは私がクラウド向けの開発をする際に常に意識していたものの、表現する言葉がなかったコンセプトを説明するのにぴったりの比喩だった。 クラウドインフラから個性を排除し、リソースを家畜のように名もなくダイナミックに扱うべきだという考え方だ。 資源は常に行き来しているため、名前を付け、餌を与え、ペットのように世話をする時間はない。

スーパーヒーローやディズニーのキャラクター、あるいはドクター・フーの悪役のような、極めてオタク的な名前を冠したサーバーを設置している場所に行ったことがある人は多いだろう。 しかし、スケーラビリティについて話し始めると、キャラクターは十分に速く想像することはできない。 アプリケーションの新しいインスタンスを何度も立ち上げるために必要な手作業は言うまでもない。 ミュサーク用にクラウドインフラを開発する際、最初の目標はインスタンスに直接接続しないことでした。 これは、アプリケーションをどのようにデプロイし、ステートを管理し、発生した問題をデバッグするかという疑問に答えるための素晴らしい出発点だと感じた。 これは主に、ミュゼルクの黎明期にどのように事業規模を拡大し始めたかについての定性的な考察である……。 だから、超オタクの皆さんのために、ロードバランシング、キャッシュ、インフラストラクチャー・アズ・コードなどの詳細については説明しない。

アプリケーションの展開

スケーリングの最も重要な側面は、アプリケーションをプログラムでデプロイできることだろう。 それさえできれば、あとは施設に過ぎない。 ここでの明白な答えはDockerだ。 より高度な答えにはKubernetesやTerraformが関わってくるが、それはまた別の日にしよう。 コンテナ化されたアプリケーションでは、依存関係、バージョン、オペレーティング・システム、前もって行う必要のあるあらゆる設定を制御できる。 つまり、必要なのはコンテナを動かすプラットフォームだけだ。 この利点は、このプラットフォームが何でもあり得るということだ！ このコンテナは、dockerをサポートする場所であればどこでも、我々が必要とするものを全く同じ方法で実行する。 これらのコンテナを1つ起動するプロセスが自動化されれば、あとはいくつでも自由に起動でき、ロードバランサーがトラフィックを適切にルーティングできるようになる。

国家管理

次に、本質的にゴミであるサーバー・インスタンスの状態をどのように管理するかという問題がある。 ディスクへの書き込みは、インスタンス間ですべての情報が失われるため、問題外だ。 NFSはどうなんだ？ これはもっともな解決策かもしれないが、プロビジョニングされたIOP（クラウドでは高価）がなければ遅すぎる。 それに、もっとうまくやるべきだ！

実際、これがデータモデルを磨き上げる出発点となり、ある種のETLの第一段階を考え出さざるを得なかった。 データを取り込む際、アプリケーションが一貫した方法でデータにアクセスできるように、データをどのように保存すればいいのだろうか？ すべてのデータが一か所に集まれば、それを「真実の情報源（Single Source of Truth）」として使うことができる。 データベースをSSOTとして使うことは、それ自体が複雑だ。 スケーラブルなインフラ全体でステートを管理するための本当の教訓は、できる限りステートを避けることだ。

デバッグ問題

最も一般的なのは、個々のインスタンスにログインする必要があるのは、通常、何が問題だったのかを把握するためである。 リソースがスケールし始めると、エラーは4台、10台、あるいは理論的にはn台のインスタンスのいずれかで発生する可能性があるため、いずれにせよこれはますます難しくなる。 では、どこで問題が起きているのかを把握し、それを解決するにはどうすればいいのか。 アプリケーション全体で監視すべきことはいろいろある。 ユーザーエクスペリエンス、リソースの傾向、ロード時間などはその一例だ。 私が思うに、最も重要なのはエラーログである。

エラーが発生したら、それを知らせてほしい。 最初のパスでは、ロガーを使うべきである。 ロガーは、ログの種類ごとにカテゴリーを割り当て、重大度順に並べることで、新しいログの作成方法を標準化することができる。 一般的なカテゴリーには、DEBUG、INFO、ERRORなどがある。 この例では、DEBUGレベルのログは、何が起こったかを解明するのに役立つ情報かもしれないが、常に目を通す必要はない。 INFOレベルのログは、もう少し深刻度を増している。 これらのメッセージは、使用状況をリアルタイムで確認できるよう、常に見ておきたいものだ。 ERRORログは、最も深刻なもので、警告を発することができる。 ERRORが記録されたときに報告するようにシステムを設定することで、即座に対処することができます。 INFOログとDEBUGログを使って、何が起こったかを特定することができる。 正しく実行できていれば、これらのログはアプリケーションが動作しているマシン固有の情報を持っているので、ハードウェア固有の問題に対処することができる。 すべてのアプリケーションのすべてのマシンからログを収集できるようになれば、各アプリケーションを対象としたダッシュボードを構築し始めることができる。 利用状況やハードウェアの指標と組み合わせることで、関連するすべての情報を一元的に見ることができる。

ご自身のクラウドインフラを考える上で、少しでも参考になれば幸いだ。 私たちは建築の改良を続けながら、もっと多くのことを分かち合いたいと考えている。 私たちは日々テクノロジーを進化させ、ETLワークフローの改善や、私たちが生成したデータで行っている膨大な処理への統合に努めています。 それまでは、私たちがこの最後のフロンティアへの旅の途中で学び、実践してきたことを記事に埋め戻していくつもりだ。

音楽業界の製品革新といえば、音楽制作の新しい方法と、ファンがそれを消費する新しい方法が中心だ。 ピアノロールにさかのぼれば、自分の好きな音楽を自分の家で機械に演奏させるというアイデアは素晴らしいもので、これがピアノロールや、より優れた 演奏のニュアンス（ダイナミクスやアタックなど）をよりよく捉え、再現するプレーヤー・モジュールへと反復されていった。 ウェルテ・ミニョンは、ドビュッシーが意図したとおりにドビュッシーを演奏する大衆をもたらした！ この自然な流れは、蓄音機、ラジオ、映画、テレビ、カセットからCD、ストリーミングなど、業界の歴史を通して見ることができる。 新しいテクノロジーが私たちに多くの音楽を聴かせてくれるようになるにつれ、ビジネスや管理サイドは、機械使用料、演奏権協会、新しいメディアに対する権利のライセンスなど、権利を適切に管理・利用する方法を常に模索してきた。 しかし、ビジネス面におけるマクロレベルでの進歩の一方で、革新の余地はまだ多く残されている。 課題は、音楽の生産と消費が与えられてきたのと同じレベルの革新をもって、業界のビジネスと管理面をどのように製品化するかということだ。 探検しよう……。

そもそも製品とは何か？

この作品では、製品とは、使用可能で生産的で満足のいく体験を生み出すために、ブランドとともにパッケージ化された部品や商品の集合体であり、その後販売されるものと呼ぶことにしよう。 え？ これは例を挙げて説明した方がいいかもしれない：

鉄の束、サードパーティ製の機械加工部品、タイヤ、コンピューター、全輪駆動システムなどは、SUVを作ることができる「部品と商品の集合体」である。

スバルのような “ブランドとパッケージされた “SUVは、スバルのSUVモデルのひとつを私たちにもたらすかもしれない。

目的地まで、マウンテンバイクを積んで森の中を、スキーを屋根に積んで雪の中を、サーフボードを積んでビーチまで（生産的な）車を走らせることができる。

つまり、音楽の場合、Spotify®やApple Music®アプリのような製品は、ライセンスされた音楽（商品）の集合体であると表現できる。 どのような商品であっても、同じような練習をすることで、なぜある商品が他の商品より選ばれるのか、なぜあるブランドが他のブランドより成功しているのかが見えてくる。 ミュセルクの製品開発では、このエクササイズを、目の前にある真の問題を特定し、その問題に正面から取り組むソリューションを構築するプロセスを開始する手段として使用しています。 では次に、音楽ビジネスにおけるイノベーションについて、私たちに何ができるかを考えてみよう。

ペインポイントと問題を混同しない

ミュセルクでは、業界の課題の根本に焦点を当て続けている。 私たちは、大まかなペインポイントを特定し、それが問題であるかのように装うことをやめるよう努力している。 実際、それが症状なのだ。 その代わり、それぞれのプロセスで、それらを分解し、並べる。 私たちの業界では、著作権や使用料の徴収、透明性の欠如など、ピンポイントで問題を指摘することに事欠かない。 音楽業界のパネルに参加したことのある人なら誰でも、私たちが業界の問題を特定することに長けていることを知っている。 残念なことに、パネルディスカッションはニューヨークの生協の株主総会と同じように、昨年と同じようなことに文句を言いながら、現実的な解決策を示さないこともある。 時折、解決策が怒りにさらされることさえある。色あせた人々は、現在の状況と、彼らにとって良い変化をもたらすかもしれない変化の両方を同じように恐れている。 あるいは、特定されたペインポイントの山を取り、個々の問題に分解し、プロセス内での位置を特定するために順番に並べることで、重要な依存関係（つまり、非常に重要な障害点）への影響を明らかにすることができる。 こうした現実的な問題に焦点を当てることが、効果的な解決策につながるのだ。 例えば、パーソナル・ファイナンスの場合、「お金が足りない」というのは、誰もが一度は直面する問題である。 それが崩れるのは、収入に問題があるか、支出に問題があるためだ。 収入の問題であれば、総支給率が低すぎるか、率が適用される時間数／日数が少なすぎることが考えられます。 あるいは、給料の差し押さえやその他の源泉徴収によって、手取りが影響を受けているかもしれない。 あなたの問題はピボットさえするかもしれない。 税引き前の退職金拠出が手取り収入に影響し、外食やコーヒーの習慣を支えられないことに気づくかもしれない。 あなたは、30年間の複利の方が、昼食やコーヒーを作らない利便性よりも実際に優れていると判断し、あなたが感じている収入の問題は、実際には支出の問題なのだ。 解決策：コーヒーもランチも自分で作る！

特定し、アレンジしよう

私たちミュゼルクは、この業界の大きな悩みのひとつを解消しています：

…権利者がいくら稼ぐべきなのか見当もつかないが、もっと稼ぐべきだという強い思いがある…

このペインポイントは、世界中に広がる膨大なプロセスに埋め込まれた、根本的な問題の症状なのだ。 レコーディング業界と出版業界は、多くのデータパイプライン、サプライチェーン、権利の種類、媒体、プラットフォーム、ライセンス形態によって細分化されたロイヤリティの流れで構成されている。 これらのロイヤリティ・ストリームは、地域市場の商習慣、著作権法、能力の影響を受ける。 絶え間なく台頭する音楽プラットフォームは、新たなライセンシング構成で新たなロイヤリティの流れを生み出し、すでに複雑な業界に複雑さを加えている。 だから、この問題を解決 するために意味のある製品を作ろうとするならば、包括的な問題を構成する大きな小さな問題をリストアップすることから始めよう：

1. DSPに音楽は入っているが、再生されていない
2. アーティストページに音楽が添付されていない
3. 自分の曲のカバー・バージョンで報酬を得られない
4. 自分のコンポジションにリンクしているISRCを見つける方法がない
5. リリースから1年、ソングライターの分裂も決まらず
6. ラジオ出演のPROマネーを集められるが、DSPからのメカニカルはなし
7. 米国内での活動に対しては徴収できるが、国際的な活動に対しては徴収できない。
8. 米国以外のすべての活動に対して徴収できること。
9. 出版資金を得るための作品登録の方法がわからない
10. マスターのカタログを取得したが、有用なメタデータがない
11. リミックスのギャラを受け取らない
12. 音楽プラットフォームが提供する2,200万行の利用データから473作品を見つけられず

…契約条件やロイヤリティ・レートについて言及する前に、永遠に続けることができるだろう。

手配開始

プロセスの順序を整理していくと、ある問題がその前の別の問題の結果であったり、その問題がさらに先の大きな問題を引き起こしていたりすることが分かってくる。 例えば、作品データを自動で世界中に配信し、データの集計と配信を支援するソリューションがあるかもしれないが、それでは世界中のデータベースに誤った情報が効率的に入力されてしまう。 おっと！ 課題は、ある分野の問題を解決したときに、別の分野の問題が発覚する可能性を予測することである。 この方法でソリューションを開発すると、最も複雑な問題でも一度にひとつずつ解決できることがすぐにわかる。 アジャイル・アプローチと組み合わせることで、多くのソフトウェア開発チームが開発に取り組んでいる。 移動する……。

自分が知っているものは直し、それ以外は音楽以外の業界からヒントを得る。

新鮮な視点が問題への新しい革新的なアプローチ方法を発見することは、誰もが認めるところである。 この件について私と話したことのある人なら誰でも、私が業界外で解決策を見つけることに関しては壊れたレコードであることを知っている（ダジャレのようなものだ）。 つまり、上記の例で言えば、データ入力の問題と配送の問題がある。 通常、私たちは業界内で解決策を探す。 しかし、同じような問題を解決して大きな成功を収めている業界を見ることは、かなり参考になるとミュサークは考えている。 データ入力の問題では、eコマースとチェックアウトプロセスについて考えてみよう。 オンラインで商品を購入したことがある場合、ショッピングカートに移動し、住所、CC情報、送料などを入力する。 企業はショッピングカートの放棄を嫌い、あなたが購入を完了するようにできることは何でもする。 音楽のメタデータを正確にシステムに取り込みたいのであれば、デザイン、UX/UI、情報収集などの面で、eコマース・ショッピングカート業界は何かを掴んでいるのかもしれない。 他の産業ですでに解決されている問題は数え切れないほどある。

本当に役に立つものを作ること、そして絶え間ない反復

今や、権利管理は多くの直線的なプロセスで構成され、それぞれが多くの障害点にさらされていることは、誰もが認めるところである。 どこかを改善すれば、他の部分の欠点が増幅される可能性があることを常に知っておくことが重要だ。 あるいは、ある分野での高性能な機能が、連鎖の下の弱いリンクによって役に立たなくなることもある。 離陸時に機体全体をバラバラにするだけなら、小型プロペラ機にジェットエンジンを搭載する理由はない。 ミュゼルクでは、一つの機能を構築しても、それをサポートするインフラ、それを統合するワークフロー、それを使用する人材がいなければ意味がないと考えています。 音源と音楽作品のリンクを発見するMuserkのAIマッチング技術であるMMatchは、概念実証の段階では、シニア開発者と技術に精通したライツ・マネージャーが実行する必要があった。 ライツマネージャーがさまざまなデータ形式を入力するためのUIや、MMatchの出力データを使える ようにするための自動化されたステップができるまでは、このテクノロジーはチームの誰にとっても利用しやすく、その結果、より頻繁に使われるようになった。 生産性が一気に向上した今、私たちはそこで止まってしまうのだろうか？ いや。 この時点で、我々は業界の需要に追いつかれることなく、反復する準備ができている。 この点で、技術の世界は厳しいかもしれない。 製品のバージョンや機能が「ベータ版」から「非推奨／廃止」になるのは、ほんの数年以内のことだ。 MMatchがチームに広く使われるようになると、ライツマネジメントは何日分もの作業を突然1時間以内に完了できるようになったことに歓声を上げたが、この大幅な改善により、ボトルネックが使用状況の発見からステージングデータ、そしてMMatchに続く分析へとシフトしたことを理解した。 労働の日々がなくなったのは事実だが、なぜそれだけにとどまるのか？ なぜMMatchを他のユースケースに適用しないのか？ あるいは、もっといいのは、この素晴らしい製品を、“使用可能で、生産的で、満足のいく体験を生み出すために、ブランドとともにパッケージ化された部品と商品 ” のひとつにすることだ。製品開発が連続的なサイクル、あるいは拡大スパイラルに似ているのはこの時点である。 産業や他業界のある分野における革新は、かつては単独で効果的なソリューションとして機能したが、その後、より大きな将来の製品の要となる。

では、復習してみよう。 私たちは、単に不満をぶちまけるだけでなく、問題を特定するようになった。 これらの問題が大局に及ぼす影響を理解することから、真の解決策を思いつくことまで。 音楽業界のビジネスサイドは、テクノロジーの面で長い道のりを歩むことになるが、私自身は、ミュゼルクが今後見られるであろう膨大なイノベーションの一部となり、音楽業界の近代化に貢献することを楽しみにしている。

「ナッシュビルにはソングライティングの長い歴史がある。

これは、2017年秋にここに引っ越してきたときに何度も耳にしたことだった。 当時は、この発言が音楽業界の運営方法についての洞察であることを理解していなかった。 私にとって、”ソングライター “という言葉は、”アーティスト “や “ミュージシャン “という言葉と大差なかった。 私は好きなアーティストの曲を演奏したり、自分で曲を作って演奏したりして育ってきた。 僕にとってはすべて音楽だった。 音楽業界は、特にナッシュビルにおいては、非常に明確な区別のもとに動いていることに気づいたのは、後になってからだった。

ナッシュビルで初めて行ったライヴのひとつが、ベルコート・タップスというダウン・ホーム・タイプの会場だった。 このショーは、4人のソングライターがステージに並んで座り、交代で最近書いた曲を演奏するという “in the round “スタイルのショーケースだった。 私が引っ越したオースティンでは、このようなショーに遭遇したことはなかったが、ここでは標準的なやり方だと感じた。 驚いたことに、特にソングライターの一人はとても下手なミュージシャンだった。 彼のギター演奏はミスノートが多く、チューニングを合わせて歌うのに苦労していた。 しかし、魅力的だったのは、彼がまったく気にしていないように見えたことだ。 彼は聴衆にもっと興味を持ち、自分の歌に対する反応を測ろうとしていた。 私はすぐに、彼がこれらの曲を自分で演奏することに関心がないことに気づいた。 彼の目標は、自分の曲を最も面白い形、つまり3分半の珠玉の曲に磨き上げることだった。 コメディアンがジョークをうまく言えるようになるまで何度も何度も練習するのを思い出した。 これは、音楽業界がいかにアーティストとソングライターを明確に区別しているかということを初めて知るきっかけとなった。

それから約1年後、私はミュゼルクでソフトウェア開発者として働き始めた。 ミュサークは、テクノロジーを活用し、卓越したスピードとスケールで業務を遂行するグローバルなライツ・アドミニストレーターです。 私は、技術者としてのキャリアと音楽への愛を結びつける機会に興味をそそられた。 さらに、音楽業界のビジネス面について学ぶチャンスでもあり、自分の音楽活動にも役立つと思った。

仕事を始めてすぐに、私は権利管理という非常に複雑な世界に放り込まれた。 私の最初のプロジェクトのひとつは、後にM-Matchとして知られることになる、膨大なDSPデータの海から作品を探し出すための当社独自のAI技術の開発だった。 その中で、私は音楽業界の儲け方の複雑さを学んだ。

音楽産業は2つの著作権から利益を得ている。1つは原作または作曲に対するもので、もう1つは録音に対するものだ。 実際には、出版社（ソングライター／作品）とレーベル（アーティスト／録音）という2つのタイプのビジネスが存在する。 つまり、Spotifyで曲を再生した場合、その曲から発生するお金の一部はレーベル／アーティストに、一部は出版社／ソングライターに渡るはずだ。 Spotifyのような会社なら、このようなことを事前にすべて知っていて、対処してくれるだろうと思うかもしれない（私もそうだった）。 そうではない。

大きな問題のひとつは、レーベル界と出版界がお互いに話をしないことだ。 つまり、レーベルはSpotifyに楽曲をプッシュし、根本的なソングライターに関する情報を提供しない（場合によっては、それすら知らない）。 そのため、スポティファイは出版社／ソングライター部分の送金先を知ることができない。 これはかなり簡略化されたものだが、正確な説明である。

ミュゼルクが輝くのはここからだ。 私たちは、適切な印税を徴収・分配できるよう、ソングライター関連のメタデータと音源のマッチングにほとんどの時間を費やしています。 デジタル音楽の時代において、これは容易なことではない。 私たちはあらゆる種類のテクノロジー、プロセス、洞察力を駆使して、可能な限り多くのデータを照合する。 私たちは、作品を迅速かつ正確に、そして大規模にマッチングできるよう、常に革新に努めています。 私はこのテクノロジーを構築し、その結果を伝える方法を生み出すことにほとんどの時間を費やしている。 自分の仕事がミュージシャンに正当な報酬が支払われることに貢献していると思うと、誇らしい気持ちになる。

ミュージシャンとして、ミュゼルクで過ごしたこれまでの時間は、音楽界の本当の仕組みに目を開かせてくれた。 私は、企業が業界のごく小さな部分に完全に専念していることを学んだ。 例えばナッシュビルでは、次のヒット曲を作ろうとする人たちのネットワークがあり、レコーディングや演奏には関心がない。 同時に、次のビッグ・アーティストになろうとしている人々のネットワークがあり、自分の曲を書くことなど気にも留めていない。 僕にとっては、自分がどこにフィットするのか、まだ見つけようとしているところなんだ。 しかし、業界全体をより広く理解することは、私自身の音楽の旅をナビゲートするのに役立つと思う。 そしてもちろん、私のメタデータは正しいものになる。

次のヒット曲は、レコーディングも演奏もどうでもいい。 同時に、次のビッグ・アーティストになろうとしている人々のネットワークがあり、自分の曲を書くことなど気にも留めていない。 僕にとっては、自分がどこにフィットするのか、まだ見つけようとしているところなんだ。 しかし、業界全体をより広く理解することは、私自身の音楽の旅をナビゲートするのに役立つと思う。 そしてもちろん、私のメタデータは正しいものになる。

ミュ-ザ-クでは、作曲著作権者に代わってロイヤリティの請求に多くの時間と労力を費やしています。 このプロセスの一部には、クライアントから受け取ったメタデータと、ストリーミング・サービスによって生成されたメタデータの照合が含まれる。 これはレコード・リンケージとして知られている。 タイトルとライターの情報しかないこともある。 この場合、まず何らかのテキスト検索を行うことを考えるかもしれない。 しかし、ストリーミングサービスは世界中のユーザーからの投稿（およびメタデータ）を受け入れるため、この方法では作曲を正しく特定することが難しくなっている。 この問題を解決するために使うテクニックのひとつが、ファジーマッチングと呼ばれるものだ。

ファジィ・マッチングは、関連する情報を結びつけるルールがファジィである場合に、関連する情報について結論を導き出すために使うことができる。人間である私たちは常にこれを行なっており、目標はそれをコンピューターで再現することである。 このプロセスにより、完全一致でないテキストレコードを取り出し、それらが関連している可能性を判断することができる。 ある曲を含むすべての動画のYoutubeメタデータを見たいとする。 私たちが目にするのは、多種多様なメタデータの集合である。 例を挙げて説明しよう：

曲名オール・マイ・ラヴィング
作家ジョン・レノン｜ポール・マッカートニー

この曲のレコードの例を2つ紹介しよう：

記録	タイトル	ライター
1	オール・マイ・ラヴィング	ジョン・レノン／ポール・マッカートニー
2	オール・マイ・ラヴィング	ジョン・レノン、ポール・マッカートニー

この2つの記録に同じ作品が含まれていることは明らかだが、この判断にどのようにアプローチすればいいのだろうか？ ルックアップのようにテキストを直接比較すると、”/”と”, “の文字がライターズ・フィールドにあるとミスマッチになる。 では、これらを同じ作品としてプログラム的に識別するにはどうすればいいのだろうか？

ひとつのアプローチは、分析する前にまずテキストを「トークンセット」に変えることだ。 この方法では、スペースと句読点で分割して、各エンティティから単語のリストを作成することができる。 そして、それらのリストをファジーアルゴリズムにかけ、類似性を判断する。 ライターのメタデータで試してみよう。 各記録から単語のリストを作成し、それらのリストをアルファベット順に並べると次のようになる：

リスト1＝【ジョン、レノン、マッカートニー、ポール
リスト2＝【ジョン、レノン、マッカートニー、ポール

素晴らしい！ ここで、リストをファジー・アルゴリズムで単語ごとに比較し、完全に一致することを見つける！ この基本的なファジィ照合アルゴリズムにより、2つのレコードを適切にリンクさせることができる。

では、もっと難しい記録に挑戦してみよう：

記録	タイトル	ライター
1	オール・マイ・ラヴィング	レノン／マッカートニー
2	オール・マイ・ラヴィング	ポール・ジェームズ・マッカートニー、ジョン・ウィンストン・レノン

ここでは、同じ作品に異なるメタデータをつけている。 同じアプローチを使えば、作家のリストは以下のようになる：

リスト1＝【レノン、マッカートニー
リスト2＝【ジェームス、ジョン、レノン、マッカートニー、ポール、ウィンストン

リスト2にはリスト1の単語がすべて含まれている。 別のファジーアルゴリズムのアプローチでは、まず同一の単語を削除し、それから前と同じファジー分析を実行する。 そうすると、次のような言葉が残る：

リスト1 = [].
リスト2＝【ジェームズ、ジョン、ポール、ウィンストン

リスト1が空になったことがわかる。 これをファジー・アルゴリズムにかけると、比較するものが何もなくなるため、100％の一致が返される。 これを要約すると、リスト2にはリスト1の全記録が含まれており、したがって両者は関連レコードである、ということになる。 この方法は完璧ではないが、大半のケースに役立つ。

さまざまなユースケースに対応できるよう、あらゆる種類のファジーマッチング・アルゴリズムがあり、ファジーマッチングはデータパイプラインの1ステップに過ぎない。 テキスト比較を実行できるほとんどのソフトウェア・パッケージは、ある種のファジーマッチ機能を備えている。 今度同じようなことがあったら試してみよう。 あなたに欠けていたツールかもしれない！