なぜ WebRTC で稼げているのか?

特定のオープンな技術で食べてくのはとても難しいのですが、今の時点で時雨堂は WebRTC という技術だけで会社が十分回る所まで来ています。そのあたりを振り返りついでに書いていきます。振り返りは何度やっても損がないと思っています。

自社製品だけに集中しない

実は時雨堂は自社製品以外の仕事もいろいろやっています。公開可能なのだと FGO の負荷試験IRIAM の配信設計でしょうか。自社製品だけやっている場合は徐々に視野が狭くなります。そのため市場を見誤ったりもしかねません。

自社製品以外で会社が回るようにする

自社製品以外の売上を確保しているので自社製品が赤字でも問題なく会社が回るようになっています。そのため、どんなに自社製品が赤字になったとしても、時雨堂は潰れることがありません。

そのため、競合がどんなに頑張ったとしても時雨堂が潰れることはありません。別に背水の陣で自社製品をやっているわけではないので、精神的にとても楽になります。

社員に売上達成目標を要求しない

創業者である自分がやりたくてやってるのが WebRTC なので、売上達成目標というのを社員たちに強いることは一切ありません。売上を上げるための努力は求めますが、売上達成のための努力は一切求めません。

無理な達成目標があると精神的に辛くなります。

コア製品は自社でフルスクラッチで開発する

稼ぎ頭である自社製品 WebRTC SFU Sora は 100% 自社開発です。ライブラリも全て自前で実装しています。フルスクラッチで開発するメリットはとても大きいです。

  • WebRTC で利用するすべてのプロトコル詳しくなる
  • 開発を自社のペースで進められる

フルスクラッチで書いているというだけで製品を購入する理由になることはほとんどありません。ただ詳しくなるのは間違いありません。それも圧倒的に詳しくなります。WebRTC 通信スタックを自前で実装しているので、通信周りの問題が起きたときの解決速度が全く違います。

さらに自社で開発しているため、自社のペースで進められます。OSS をベースにしたりすると OSS 側の開発に振り回されたりしますが、それがなくなります。

コア製品以外を OSS で公開する

SDK やライブラリ、さらにはクライアントをすべて Apache License 2.0 で OSS として公開しています。

時雨堂の一番の強みはこの部分にあります。JavaScript や iOS や Android 向けの SDK だけでなく React Native 向けライブラリや Native Client を前のめりでメンテしているのです。

商用サポートは提供していませんが、バグフィックスは優先的に対応しますし、問題の問い合わせも可能な限り当日に回答します。

クライアントを SDK 利用して開発しているときに、ソースが見れないのはとてもストレスがたまります。なのでソースコードがオープンになっているのは本当に重要です。

さらに公開している OSS はすべて libwebrtc というライブラリに依存しています。このライブラリは Chrome や Firefox が WebRTC を実現するのにも利用されています。この libwebrtc のアップデートの追従することで、社内に莫大なノウハウが残ることになります。時雨堂ではとりあえず作って問題が起きるまでは放置ではなく、積極的なアップデートをしています。追従力は本当に WebRTC では重要になります。

libwebrtc に WebRTC SFU を追従させていく、これを会社で保証することが稼げいる大きな理由の一つです。

OSS で公開している製品の開発を社外の人に手伝ってもらう

時雨堂は小さな会社なので、コア製品以外の OSS で公開している製品に関しては社外の人にお手伝いをお願いしています。Android SDK や React Native WebRTC Kit や WebRTC Native Client Momo のベースはすべてお手伝いしてくれている方に作っていただきました。

また最近では WebRTC Signaling Server を開発していますが、これもお手伝いしてもらっている方に開発をお願いしています。

社外の技術力の高い人にお手伝いをお願いするときそれが OSS であるというのはとても手伝いやすくなります。

さらに一番コストがかかるリリースや品質保証、ドキュメントなどを時雨堂社内で担保することで、純粋に開発に集中できるようになります。

このように OSS として公開することは、優秀な社外のリソースを利用しやすくなります。

品質にコストをかける

機能より品質を優先するようにしています。特にコードを積極的にリファクタリングすることはとても大切にしています。

WebRTC 関連はとても変化が早い技術です。そのため下手に機能を優先したりすると、足元を救われる可能性がとても高くなります。

それよりは基本的な機能をしっかり作り込んではコードを見直して作り直しなどを繰り返すのがとても重要です。それを繰り返し続けることで、安定して動作する製品が実現できます。

実際に競合から自社に乗り換えるお客様がとても多くほとんどが「他社が不安定なので乗り換えたい」と問い合わせをいただきます。

品質を優先することは、機能を優先することより見栄えが悪いため無駄に思える人が多いようですがそんなことはありません。

目に見えない品質の部分が一番の利益を生み出すと考えています。

製品の軸を WebRTC 以外には手を広げない

時雨堂では自社製品の軸を WebRTC から一切ずらしていません。競合がどんなに新しい機能を実現したとしてもそれは自社で実現するものではないと考えています。

WebRTC だけで大丈夫なの?と思われるかもしれませんが、 WebRTC だけでもやることは山のようにあります。例えば、最近では QUIC もやらなくてはいけなくなりました。さらに WebRTC SFU 側でも libwebrtc への追従以外にもやること、やれることは沢山あります。

なのでむしろ WebRTC に特化するというのはとても良いことだと考えています。

独自の機能の提供

WebRTC SFU Sora にはスポットライト機能という独自の機能があります。これは WebRTC SFU の課題である大人数の会議を実現するための仕組みです。

この機能は「直近で発言した5人」だけを配信するという機能です。この機能を利用すると 1 会議室に 100 人入っても問題ありません。実際に大手で利用されています。

通常の WebRTC SFU であれば 1 会議室に多くても 10 人程度が限界なはずです。この機能はリリースまで半年以上を費やした機能です。

この機能自体を求める人はそんなにはいませんが、この機能を実現していることはとても強いアピールになります。SFU が持っている弱点を機能でカバーしているためです。

小さなチーム

時雨堂は従業員が片手で足りるくらいの小さなチームです。だからこそ意思決定や情報共有のコストはまったくありません。稟議を上げたり、予算をとったりという概念は不要です。

実際、時雨堂の社員でテスト中心にしているプログラマーの仕事は「WebRTC 関連のテストなんかうまいことやっていきたいからなんか作って。2019 年内はそれで」というものです。

社員は自己判断で好きに進められますし、相談したければ普通に F2F で相談できます。そもそも自分が雑談しに行きます。

従量課金ではない

自社製品である WebRTC SFU Sora は同時接続 100 までであれば 1 年間で 60 万円(採用事例あり価格)で提供しています。なんとサポート込みです。小さい企業で社内利用であれば 1 台で十分です。実際、自社の会議用に使ってらっしゃるお客様は多いです。

この金額は 1 人の WebRTC に詳しい技術者を雇うより全然安いです。また運用はたまにアップデートする以外は手間がかかりません。さらにパッケージ製品のため、転送量単位での費用などはかかりません。

従量課金ではないのは実は企業としてはとても使いやすいし、予算計画がとても立てやすいです。

まとめ

実際、何が理由で自社製品が売れるかどうかなんてそう簡単にわかりません。銀の弾丸はありません。実際、時雨堂でとっている戦略は別に特別な戦略だとは思っていません。

ただ、これらの戦略を継続的に実行し、時代が変わればその戦略を見直して変化させていっています。実際、売り始めと今では戦略は大きく変わっています。

今後は海外勢いのある企業がマネーパワーで攻めてくるのが目に見えています。それに負けず、稼げる戦略を考え、実行していきます。