小さな製品、大きな利益
自社商用製品の規模を小さいまま維持して稼ぐという話を大変雑に書いていく。これは自分がやってみて上手くいっているというだけで、これが良いとかの話ではない。
自社商用製品について
自分の会社の商用製品は「サブスクリプション型のパッケージソフトウェア」で、製品を購入した人が自分たちのサーバーにインストールして利用するミドルウェアソフトウェアである。
Erlang/OTP を利用して書かれており、年間ライセンスでのサブスクリプション契約。ソフトウェアを利用する権利を毎年更新して貰うというのがわかりやすいかもしれない。
製品の価格は最小が年 60 万円で、そのソフトウェアを同時に利用する事ができるクライアント数で金額が増えていくという価格体系。
サポートはライセンス料金に込みなので、別途サポートなどを契約する必要はない。
小さな製品とは
自分の考える小さな製品というのは開発者 1 人でその製品にだけ注力することでなんとか開発/メンテできる規模と考えている。
そのためその規模を越える機能追加は一切行わないという方針をとっている。もし大きめの機能をいれるのであれば、欲しい人には欲しいが、あまり使われない機能としている。
最近であればクラスター機能という、マスターレスの冗長構成機能を今までで一番大きい機能を製品開発 7 年目にして入れることにした。機能を導入した理由は自社製品のマネージドサービスを行うためであり、市場を見ての機能追加ではない。
小さな製品を維持するためにやってること
顧客の要望を聞かないがすべてだと思っている。基本的に顧客の要望は「自分たちが欲しい機能」であり「製品に欲しい機能」ではない。
なので自社では「自分たちが必要だと考えている機能一覧」に入っていない要望機能は実装しない。
また、市場や競合を参考にしない事も重要だとおもう。市場の声に惑わされる必要はないし、競合が実装しているから実装するも違う。
よほど製品のコアになるような機能なら別だが市場や競合の判断を信じてはいけない。信じるなら自分の判断だ。実際に売上がでているのであればそちらを信じた方がいい。
具体的に顧客に「この機能が足りていないので採用を見送った」というのが何度も続いたのであれば検討くらいはした方が良い。
自社の場合一番見送られる理由が「パッケージ製品なので構築と運用が大変と感じた」だったということもあり、マネージドサービスを重い腰を上げて始めることにした。これは十分な利益を確保してから始めている。
小さい製品の強み
コードが把握しやすい、テストがしやすい、ドキュメントが維持しやすい、つまりメンテコストが下がるというのがすべてだ。
パッケージソフトウェア開発はメンテナンスコストが 99% くらいなので、メンテナンスコストをどれだけ下げられるかだけに注力すればいい。
質を上げやすいというのもある。小さいからこそ機能ではなく質にこだわることもできる。質はいくらでも投資できるので、開発計画が立てやすい。
小さな製品をたくさんの OSS で補完する
これが他社と大きな差別化だと考えている。自社の商用製品は小さいまま維持しつつ、 SDK やツールなどは OSS として開発して広げていくという戦略をとっている。開発リソース的には OSS が 8 割、商用製品が 2 割くらいの割合で、大きく OSS への投資をしている。
さらに SDK やツールの開発はほとんど自社で行っておらず、お手伝いしてくれている外注メンバーにお願いしている。開発の方針だけ共有してプロジェクト管理、開発、検証、リリースまで任せてしまっている。
OSS で提供することでコミュニティサポートのみと絞っているが、その分フィードバックを共有しやすく改善もしやすい。自社の Discord で運営しているコミュニティ参加者は 1000 人を越えている。OSS を提供為ている場合はコミュニティをうまく運営することはとても重要と考えている。コミュニティ運営も自社で行わず外注メンバーにお願いしている。
会社規模と利益
従業員数は片手で足りる程度。商用製品の利益だけで社員一人一人に賞与を 1200 万以上払っても充分会社に残せて、社員 1 人単位の売上が 1 億円を目指せる状況。
小さな製品なのでサポート問い合わせはほとんど来ないため、基本的には開発に注力している。営業などは一切行っておらず、ウェブサイトからの問い合わせのみ。無理に売らず、本当に欲しい人だけに売る。
質への投資
大事なのは製品の小ささと質であり、多機能な製品は維持コストやサポートが大変になるので厳しい。
質への投資は管理も楽。機能追加は考えることが多いが質は今より良ければいいというシンプルになる。
次のステップとしてのマネージドサービス
小さな製品をマネージドサービスとして提供してみることにした。製品に付加価値をつけて提供とかではなく「構築と運用をしなくていい」だけのマネージドサービス。
他社との差別化を大きくつけるためにも「利用時間」や「転送量」といった課金モデルを採用せず製品もともとにある「同時利用数」と「利用帯域」での課金モデルを採用。つまりつなぎ放題を意識してる。大きい市場はないが「需要が少なからずある」という部分でビジネスしていくことにした。
これも小さな製品を意識している。マネージドだからといって多機能を提供するのではなくあくまで素材（製品）の良さを生かすことにした。
