Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
時雨堂自社製品コトハジメ

時雨堂自社製品コトハジメ

更新:2019-06-17
作者:@voluntas
バージョン:19.06.0
URL:https://voluntas.github.io/

概要

定期的に更新している

株式会社時雨堂 を作ってから 5 期目で自社製品の売上だけで十分社員の給与をまかなえる様になった。

ここにくるまで、色々あったのでまとめておくことにした。

時雨堂がどんな会社なのかは 時雨堂コトハジメ を見てほしい。

前提

  • 時雨堂は自社製品のみでご飯を食べていけるようにするのが目標の会社である
  • 外部からの資金調達は一切行わない
    • 会社を回していくのは皆で頑張る
    • 技術で収入を増やし、総務で支出を減らす

自社製品の歴史

第一弾は Lua の Lint ツール

とにかく自社製品を出したかったが、当時はラーメン代稼ぎで忙しかったので CTO にお願いして作ってもらった。 あまり売れなかったが、時雨堂らしい製品はここがスタート、本当に作ってよかった。

2017 年 5 月でオープンソース化して販売終了した。

第二弾は MQTT シリーズ

ある案件で WebSocket で作ったシステムが結構面倒だった時に MQTT というプロトコルを教えてもらい、勉強がてら MQTT ブローカーを開発した。作りたいものを作ったというよりは、面白そうだから作ったというのが正直な所。

また、 MQTT ブローカーを無料、または 500 円/月で使えるサービスを提供した。さらに IoT ということでデータ集約して送りつける仕組みとしてゲートウェイを作った。

MQTT ブローカーはあまり売れなかった。問い合わせは合ったが売れるところまでは行かないことが多かった。製品説明はかなりしにいった気がする。大阪や京都まで行った事もあった。ただ「勉強になりました」って言われて終わりだった。

IoT は実証実験まではお金が出るが、長期的に利用するサービスはかなり難しいという印象。さらにセンサーやハード側があまりネットワークを理解していないこともあり、サポート負担も高かったため、撤退を決めた。

費用が出にくいと感じていたところにオープンソースで VerneMQ が出てきたのこともあり、商用パッケージで戦うのは難しいと感じていたのも事実だ。

ただ、サービスの方はかなり使っていただいた。2017 年 6 月一杯で MQTT シリーズを終了したが、1000 人以上の方に使っていただいた。これはとても嬉しかった。

第三弾は WebRTC シリーズ

もともと SIP 関連の製品を作りたいと考えていたが SIP はあまりにも癖が強すぎたため、少ないリソースでは体力的にやっていけないと判断したため、 WebRTC 関連の製品を作っていくことにした。

ただ P2P では誰もが実現できてしまうため、サーバ経由モデルを採用。 WebRTC SFU という種類の製品を開発することにした。

開発期間は 1 年程度、もちろんライブラリからフルスクラッチ。その後 2015 年 12 月に正式リリース。WebRTC SFU を無料で利用できるサービスを 2016 年 3 月にリリース。さらに同じ時期に組み込みで WebRTC を利用できる実験製品をリリースした。

  • 2017 年 7 月時点でリリースして 1 年半経過し、社員の給与がすべて自社製品の売上でまかなえるところまでは来た
  • 2018 年 9 月時点でリリースして 2 年半経過し、去年の 2 倍の売上を実現できている
  • 2019 年 3 月時点でリリースして 3 年経過し、去年の 1.5 倍の売上を実現できている

第四弾は負荷試験ツール

いままで仕事で依頼されて負荷試験ツールやシナリオ型の試験ツールは作ってきたが、自社製品として負荷試験ツールいつか作ってみたいと考えていた。

WebRTC SFU に続く自社製品ということで、開発をしていた。あーりアダプターとして採用していただいたお客様でも良い結果を出すことができた。

FGO を支える負荷試験ツール

負荷試験ツールの自社パッケージ製品化はとにかく難しいことがわかった。負荷試験といっても幅広いためカスタマイズなしで請け負うとなると、一通りの機能を実現している必要がある。また固有の環境に対応できるお客様が自由に設定可能な仕組みも必要になる。

そしてそこで動かないとなるとサポートが大変になる。顧客環境でしか発生しない問題を再現するのがとても難しいためだ。

負荷試験ツールを提供して販売するには、ある程度のリソースが必要になることを実感できた。今の規模では負荷試験ツールを開発、維持、サポートしていくのは難しいと考え、新規顧客への販売は諦めることにした。

第五弾は WebRTC シリーズの 1 製品をリニューアルしてオープンソースに

WebRTC Gateway Momo を WebRTC Native Client Momo として完全に 1 から開発し、オープンソースとして公開した

もともと 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 の P2P 向けシグナリングサーバと SDK

利益を目的としない、WebRTC という技術への貢献のための製品

WebRTC の P2P の仕組みは本当に素晴らしいが、自社では SFU を利用したサーバ経由の仕組みのため P2P を利用していない。 そこで WebRTC の P2P を利用する際に必要になるシグナリングサーバを開発しオープンソースとして公開することにした。

シグナリングサーバでベンダーロックされずにメンテナンスされ続けているのが少ないため、ベンダーロックしないシグナリングサーバを提供し続け、 WebRTC に興味を持った人が学びやすくするのが目的だ。 そのためサンプルアプリも用意することにした。

  • ライセンスを Apache License 2.0 としてオープンソースとして公開する
  • Go を利用したスケールアップ可能なシグナリングサーバ
  • Ayame Web SDK の提供
  • React を利用したサンプル
  • React Native のサンプルも作っていく予定

シグナリングの仕様は AppRTC という WebRTC.org が公開しているサンプルと互換性がある仕組みにした。 これは独自にしてしまうとベンダーロックを意識させてしまうからだ。

またコードが複雑になりがちな 3 人以上のフルメッシュの仕組みを排除した。 1 ルーム 2 人に制限することでコードをシンプルに保っている。

最初の売上まで

これはあくまで WebRTC SFU Sora を例にしているので、参考程度にしてほしい。

  • 開発期間に 1 年かかっているので、その間は利益はない
  • リリースしてから売れるまでは半年かかった、WebRTC SFU という概念がまったく認知されていなかった
  • 問い合わせが増えたのもリリースして半年過ぎてから

WebRTC SFU という概念が浸透するのに 1 年以上かかったとのではないか?と勝手に考えてみた。

クローズドソース自社製品の方針

主に 2019 年 6 月時点で時雨堂の主力製品である WebRTC SFU Sora を前提としている。

自社製品を開発、販売、サポートするにあたり方針を決めていった。 実際は提供後に決めたものも多く、事前に決めておくことに越したことはないが、状況に合わせて変化はさせていく。

  • 自社製品は自社で作るモチベーションが維持されることを重視し、利益を重視しない
  • 販売する自社製品はフルスクラッチで開発する
  • 落ちない、簡単、安いを売りにした製品にする
    • 落ちないと運用者のため
    • 簡単は開発者のため
    • 安いは経営者のため
  • 積み重ね型のため、1 台あたりのライセンス価格は低めに設定する
    • 長く使ってもらえる製品を作っていく必要があるライセンス価格にする

販売方針

  • 評価利用を前提とした 1 ヶ月だけ利用可能な評価版を提供する
    • 1 ヶ月以上を利用する場合は有償とする
  • 製品のウェブサイトは 1 年程度でリニューアルする
  • カスタマイズは一切行わない
  • 値下げ要望を受け付けない
    • 大量購入による割引のみ適用する
  • 営業担当者を置かない
    • ブログや技術資料の公開
    • Google Adword による広告
    • 開発者向けのセミナー
  • パッケージ製品のみを販売する
  • 利用料として毎年費用がかかるサブスクリプションライセンス方式を採用する
    • 1 年毎の更新
  • 採用事例が難しい場合は、販売価格を 1.3~1.5 倍高めにする
  • 相手の会社が大きくても小さくても同じ対応する
  • 日本国内だけに販売する
  • 新機能追加での値上げは行わない

広告方針

  • Gist に資料を公開し、積極的にアップデートする
    • 検索するターゲットを技術者に絞る
  • ウェブサイトはわかりやすく

開発方針

  • 落ちない実装を重視する
  • 多くの機能を実装しない
  • 実験的な機能はプレビュー版として提供し、お客様の反応をみる
  • ライセンス料金にはサポート費用を含む
  • 対応 OS は CentOS と Ubuntu LTS のみ
    • 2 世代まで
    • CentOS 8 が出て 1 年が過ぎたら 6 はサポートから落とす
    • Ubuntu 18.04 が出て 1 年が過ぎたら 14.04 はサポートから落とす
  • 製品のバージョン番号は YY.MM.リリース番号 とし、シンプルにする
  • 定期的にリリースする
    • 少なくとも 2 ヶ月に一回はリリースする
  • ライブラリは常に最新版を利用する
  • 内部構造は積極的に変更する

サポート方針

  • 6 時間以内にはファーストレスポンスを返す
  • サポートはサポート・システムができるまではメールのみとし、電話での対応は受け付けない
  • サポートは営業時間のみの対応とし、24/365 は受け付けない
  • ライセンス料金に含まれるサポートは製品のみの対応とし、SDK などのサポートは含まない
  • サポート対応はその製品や SDK の開発者が担当する
  • サーバ、ブラウザ、SDK すべて最新版での問い合わせ以外は受け付けない

ドキュメント方針

  • Sphinx を利用する
  • クイックスタートで簡単に動かせるようにする
  • 細かい点について QA 方式で確認ができるようにする

SDK 方針

  • オープンソースで提供する
    • ライセンスは Apache License 2.0
  • サポートは GitHub Issues か Stack Overflow を利用する
  • Pull-Request はバグ修正以外では受け付けない
  • リソースに余裕できたら有償サポートを受け付ける
  • サンプルをできるだけ用意する

利益モデルのオープンソース自社製品の方針

ここでは 2019 年 6 月時点で OSS として公開し、テクニカルサポートを有料で提供している WebRTC Native Client Momo を前提としていく。

提供方針

  • Apache License 2.0 でソースコードを GitHub に公開する
  • 定期的なアップデートを提供する
  • 機能追加は無料では受け付けない
  • ハードウェア対応の追加は無料では受け付けない
  • アーキテクチャ対応の追加は無料では受け付けない
  • カスタマイズは有料でも受け付けない
  • カスタマイズのテクニカルサポートは有料で受け付ける
  • Windows 対応をクローズドソースにし有料で提供する

開発方針

  • あまり機能追加をせず基本的な機能だけを実装していく
  • 最新ライブラリへの追従
  • カスタマイズしやすくする

テクニカルサポート方針

  • 自社のチャットに専用の部屋を用意する
  • 有料で月額単位で提供する

非利益モデルのオープンソース自社製品の方針

ここでは 2019 年 2 月時点で OSS として公開している WebRTC Signaling Server Ayame を前提としていく。

提供方針

  • Apache License 2.0 でソースコードを GitHub に公開する
  • 定期的なアップデートを提供する
  • 機能は最低限に抑える
  • カスタマイズは有料でも受け付けない
    • ただし自社で受けないだけで共同開発者は受け付けている
  • カスタマイズのテクニカルサポートは有料で受け付けない
    • ただし自社で受けないだけで共同開発者は受け付けている

開発方針

  • あまり機能追加をせず基本的な機能だけを実装していく
  • 最新ブラウザへの追従
  • カスタマイズしやすくする

信念

方針とかぶってるが、大事なことなので二回言いましたということで

将来

サポート専用システムを提供する

現時点ではメールでの対応となっているが、サポート専用サイトを用意し、そこでチケットを発行する形での問い合わせを実現したい。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.