| 更新: | 2024-05-21 |
|---|---|
| 作者: | @voluntas |
| バージョン: | 2024.1 |
| URL: | https://voluntas.github.io/ |
定期的に更新している
株式会社時雨堂 を作ってから 7 期目で自社製品の売上だけで十分社員の給与と賞与をまかなえる様になった。
ここにくるまで、色々あったのでまとめておくことにした。
時雨堂がどんな会社なのかは 時雨堂コトハジメ を見てほしい。
- 時雨堂は自社製品のみでご飯を食べていけるようにするのが目標の会社である
- すでに達成されている
- 外部からの資金調達は一切行わない
- 会社を回していくのは皆で頑張る
- 技術で収入を増やし、総務で支出を減らす
とにかく自社製品を出したかったが、当時はラーメン代稼ぎで忙しかったので CTO にお願いして作ってもらった。 あまり売れなかったが、時雨堂らしい製品はここがスタート、本当に作ってよかった。
2017 年 5 月でオープンソース化して販売終了した。
ある案件で WebSocket で作ったシステムが結構面倒だった時に MQTT というプロトコルを教えてもらい、 勉強がてら MQTT ブローカーを開発した。作りたいものを作ったというよりは、面白そうだから作ったというのが正直な所。
また、 MQTT ブローカーを無料、または 500 円/月で使えるサービスを提供した。 さらに IoT ということでデータ集約して送りつける仕組みとしてゲートウェイを作った。
MQTT ブローカーはあまり売れなかった。問い合わせは合ったが売れるところまでは行かないことが多かった。 製品説明はかなりしにいった気がする。大阪や京都まで行った事もあった。ただ「勉強になりました」って言われて終わりだった。
IoT は実証実験まではお金が出るが、長期的に利用するサービスはかなり難しいという印象。 さらにセンサーやハード側があまりネットワークを理解していないこともあり、サポート負担も高かったため、撤退を決めた。
費用が出にくいと感じていたところにオープンソースで VerneMQ が出てきたのこともあり、 商用パッケージで戦うのは難しいと感じていたのも事実だ。
ただ、サービスの方はかなり使っていただいた。 2017 年 6 月一杯で MQTT シリーズを終了したが、1000 人以上の方に使っていただいた。これはとても嬉しかった。
もともと SIP 関連の製品を作りたいと考えていたが SIP はあまりにも癖が強すぎたため、 少ないリソースでは体力的にやっていけないと判断したため、 WebRTC 関連の製品を作っていくことにした。
ただ P2P では誰もが実現できてしまうため、サーバ経由モデルを採用。 WebRTC SFU という種類の製品を開発することにした。
開発期間は 1 年程度、もちろんライブラリからフルスクラッチ。 その後 2015 年 12 月に正式リリース。WebRTC SFU を無料で利用できるサービスを 2016 年 3 月にリリース。 さらに同じ時期に組み込みで WebRTC を利用できる実験製品をリリースした。
- 2017 年 7 月時点でリリースして 1 年半経過し、社員の給与がすべて自社製品の売上でまかなえるところまでは来た
- 2018 年 9 月時点でリリースして 2 年半経過し、去年の 2 倍の売上を実現できている
- 2019 年 12 月時点でリリースして 4 年経過し、去年の 1.5 倍の売上を実現できている
- 2020 年 11 月時点でリリースして 5 年経過し、去年の 2 倍の売上を実現できている
いままで仕事で依頼されて負荷試験ツールやシナリオ型の試験ツールは作ってきたが、自社製品として負荷試験ツールいつか作ってみたいと考えていた。
WebRTC SFU に続く自社製品ということで、開発をしていた。アーリアダプターとして採用していただいたお客様でも良い結果を出すことができた。
負荷試験ツールの自社パッケージ製品化はとにかく難しいことがわかった。 負荷試験といっても幅広いためカスタマイズなしで請け負うとなると、一通りの機能を実現している必要がある。 また固有の環境に対応できるお客様が自由に設定可能な仕組みも必要になる。
そしてそこで動かないとなるとサポートが大変になる。顧客環境でしか発生しない問題を再現するのがとても難しいためだ。
負荷試験ツールを提供して販売するには、ある程度のリソースが必要になることを実感できた。 今の規模では負荷試験ツールを開発、維持、サポートしていくのは難しいと考え、新規顧客への販売は諦めることにした。
https://github.com/shiguredo/react-native-webrtc-kit
iOS SDK と Android SDK が出揃ったタイミングでよくあるクロスプラットフォームモバイル向けのライブラリを作ることにした。 もともとは既存の react-native-webrtc に貢献していくという方針を取る予定だったが、自社と合わなかったこともあり、自社開発に踏み切った。
- 最初は iOS のみの対応とした
- iOS の取っ掛かりは外部への委託
- リリースまでのラストワンマイルは自社で
- Android の取っ掛かりも外部へ委託
React Native は React というブラウザのフレームワークをモバイルに持ち込むという概念がとても気に入っており、 この製品は完全に自分の趣味で開発している。
実際 React Native は MS が力を入れ始めて Windows ネイティブでも動くようになっている。
react-native-webrtc の開発が安定したこともあり、クローズした。
WebRTC Gateway Momo を WebRTC Native Client Momo として完全に 1 から開発し、オープンソースとして公開した
https://github.com/shiguredo/momo
もともと WebRTC Gateway Momo はクローズドソースで実験的な製品だった。実験的なため利用もほとんどされず、開発リソースも投入できず放置していた。
7 期は売上が安定してきたこともあり新しいことをやりたいと考え、 WebRTC Gateway Momo を WebRTC Native Client Momo として、様々な環境で動くブラウザ不要の WebRTC クライアントとして開発することにした。
- ライセンスを Apache License 2.0 としてオープンソースとして公開する
- Raspberry Pi だけではなく Ubuntu (x86_64 / ARMv8) や 、macOS でも動かせるようにする
- カスタマイズを容易にする
- Raspberry Pi では GPU に搭載されている HWA を利用できるようにする
市場や需要は無視して自分が必要だろうと考えるものを作ることにした。ただし開発自体は社外の人にお手伝いとして入ってもらい、自社は製品の改善と検証に注力することにした。
また自社製品でも利用はできるがあくまで単体で利用できる製品としてリリースした。
多くの人に体験してもらいたいというのが一番の目的ではあるが、ハードウェアに近いところでの WebRTC 需要を広げていきたいというのがある。
ハードウェアに近い場合、 Momo に対してカスタマイズが必要となると考えており、WebRTC SFU Sora のライセンス購入者に対して Momo のテクニカルサポートを提供している。 すでに数社がテクニカルサポート契約をしてくれている。
利益を目的としない、WebRTC という技術への貢献のための製品
WebRTC の P2P の仕組みは本当に素晴らしいが、自社では SFU を利用したサーバ経由の仕組みのため P2P を利用していない。 そこで WebRTC の P2P を利用する際に必要になるシグナリングサーバを開発しオープンソースとして公開することにした。
シグナリングサーバでベンダーロックされずにメンテナンスされ続けているのが少ないため、 ベンダーロックしないシグナリングサーバを提供し続け、 WebRTC に興味を持った人が学びやすくするのが目的だ。そのためサンプルアプリも用意することにした。
- ライセンスを Apache License 2.0 としてオープンソースとして公開する
- Go を利用したシンプルなサーバ
- Ayame Web SDK の提供
- React を利用したサンプルの提供
- React Native のサンプルの提供
コードが複雑になりがちな 3 人以上のフルメッシュの仕組みを排除することで、仕組みをシンプルにした。 1 ルーム 2 人に制限することでコードをシンプルに保っている。
利益を目的としない、WebRTC という技術への貢献のためのサービス
WebRTC の P2P 向けシグナリングサーバをオープンソースで公開したが、より使ってもらいやすくするためにサービスを提供することにした。
- このサービスのための変更をシグナリングサーバ側に手を入れない
- 無料で利用できる
- GitHub アカウントを利用してログインできるようにする
- 認証や TURN サーバの提供などで付加価値をつける
- 転送量は「限界を超えたら全員が使えなくなる」という方針をとった
多くの方が使ってくれており、ベンダーロックフリーの重要性を感じている。 利益は出せないが貢献という意味で投資していきたい。
利益を目的としない、WebRTC SFU を気軽に試せるサービス
- 評価版を試す一歩前の「まず触ってみる」を実現するためのサービス
- 検証目的であれば無料で利用できる
- GitHub アカウントを利用してログインできるようにする
- さくらインターネット様にサーバを提供してもらえた
- 定期的にアカウントをリセットする
- 企業やアカデミックの利用は申請を必要とする
公開してからすぐに Sora の評価版を使ってくれるお客様がでてきたりと、 かなり効果はでている。また仕事で Sora を使っている技術者がプライベートで触ったりといろいろ展開が早くてびっくりしている。
自社製品の利用してもらえる幅を広げる
- OSS として Apache License 2.0 で公開
- Unity という自社にとって未知な製品への対応
- 自社での開発はせず外部委託で開発、メンテをすることを決断
- インターフェースの設計、リリース判断については自社で行う
- 開発、検証については外部へ委託する
- Windows / macOS への対応を行った
- iOS / Android への対応を行った
お客様から Unity クライアントへの対応を依頼され、色々検討した結果、対応をすることにした。 Momo に続き開発とメンテナンスを完全に外部へ委託している。
自社製品の買いたくなるツール第一弾
- OSS として Apache License 2.0 で公開
- オリジナルな負荷試験ツールを開発して提供したかった
- 自社での開発はせず外部委託で開発、メンテをすることを決断
- 自社製品のキャパシティプランニングをしたいという要望に答える
- Linux のみの対応
- 継続的に改善を行い大規模な負荷や柔軟なシナリオを実現していく
お客様から「マシンスペック」を聞かれることが多いが、 実際はネットワークやビットレートに依存するため、回答が難しかった。
とはいえ、WebRTC に明るくないお客様が 100 クライアントなどの負荷を実現するのは難しい、 ということで、CPU さえあれば実現可能なツールを開発した。
開発とメンテナンスを完全に外部へ委託している。
選択肢として選べなけば行けない
- OSS として Apache License 2.0 で公開
- オープンソースで提供することの重要性
- WebRTC SFU を利用する限り「悪意ある管理者」による情報漏えいは避けられない
- クライアント側の立場から「悪意ある管理者」からの防御策を用意
Zoom で話題になった E2EE を実現する。ブラウザレベルで実現することで、利用障壁を下げる。
自社製品の買いたくなるツール第二弾
- OSS として Apache License 2.0 で公開
- ライセンスをクリーンなものとして提供する
- 簡単に利用できる
- 自由に設定ができる
自社製品で録画した複数の映像を合成して一つにするツール。 今までは簡易的なシェルスクリプトを提供していたが、複数のお客様から需要があったため開発し公開
開発とメンテナンスを完全に外部へ委託している。
自社製品の買いたくなるツール第三弾
- OSS として Apache License 2.0 で公開
- 自社製品の統計情報を収集してモニタリングできるようにする仕組み
- TimescaleDB / Grafana を採用
自社製品に組み込んで統計情報を収集して解析できるようにするツール。 今までは顧客事に独自で作って貰っていたのを SDK への組み込みなどで気軽に利用できるようにする。
今後ブラウザでのメディア処理は当たり前になっていくと判断
- OSS として Apache License 2.0 で公開
- 仮想背景やノイズ抑制といったのをブラウザにて実現
- ベンダーロックフリーで npm で提供
誰もが気軽に仮装背景やノイズ抑制と行った仕組みをブラウザで実現するライブラリ。 自社製品に組み込むのではなく、一般的なライブラリとして提供。
自社製品を利用した有料のサービス
- 常時配信を目的とした同時接続数と帯域での課金をするサービス
- 自社製品を運用する初めてのサービス
- サービス運用コストを可能な限り下げる
- クラウドサービスはできるだけ OSS を提供している企業のものを利用する
会社自体に体力が付いたので、自社製品を利用したサービスを提供する。 自社製品を使いやすい形で提供する。パッケージへの移行も簡単にする。
SDK コアライブラリ
- 自社製品で培ったノウハウを利用して新たな分野に展開するための製品
- よりディープな使い方をしたい人向け
- 他の SDK のコアライブラリとして利用する
今までは対応していなかったより低レイヤー向けの SDK を提供することで、 今まで自力で頑張っていた市場に切り込む。
Unity SDK は C++ SDK で置き換えた。 今後は iOS / Android を C++ SDK で置き換えていく予定。
開発終了
- C++ SDK をベースとして Flutter でマルチプラットフォーム対応
- ハードウェアアクセラレーターが気軽に使える Flutter SDK を提供したい
React Native の WebRTC ライブラリをうまくハンドリングできなかった反省を生かして、 ベースを C++ SDK にすることで開発とメンテナンスコストを減らしている。
リリース前に Flutter ユーザーと自社製品ユーザーがマッチしていないと判断し開発を終了。 今後はこのようなマルチプラットフォーム向けの製品への対応は行わないことにした。
- Sphinx で提供為ている自社製品ドキュメントの全部検索対応
- Meilisearch を利用して提供
- 日本語でもインスタントサーチが出来る
ドキュメントがとても重要だが、今までは検索が弱すぎて使い物にならなかったのを専用の全文検索サーバーを運用することで対応
まずはドキュメントを検索してみるというのができるようになった。
提供終了
- Google が公開している超低ビットレートでの音声通話を可能にするコーデックの WebAssembly 化
- Machine Learning と Codec の組み合わせは今後当たり前になると判断
- 自社製品にも組み込み SDK でも気軽に利用できるようにする
WebAssembly 化を行い、ブラウザにから利用できるようにした。 リアルタイムコミュニケーションではビットレートが低いのが正義。
- オープンソースとして公開してる録画合成ツールのクラウド版を提供する
- リアルタイム配信において録画合成は当たり前になりつつあるため
- オープンソースのクラウド版を有償で提供する初の試み
合成用の録画ファイルを格納しておく S3 互換ストレージを用意したりと試行錯誤。 ジョブキューの仕組みを作ったりとこちらも初の試み。
- C++ SDK をベースとして Python でマルチプラットフォーム対応
- 機械学習用途で WebRTC を気軽に使えるようにしたい
C++ SDK をベースに Python から呼び出せるようにした。 PyPI にも登録し、気軽に SDK を利用できるようになった。
- 組み込み向けにバイナリサイズが小さく、フットプリントが軽い SDK を提供したい
- 既存のライブラリだと 4 週間リリースのため、組み込みに使いづらい
- ビルドしやすく、最小限コードでの SDK を提供したい
OBS でも利用されている libdatachannel というライブラリを利用した、 C 向けの WebRTC SDK を提供し始めた。
主にハードウェア組み込みなどの製品をターゲットにしていく。
- ほぼ全てのスマホに搭載されている H.265 ハードウェアアクセラレーター (HWA) を利用したい
- ライセンスをクリアした状態で提供したい
- 中長期的にパッチをメンテしていく
ライセンスは主要なパテントプール 2 団体に確認をとり、 HWA を利用した SDK をバイナリで配布する場合はライセンスは不要との確認を取った。
利用側の判断に委ねる形にはなるが、選択肢が1つ増えた。
これはあくまで WebRTC SFU Sora を例にしているので、参考程度にしてほしい。
- 開発期間に 1 年かかっているので、その間は利益はない
- リリースしてから売れるまでは半年かかった、WebRTC SFU という概念がまったく認知されていなかった
- 問い合わせが増えたのもリリースして半年過ぎてから
WebRTC SFU という概念が浸透するのに 1 年以上かかったとのではないか？と勝手に考えてみた。
パッケージ製品の顧客がおり、その分野ではある程度名前が広まっている状態
- リリース前から使いたいといって頂き、実際リリース後から複数の顧客が付いた
- 売上がリリース直後から確定しまった
定期的にどんな状況なのかを書いていく
- パッケージ製品である WebRTC SFU Sora の売上だけで、社員の給与と賞与を十分まかなえるようになった
- オープンソース製品の優先実装での売上が出せるようになった
- パッケージ製品である WebRTC SFU Sora のクラウド版で売上が出せるようになった
- フルタイムの QA 担当者複数を雇えるようになった
主に 2024 年 5 月時点で時雨堂の主力製品である WebRTC SFU Sora を前提としている。
自社製品を開発、販売、サポートするにあたり方針を決めていった。 実際は提供後に決めたものも多く、事前に決めておくことに越したことはないが、状況に合わせて変化はさせていく。
- 自社製品は自社で作るモチベーションが維持されることを重視し、利益を重視しない
- 販売する自社製品はフルスクラッチで開発する
- 落ちない、簡単、安いを売りにした製品にする
- 落ちないのは運用者のため
- 簡単は開発者のため
- 安いは経営者のため
- 積み重ね型のため、1 台あたりのライセンス価格は低めに設定する
- 長く使ってもらえる製品を作っていく必要があるライセンス価格にする
- 打ち合わせをしない
- 評価利用を前提とした 1 ヶ月だけ利用可能な評価版を提供する
- 1 ヶ月以上を利用する場合は有償とする
- 製品のウェブサイトは積極的に更新する
- カスタマイズは一切行わない
- 値下げ要望を受け付けない
- 大量購入による割引のみ適用する
- 営業担当者を置かない
- ブログや技術資料の公開
- 開発者向けのセミナー
- パッケージ製品のみを販売する
- 利用料として毎年費用がかかるサブスクリプションライセンス方式を採用する
- 1 年ごとの更新
- 3 ヶ月ごとの更新
- 6 ヶ月ごとの更新
- 採用事例なしの場合は販売価格を高めにする
- 最初はかならず採用事例なしの価格からスタート
- 相手の会社が大きくても小さくても同じ対応する
- 新機能追加での値上げは行わない
- 失礼な顧客は相手にしない
- Gist に資料を公開し、積極的にアップデートする
- 検索するターゲットを技術者に絞る
- ウェブサイトはわかりやすく
- オンラインでのセミナーを定期的に行う
- 継続し続けるを重視する
- 多くの機能を実装しない
- 実験的な機能はプレビュー版として提供し、お客様の反応をみる
- ライセンス料金にはサポート費用を含む
- 対応 OS は RHEL と Ubuntu LTS のみ
- 積極的に最新版の利用を推奨する
- 製品のバージョン番号は YYYY.RELEASE.FIX とし、シンプルにする
- 定期的にリリースする
- 少なくとも 6 ヶ月に一回はリリースする
- ライブラリは常に最新版を利用する
- 内部構造は積極的に変更する
- 6 営業時間以内にはファーストレスポンスを返す
- サポートはサポート・システムができるまではメールのみとし、電話での対応は受け付けない
- サポートは営業時間のみの対応とし、24/365 は受け付けない
- ライセンス料金に含まれるサポートは製品のみの対応とし、SDK などのサポートは含まない
- サポート対応はその製品の開発者が担当する
- 製品リリース後は約 12 ヶ月サポートを行う
- ライセンス費用とは別に有料で月単位で提供する
- 自社のチャットに専用のチャンネルを用意する
- Sphinx を利用する
- Sphinx 独自テーマを利用する
- クイックスタートで簡単に動かせるようにする
- 細かい点について FAQ 方式で確認ができるようにする
- 全文検索を提供する
- Discord を利用したコミュニティ運用に寄せる
- オープンソースで提供する
- ライセンスは Apache License 2.0
- 相談はまずは Discord で受ける
- 相談のない GitHub Issues や Pull-Request は受け付けない
- サンプルはシンプルなものにする
- ショウケースをできるだけ用意する
- 製品を購入を前提に技術コンサルを有償で受ける
ここでは 2023 年 8 月時点で OSS として公開し、 テクニカルサポートや開発の優先度を高くする事を有料で提供している WebRTC Native Client Momo や Sora の SDK やツールを前提としていく。
- Discord を利用したコミュニティ運用に寄せる
- Apache License 2.0 でソースコードを GitHub に公開する
- 定期的なアップデートを提供する
- ロードマップにない機能は有償での優先実装で受け付ける
- カスタマイズは有料でも受け付けない
- カスタマイズのテクニカルサポートはクローズド製品を購入してもらってる顧客からのみ有料で受け付ける
- あまり機能追加をせず基本的な機能だけを実装していく
- 最新ライブラリへの追従
- カスタマイズしやすくする
- 自社のチャットに専用のチャンネルを用意する
- 有料で月額単位で提供する
ロードマップにある機能を早めに実装する対応.
全ての自社 OSS 製品で受け付けている。
ここでは 2024 年 5 月時点で OSS として公開している WebRTC Signaling Server Ayame を前提としていく。
- Discord を利用したコミュニティ運用に寄せる
- Apache License 2.0 でソースコードを GitHub に公開する
- 定期的なアップデートを提供する
- 機能は最低限に抑える
- カスタマイズは有料でも受け付けない
- カスタマイズのテクニカルサポートは有料で受け付けない
- あまり機能追加をせず基本的な機能だけを実装していく
- 最新ブラウザへの追従
- メンテナンス効率を優先する
ここでは 2024 年 5 月時点で提供中の Sora Cloud を前提とする。
- あくまでパッケージ製品のクラウド版を提供する
- 色気を出していろいろな機能を提供しない
- 安価で利用可能
- 同時接続数と利用帯域の二つで従量課金モデル
- とにかく高可用性を優先する
- サポートを独自チケットシステムで提供
- 焦らない
- API を提供する
ここでは 2024 年 5 月時点で提供予定の Hisui のクラウド版を前提とする。
- あくまでオープンソース製品のクラウド版を提供する
- 商用製品のクラウド版に機能追加というかたちで提供する
- 色気を出していろいろな機能を提供しない
- 追加料金なしで利用可能
ここでは 2024 年 5 月時点で公開している Sora Labo を前提とする。
- Discord を利用したコミュニティ運用に寄せる
- 無料で利用できる
- メンテナンスは Discord でのみ告知
- 冗長化しない
- サポートはしない
- アドバイスはする
- 稼働保証しない
- データベースの初期化を定期的に行う
- 検証向け機能を実装する
ここでは 2024 年 5 月時点で公開している Ayame Labo を前提とする。
- Discord を利用したコミュニティ運用に寄せる
- 無料で利用できる
- メンテナンスは Discord でのみ告知
- 冗長化しない
- サポートはしない
- アドバイスはする
- 稼働保証しない
- データベースの初期化を定期的に行う
- 自社製品の検証の場とする
- 焦らない
- 機能追加は慎重に
- 対応は Discord でのみ行う
- コミュニティーマネージャを置く
- 「今までの質問に回答したことがある人」に対して優先的に回答する
- バグ報告は優先的に対応する
- Pull-Request には説得を求める
方針とかぶってるが、大事なことなので二回言いましたということで
- 品質を上げてサポートの負担を減らす
- 製品の販売数で勝負する以上は、サポートへの負担は避けられない
- 品質を上げてサポートの負担を減らす – V – Medium
- カスタマイズをしない
- カスタマイズは利益を一時的に生み出すが、製品の寿命を縮める
- カスタマイズをしない – V – Medium
- 営業を雇わない
- インターネットを大いに活用する
- 経営者に優しい製品にする
- 開発者に優しい製品にする
- 運用者に優しい製品にする
サポートとは異なり、自社製品のライセンス契約者であれば好きなだけ参加できる、 クローズドなトレーニングやセミナーを定期開催していきたい。
これは全てオンライン上で開催できる仕組みを想定している。
サポートがライセンス契約に含まれているように、 トレーニングやセミナーの受講もライセンス契約に含めるイメージ。