Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
時雨堂を支えるビジネスモデル

時雨堂を支えるビジネスモデル

更新:2021-03-14
作者:@voluntas
バージョン:2020.2
URL:https://voluntas.github.io/

概要

定期的に更新している

株式会社時雨堂 を作って自分が選択したビジネスモデルで利益を上げられるようになったので雑に書き出していく。

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

前提

IT 系零細パッケージメーカー

ライセンス契約モデル

時雨堂は自社開発ミドルウェアのライセンス契約モデルで利益を出している。

  • 時雨堂のミドルウェアを利用するためにはライセンスが必要
  • 時雨堂のミドルウェアを利用したい顧客とライセンス利用契約を結ぶ
  • ライセンスには利用期限があり、延長して利用したい場合は再度ライセンス利用契約を結ぶ

ライセンスの期限は 2021 年 3 月の時点で 3 ヶ月と 12 ヶ月の 2 種類ある。

ミドルウェアを売り切りモデルで販売しているわけではなく、 あくまでミドルウェアを利用する ライセンス契約 で収益を上げている。

そのためライセンスが切れた状態でミドルウェアを利用した場合には契約違反となる。

ライセンス契約モデルを選択した理由

ライセンスファイルを提供するだけでよいため作業コストが低いと判断したため。

実際、新規であれば期限を設定したライセンスファイル生成して提供するだけで、 更新であれば期限を更新したライセンスファイルを生成して提供するだけ。

ライセンスファイルの生成は非技術者でも簡単にできるような仕組みを用意してある。

サポート契約モデルを選択しなかった理由

社員時代にミドルウェアのサポート契約モデルが破綻するのを経験したため。

サポート契約モデルは本体を最初に販売し、 その後サポートを契約してもらうことで毎年の利益を得てくモデルになる。

ただ、サポート契約といのは保険みたいなもので障害がなければないほど契約してもらえなくなる。 つまり自分たちが作りたい落ちにくい製品にすればするほどサポート契約をしてもらえなくなる。

または契約していたとしても「今年はサポート問い合わせほとんど発生しなかったのでサポート費用下げてほしい」なんて要望が出てくる。

そうするとサポート契約は義務ではありませんとなり、製品自体の料金を上げていくという戦略か アップデート費用という「大きな機能を追加したのでアップデートしたから上げるのであれば追加費用を払え」という仕組みを顧客に強要することになる。

自分たちが使わない機能追加にたいしてお金を払う必要が出てくる場合もあるため、 アップデートによる追加費用による利益も出るはミドルウェアではよい選択だとは思えなかった。

アップデートが必須なのかどうかもあやふやになる。 アップデートしないとサポート契約は更新できませんなんて選択肢を用意する場合もある。

サポート契約モデルは零細企業のとる戦略ではなくある一定規模の企業がとる戦略だと思っている。

ライセンス契約期間中はアップデートは無料

アップデート費用モデルが大嫌いだったので「ライセンス契約期間中はどんなに機能が追加されてもアップデートは無料」という仕組みを採用した。

アップデート費用モデルは「費用を稼ぐための新機能を追加する」という営業的要素が入ってくる場合がある。顧客全員が使わない機能でお金を取るとは何事かというのが自分の思いとしてある。

どんな便利な機能が入っても利用料は一切変わらない という方針は自社にも顧客にもシンプルわかりやすいと判断した。

オプション販売は行わない

ミドルウェアだとありがちなのが「機能の個別販売」だ。これも嫌いで「全部使える」を採用した。

たとえば A という機能は「ライセンスに A が利用可能 と入っていないと利用できない」という仕組み自体は実装できるがコードを複雑にするし、そもそも顧客管理が複雑になる。

それよりは全部入りで料金はシンプルにする方がよい。特定の市場向けの特定機能は別に使わなければいいだけなので、入っていても問題ない。

カスタマイズは行わない

社員時代にカスタマイズで破綻するのを経験したため、 カスタマイズは絶対に行わないという強い意志で製品を販売している。

これについてはブログを書いてるので興味あれば読んでみてほしい。

カスタマイズをしない

利用権利を売る

ライセンス契約と書くとちょっと小難しいイメージなので、簡単に書くと「使う権利を売る」となる。

時雨堂が開発したミドルウェアを「自社で使いたいな」という人に「では 1 年でこのくらいいただければ使う権利をお売りしますよ」と。

使いたくなくなったらお金を払わなければいい。使い続けたければお金を払うというシンプルなモデル。

サポートモデルだと「使いたいけどサポート費用払いたくない」という思いが出てくるので「使う=お金」というシンプルにした。

ライセンス契約にサポート対応を入れ込む

サポート費用という概念をなくした。ライセンス契約をしてくれている顧客はいつでも自社製品の問い合わせを行うことができる。 サポート費用は保険という考えが多くの人にあるため、その概念をなくしたかった。

ライセンス契約をしてくれている間は面倒見ますよモデル。

事例公開でライセンス料金を変更する

明確に事例公開ありの方が料金が低くなるように設定している。

キャンペーン料金はなし

ライセンス契約モデルの場合、キャンペーン料金というのは 既存顧客に対してとても失礼な行為 と思っているので絶対やらない。

サポートが難しい場合は契約しない

時雨堂がとても重視しているのはライセンス契約後にサポートが必要な問題が発生した場合に問題解決が難しいと判断した顧客とは契約を断るというものだ。

ミドルウェアを利用するには一定の技術力を必要とするが、それを満たしていない場合はサポートコストが跳ね上がる。

そのため、時雨堂ではまず無料で利用できる機能制限のない評価版を提供し、頂いたフィードバックを元にライセンス契約を行うかどうかを判断しており、いきなりライセンス契約を行えなくしている。

打ち合わせしない

ウェブサイトを充実させ、必要な情報はメールにて聞いてもらうようにしている。 また、一ヶ月無料で使える評価版を提供している。百聞は一見にしかずという方針をとっている。

ミドルウェアなので実際に使ってみて「自分たちが求めているモノなのかどうか」を判断してもらうのがよいと思っている。

打ち合わせしない分、開発やテスト、ドキュメントにリソースをつぎ込める。

とりあえず、情報収集のために打ち合わせだけしたいという企業も多い。 そのあたりは以下にまとめている。

無償での情報搾取

サプライズやステルスはしない

「サプライズの機能発表があります」や「言えませんがステルスで機能開発してます」は行わない。こんなことやりますよといったロードマップや方針は積極的に共有するようにしている。

ミドルウェアのような地味な製品はサプライズなんか内容がよい。それよりもロードマップが明示的になっていたりしたほうが絶対採用しやすい。サプライズは自己満足でしかない

ステルスも同様で、どんな機能を追加しているかどうかなんて隠す必要は全くない。 もし競合がいたとしても公開したタイミングで二番煎じされる。二番煎じされるまでの時間がちょっと長いくらいで顧客への情報共有を遅らせる理由にはならない。

SDK はサポートしない

ミドルウェアを販売すると出てくる 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 年程度だが技術者コミュニティを運用してきたということもありなんとなく感覚があったのは助かった。 とはいえコミュニティ運用はとても難しい。

一番やってはいけないのは「コミュニティなんで参加者の皆さん回答おねがいします」といった対応だ。コミュニティこそ企業が積極的に関わっていくべきなのに、勘違いしている人は多く見受けられる。

また企業のオープンソースのコミュニティの運営は「参加者の匿名性」を大事にすることが求められると思っている。パブリックな場所で所属を明示して発言するのはコストが高いためだ。

主力製品はクローズドソースにする

残念ながらオープンソースで成功するビジネスモデルを思いつけなかった。

単にそれだけの理由。 クローズドソースであれば「オープンソースではないのでライセンス契約する」という選択肢をとってもらえる。

クローズドソースな自社製品は社内で開発する

自社製品でクローズドソースなものは社外のお手伝いも一切いれずに社内に閉じて開発している。

開発方針の共有コストを考えると社内に閉じることが重要になる。

ミドルウェアは「スケールできない範囲でしか開発しない」というのが重要だと考えている。

社内だけで開発できる範囲で開発し、無理をしないという方針をとっている。

関連製品はオープンソース化する

主力製品以外はオープンソース化することで、コミュニティを盛り上げやすい。 ソースコードが見えないというのは思った以上にストレスがたまる。

オープンソースな自社製品は社外と開発する

自社製品でオープンソースなものは設計以外は基本的に社外のお手伝いしてくれている方と開発している。 社内だけに閉じているオープンソースもあるがそれクローズドな自社製品と密結合している場合のみだ。

オープンソースのお手伝いというのは社外の人にとっては「アピールしやすい」というメリットがある。 また隠すモノがないので開発時に得られたノウハウを活用して別の場所で活用もできる。

WebRTC Load Testing Tool Zakuro を作った話

他にも libwebrtc に貢献する仕事で名前が載ったりする。

https://webrtc.googlesource.com/src.git/+/198299c16144506591282ddb93a902242a4c05d3%5E%21/#F0

また、メンテナンスという名目で社外の方に仕事を出しやすいというのもある。

ドキュメントにコストを払う

サポートコストを下げるという目的もあるが、 クローズドソースな製品の場合ソースコードが読めないのでドキュメントだけが頼りになる。あとはサポートに問い合わせるしかない。そのため、とにかくドキュメントには情報を詰め込んである。

自社用 Sphinx テーマを作成している - V - Medium

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment