00:06
ライブのコラボ配信みたいなのが始まったタイミングで、ユーザーの熱量の角度が上がったみたいな。
アーキテクチャ全体がだいぶよくわかった気がします。
面白いですね、ここの設計は。
こんにちは、いわしです。
普段は通信事業者で人材開発や組織開発を進めたり、また部分的にソフトウェアエンジニアとして働いています。
この番組では、スタートアップ企業や誰もが知っている有名企業で活躍するエンジニアの方々にインタビューを行い、
彼らの作説ストーリーや人生を変えた出来事など、キャリア形成に役立つ情報を配信していきます。
今回のテーマは、スタンドFMと音声メディア市場、またスタンドFMを支える技術です。
インタビューするのはスタンドFMのエンジニア、和田隆彦さん。
まずは和田さんにスタンドFMについて教えていただきました。
簡単に言うと音声配信のアプリでして、
例えばポッドキャストみたいにラジオ番組をスマホ一つで収録から公開までできるという風なアプリです。
配信の方法には二つタイプがありまして、
一つはあらかじめ録音して編集したものを公開する、いわゆるポッドキャストみたいな感じの方式ですね。
もう一つはライブ形式でも配信することができまして、
リアルタイムで配信、例えばYouTubeライブみたいなのの音声だけのバージョンみたいなイメージしてもらうといいかなと思います。
さらにこのライブ配信ではリスナーを壇上にあげてコラボして配信するみたいな、
いわゆるクラブハウス的な体験ですかね、といったこともできます。
なので実際にタレントの配信ではファンを壇上にあげて会話したりするとか、
そういった取り組みとかもされてたりしますね。
でももちろんリスナーとしてはこのStandFM上で好きな配信を見つけて聞くと、
そういったことができるような音声配信のアプリになっています。
このエピソード自体がまさにポッドキャストとして配信されているものなのに、
一番の差分はやっぱりライブもあるっていうところになるんですか?
そうですね。ライブがあるっていうところが大きな差分になるかなと思います。
あとはこのStandFM内にコミュニティというか、
この中で簡単な交流とかもできるので、
その中にユーザーの空間があるみたいなところも一つ違いになるかなと思います。
じゃあユーザー間のインタラクションがあったりとか。
ポッドキャストってどうしてもプラットフォームだけだと一方向になってしまうので、
何か組み合わせる必要もあるんですけども、
これがかなりStandFMではこの中でインテグレーションされていて良い感じですかね?
そうですね。例えばレター機能みたいなのがありまして、
匿名で質問箱みたいな感じで配信者にレターを送れるみたいなことがあって、
03:00
配信者側としてはやっぱり話すトピックに困ることってあると思うんですけども、
そういったところをレターでネタを募集できるみたいなのも一つ特徴かもしれないですね。
じゃあ昔からあったラジオでお便り投稿みたいな。
まさにそんな感じです。
特にライブ配信してるとレターをライブ画面に貼り付けて表示したりできるので、
レターを読みながら配信するみたいな、
ちょっとしたラジオパーソナリティみたいな気分が味わえたりできるかなと思います。
StandFMはスマホ一つで録音と編集までできて、
クラブハウスのようにライブ配信もできますね。
1ユーザーとして利用するととても使いやすいことが分かります。
ではそのStandFMを支える技術はどのようなものなのでしょうか。
ちょっとビジネスっぽい話になるんですけど、
StandFMっていうのは結構音声市場というか、
元々YouTubeとかって世の中ですごい流行ってるってのは分かるんですけど、
結構Podcastってそれに比べるとニッチな分野であり、
特に音声、StandFMはPodcastだけじゃないんですけど、
ニッチな分野に飛び込もうっていう理由とか狙いとかってどういうところにあるんですか。
これは僕が入る前になるんで、
この事業を始めたのは結構前で、
ステレスで始めてるのを含めると3年ぐらい前になるのかな、なんですけど、
その頃でも動画の分野とかYouTubeとかTikTokとか、
民主化されてきたところがあったと思うんですけども、
まだ音声の市場では、
特に日本ではまだ民主化があまり進んでないなと思ったっていうところが一つだったと聞いてます。
あとは、そのときの会社のメンバーにもこういったPodcast好きとかが多かったから、
っていうふうな感じだったと聞いてますね。
単純にみんな気になると思うんですけど、
例えば日本と海外とかで市場規模というか流行り具合ってどのぐらい違うんですか?音声市場。
そうですね。一般的に言うとアメリカとかだと車移動が多いんで、
その間にPodcastとかラジオを聴く文化がもともとあったので、
その分アメリカの方はPodcastとかも進んでるみたいなことはよく聞きますね。
なるほど。確かに車通勤が多いですもんね。
そうですね。
これ今、例えばコロナ禍とかでリモートが増えてきていて、
しかも電車通勤がやや減っている可能性もあって、
この中だと少しユーザー数の繊維とか変化はスタンドFM側では見られたりするんですか?
そうですね。その一方で、作業中に流劇みたいな用途もあるみたいでして、
サービスの自体は引き続きコロナ禍でも成長しているという状況ですね。
じゃあスタンドFMのリスナー数はどんどん増えているみたいな?
そうですね。順調に増えております。
これは特別にグロースさせるために何かされるとかあるのか?
今のところ結構オーガニックで成長している感じですね。
すごいですね。オーガニックで成長されるということは、
プロダクトに価値があるからこそそうなると思うので、
06:01
それは何でオーガニックで成長するというところとかって、
スタンドFM側ではどういう分析、どういう要因が強いと思っていらっしゃるんですか?
一つは、これは僕が入る前なんですけども、
ライブのコラボ配信みたいなのが始まったタイミングで、
ユーザーのネットユーザーの角度が上がったみたいなのはあったと聞いてますね。
なるほど。ライブ配信がないと本当にただのポッドキャスに近くなりますからね。
そうですね。
この辺からユーザーに火がついて、
ヴァイラルとか内線情報とかで広がっていったというのが有意味ですかね?
そうですね。
中身の技術っぽいところを、
エンジニア向けポッドキャスとしては聞いてみたいと思っていてですね。
この今お話を聞いてきた、例えば配信するとかライブ機能とかって、
技術的にはどういう仕組みで実装提供されているんですか?
まずフロントエンドはリアクトネイティブで作ってます。
iOS、Androidともに両方作ってまして、
ただネイティブに近いところ、
例えば収録する部分とかライブ配信の部分とかはネイティブのコードを触って作ってます。
バックエンドに関してはNode.jsで開発してます。
あとライブ配信の周りはWebRTCで買ったり、
HLSで配信したりとか、
用途に応じて適切な配信方法を選んで設計したりはしてますね。
ありがとうございます。これやっぱりみんな気になると思うんですけど、
音声周りなのでちょっとネイティブに近い分野が絶対あるはずで、
その時にリアクトネイティブっていう選択肢を取ったきっかけとか、
その選定理由とかどういうところにあるんですか?
開発始めた頃って、
社内にエンジニア2人で作ってたんですね。
なのでその2人でiOS、Android両方作るってなると、
自然にやはりクロスプラットフォームの方が効率いいよねっていう背景はあったかなと思います。
ただ、もちろんリアクトネイティブを選択しても、
ネイティブの部分が触れないってわけじゃないので、
特に音声配信のアプリを作るという意味でも、
特にリアクトネイティブを選ぶデメリットも逆になかったからっていうのがまた理由かなと思いますね。
なるほど。じゃあリアクトネイティブだからこそ、
本当に困ってできないってことはなかったっていうことなんですか?
そうですね。基本的にはないと思います。
ネイティブが必要なところではネイティブのコードを組み合わせて書くことは可能なので、はい。
3年間実装してきて、やっぱり方針変えようかなみたいなところってあったりするんですか?
そうですね。適宜リファクターとかはやりながらやっていますね。
結構大規模な式年宣言的なところの予定とかも別になくって感じですかね?
まあ、細かいところであります。やりたい、ここ変えたいなみたいな。
けど大変だよなみたいな中で、どうしようかなみたいなディスカッションは常にやってますね。
なるほど。ありがとうございます。
ちなみに社内でフラッターの話とかされるんですか?
この開発始まった頃にはまだフラッターがそこまで定熟してなかったので、多分選択肢がなかったと思うんですけども、
09:06
興味としてはある人もいるし、フラッター経験があるエンジニアも何人かいますね、社内には。
すでに触ったことがあって、でも今プロダクト社はリアクトネイティブなのでそれを書いてるっていうのはエンジニアがやられてることですかね?
そういったエンジニアもいますね。
リアクトネイティブって触っていってたんですけど、リアクトネイティブって触っていって、プロダクト開発にとってこれがメリット、これが強みだなみたいなことってどういうところがあるんですか?
一つはリアクトのポリシーにあるんですけども、Learn Once, Write Anywhereって言うんですけども、
一回リアクトを学ぶといろんなところでそれを書けると。
例えばWebの方を書くんだったらリアクトJSで書けるし、アプリはリアクトネイティブで書けるし、
さらにリアクトネイティブで作ったアプリをまたWebに変換する、リアクトネイティブ for Webっていうのがあるんですね。
ちょっとまどろっこしいんですけど、リアクトネイティブをWebにするっていう。
もともとリアクトはWebでしたもんね。
用途としては、例えばアプリファーストで作ったサービスの一部をWebに露出するみたいな。
例えばInstagramとかもアプリだけど一部閲覧だけWebでできたりするじゃないですか。
ああいったものを作るときに便利な機能ですね。アプリの一部をWebに変換するみたいな。
Standard FMでも実際使ってまして、リアクトネイティブ for Webは、
例えばラジオの配信の聞く方だけはWebのブラウザでもできるんですね。
そこでリアクトネイティブ for Webを使ってたりします。
もう一点聞いてみたいポイントとして、先ほどバックエンド、インフラ側はNode.jsで書かれているっておっしゃっていたんですけども、
これはNode.jsはどういう機能を実装されているんですか。
例えばAPIサーバーだったりとか、ライブ周りだとWebソケットでリアルタイムな通信とかをやってたりするんで、その辺のバックエンドの処理とか。
あとデータベースはMongoDB使ってるんで、その辺とのやりとりとかはNode.js、バックエンドとかでやってたりしますね。
なるほど。じゃあNode.jsではExpressとかFastifyみたいな割と著名なウェブサーバーを使っていて、そこでMongoDBをバックエンドにしているというところで。
これあと今お聞きしたいのはWebソケットとかを使ってやってられるのは、リアクトネイティブのフロント側のアプリケーションから、
例えばさっきのレター機能とかリアクションとかテキストを使うときにそれを同期的に送ってるってイメージですかね。
そうですね。特にライブの画面にリアルタイムにコメントを送ったりとか、あとはハートの演出をリスナーが送ったりできるんですけども、
12:01
そういうものは即時でリアルタイムに他のような画面に反映したいので、Webソケットで通信したりします。
なるほど。これ音声のライブリアルタイムの配信っていうのは、この音声はたぶんNodeを噛んでないですよね。
音声はHLSで配信してますね。
じゃあHLSなので、このサーバー側で断片ファイルにして、それを的にHTTPに載せていくって感じですね。
そうですね。
これってどのくらいスケールするんですか。
そのスケールのことを考えて、配信のほうでは配信のサーバーをWowserっていう所要なものを使ってるんですけども、
そことユーザーの間にCDNかまして、スケールしやすいようにしてたりという、そういった工夫はやっていますね。
なるほど。HLSなので、普通のファイルなのでキャッシュまで効くので、基本理論値ですけど、
CDNが続く限りは無限にスケールしていくみたいな感じですね。
そんな感じですかね。
その分、ちょっと遅延が発生しちゃうのは、そこは強要してるってことですね。
そうですね。もう少しちょっと具体的に言うと、例えばちょっと面白いところで言うと、
ライブのコラボ配信、クラブハウスみたいな感じで、複数の登壇者が話して、それを大勢のユーザーに届けるみたいな、そういったユースケースもあるんですけども、
そこで言うと、その登壇者同士はなるべく遅延なく、遅延少なく会話したいので、
そこの登壇者同士はWebRTCでつないでコミュニケーションしますと。
で、そのコミュニケーションしたものをライブのオーナーのスマホを通して、
ワウザのサーバーに送って、そのワウザのサーバーから大勢のユーザーに配信するところは、
多少遅延があっても強要するというところで、そこからはHLSを使うと。
HLSのほうが大勢のユーザーには配信しやすいというところで、
そういったHLSとWebRTCの使い分けをうまいことやるという設計をしたりします。
WebRTCというのは、リアクトネイティブから簡単に触れるものなんですか?
そうですね。そこはネイティブのコードは書いたりはしてますね。
そこはリアクトだけだと吸収がなかなか難しくてという感じですね。
そうですね。あとちょっと細かいことをいろいろとしてくると、
やっぱりネイティブを触らないといけない部分が出てきますかね。
じゃあこの5秒、10秒ぐらいの遅延があると、
さすがにP2P的なWebRTCの通信は耐えられないので、
そこは別のWebRTCを使っていて、
オーナーからワウザのほうに直接何か音声のファイルを送り続けてるってことですか?
そうですね。そこはワウザのSDKがあるので、それを使ってますね。
なるほど。フロントエンドのモバイルアプリケーションでは、
15:00
リアクトネイティブを使って実装してるんですけど、
そのワウザのライブラリを一緒に取り込んでいて、
ワウザ側のプロトコルというか専用のライブラリを使って、
ひたすらデータを送り込んでいるってことですね。
はい、そうですね。
なるほど。ワウザ側でワウザのサーバーをきっとスタンダードエフェルまでホストしてるので、
それをワウザ側のサーバーでHLSに変換して、CDなどを配っていくのでスキルすると。
はい、そういった形ですね。
なるほど。アーキテクチャ全体がだいぶよくわかった気がします。
面白いですね、ここの設計は。
今回はStand FMが狙う音声市場やStand FMを支える技術についてお伺いしました。
単にアーカイブした音声を配信するだけではなく、
リアルタイム性も要求されるシステムでした。
そのため、ネイティブ向けのライブラリに手を入れるなどの工夫もありましたね。
エンジニアにとって技術的に非常に興味深い点だったと思います。
次回も引き続きStand FMのエンジニア、和田孝彦さんにお話を伺います。
この番組はPodcast Production、Pitopaのオリジナルコンテンツです。
番組の感想・リクエストは概要欄のリンクよりお待ちしています。
それではまた次回お会いしましょう。
