ポエムです。
自社パッケージ製品のクラウド版を提供して1ヶ月で利益が出たので、どんな感じだったのかを時系列で雑に書いていきます。
前提
- 従業員が片手で足りる人数の零細企業
- パッケージ製品で充分な利益を出している
パッケージ製品のクラウド化 (2022 年 1 月)
自社では WebRTC に関連するミドルウェアのパッケージ製品を提供しており、これが主力商品となっています。パッケージ製品ということで運用はお客様にしてもらいます。閉じた環境でも使えるため多くのお客様に使って頂いています。
パッケージ製品の開発が落ち着いてきたこともあり、クラウド化としてとして提供することにしました。
目的としてはパッケージ運用したくないという企業の取り込みです。またパッケージは年間ライセンスですが、クラウド版は月額利用モデルにすることで、収入の安定化です。
無料のサービスで検証 (2022 年 1–3 月)
まずやったことは、作ろうとしているサービスの似たような仕組みを「自社製品を無料で検証できるサービス」で実験してみるということでした。自社では自社のパッケージ製品を無料で検証できるサービスを提供しています。多くはないですがいろいろな方に使って頂いております。
このサービスをクラウド版の検証場所として色々実現したいことを試しました。認証の仕組みやらログ周りなどなど。利用する技術の検証もここでしました。無料かつ無保証で提供していることもあり、やりたい放題です。
自社パッケージの構成や監視などもここで検証しました。約 3ヶ月間程度検証し、問題なくクラウド版を提供できそうだと手応えを感じたので、クラウド版の開発に移りました。
徹底的な低コスト (2022 年 4–5 月)
パッケージ版では先発でしたが、クラウドサービスとしてはかなり出遅れています。そのため「価格面」での優位度を取ることにしました。
そもそもクラウド化する製品自体は充分な実績がある製品なので、価格にこだわりました。
価格を安くするといっても、利益が出ないようでは意味がありません。利益を十分に出しつつ安く提供する。これを実現するためにパッケージ版では存在しない「日々かかる費用」を下げる技術選定をしました。
- 主要クラウドサービスを採用しない
- できるだけ自前でやる
テーマは二つです。主要クラウドサービスは普通に高いので採用せずに、ベアメタルサーバー (DataPacket) と格安なクラウドサービス (Vultr と Linode) を利用することにしました。
さらに監視なども全てサービスを利用せずに自前で構築することにしました。ちなみに監視ツールには VictroiaMetrics と Grafana を採用しています。
少人数での開発と運用
メイン開発者は 1 人です。プロジェクトに関わっている人自体は 5 名くらいいますが、主に検証がメインです。フロントエンドからバックエンド、インフラ、運用全て 1 人でまかなえるような仕組みを意識しました。
実績のあるパッケージ製品を「簡単に使えるようにする」サービスの提供なので機能を作り込む必要がないというのも少人数でなんとかなります。
自分はビジネスやシステムの設計を担当しました。
機能は最低限
あれもこれもというのではなく、とにかく自社製品を運用せずに利用できる「だけ」という方針で開発を進めました。
機能は後からいくらでも追加できますが、サービスが提供されるタイミングは早ければ早いほうが良いからです。
アーリーアクセスの提供 (2022 年 6–9 月)
サービス開始前に 4 ヶ月のアーリーアクセスを無料で提供することにしました。あせって正式版を公開したり利益を上げるよりも、まずは無料で使ってもらえるアーリーアダプターを集める事を優先しました。
思った以上の企業がアーリーアクセスに参加してくれて、フィードバックもいただけました。実際に運用してみて色々な課題があることがわかりました。
1 から書き直し (2022 年 10–11 月)
課題を解決するため 2 ヶ月後のリリースに向けて 1 から書き直すことにしました。いろいろこねくり回すより最初から書き直した方が早いと判断しました。
書き直しすることでコードも良くなりますし、仕組み自体も良くなります。強くてニューゲームは本当にオススメです。
サービス開始 (2022 年 12 月)
11/30 に募集開始、12/1 にサービス開始しました。開始と同時に複数のお客様から契約したいとお問い合わせを頂きました。パッケージ製品の運用はしたくないけど使いたい、というお客様が意外にも多いことがわかりました。
開始直後にいくつかいけてないバグも見つかったりしましたが、あせらず対応しました。
ベアメタルサーバーのハードウェア変更
思った以上に利用頂くお客様が多くなってきたことから、年末に思い切って AMD EPYC のお高いハードウェアに変更。少なくとも 3 年は戦えるハードウェアにしました。3 時間の停止メンテナンスでなんとか実現しました。今後は停止メンテナンスを一切やらないつもりです。
利用企業が増えていく (2023 年 1 月)
今回のクラウド版は「利用時間」や「転送量」といった一般的な課金方式を一切とらず「繋ぎっぱなし」にしても定額にするというニッチな仕組みを狙いました。
そもそも儲からないモデルというのもありますが、世界中でも競合というものはほぼ存在しません。ありがたいことにお客様も徐々に増えていきました。
利益が出る
もともと低コストでサービスを開発、運用していることもあり、サービス開始1ヶ月で月々にかかるランニングコストを越える売上が出てしまいました。つまり、利益が出てしまいました。
営業なし、宣伝ほぼなし、開発 1 名、大手クラウド利用なしという今の時代とは逆行しているやりかたと見えますが、コストをかけるべきはそこではなく製品の質だと思っているので、そこは技術で解決できればと思っています。
このまま利用企業が増えれば、よりいろいろな投資ができるようになりそうです。パッケージ製品も安定して売上をだしてくれており、クラウド版と二枚看板になっていきそうです。
まとめと今後
とにかく安く作って安く提供する、ただし質は最高のものを。という方針でやっていってますが、うまくいったようです。
今後も低価格路線は変えませんが、より使ってもらえるような機能を提供できればと思っています。
配信周りに懸念は一切ないため、今後は録画や録画合成といった他社が取り組みにくい部分に投資をしていきます。
もし興味があれば、お問い合わせください。
宣伝
12 月 19 日までラムダノートの全ての電子書籍が 50% オフで買える感謝セールを開催中です。
クーポンネーミングライツスポンサー
今回、時雨堂はラムダノートの電子書籍が 50% オフで買える「クーポン」のネーミングライツ、つまりクーポンに付ける名前の権利をラムダノートから購入しています。
これは夏くらいにふと思いついたアイデアです。
時雨堂はただの零細企業なのでとにかく名前を知ってもらう必要があります。知られなければどんなに良い製品を作っても買ってもらえないからです。
主に技術者が利用するミドルウェアを開発、販売している時雨堂としてはラムダノートの本を買おうとする技術者に会社の名前を知ってもらうというのは良い宣伝になるなと思ってはいました。
時雨堂は宣伝になる、ラムダノートは広告費の売上があるということでよくわからんけどとりあえずラムダノートの社長である鹿野さんに相談してみることにしました。
ここで前提となりますが、時雨堂はラムダノートの大株主です。さらに時雨堂のバックオフィス担当社員はラムダノートの総務/経理顧問としてお手伝いをしており、良い意味でズブズブです。
とはいえ、だからといって自分は別にラムダノートに口を出すことはほぼありません。いままで 1–2 回、鹿野さんにこうした方がいいんじゃない?って話をしたくらいです。
鹿野さんとしては、そんなんでお金貰っていいのか?というのが最初の反応でした。とはいえ、特に反対する事はないということで大株主と経営者の間ではすぐに合意がとれました。
あとは、自分や鹿野さんの手は離れて、チームバックオフィスに丸投げされました。そしてその対応が本当に素晴らしかったので裏話として残しておきます。
クーポンの名前
実は自分は「時雨堂の WebRTC SFU Sora !!」みたいな製品名を宣伝することを想定していました。なんとか知ってもらおうと必死でした。
ただ、この案は最終的になくなりました。時雨堂のバックオフィス担当社員とラムダノートのバックオフィス社員の二人がかなりもんで決めてくれたのが、今のクーポン名です。
時雨堂と一緒にラムダノートの8周年突入をお祝いしよう!
自分では全く思いつかない「一緒」に「お祝い」という方向になっていて、衝撃を受けました。これだととてもわかりやすいし、時雨堂を知らない人でも「お祝い」としてクーポンを使うことになるからです。
実際このクーポンの効果は絶大でした。ツイッターに共有する画像には時雨堂ありがとう!とほぼ必ず一緒につぶやかれますし、スクリーンショットにはお祝いのメッセージがたくさん載ります。
このクーポンコードの文字列「時雨堂と一緒にラムダノートの8周年突入をお祝いしよう!」は、お買い物で使ってもらうたびに当社のバックヤードに流れるので、みなさんにお祝いしてもらっている感も半端ありません。ほんとうにほんとうにありがとうございます。
今回のクーポン名を考えたバックオフィスチームの二人は天才だと思います。
クーポンの効果
せっかくセールやるのだからいろいろな人に売れるといいな、と思っていましたがクーポンの効果は絶大だったようです。
売上の詳細は知りませんが、今回をきっかけに新しくラムダノートの本を買って頂いた方も多いようです。
2 週間以上の長い期間にも関わらず、ずっと売れているのも本当に嬉しいです。
そしてこれを機に時雨堂という名前を知って頂いた方もいらっしゃいました。よしよし。
企業の広報担当者へ
今回のような電子書籍全品 50% オフというのはさすがに難しいと思いますが、クーポンのネーミングライツはラムダノートは今後もやっていきたいと考えているようです。
例えばセキュリティ企業が SSL/TLS プロフェッショナルのクーポンを提供するなどはとても良い宣伝になると思います。
是非、興味があったらラムダノートに連絡してみてください。話だけ聞いてみたいというのでも大丈夫だと思います。
今回のセールが時雨堂にとっても、ラムダノートにとっても本当にうまくいって大変よかったです。残り二日間となりますが、是非お買い忘れのないようお願いします。
ラムダノートという IT 技術書籍を世に出している小さな出版社があります。もしかすると IT 技術者であれば、一度はラムダノートの本を手に取ったことがあるかもしれません。
自分は代表である鹿野さんが別の出版社にいたころ編集者として手がけた多くの技術書にお世話になってきました。
その恩返しの気持ちもあり、鹿野さんが自身の出版社であるラムダノートを立ち上げる際に時雨堂として出資をさせてもらったのが 7 年前の 2015 年のことです。
そして今日、2022 年 12 月 1 日にラムダノートは第 8 期に入ります。大変めでたい!
そんなラムダノートをこれからも応援したい、そしてラムダノートの本をもっと多くの IT 技術者に知ってもらいたい。そんな思いから、今回ラムダノートと時雨堂で共同キャンペーンを企画し、ラムダノートのほぼすべての電子書籍がなんと、半額になるセールが実現しました。
ラムダノートの電子書籍を購入する際に、以下の文字列をクーポンコードとして入力してみてください。(数字は半角、記号は全角)
時雨堂と一緒にラムダノートの8周年突入をお祝いしよう!
具体的な購入方法やキャンペーンの期間については、ラムダノートのお知らせ を確認してください。
この機会に、自分自身がそうだったように、多くの人が良い書籍に出会ってほしいと思っています。
ちなみに初めて読んだ鹿野編集本は RTP 本です。そしてオススメの一冊はプロフェッショナル SSL/TLS です。
本日 2022 年 11 月 30 日に時雨堂のパッケージソフトウェア WebRTC SFU Sora (以下 Sora) のクラウド版である Sora Cloud の申込受付を開始しました。
要約
- Sora のクラウド版でサーバーの構築や運用が不要
- 転送量や利用時間ではなく最大同時接続数と最大利用帯域による料金体系
- 思い切った低価格
- 自社パッケージ製品のクラウド版にこだわる
クラウド版の提供
Sora はパッケージソフトウェアとして提供しているため、ユーザー自身でサーバー構築と運用が必要です。Sora Cloud は Sora のクラウド版として時雨堂が構築や運用を行い、マルチテナンシーを実現し、提供します。
パッケージ製品を提供しているにもかかわらず、なぜクラウド版の提供を始めるのかというと、Sora でクラスター機能を実現したことにより耐障害性が高まったため、少人数のメンバーでもサービスを運用していけると判断したからです。
また、日本での WebRTC SFU パッケージ市場はほとんど敵なしになったと感じていたため、クラウド市場に殴り込みをかけることにしました。
料金体系
クラウド版の提供で一番悩んだのは料金体系です。世の中の WebRTC SFU クラウドは転送量課金(1GB いくら) か利用時間課金 (1 分いくら) のどちらかです。この料金体系は、営業や体力勝負になるのが目に見えています。
そのため、全く別の料金体系を取ることにしました。
- もともと Sora のライセンス料金でも採用している「最大同時接続数」での課金
- 「最大利用帯域」での課金
転送量や利用時間による課金とは異なり、「最大同時接続数や最大利用帯域が変わらなければ定額で利用できる」という料金体系を採用しました。
これは、今後リアルタイム配信には「常時接続」が要求される場面が増えると考えているためです。もちろん他社との差別化という目的もあります。
そして、料金は思い切って最初から可能な限り下げました。月 100 Mbps 使い放題、最大同時接続数 10 で、月 5 万円です。1 ヶ月間繋ぎっぱなしにしても月 5 万円です。もしこれが転送量課金や時間課金だと大変な額が請求されます。少なくとも 10 倍以上は差が出ると思います。
あくまで自社製品のクラウド版にこだわる
Sora Cloud はシンプルに Sora をクラウド版として提供するものであり、それ以外の付属機能などは一切提供しません。
録画ファイルの保存も S3 または S3 互換ストレージをユーザーに用意してもらい、そこにアップロードする仕組みとなっています。
今後は Sora をより便利に使うために時雨堂が開発している Sora 専用ツールのクラウド版も提供し、映像合成やリアルタイム文字起こしなども実現できるようにする予定です。リアルタイム文字起こし機能については Sora Cloud の機能としては提供せず、AWS や GCP などの Speech To Text サービスをユーザーに準備してもらってそれと連携できるようにする方針です。
Sora の機能に色々な付加価値を付けて提供するといった戦略はとりません。シンプルに自社パッケージ製品 Sora のクラウド版として提供することにこだわります。
今後
まずはログ全文検索機能、統計情報の収集機能など、Sora をクラウド化することで一部利用が制限されている機能も利用できるようにし、パッケージ版との差を埋めていければと思います。
もともと Sora 自体も継続的な開発により少しずつできることが増え、今回自分たち自身がサーバーを構築し運用する経験をすることで得られる情報や知見も増えたので、今後より一層パッケージ版の Sora も改善して行けると考えています。
引き続き Sora と Sora Cloud をよろしくお願いします。
IT 系零細パッケージメーカーの場合
自社商用製品の規模を小さいまま維持して稼ぐという話を大変雑に書いていく。これは自分がやってみて上手くいっているというだけで、これが良いとかの話ではない。
自社商用製品について
自分の会社の商用製品は「サブスクリプション型のパッケージソフトウェア」で、製品を購入した人が自分たちのサーバーにインストールして利用するミドルウェアソフトウェアである。
Erlang/OTP を利用して書かれており、年間ライセンスでのサブスクリプション契約。ソフトウェアを利用する権利を毎年更新して貰うというのがわかりやすいかもしれない。
製品の価格は最小が年 60 万円で、そのソフトウェアを同時に利用する事ができるクライアント数で金額が増えていくという価格体系。
サポートはライセンス料金に込みなので、別途サポートなどを契約する必要はない。
小さな製品とは
自分の考える小さな製品というのは開発者 1 人でその製品にだけ注力することでなんとか開発/メンテできる規模と考えている。
そのためその規模を越える機能追加は一切行わないという方針をとっている。もし大きめの機能をいれるのであれば、欲しい人には欲しいが、あまり使われない機能としている。
最近であればクラスター機能という、マスターレスの冗長構成機能を今までで一番大きい機能を製品開発 7 年目にして入れることにした。機能を導入した理由は自社製品のマネージドサービスを行うためであり、市場を見ての機能追加ではない。
小さな製品を維持するためにやってること
顧客の要望を聞かないがすべてだと思っている。基本的に顧客の要望は「自分たちが欲しい機能」であり「製品に欲しい機能」ではない。
なので自社では「自分たちが必要だと考えている機能一覧」に入っていない要望機能は実装しない。
また、市場や競合を参考にしない事も重要だとおもう。市場の声に惑わされる必要はないし、競合が実装しているから実装するも違う。
よほど製品のコアになるような機能なら別だが市場や競合の判断を信じてはいけない。信じるなら自分の判断だ。実際に売上がでているのであればそちらを信じた方がいい。
具体的に顧客に「この機能が足りていないので採用を見送った」というのが何度も続いたのであれば検討くらいはした方が良い。
自社の場合一番見送られる理由が「パッケージ製品なので構築と運用が大変と感じた」だったということもあり、マネージドサービスを重い腰を上げて始めることにした。これは十分な利益を確保してから始めている。
小さい製品の強み
コードが把握しやすい、テストがしやすい、ドキュメントが維持しやすい、つまりメンテコストが下がるというのがすべてだ。
パッケージソフトウェア開発はメンテナンスコストが 99% くらいなので、メンテナンスコストをどれだけ下げられるかだけに注力すればいい。
質を上げやすいというのもある。小さいからこそ機能ではなく質にこだわることもできる。質はいくらでも投資できるので、開発計画が立てやすい。
小さな製品をたくさんの OSS で補完する
これが他社と大きな差別化だと考えている。自社の商用製品は小さいまま維持しつつ、 SDK やツールなどは OSS として開発して広げていくという戦略をとっている。開発リソース的には OSS が 8 割、商用製品が 2 割くらいの割合で、大きく OSS への投資をしている。
さらに SDK やツールの開発はほとんど自社で行っておらず、お手伝いしてくれている外注メンバーにお願いしている。開発の方針だけ共有してプロジェクト管理、開発、検証、リリースまで任せてしまっている。
OSS で提供することでコミュニティサポートのみと絞っているが、その分フィードバックを共有しやすく改善もしやすい。自社の Discord で運営しているコミュニティ参加者は 1000 人を越えている。OSS を提供為ている場合はコミュニティをうまく運営することはとても重要と考えている。コミュニティ運営も自社で行わず外注メンバーにお願いしている。
会社規模と利益
従業員数は片手で足りる程度。商用製品の利益だけで社員一人一人に賞与を 1200 万以上払っても充分会社に残せて、社員 1 人単位の売上が 1 億円を目指せる状況。
小さな製品なのでサポート問い合わせはほとんど来ないため、基本的には開発に注力している。営業などは一切行っておらず、ウェブサイトからの問い合わせのみ。無理に売らず、本当に欲しい人だけに売る。
質への投資
大事なのは製品の小ささと質であり、多機能な製品は維持コストやサポートが大変になるので厳しい。
質への投資は管理も楽。機能追加は考えることが多いが質は今より良ければいいというシンプルになる。
次のステップとしてのマネージドサービス
小さな製品をマネージドサービスとして提供してみることにした。製品に付加価値をつけて提供とかではなく「構築と運用をしなくていい」だけのマネージドサービス。
他社との差別化を大きくつけるためにも「利用時間」や「転送量」といった課金モデルを採用せず製品もともとにある「同時利用数」と「利用帯域」での課金モデルを採用。つまりつなぎ放題を意識してる。大きい市場はないが「需要が少なからずある」という部分でビジネスしていくことにした。
これも小さな製品を意識している。マネージドだからといって多機能を提供するのではなくあくまで素材(製品)の良さを生かすことにした。