カテゴリー: ビジネス

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

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

アプリケーションの展開

スケーリングの最も重要な側面は、アプリケーションをプログラムでデプロイできることだろう。 それさえできれば、あとは施設に過ぎない。 ここでの明白な答えは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を他のユースケースに適用しないのか？ あるいは、もっといいのは、この素晴らしい製品を、“使用可能で、生産的で、満足のいく体験を生み出すために、ブランドとともにパッケージ化された部品と商品 ” のひとつにすることだ。製品開発が連続的なサイクル、あるいは拡大スパイラルに似ているのはこの時点である。 産業や他業界のある分野における革新は、かつては単独で効果的なソリューションとして機能したが、その後、より大きな将来の製品の要となる。

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