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