【stand.fmと音声市場、stand.fmを支える技術】 podcast エンジニアトーク ROLE MODEL 前半 -全文書き起こし-
弊社エンジニアの和田さん (@takahi5) がpodcast エンジニアトーク「ROLE MODEL」にゲスト出演しました。「音声配信アプリ stand.fmを支える技術」をテーマにしたお話しした配信回の全文書き起こしました。
パーソナリティー iwashi氏 @iwashi86
通信事業者で人材開発や組織開発を進めたり、また部分的にソフトウェアエンジニアとして働いています。fukabori.fm のパーソナリティー
stand.fm エンジニア 和田 崇彦 @takahi5
DeNAにてソーシャルゲーム、新規サービス開発にエンジニアとして従事した後、 スタートアップのCTOなどを経て、2021年にstand.fmにジョイン。toCのサービスを作るのが好き。
音声配信アプリstand.fmについて
iwashi氏（以下、敬称略）：こんにちは、iwashiです。普段は、通信事業者で人材開発や組織開発を進めたり、また部分的にソフトウェアエンジニアとして働いています。
この番組では、スタートアップ企業や、誰もが知っている有名企業で活躍するエンジニアの方々にインタビューを行い、彼らのサクセスストーリーや、人生を変えた出来事など、キャリア形成に役立つ情報を配信していきます。
今回のテーマは、「stand.fmと音声メディア市場、stand.fmを支える技術」です。
インタビューするのは、stand.fmのエンジニア、和田 崇彦（タカヒコ）さん。まずは和田さんに、stand.fmについて教えて頂きました。
stand.fmとは？
和田氏（以下、敬称略）：簡単に言うと音声配信のアプリでして、例えば podcast みたいにラジオ番組をスマホひとつで収録から公開までできるというふうなアプリです。
で、配信の方法には2つタイプがありまして一つはあらかじめ録音して編集したものを公開する、いわゆる podcast みたな感じの方式ですね。
もう一つはライブ形式でも配信することができまして、リアルタイムで配信、例えば youtube live などの音声だけのバージョンをイメージをしてもらうといいかなと思います。
さらにこのライブ配信ではリスナーを壇上に上げてコラボして配信する、いわゆるあのclubhouse的な体験ですかね、といったこともできます。
なので実際にタレントの配信ではファンとを壇上に上げて会話したりするとか、そういった取り組みとかもされていたりしますね。
もちろんへリスナーとしてはこのstand.fm上で好きな配信を見つけて聞くと、そういったことができるような音声配信のアプリになっています。
podcastとstand.fmの違いとは？双方向のコミュニケーション
iwashi：このエピソードとしてまさにポッドキャストとして配信されているものとの一番の差分は、やっぱりライブがあるっていうところなんですか？
和田：そうですね、はい。ライブがあるというところが大きな差分になるかなと思います。あとはこのstand.fm内にこうコミュニティというか、この中で簡単な交流とかもできるので、その中にこうユーザーの空間があるところも一つ違いになるかなと思います。
iwashi：じゃあユーザー間のインタラクションがあったりとか。Podcastってどうしてもこう、そのプラットフォームだけだと一方向になってしまうので何か組み合わせる必要があるんですけども、それがかなりstand.fmでは中でインテグレーションされていて良いんですかね。
和田：そうですね。例えばレター機能のがありまして、匿名で質問箱みたいな感じで配信者にデータを送れることがあって、配信者側としてはやっぱりこう話すトピックに困る事ってあると思うんですけれども、そういったところをレターでネタを募集できる、のも一つ特徴かもしれないですね。
iwashi：じゃあよく昔からあったラジオでいうお便り投稿みたいな。
和田：まさにそんな感じです。特にをライブ配信しているとレターをこうライブ画面に貼り付けて表示したりできるので、レターを読みながら配信する、ちょっとしたラジオパーソナリティ気分が味わえたりできるかなと思います。
音声市場に挑戦する理由、狙い
iwashi：このstand.fmっていうのは結構音声市場というか、割とこうもともとが youtube へとかって世の中にすごい流行ってるのってわかるんですけど、結構Podcastってそれに比べとニッチな分野であり、特に音声、まあstand.fmやPodcastだけじゃないんですけど、このニッチな分野に飛び込もうっていう理由とか狙いとかってどういうところにあるんですか？
和田：これは僕が入る前になるんで、そうですね、この事業を始めたのは結構前で、ステルスで始めているのを含めると3年くらい前になるのかな？なんですけど、その頃でも動画の分野とか youtube とかTikTokとか民主化されてきたところがあったと思うんですけど、まだ音声の市場では特に日本では民主化が進んでないなと思った、というところが1つあったと聞いています。あとは、その時の会社のメンバーにもpodcast好きが多かったから、と聞いていますね。
iwashi：単純にみんな気になると思うんですけど、例えば日本と海外とかで市場規模というか流行り具合っていうのはぐどれくらい違うんですか？音声市場って。
和田：そうですね、なんか一般的に言って、アメリカとかだとその車移動が多いんでその間に podcast とかラジオを聴く。ラジオを聴く文化がもともとあったので、その分アメリカの方はPodcastとかも進んでいるということはよく聞きますね。
iwashi：なるほど。確かに車通勤が多いですもんね。
和田：そうですね。
コロナ渦におけるオーガニックでのユーザーの増加
iwashi：これ今例えば結構コロナ禍とかでリモートが増えてきていて、しかも電車通勤がやや減っている可能性もあって、この中だと少しユーザー数の遷移とか変化はstand.fm側で見られたりするんですか？
和田：そうですね、けどその一方でやっぱこう…ながら聞きと言うか、作業・仕事しながら作業中にながら聞みたいな用途もあるみたいでして、サービス自体は引き続きもコロナ禍でも成長しているという状況ですね。
iwashi：じゃあstand.fmのリスナー数はどんどん増えているみたいな？
和田：そうですね、はい。順調に増えております。
iwashi：これは何か特別にグロースさせるために何かされるとかあるんですか？
和田：今のところは結構オーガニックで成長している感じですね。
iwashi：すごいですね。オーガニックで成長されているということは、プロダクトに価値があるからこそ、そうなると思うので。それは何でこうオーガニックで成長するというところとかって、stand.fm側ではどういう分析、どういう要因が強いと思ってらっしゃるんですか？
和田：ひとつは、僕が入る前なんですけれども、ライブのコラボ配信が始まったタイミングで、ユーザー側の熱量の角度が上がったのはあったと聞いていますね、はい。
iwashi：なるほど。ライブ配信がないと本当にただのPodcastに近くなりますからね。
和田：そうですね、はい。
iwashi：この辺からユーザーに火がついてそのバイラルとかSNS上で広がっていったっていうのが強いんですかね？
和田：そうですね、はい。
stand.fmを支える技術
フロントエンド React Native、バックエンド Node.js、ライブ配信 WebRTC/HLS
iwashi：中身の技術っぽいところをエンジニア系Podcastとしては聞いてみたいと思っていてですね。
この今お話を聞いてきた、例えばこう配信するとかライブ機能とかって技術的にはどういう仕組みで実装を提供されているんですか？
和田：はい。えっとまず、フロントエンドはReact Nativeで作ってます。 iOS、Android ともに両方作ってまして、まあただネイティブに近いところ、例えば収録する部分とかライブ配信の部分とかはネイティブのコードを触って作っています。
で、バックエンドに関してはNode.jsで開発してます。あとライブ配信の周りは WebRTC使ったりHLSで配信したりとか、用途に応じて適切なそういう配信方法を選んで設計したりはしてますね。
React Nativeを選択したきっかけ、実際の運用はどうか？
iwashi：ありがとうございます。これやっぱみんな気になると思うんですけど、音声回りなのでちょっとネイティブに近い分野が絶対あるはずで、その時にReact Nativeっていう選択肢をとったきっかけとか、その選定理由はどういうところにあるんですか？
和田：これ始めた開発始めた頃って社内にエンジニア2人で作ってたんですね。なので、そのまま2人でこう iOS、Android 両方作るってなると自然にやはりクロスプラットフォームの方が効率いいよねっていう背景はあったかなと思います。ただもちろんReact Nativeを選択してもネイティブの部分が触れないっていうわけじゃないので、特にその音声配信アプリを作るという意味でも特にReact Nativeを選ぶまあデメリットも逆になかったからっていうのはまた理由なのかなと思いますね。
iwashi：なるほど、じゃあReact Nativeだからこそ本当に困ってできないということはなかったということなんですね。
和田：そうですね、基本的にはないと思います。ネイティブが必要なところではネイティブのコードを組み合わせて書くことが可能なので、はい。
iwashi：3年間実装してきて、やっぱここ方針変えようかなとかはあったりするんですか？
和田：えっと、そうですね、適宜リファクタとかはやりながらやっていますね、はい。
iwashi：結構大規模な、式年遷宮的なところも予定とかは別になくって感じですかね。
和田：細かいところであります。(笑) やりたい、ここを変えたいな、みたいな。けど大変な中でどうしようかなというディスカッションは常にやってますね。(笑)
iwashi：(笑) なるほど、ありがとうございます。ちなみに社内でFlutterの話とかはされるんですか？
和田：この開発が始まった頃にはまだFlutterがそこまで成熟してなかったので、多分選択肢になかったと思うんですけれども、まぁ興味としてはある人もいるし、Flutter経験があるエンジニアも何人か居ますね社内には。
iwashi：ああ、すでに触ったことがあって、でもいまプロダクトとしてはReact Nativeなのでそれを書いてる、っていうのはエンジニアがやられてることですかね。
和田：そういったエンジニアもいますね、はい。
React Nativeでのアプリ開発のメリット
iwashi：React Nativeってさらって言ってたんですけど、React Nativeって触っていてこれプロダクト開発にとってこれがメリットだみたいな、これが強みだなみたいなことってどういうところがあるんですか？
和田：ひとつはReactってReactのポリシーにあるんですけれども 、Learn once, Write anywhere.って 言うんですけども、1回Reactを学ぶといろんなところでそれを書けると。例えば web の方書くんだったまあReact.jsで書けるし、アプリはReact Nativeで書けるし、さらにReact Nativeで作ったアプリをまた web に変換するReact Native for webっていうのがあるんですね、ちょっとまどろっこしいんですけど。(笑) React NativeをWebにするっていう。
iwashi：そうですよね(笑) もともとReactはWebですもんね。
和田：そうですね、ちょっとまどろっこしいんですけど、用途としては例えばこうアプリファーストで作ったサービスの一部をwebに露出する、みたいな。例えばインスタグラムとかもアプリだけど一部閲覧だけ web でできたりするじゃないですか。ああいったものを作る時に便利な機能ですね、アプリの一部を web に変換するみたいなときに使います。stand.fmでも実際使ってまして、React Native for webは。例えばラジオの配信の聴くことだけはwebのブラウザでもできるんですね。そこでReact Native for webを使っていたりします。
バックエンドの技術スタックと構成
Node.js, Mongo DB, WebSocket
iwashi：もう一点聞いてみたいポイントとして、先ほどバックエンド、インフラ側はNode.jsで書かれているって仰っていたんですけれども、これNode.jsはどういう機能を実装されてるんですか？
和田：例えば APIサーバーだったりとか、ライブ周りだとWebSocketでリアルタイムな通信とかをやってたりするんで、その辺のバックエンドの処理とか。あとデータベースはMongo DB使ってるんで、そん辺とのやりとりとかはNode.jsバックエンドの側でやってたりします。
iwashi：なるほど。じゃあNode.js ではExpressとかFastifyみたいな、割と著名なサーバーを使っていて、そこでMongo DBをバックエンドにしているというところで、これあと今お聞きしたいのは、 WebSocketとかを使ってやっておられるのはReact Nativeのフロント側のアプリケーションから、例えばレター機能とかリアクションとか、テキストを使うときにそれを同期的に送ってるってイメージですかね？
和田：そうですね。特にライブ画面で使う機能、ライブの画面にリアルタイムにコメントを送ったりとか、あとはハートの演出をリスナーが送ったりできるんですけれども、そういうものは即時でリアルタイムに他のユーザーの画面に反映したいのでWebSocketで通信してたりします。
音声のライブ配信、コラボ配信技術
iwashi：なるほど。これ音声のライブ、リアルタイムの配信っていうのは、この音声はNode.jsをかんでないですよね？
和田：音声はそうですね、HLSで配信してますね。
iwashi：じゃあHLSなので、サーバー側で断片ファイルにしてそれを適宜HTTPにのせていくって感じですね？
和田：あ、そうですね、はい。
iwashi：これってどのくらいスケールするんですか？
和田：えっとですね、そのスケールのことを考えて配信の方では配信のサーバをWowzaっていう所用のものを使っているんですけども、そことユーザーの間にCDNかましてスケールしやすいようにしてたり、そういった工夫は行っていますね、はい。
iwashi：なるほど。HLSなので普通のファイルなのでキャッシュがきくので、基本まあ理論値ですけどHDNが続く意味では無限にスケールしていくみたいな感じですね。
和田：そんな感じですかね。
iwashi：じゃあそうですね、その分ちょっと遅延が発生しちゃうのは、そこは許容しているということですね。
和田：そうですね、はい。で、もう少し具体的に言うと、たとえばちょっと面白いところで言うと、ライブのコラボ配信、あのクラブハウスみたいな感じで複数の登壇者が話してそれを大勢のユーザーに届ける、そういったユースケースもあるんですけれども、そこで言うとその登壇者同士はなるべくこう遅延なく、遅延少なく会話したいのでそこの登壇者同士はWebRTCでつないでコミュニケーションをしますと。で、そのコミュニケーションしたものをそのライブのオーナーのスマホを通してWowzaのサーバーに送って、そのWowzaのサーバーから大勢のユーザーに配信するところは多少遅延があっても許容するというところで、そこからはHLSを使うと。HLSの方が大勢のユーザーには配信しやすいというところでまあそういったHLSとWebRTCの使い分けをうまいことやるっていう設計をしていたりします
iwashi：なるほど。WebRTCというのはReact Nativeから簡単に触れるものなんですか？
和田：そうですね、はい。まぁそこネイティブのコードは書いたりはしてる、してますね、はい。
iwashi：あぁなるほど。そこはReactだけだと吸収がなかなか難しくて、という感じですね。
和田：そうですねあとちょっと細かいことを色々としてくるとやっぱりネイティブを触らないといけない部分が出てきますかね。
iwashi：じゃあこの5秒、10秒ぐらいの遅延があるとさすがにこう、なんだろうな、いわゆるP2P的なWebRTCの通信は耐えられないので、そこは別のWebRTCを使っていて、オーナーからWowzaの方に直接何かその音声のファイルを送り続けているということですか？
和田：そうですね、はい。そこはWowzaのSDKがあるのでそれを使ってますね。
iwashi：あ〜なるほど。そのフロントエンドのモバイルアプリケーションではReact Nativeを使って実装してるんですけど、そのWowzaのライブラリも一緒に取り込んでいて、Wowza側のプロトコルというか専用のライブラリを使ってひたすらデータを送り込んでいる、ということですね。
和田：はい、そうですね。
iwashi：なるほど。で、Wowza側で、Wowzaのサーバーがきっとそのstand.fm側でホスティング、ホストしているので、それをWowza側のサーバーでHLSに変換してCDNを通して配ってくんでスケールすると。
和田：はい、そういった形ですね。
iwashi：ふむふむ、なるほど。だいぶアーキテクチャ全体がよく分かった気がします。
和田：面白いですね、ここの設計は。
iwashi：今回はstand.fmが狙う音声市場や、stand.fmを支える技術についてお伺いしました。単にアーカイブした音声を配信するだけでなく、リアルタイム性も要求されるシステムでしした。そのため、ネイティブ向けのライブラリに手を入れるなどの工夫もありましたね。
エンジニアにとって技術的に興味深い点だったと思います。
次回も引き続き、stand.fmのエンジニア、和田 崇彦（タカヒコ）さんにお話を伺います。
宣伝：stand.fmを一緒に開発する仲間を探しています！
ご興味ある方はお気軽に、カジュアル面談やオンライン会社説明会へご参加いただけます！
この記事が気に入ったらサポートをしてみませんか？