| 更新: | 2023-12-08 |
|---|---|
| 作者: | @voluntas |
| バージョン: | 2023.2 |
| URL: | https://voluntas.github.io/ |
タイポなどは Twitter の @voluntas までお願いします。
定期的に更新している
株式会社時雨堂 を作って、 自分が選択したビジネスモデルで充分な利益を上げられるようになったので雑に書き出していく。
時雨堂がどんな会社なのかは 時雨堂コトハジメ を見てほしい。
IT 系零細パッケージメーカー で、ここ最近はパッケージをクラウド版として運用をセットで提供するビジネスも始めている。
主力製品はパッケージソフトウェア製品と、パッケージソフトウェア製品のクラウド版の２つ。
時雨堂は自社開発ミドルウェアのライセンス契約モデルで利益を出している。
- 時雨堂のミドルウェアを利用するためにはライセンスが必要
- 時雨堂のミドルウェアを利用したい顧客とライセンス利用契約を結ぶ
- ライセンスには利用期限があり、延長して利用したい場合は再度ライセンス利用契約を結ぶ
ライセンスの期限は 2023 年 12 月の時点で 3 ヶ月と 6 ヶ月と 12 ヶ月の 3 種類ある。
ミドルウェアを売り切りモデルで販売しているわけではなく、 あくまでミドルウェアを利用する ライセンス契約 で収益を上げている。
そのためライセンスが切れた状態でミドルウェアを利用した場合には契約違反となる。
ライセンスファイルを提供するだけでよく、コストが低いと判断したため。
実際、新規であれば期限を設定したライセンスファイル生成して提供するだけで、 更新であれば期限を更新したライセンスファイルを生成して提供するだけ。
ライセンスファイルの生成は非技術者でも簡単にできるような仕組みを用意してある。
社員時代にミドルウェアのサポート契約モデルが破綻するのを経験したため。
サポート契約モデルは本体を最初に販売し、 その後サポートを契約してもらうことで毎年の利益を得てくモデルになる。
ただ、サポート契約といのは保険みたいなもので障害がなければないほど契約してもらえなくなる。 つまり自分たちが作りたい落ちにくい製品にすればするほどサポート契約をしてもらえなくなる。
または契約していたとしても「今年はサポート問い合わせほとんど発生しなかったのでサポート費用下げてほしい」なんて要望が出てくる。
そうするとサポート契約は義務ではありませんとなり、製品自体の料金を上げていくという戦略か アップデート費用という「大きな機能を追加したのでアップデートしたから上げるのであれば追加費用を払え」という仕組みを顧客に強要することになる。
自分たちが使わない機能追加にたいしてお金を払う必要が出てくる場合もあるため、 アップデートによる追加費用による利益も出るはミドルウェアではよい選択だとは思えなかった。
アップデートが必須なのかどうかもあやふやになる。 アップデートしないとサポート契約は更新できませんなんて選択肢を用意する場合もある。
サポート契約モデルは零細企業のとる戦略ではなく、ある一定規模の企業がとる戦略だと思っている。
アップデート費用モデルが大嫌いだったので「ライセンス契約期間中はどんなに機能が追加されてもアップデートは無料」という仕組みを採用した。
アップデート費用モデルは「費用を稼ぐための新機能を追加する」という営業的要素が入ってくる場合がある。顧客全員が使わない機能でお金を取るとは何事かというのが自分の思いとしてある。
どんな便利な機能が入っても利用料は一切変わらない という方針は自社にも顧客にもシンプルわかりやすいと判断した。
ミドルウェアだとありがちなのが「機能の個別販売」だ。これも嫌いで「全部使える」を採用した。
たとえば A という機能は「ライセンスに A が利用可能 と入っていないと利用できない」という仕組み自体は実装できるがコードを複雑にするし、そもそも顧客管理が複雑になる。
それよりは全部入りで料金はシンプルにする方がよい。特定の市場向けの特定機能は別に使わなければいいだけなので、入っていても問題ない。
社員時代にカスタマイズで破綻するのを経験したため、 カスタマイズは絶対に行わないという強い意志で製品を販売している。
これについてはブログを書いてるので興味あれば読んでみてほしい。
ライセンス契約と書くとちょっと小難しいイメージなので、簡単に書くと「使う権利を売る」となる。
時雨堂が開発したミドルウェアを「自社で使いたいな」という人に「では 1 年でこのくらいいただければ使う権利をお売りしますよ」と。
使いたくなくなったらお金を払わなければいい。使い続けたければお金を払うというシンプルなモデル。
サポートモデルだと「使いたいけどサポート費用払いたくない」という思いが出てくるので「使う＝お金」というシンプルにした。
サポート費用という概念をなくした。ライセンス契約をしてくれている顧客はいつでも自社製品の問い合わせを行うことができる。 サポート費用は保険という考えが多くの人にあるため、その概念をなくしたかった。
ライセンス契約をしてくれている間は面倒見ますよモデル。
明確に事例公開ありの方が料金が低くなるように設定している。
ライセンス契約モデルの場合、キャンペーン料金というのは 既存顧客に対してとても失礼な行為 と思っているので絶対やらない。
たまに値下げ要求をされることがあるが、値下げ要求は断る。 特定顧客だけを値下げすると、既存の顧客に説明が付かない。
時雨堂がとても重視しているのはライセンス契約後にサポートが必要な問題が発生した場合に問題解決が難しいと判断した顧客とは契約を断るというものだ。
ミドルウェアを利用するには一定の技術力を必要とするが、それを満たしていない場合はサポートコストが跳ね上がる。
そのため、時雨堂ではまず無料で利用できる機能制限のない評価版を提供し、頂いたフィードバックを元にライセンス契約を行うかどうかを判断しており、いきなりライセンス契約を行えなくしている。
パッケージ製品として販売している自社製品を自社でサーバーを用意して提供するビジネスモデルを始めた。
基本的には「既存製品を運用するサービス」にしている。付加価値などはできるだけ付けないようにしている。
またオープンソースとして公開しているツール類も組み込んで運用して API や GUI で提供している。
そのため開発はパッケージ製品やオープンソースをサービスとして提供するためのグルーコードがメインになる。
ウェブサイトを充実させ、必要な情報はメールにて聞いてもらうようにしている。 また、一ヶ月無料で使える評価版を提供している。百聞は一見にしかずという方針をとっている。
ミドルウェアなので実際に使ってみて「自分たちが求めているモノなのかどうか」を判断してもらうのがよいと思っている。
打ち合わせしない分、開発やテスト、ドキュメントにリソースをつぎ込める。
とりあえず、情報収集のために打ち合わせだけしたいという企業も多い。 そのあたりは以下にまとめている。
「サプライズの機能発表があります」や「言えませんがステルスで機能開発してます」は行わない。 こんなことやりますよといったロードマップや方針は積極的に Discord や Twitter で共有するようにしている。
ミドルウェアのような地味な製品はサプライズなんか無い方がよい。 それよりもロードマップが明示的になっていたりしたほうが絶対採用しやすい。サプライズは自己満足でしかない
ステルスも同様で、どんな機能を追加しているかどうかなんて隠す必要は全くない。 もし競合がいたとしても公開したタイミングで二番煎じされる。二番煎じされるまでの時間がちょっと長いくらいで顧客への情報共有を遅らせる理由にはならない。
ミドルウェアを販売すると出てくる SDK やツールの対応問題。これは実はとてもやっかいでここを甘く見ている企業は多いと思う。
ミドルウェアを販売して稼ごうとするときに一番問題が起きるのが 顧客が直接触る部分 だ。
SDK は顧客側のソースコードにべったりになるため、サポートコストがとても高くなる。 そこで時雨堂では SDK はサポート一切しない、 ただし SDK のすべてのソースコードを Apache License 2.0 で GitHub に公開するという方針を採用した。
さらに SDK のドキュメントを充実させる、そしてコミュニティを運営し情報共有をしやすくした。
サポートしないというのは SDK の問題を放置するという意味ではない。むしろ SDK のバグは最優先で対応している。数ヶ月待たせたりはなく、早ければその日に対応する。コミュニティだからといってないがしろにすることはない。
SDK やツールをオープンソースにすることで問題解析を顧客がしやすくしている。 また課題に対しての改善提案も行いやすくしている。
オープンソースにしていると素晴らしいプルリクエストを頂いたりもする。
Export ES module by rosylilly · Pull Request #44 · shiguredo/sora-js-sdk
自社オープンソースについて情報共有の場を Discord に用意した。メーリングリストやサイトは運営コストが高いと判断した。さらに管理者を社外の人間として雇った。コミュニティの運営は自社の人間でやると「時間外対応」が難しくなるためだ。
コミュニティ運用にについてはブログを書いてるので興味あれば読んでみてほしい。
自社 OSS のコミュニティ運用を Discord に集約した
自分は 10 年程度だが技術者コミュニティを運用してきたということもありなんとなく感覚があったのは助かった。 とはいえコミュニティ運用はとても難しい。
一番やってはいけないのは「コミュニティなんで参加者の皆さん回答おねがいします」といった対応だ。 コミュニティこそ企業が積極的に関わっていくべきなのに、勘違いしている人は多く見受けられる。
また企業のオープンソースのコミュニティの運営は「参加者の匿名性」を大事にすることが求められると思っている。 パブリックな場所で所属を明示して発言するのはコストが高いためだ。
https://discord.gg/shiguredo から参加できる。
残念ながらオープンソースで成功するビジネスモデルを思いつけなかった。
単にそれだけの理由。 クローズドソースであれば「オープンソースではないのでライセンス契約する」という選択肢をとってもらえる。
自社製品でクローズドソースなものは社外のお手伝いも一切いれずに社内に閉じて開発している。
開発方針の共有コストを考えると社内に閉じることが重要になる。
ミドルウェアは「スケールできない範囲でしか開発しない」というのが重要だと考えている。
社内だけで開発できる範囲で開発し、無理をしないという方針をとっている。
主力製品以外はオープンソース化することで、コミュニティを盛り上げやすい。 ソースコードが見えないというのは思った以上にストレスがたまる。
自社製品でオープンソースなものは設計以外は基本的に社外のお手伝いしてくれている方と開発している。 社内だけに閉じているオープンソースもあるがそれクローズドな自社製品と密結合している場合のみだ。
オープンソースのお手伝いというのは社外の人にとっては「アピールしやすい」というメリットがある。 また隠すモノがないので開発時に得られたノウハウを活用して別の場所で活用もできる。
WebRTC Load Testing Tool Zakuro を作った話
また、メンテナンスという名目で社外の方に仕事を出しやすいというのもある。
オープンソースでの開発は完全にクローズドで、開発して情報共有だけオープンにしている。
これは Lua の開発スタイルを参考にしている。
Lua はオープンソフトウェアだが、オープン開発されたことは一度もない | by V | Medium
自社製品に対して「ロードマップにある機能」を「早めに実装する権利」というのを有償かつ、 ライセンス契約をしているお客様前提で提供している。
これはいつか実装する予定、というのを直近で必要としている顧客から費用支払って貰い、開発をする。
主にオープンソースでやっているが、クローズドソースの主力製品でもやる場合もある。
サポートコストを下げるという目的もあるが、 クローズドソースな製品の場合ソースコードが読めないのでドキュメントだけが頼りになる。あとはサポートに問い合わせるしかない。そのため、とにかくドキュメントには情報を詰め込んである。
こちらもサポートコストを下げるという目的もあるが、 品質が高い製品は、継続して使って貰えるようになる。顧客が競合に乗り換えるのはコストか品質の二択。
コストでの乗り換えはどうしようもないが、品質で乗り換えられるのは製品としてあってはいけないと思う。 なので、品質には特にコストをかけている。
twitterから来ました。参考になるドキュメントありがとうございます。
は、
のtypoかもしれません。