Submit Search
Upload
業界あるある Music偏
•
Download as PPTX, PDF
•
1 like
•
1,130 views
recotech
Follow
2017年5月25日 業界あるあるLT大会 登壇資料
Read less
Read more
Technology
Report
Share
Report
Share
1 of 12
Download now
Recommended
RecoChoku tech night #09 -reinvent2018報告会- オープニング
RecoChoku tech night #09 -reinvent2018報告会- オープニング
recotech
Reco choku tech night #09 -reinvent2018報告会-
Reco choku tech night #09 -reinvent2018報告会-
recotech
Amazon Kinesis Streams デモ
Amazon Kinesis Streams デモ
recotech
Amazon SageMaker の紹介 + デモ
Amazon SageMaker の紹介 + デモ
recotech
Aws導入時にまず考える〇〇のこと
Aws導入時にまず考える〇〇のこと
recotech
レコチョク・ラボが考える人工知能
レコチョク・ラボが考える人工知能
recotech
Oracle racからaurora my sqlへの移行
Oracle racからaurora my sqlへの移行
recotech
Git hubenterpriseを導入してみて
Git hubenterpriseを導入してみて
recotech
Recommended
RecoChoku tech night #09 -reinvent2018報告会- オープニング
RecoChoku tech night #09 -reinvent2018報告会- オープニング
recotech
Reco choku tech night #09 -reinvent2018報告会-
Reco choku tech night #09 -reinvent2018報告会-
recotech
Amazon Kinesis Streams デモ
Amazon Kinesis Streams デモ
recotech
Amazon SageMaker の紹介 + デモ
Amazon SageMaker の紹介 + デモ
recotech
Aws導入時にまず考える〇〇のこと
Aws導入時にまず考える〇〇のこと
recotech
レコチョク・ラボが考える人工知能
レコチョク・ラボが考える人工知能
recotech
Oracle racからaurora my sqlへの移行
Oracle racからaurora my sqlへの移行
recotech
Git hubenterpriseを導入してみて
Git hubenterpriseを導入してみて
recotech
Swaggerを利用した新規サービス開発
Swaggerを利用した新規サービス開発
recotech
レコチョクのサービス群を支えるApiたち
レコチョクのサービス群を支えるApiたち
recotech
そうだApi公開しよう feat. 有志のエンジニア
そうだApi公開しよう feat. 有志のエンジニア
recotech
Mackerel x Twilio ~レコチョクの場合~
Mackerel x Twilio ~レコチョクの場合~
recotech
#reco_tech Cloud searchでレコチョク検索の実現に向けて
#reco_tech Cloud searchでレコチョク検索の実現に向けて
recotech
#reco_tech OracleからAuroraへ feat. 開発しかやってこなかったエンジニア
#reco_tech OracleからAuroraへ feat. 開発しかやってこなかったエンジニア
recotech
#reco_tech AWSへ全面移行した今を話ます。
#reco_tech AWSへ全面移行した今を話ます。
recotech
WIZY企画の裏側
WIZY企画の裏側
recotech
#recotech_AWS移行してみたけどぶっちゃけどうよ。
#recotech_AWS移行してみたけどぶっちゃけどうよ。
recotech
#recotech_WIZY開発の裏側
#recotech_WIZY開発の裏側
recotech
#recotech_レガシーなシステムから立て直すためにしたこと
#recotech_レガシーなシステムから立て直すためにしたこと
recotech
自分史上一番早い2024振り返り〜コロナ後、仕事は通常ペースに戻ったか〜 by IoT fullstack engineer
自分史上一番早い2024振り返り〜コロナ後、仕事は通常ペースに戻ったか〜 by IoT fullstack engineer
Yuki Kikuchi
クラウドネイティブなサーバー仮想化基盤 - OpenShift Virtualization.pdf
クラウドネイティブなサーバー仮想化基盤 - OpenShift Virtualization.pdf
FumieNakayama
AWS の OpenShift サービス (ROSA) を使った OpenShift Virtualizationの始め方.pdf
AWS の OpenShift サービス (ROSA) を使った OpenShift Virtualizationの始め方.pdf
FumieNakayama
モーダル間の変換後の一致性とジャンル表を用いた解釈可能性の考察 ~Text-to-MusicとText-To-ImageかつImage-to-Music...
モーダル間の変換後の一致性とジャンル表を用いた解釈可能性の考察 ~Text-to-MusicとText-To-ImageかつImage-to-Music...
博三 太田
CTO, VPoE, テックリードなどリーダーポジションに登用したくなるのはどんな人材か?
CTO, VPoE, テックリードなどリーダーポジションに登用したくなるのはどんな人材か?
akihisamiyanaga1
TataPixel: 畳の異方性を利用した切り替え可能なディスプレイの提案
TataPixel: 畳の異方性を利用した切り替え可能なディスプレイの提案
sugiuralab
NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)
NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)
NTT DATA Technology & Innovation
デジタル・フォレンジックの最新動向(2024年4月27日情洛会総会特別講演スライド)
デジタル・フォレンジックの最新動向(2024年4月27日情洛会総会特別講演スライド)
UEHARA, Tetsutaro
業務で生成AIを活用したい人のための生成AI入門講座(社外公開版:キンドリルジャパン社内勉強会:2024年4月発表)
業務で生成AIを活用したい人のための生成AI入門講座(社外公開版:キンドリルジャパン社内勉強会:2024年4月発表)
Hiroshi Tomioka
More Related Content
More from recotech
Swaggerを利用した新規サービス開発
Swaggerを利用した新規サービス開発
recotech
レコチョクのサービス群を支えるApiたち
レコチョクのサービス群を支えるApiたち
recotech
そうだApi公開しよう feat. 有志のエンジニア
そうだApi公開しよう feat. 有志のエンジニア
recotech
Mackerel x Twilio ~レコチョクの場合~
Mackerel x Twilio ~レコチョクの場合~
recotech
#reco_tech Cloud searchでレコチョク検索の実現に向けて
#reco_tech Cloud searchでレコチョク検索の実現に向けて
recotech
#reco_tech OracleからAuroraへ feat. 開発しかやってこなかったエンジニア
#reco_tech OracleからAuroraへ feat. 開発しかやってこなかったエンジニア
recotech
#reco_tech AWSへ全面移行した今を話ます。
#reco_tech AWSへ全面移行した今を話ます。
recotech
WIZY企画の裏側
WIZY企画の裏側
recotech
#recotech_AWS移行してみたけどぶっちゃけどうよ。
#recotech_AWS移行してみたけどぶっちゃけどうよ。
recotech
#recotech_WIZY開発の裏側
#recotech_WIZY開発の裏側
recotech
#recotech_レガシーなシステムから立て直すためにしたこと
#recotech_レガシーなシステムから立て直すためにしたこと
recotech
More from recotech
(11)
Swaggerを利用した新規サービス開発
Swaggerを利用した新規サービス開発
レコチョクのサービス群を支えるApiたち
レコチョクのサービス群を支えるApiたち
そうだApi公開しよう feat. 有志のエンジニア
そうだApi公開しよう feat. 有志のエンジニア
Mackerel x Twilio ~レコチョクの場合~
Mackerel x Twilio ~レコチョクの場合~
#reco_tech Cloud searchでレコチョク検索の実現に向けて
#reco_tech Cloud searchでレコチョク検索の実現に向けて
#reco_tech OracleからAuroraへ feat. 開発しかやってこなかったエンジニア
#reco_tech OracleからAuroraへ feat. 開発しかやってこなかったエンジニア
#reco_tech AWSへ全面移行した今を話ます。
#reco_tech AWSへ全面移行した今を話ます。
WIZY企画の裏側
WIZY企画の裏側
#recotech_AWS移行してみたけどぶっちゃけどうよ。
#recotech_AWS移行してみたけどぶっちゃけどうよ。
#recotech_WIZY開発の裏側
#recotech_WIZY開発の裏側
#recotech_レガシーなシステムから立て直すためにしたこと
#recotech_レガシーなシステムから立て直すためにしたこと
Recently uploaded
自分史上一番早い2024振り返り〜コロナ後、仕事は通常ペースに戻ったか〜 by IoT fullstack engineer
自分史上一番早い2024振り返り〜コロナ後、仕事は通常ペースに戻ったか〜 by IoT fullstack engineer
Yuki Kikuchi
クラウドネイティブなサーバー仮想化基盤 - OpenShift Virtualization.pdf
クラウドネイティブなサーバー仮想化基盤 - OpenShift Virtualization.pdf
FumieNakayama
AWS の OpenShift サービス (ROSA) を使った OpenShift Virtualizationの始め方.pdf
AWS の OpenShift サービス (ROSA) を使った OpenShift Virtualizationの始め方.pdf
FumieNakayama
モーダル間の変換後の一致性とジャンル表を用いた解釈可能性の考察 ~Text-to-MusicとText-To-ImageかつImage-to-Music...
モーダル間の変換後の一致性とジャンル表を用いた解釈可能性の考察 ~Text-to-MusicとText-To-ImageかつImage-to-Music...
博三 太田
CTO, VPoE, テックリードなどリーダーポジションに登用したくなるのはどんな人材か?
CTO, VPoE, テックリードなどリーダーポジションに登用したくなるのはどんな人材か?
akihisamiyanaga1
TataPixel: 畳の異方性を利用した切り替え可能なディスプレイの提案
TataPixel: 畳の異方性を利用した切り替え可能なディスプレイの提案
sugiuralab
NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)
NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)
NTT DATA Technology & Innovation
デジタル・フォレンジックの最新動向(2024年4月27日情洛会総会特別講演スライド)
デジタル・フォレンジックの最新動向(2024年4月27日情洛会総会特別講演スライド)
UEHARA, Tetsutaro
業務で生成AIを活用したい人のための生成AI入門講座(社外公開版:キンドリルジャパン社内勉強会:2024年4月発表)
業務で生成AIを活用したい人のための生成AI入門講座(社外公開版:キンドリルジャパン社内勉強会:2024年4月発表)
Hiroshi Tomioka
Recently uploaded
(9)
自分史上一番早い2024振り返り〜コロナ後、仕事は通常ペースに戻ったか〜 by IoT fullstack engineer
自分史上一番早い2024振り返り〜コロナ後、仕事は通常ペースに戻ったか〜 by IoT fullstack engineer
クラウドネイティブなサーバー仮想化基盤 - OpenShift Virtualization.pdf
クラウドネイティブなサーバー仮想化基盤 - OpenShift Virtualization.pdf
AWS の OpenShift サービス (ROSA) を使った OpenShift Virtualizationの始め方.pdf
AWS の OpenShift サービス (ROSA) を使った OpenShift Virtualizationの始め方.pdf
モーダル間の変換後の一致性とジャンル表を用いた解釈可能性の考察 ~Text-to-MusicとText-To-ImageかつImage-to-Music...
モーダル間の変換後の一致性とジャンル表を用いた解釈可能性の考察 ~Text-to-MusicとText-To-ImageかつImage-to-Music...
CTO, VPoE, テックリードなどリーダーポジションに登用したくなるのはどんな人材か?
CTO, VPoE, テックリードなどリーダーポジションに登用したくなるのはどんな人材か?
TataPixel: 畳の異方性を利用した切り替え可能なディスプレイの提案
TataPixel: 畳の異方性を利用した切り替え可能なディスプレイの提案
NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)
NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)
デジタル・フォレンジックの最新動向(2024年4月27日情洛会総会特別講演スライド)
デジタル・フォレンジックの最新動向(2024年4月27日情洛会総会特別講演スライド)
業務で生成AIを活用したい人のための生成AI入門講座(社外公開版:キンドリルジャパン社内勉強会:2024年4月発表)
業務で生成AIを活用したい人のための生成AI入門講座(社外公開版:キンドリルジャパン社内勉強会:2024年4月発表)
業界あるある Music偏
1.
© RecoChoku Co.,Ltd.
Proprietary and Confidential 株式会社レコチョク 2017/5/30 音楽×著作権
2.
© RecoChoku Co.,Ltd.
Proprietary and Confidential 目次 • 自己紹介 • サービス紹介 • 著作権 -音楽著作物の権利処理って? -著作権業務の概要 • 著作権報告処理 - 著作権報告あるある • 今後取り組みたいこと 22017/5/30
3.
© RecoChoku Co.,Ltd.
Proprietary and Confidential 自己紹介 高村 幸樹 事業システム部 サプライチェーンマネジメントグループ ■ 経歴 2013年レコチョク入社 ⇒実績報告、著作権処理等のバックエンドシステムを担当 ■ 趣味 旅行、お酒 筋トレ(筋肉痛がちょっとうれしい) ダンス(Breakやってたけど…) ■ 最近気になること 音楽教室×JASRAC 32017/5/30
4.
© RecoChoku Co.,Ltd.
Proprietary and Confidential サービス紹介 42017/5/30 より幅広い音楽ソリューションサービスへ 協業 定額課金制 従量課金制 定額課金制 デジタル音源配信 自社(レコチョク) 従量課金制
5.
© RecoChoku Co.,Ltd.
Proprietary and Confidential 52017/5/30 著作権
6.
© RecoChoku Co.,Ltd.
Proprietary and Confidential 音楽著作物の権利処理って? [物品販売] 62017/5/30 [音楽配信] 仕入 販売 支払 支払 お客様 販売店 仕入先 モノとお金の流れ(物品販売とのイメージ比較) コンテンツプロバイダ レコード会社 お客様 配信 支払 音源提供 分配 著作権管理事業者 著作物使用料支払 利用許諾 利用許諾
7.
© RecoChoku Co.,Ltd.
Proprietary and Confidential 著作権業務の概要 サービスで配信された著作物の利用実績の報告 72017/5/30 許諾契約 利用実績報告 支払い業務 新規サービス開始時や既存サービスの内容変更に伴う、 著作物の利用許諾の取得 利用実績に対する請求の支払い
8.
© RecoChoku Co.,Ltd.
Proprietary and Confidential 82017/5/30 著作権報告処理
9.
© RecoChoku Co.,Ltd.
Proprietary and Confidential 著作権報告あるある 92017/5/30 手先のシステム対応で乗り切ろうとする風潮 著作権報告業務を考える人が少ない 許諾番号の発行はサービスイン後がほとんど サービス先行でプロジェクトが動くため忘れられる お金かけられないから今の システムでなんとかして! ○月にサービス始めないと いけないから進めるね 著作権報告は○○サービスと 一緒でいいよね? まだ許諾番号もらってない んだよねぇ
10.
© RecoChoku Co.,Ltd.
Proprietary and Confidential 著作権報告あるある 許諾の発行ルールが複雑(利用許諾≠サービス) (例)サービス形態×課金単価×会員区分×試聴状態・・・ 102017/5/30 要件が確定してからの開発期間が短い 許諾 サービ ス 形態 課金 単価 会員 区分 試聴 状態 再生 時間 公開 楽曲数 聴き放題 プレイリスト型 従量課金 300円 500円 ・・・ 有料会員 有料会員(初回無料) お試し ・・・ 30秒以内 30秒超え 45秒超え ・・・ 通常再生 試聴 10万曲以内10 万曲超え ・・・
11.
© RecoChoku Co.,Ltd.
Proprietary and Confidential 著作権報告あるある 112017/5/30 サービスが出来るたびにログがバラバラ ログフォーマットの共通化 分散されていた全サービスの情報を集約 ほぼ創業時からの継ぎはぎシステム RedShiftXIV オンプレミス 2億レコードを越える実績を短時間で集計
12.
© RecoChoku Co.,Ltd.
Proprietary and Confidential 122017/5/30 今後取り組みたいこと
Editor's Notes
株式会社レコチョクの高村と申します。 今日は初めての登壇なのでだいぶ上がってますが、温かい目で見て頂ければ幸いです。 今日は音楽×著作権をテーマに音楽配信業界ならではのあるあるをお話しさせていただきます。
今日はこのような流れで進めていきます。
まず最初に、簡単に自己紹介を。 改めまして、株式会社レコチョクの高村幸樹と申します。 2013年に入社し、それ以降実績処理や権利処理に関するシステムの担当をしております。 趣味は、旅行やお酒を飲むこと、筋トレやダンスが好きで筋トレはたまにトレーニングのサポートなんかもやらせてもらっています。 最近気になる話題としては音楽教室とJASRAC 音楽教室での演奏に著作権が及ぶ及ばないーってやつですね。 昨日も京大の使用料請求についてはJASRACが取り下げると発表がありましたが、 こちらどうなるか、今後の動向が気になるところです。
ここで弊社が展開しているサービスをサラッと紹介しておきます。 大きく3つの分類として従量課金制のサービスや定額課金制のサービス、さらには音楽をテーマに新規サービス等、様々なサービスを展開しています。
ここからが本題になりますが、まず著作権について 皆さんはどんなイメージをお持ちでしょうか。 映画や漫画、音楽のコンテンツ作成者の利益を守る権利なのかな?と 皆さんも一度は耳にしたことがあるJASRACのニュースもちょくちょく目にされてると思うのでイメージはあると思いますが、 その権利がどのように作用するのかはなかなか普段の生活では見えないのでイメージしにくいと思います。
なので、簡単にイメージして頂けるよう、ここでは物品販売と音楽配信をモノとお金の流れに絞って見ていきたいと思います。 まず、物品販売ですと、販売店は仕入先から商品を仕入れてお客様に販売、お客様は対価として代金を支払い、販売店は仕入れ先へ原価を支払います。 対して音楽配信では弊社を含めたコンテンツプロバイダがレコード会社から音源の提供を受け、お客様に配信します。 お客様は対価としてサービス料を支払い、コンテンツプロバイダはそのサービス料を基にレコード会社に分配します。 この時に著作物に対する使用料の支払いが発生する。というのが物品販売と大きく異なる点です。 この前段として音楽著作物の利用に当たってはレコード会社、コンテンツプロバイダ共に管理事業者が利用許諾を得る必要があるという点もポイントになります。 この図ですと著作権が絡んでもシンプルには見えますが、実際には権利処理は非常に複雑で出版や音楽については多くの権利者、事務所が関係してくるため、特に複雑な業界でもあります。 著作権が複雑なのは出版と音楽 →登場人物が多い 著作権法律上の利用と使用は違うが実務上は区分けが生きていない。 [前提]許諾権を持っている人に許可を得る 利用:許諾を得た上で使うこと。 使用:権利者の許諾を得る必要なく使用すること。 (例)引用 音源を作るにあたって利用許諾を受ける 音源の提供を受けてお客さんに届ける我々配信事業者も著作物の利用について管理事業者から受ける。
この権利処理について弊社ではどんな業務を行っているのかお話しますと、大きくは3つの業務に分かれます。 一つ目は許諾契約、新たにサービスを始める時や既存のサービスで内容の変更が生じたときに管理事業者と協議を行い、利用許諾を取得します。 二つ目は利用実績報告、サービスで利用した実績を許諾の単位で報告します。 そして三つ目は支払業務、報告した利用実績に対する請求の支払いを行います。 これら業務を一つ一つお話ししていくと10分では収まらない為、今日は利用実績報告にフォーカスを当てて著作権のあるあるネタを紹介させていただきます。 著作権管理事業者は使用料規定を公示しなければならないが、定義が汎用的な内容の為、個別の協議が必要
雑に並べていますが、 まず、著作権報告業務を考える人が少ない 開発が始まってから要件が決定するのが大体ですね。 二つ目はサービス先行でプロジェクトが動くため忘れられる プロジェクトのスピードが速く、結構置いてけ堀を食らいます。 三つ目は手先のシステム対応で乗り切ろうとする風潮 上の二つから繋がりますが、無邪気な要望が多いです。 そして四つ目は許諾番号の発行のほとんどがサービスイン後 結果2段階リリースになることはよくあります。
それら一つ一つが合わさった結果、一番苦労するのが、要件が確定してからの開発期間が短いことです。 そもそも許諾の発行ルールが複雑なので要件確定後に短い開発期間で対応しなければいけないのがなかなかヘビーです。 複雑さは図を見ていただけると何となくわかっていただけると思いますが、 単純にサービス毎の利用実績を集計して報告するのではなくて、様々な要素を基に報告単位、つまり許諾が決まる為、 結果的に処理は複雑に、扱うデータ量は増えてしまいます。 利用許諾≠サービス サービス×商品×キャリア×DRM×再生時間 利用実績だけでなく公開実績も必要 →サービスによって公開している音源が異なる 無料施策、有料等ルールに合わせた実績の振り分けが大変 想像力を働かせて業務観点で提案 会計処理にも密接に絡む フロントサービスとのギャップがある →ログのインポートやマッピングマスタで柔軟に対応
それでも月次の業務サイクルに間に合わせるため、パフォーマンスを落としてはいけないのですが、 もともと創業時からの継ぎはぎできたシステムだった為、処理の複雑化、データ量増加の影響で処理が終わらないといった問題も発生しました。 ストレージを乗せ換えたりマシンパワーを上げてごまかしていたのですが、改めてサービス多様化に合わせて2016年2月に既存システムを AWSに移管し、DBもカラムナー指向のDBに変える対応やサービスの種類に合わせてログの共通化を図たり、全サービスの情報も一つに集約するなど、 裏側での努力の結果、システムのパフォーマンスを向上しています。 バックエンドでよくある見えない努力ですね。 利用許諾≠サービス (例)サービス×コース×商品×有料(無料) 3DS:39,395 ANIUTA:2,594,154 Best:5,260,713 d月額:3,461,581 ひかり:2,769,007 dヒッツ:149,185,901 OTORAKU:27,143,121 RBT:2,053,917 replay:746,661 アラカルト:2,349,525 計:195,603,975 利用許諾≠サービス サービス×商品×キャリア×DRM×再生時間 利用実績だけでなく公開実績も必要 →サービスによって公開している音源が異なる 無料施策、有料等ルールに合わせた実績の振り分けが大変 想像力を働かせて業務観点で提案 会計処理にも密接に絡む フロントサービスとのギャップがある
Download now