タグ: ミュスターク

マデリーン・デルーカ著

ちょうど1年前、私はミュゼルクでライツ・マネージャーとしての仕事を始めた。 私がこの仕事に就いた初日は、この会社が初めて正式にリモートワークを開始した日だった。 ビデオ通話や画面共有、そして昔ながらの試行錯誤を通じて新しい仕事のやり方を学ぶというユニークな経験をした。 このパンデミック以前に学ぶ機会がなかったかもしれない新しいスキルを身につけることができた。

そのような思いから、私はミュゼルクの同僚たちに、この1年間で彼らにとって有益だったお気に入りのコツや秘訣を教えてくれるよう頼んだ。 これを読んでいる人が、在宅ワークの経験をより良いものにするためのアドバイスや情報を、少なくともひとつでも見つけられることを願っている。

1. すぐに行動する必要のない仕事上の考え専用のメモ帳を物理的に用意しておく。 深夜や早朝に時間外労働ができるからといって、そうしなければならないわけではない。 勤務時間外に考えた仕事はすべて書き出し、翌日のために取っておく。
2. 日中、特に暖かいときに散歩をする。 ストレスを軽減することができる。 在宅勤務の利点は、昼間に散歩して新鮮な空気を吸えることだ。 頭をすっきりさせて集中力を高め、午後3時のスランプを乗り越えることができる。
3. キーボードショートカットを覚えて使う。 自宅で仕事をする場合、モニターからプラグを抜いて別の場所で仕事ができるのはありがたい。 キーボードショートカットを使えば、タブやワークブック間をスムーズに移動できる。
4. ポモドーロ・テクニックを使ってみよう。 ポモドーロ・テクニックとは、作業時間をインターバルに分け、各インターバルの終わりに休憩時間を設定する時間管理法である。 常に邪魔が入るため、目の前のタスクに集中するのが難しいという人は、このテクニックを使うことで、より効率的に目の前のタスクをこなしながら、忍び込んできた雑念を処理するために休憩を取ることができる。
5. ズームを活用しよう。 Zoomをツールとして使い始めて1年が経とうとしている今、私たちはZoomを呪いながらも祝福しているが、過去に電話でしか話したことがないような人たちとビデオ会議をするのは素晴らしいことではないだろうか？
6. 時間ではなく、実際の仕事の進捗状況に基づいて、生産性の週次および日次目標を設定する。 誰にでも1日／1週間で達成したい目標があり、時にはそれに圧倒されることもある。 たとえ一日中、食器洗い機や芝刈り機、洗濯機などの音に邪魔されたとしても、作業時間ではなく具体的なタスクに基づいて目標を設定すれば、達成感と生産性を感じることができる。
7. 朝の習慣を持ち、それを守る。 ベッドから起き上がり、ノートパソコンを持って仕事を始めるのはとても簡単だが、経験上、これはワークライフバランスを損なうことになりかねない。 コーヒーを淹れたり、散歩に出かけたり、ポッドキャストを聴いたり、朝食を食べたり、本を読んだりするのに十分な時間を持って起床する。 一日を区切る個人的な時間を確保する。 ノリに乗ってしまえば、毎日がもっと楽しく感じられるはずだ。 また、オフィスに戻ってもこのルーチンを続けることができ、その移行はよりシームレスに感じられると思う。

私はこれらのヒントを何らかの形で仕事のルーチンに取り入れ、在宅勤務の経験を劇的に向上させた。 個人的には、また安全に集まれるようになるのが待ち遠しいが（そして実際に同僚に会えるのが待ち遠しい-初めて会う同僚もいる）、それまでの間は、快適なソファで仕事をしたり、毎日の通勤がなくなり、夫と過ごす時間が数時間増えたり、ランチタイムに無限に思える量の洗濯ができたりするのを楽しむつもりだ。

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

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

アプリケーションの展開

スケーリングの最も重要な側面は、アプリケーションをプログラムでデプロイできることだろう。 それさえできれば、あとは施設に過ぎない。 ここでの明白な答えは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ワークフローの改善や、私たちが生成したデータで行っている膨大な処理への統合に努めています。 それまでは、私たちがこの最後のフロンティアへの旅の途中で学び、実践してきたことを記事に埋め戻していくつもりだ。

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

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

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

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

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

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

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

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

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

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