時雨堂創業 12 年目
2013 年 3 月 8 日に時雨堂を創業し、2024 年 3 月 8 日で時雨堂創業 11 年、そして 12 年目にはいりました。あっという間です。 起業のきっかけは、ある経営者に「貴方がどんなに一生懸命に製品を作ってもそれは会社のものでしかないので、自分の会社を持って自分の製品を作って、売った方がいい」といわれた事なんですが、それから 11 年立ちました。 起業したときから状況も大きく変わりました。自社製品の売り上げだけで会社が回っています。今後の時雨堂について雑に書いて行きます。 少人数でスケールする製品を作り続ける時雨堂はパッケージソフトウェアのサブスクリプションで稼いでいる会社です。営業もいないため、買いたいといってくれる企業に売るだけです。 社員が社内にあるライセンス発行サーバーに Tailscale でリモートで繋いでライセンス (JSON ファイル) を発行し、ライセンスフ
2022 年に学んで良かった技術
雑に書いていきます。 バックグラウンド自分のバックグラウンドスキルは以下の通り。専門はリアルタイムな通信プロトコルを利用したサーバーの設計と開発とマーケティング。 Erlang/OTPWebRTCEnd to End Encryption細かいのはこちら。 SQLGo で sqlc を使うために学ぶことにした。sqlc を採用したのは複数人数で開発するときの共通言語としては SQL の方がいいだろうというのと、SQL はどんなデータを持たせたいのかを伝えるのに便利と判断したため。 今までずっと通信系ミドルウェアの開発をしてきたこともあって SQL を学ぶ必要が無かったが、今回いい機会なのでちゃんと学ぶことにした。 まずは利用データベースを完全にしぼって TimescaleDB (PostgreSQL ベース) で利用する SQL だけを学ぶことにした。 書籍は元 SIer のガチ SQL
企業 OSS を継続開発するためにやっていること
時雨堂は企業か開発する OSS としていくつかのリポジトリを GitHub に公開しています。これらを継続的に開発するためになにをしているかを書いていきます。 まとめOSS に利益を期待しないコミュニティや社外の人と仲良くするOSS に理解のある人だけを社員として雇う前提オープンソースのライセンスは Apache License 2.0ソースコードはオープン、開発はクローズコミュニティは Discord のみOSS の定義“オープンソースの定義” を前提としています。 時雨堂が OSS 採用しているライセンスである Apache License 2.0 は OSI 承認オープンソースライセンスです。 そのため時雨堂が公開している OSS は Apache License 2.0 のもと、利用可能です。 ソースコードはオープン、開発はクローズド 時雨堂の OSS の開発方針は Lua の開発
時雨堂 7 期振り返り
期末が 9 月なので残り 3 ヶ月切りました、振り返りは何度やってもいい、ということで少し早いですが振り返ることにしました。 秋の時代 豊作の秋今期はなぜか馬車馬のように働いた前期の過去最高の売上をさくっと超えてしまう予定です。自社製品の売上は前期比で現時点で 1.5 倍で、もう少し増えそうです。 想定とは大きく異なりますが、会社的にはとても良い結果になりそうです。経営者的にはまったく機能していないことがよくわかります。 方針通りには進んだ前期の始まりに掲げた会社の方針は以下のとおりです。 今期は新規のお手伝いする場合は WebRTC や負荷試験など時雨堂が今後やっていこうとしている方向に絞って受け、それ以外は自社製品にコミットしていくという方針を取っていきますこの方針はほぼ守れています。 WebRTC と負荷試験以外の仕事はほぼ受けていません。それ以外の仕事はお手伝いしてくれている める
食べていけてる時は無理に稼がない
ありがたいことに自社製品が多くの企業に導入して頂けており、自社製品の売上だけで食べていけるようになりました。 今までは自社製品だけでは食べていけなかったため、外のお手伝いをしていました。ただ自社製品だけで食べていけるようになったのは経営者としてはじめてなので、どうしてみてるかを書いていきます。 会社の状況従業員たちの給与と会社の維持にかかる費用はすでに自社製品の売上で十分まかなえています。普通に賞与も出せるレベルです。 自社製品はパッケージ製品のため、運用などはありません。労働時間は 6 時間の定時労働、土日祝日、年末年始はお休みです。残業はお手伝い系の仕事が忙しくなるとありますが、自社製品に関しては皆無です。 パッケージ製品の開発方針機能より品質重視という方針をとっています。またカスタマイズは受けていません。そのため、自社製品に関しては顧客との調整などは発生しません。サポートの問い合わせ
打ち合わせの条件
自社ではミドルウェアパッケージ製品を開発して販売しています。営業はおらず、検索からの問い合わせがほとんどです。 その場合、詳細な要件は内緒だが、まずは打ち合わせしてほしいと言われることがありますが、もともとの知り合いとかではない限り、打ち合わせをするため条件に１ヶ月間、無料で利用できる評価版を使ってみることをお願いしています。普通はまず打ち合わせをして、そこから評価版へと行くのが多いと思いますがその逆をやってみています。 打ち合わせの前に評価版を提供する理由結構ネガティブな理由が多いです。 小さい会社なので打ち合わせに時間を取られなくない要件がまとまっていない打ち合わせはお互い嬉しくないただ一方的な情報交換がしたいだけなので会いたくないそもそも製品を買いたいなら使ってみるのが一番本気で検討しているなら検証する時間を取る実際に使いながらの質疑応答が効率がいいミドルウェアの場合は実際使ってみな
商売の脆弱性
ソフトウェアのパッケージ販売に携わってもう 10 年以上になるが、どうもこのビジネスってずるすぎないか？ってずーっと思いながらやっているのだが、 ajiyoshi が商売の脆弱性という、うまい表現を使っていたのでパクることにして、ブログを書いてみることにした。タイトル重要。 前提自分はミドルウェアという分野のソフトウェアパッケージ製品を専門にしている開発者（あと経営者）という立場。会社を持つ前も同じ分野を担当していた。 ここでのソフトウェアのパッケージ販売というのはミドルウェア製品のパッケージ製品のサブスクリプションライセンス販売を指している。 ソフトウェアのパッケージ販売在庫が不要ほんとこれ。なんだよそれって思う。うちの例だとダウンロード URL とライセンスファイルをメールで送ってそれで納品完了。 在庫がないのに物が売れるって本当に意味がわからない。ダウンロード URL から製品をダウ
無償での情報搾取
IT 系零細企業を経営していて、特定の技術に強いと外から思われ始めると無償での技術情報の搾取を目的とした問い合わせが多くなる。 自分は残念ながら無償で技術情報の搾取をされた経験があるので、注意喚起として書いておく。この悪しき習慣を潰したい。 情報交換をしたいこのフレーズがメールの文章に含まれていた場合は、とても注意すべきだ。殆どの場合であなたの会社の方が情報を持っており、相手は無償で技術的な情報を得たいと考えていることが多い。 技術の分野の世界はとても狭いので、ほんとうの意味で情報交換を申し込んで来る人はあなたがすでに知っている人の可能性が高い。全く知らない人が情報交換を持ちかけてくるのはまず疑ったほうがいい。 知らない会社から「情報交換をしたい」と言われたら、丁重にお断りをするべきだ。情報交換をしたいと言ってきた会社から仕事につながった経験はまったくない。彼らは一方的な搾取を望んでいるだ
自社製品で食べていけるようになるまでやったこと
ミドルウェアのパッケージ製品で食べていけるようになるまでやったことを自分のメモ代わりにまとめておきます。 製品の事業計画を明確にしない自分が想定したとおりに行くことが少ないこともあり事業計画を書いたりしません。日々の状況を見ながら判断をしていくということをしています。そのため中長期的な計画は品質の向上くらいにしておき、機能追加に関してはその度々に考えて実装していくのが一番です。 変化が早い分野でもあるので、事業計画を用意するメリットが零細企業にはないと考えています。 リリース前の開発進捗を共有するステルスはデメリットが多いと判断し、今開発しているもの開発中の状況などを共有しました。これは「製品をステルスで開発して、出したとしても買ってもらうまでの時間がかかる」と考えたからです。 それよりはあの会社があんなの作ってるそろそろ出るらしいと思ってもらえたほうが検討してもらいやすくなります。 今、
評価制度について – V – Medium
評価制度について年一回、自分の考えを書いていくということをやっていくことにする。 自社の評価制度評価制度自体がないので、評価は行っていない。給与も同じで賞与も同じ。詳細を知りたい方は評価制度の無い評価制度という資料があるので見てもらいたい。 従業員が数名であることもあり、評価制度がない状況でうまく回っている。実際社員に聞いても評価制度がないのは働きやすいとのこと。 会社の事業に対してコミットし、会社の利益がでれば賞与として還元される。この仕組で困っていない。 評価制度に対する考え上司による評価、経営者による評価、全方位評価、様々な評価を受けてきたが、残念ながらどれも満足した評価制度だったことはない。 評価制度は「その評価制度」をハックする仕組みがあるのが問題だと考えている。自分はどうもその評価制度をハックするのがうまいようで、今の所不当な評価をされたことはない。 ただ、ハックできない人が評
自分が働きたい会社にしない
時雨堂は会社の仕組みを Gist でオープンにしている。実はあの仕組みは自分が働きたいと思う会社の仕組みではない。 時雨堂は 10:00–17:00 の定時制で 6 時間労働。さらには仕事は選べない。技術もあまり選べない。月給は安く抑えられており、賞与は保証なし。ただし儲かった場合は賞与を高めに出す。評価制度はない。 時雨堂で自分が従業員として働きたいとは思っていない。自分が従業員として働くのであれば、裁量労働で、仕事は好き勝手に選べて、給与は稼いだ分だけほしい。さらに技術は自分が使いたいものを使う。ただし食堂はあってほしい。 ではなぜ時雨堂は自分の働きたい会社になっていないのか。それは単純で自分はあくまで経営者であり、従業員ではないからだ。そして自分は社会不適合者であるため、従業員としてやっていけなかったから起業した身であるからだ。 つまり従業員としてやっていけなかった人が望む会社の仕組
レベルが高い人を雇って物理で殴る. 先日、門脇(kdxu)とめるぽんと自分で 3… | by V | Medium
先日、門脇(kdxu)とめるぽんと自分で 3 人でやっていたお手伝い案件が終わった。納期は一ヶ月前倒し、顧客の要望はほぼ全て実現という内容で、顧客も大喜び。 門脇とめるぽんはフリーランスとして仕事をしており、自分がお手伝いさせて頂いている会社（それぞれ別の会社）でふたりともフルタイムとして働いている。 そのため、平日の夜や土日が主な作業時間になる。完全非同期で作業して、うまくいったのでそれを記録しておきたい。 案件内容、技術については一切触れない。 自分はプロジェクトマネージメントのみコードは書かないプロジェクト開始前に一通りの要望は洗い出しておいた追加要件にできるだけノーを言わないロードマップを１ヶ月単位で引いた二人を作業者として雇った設計や交渉などはすべて自分が行った顧客には二人が作業者として伝えてある顧客と直接のやり取りは二人は行っていない顧客との打ち合わせにも参加してもらっていない
集中力のない人の戦略
集中力がないといろいろなところで苦労します。とりわけ苦労したのが学校です。学校では決められた時間で学ぶ授業、決められた時間で問題を解き結果を出す試験があります。これが本当に集中力のない自分には地獄でした。とにかく決められた時間で何かをするというのがとても苦手でした。 恐ろしいほど集中力がなく、決められた時間の中で結果を出すことができない自分がどうやって仕事をしているのかという話を書いてきます。 ダラダラ継続する結論を先にいうと「人の何倍も時間をかけて、常に変化する分野ピンポイントにダラダラと継続する」という戦略を取ることにしました。 継続といえばカッコイイですが所詮は「ダラダラ」です。つまり気分が乗ったときだけダラダラとやっていきます。 ただ、ダラダラやるのも１年、５年、１０年と続ければ結果は出ます、多分。 また、常に変化する分野であれば集中力よりも、継続が求められるはずだとも考えました。
コードを書き続ける
「開発者は経営者になったらコードを書くのやめて、経営に集中すべき」という考え方を聞いたことがある人はいるだろうか？ 自分はこの考えを持っていた経営者の元で働いていたことがあるので、強く印象に残っている。そして優秀な開発者たちが無理やりコードを書く時間を取り上げられ、経営者とされていったのを何度か見ている。 ここに書くのは自分の経験談であり、こうすべきとかではない。そしてなにより自分は死ぬまでコードを書き続けたいと考えているタイプであるということだ。 伝えたいことは一つだけでコードを書き続けたい経営者からコードを書くのを取り上げるのが良い方法だと思わないということだ。 また、経営者だから偉そうにコードを書くとかは当たり前だがなしだ。経営者関係なく、ただの開発者としてコードを書くという前提のお話。 開発者と経営者起業して 5 年が過ぎた。経営者としても 5 年、開発者としても 5 年。社員をし
フルリモートワークを諦めた
正社員のフルリモートワーク採用を目標としていたが諦めた。 現在、自社では週１出社それ以外は自宅からのリモートワーク社員がいる。一緒に働いて感じたことはフルリモートワークの場合はうまくやっていくことはかなり難しいだろうと感じたことだ。 自社では自社パッケージ製品を開発している。この開発には双方向のコミニュケーションがかなり必要になる。特に顔を突き合わせて話すというのがとても重要になる。さらに感覚的な話も多くなりがちだ。 実際、週１出社してる社員とはよく話をする。仕事の話、雑談。本当に色々話をする。 特に自社は社員も少なく１社員が担う範囲も多く、意思疎通がとても重要になる。これが週１出社してもらうだけで、かなり違う。ギャーギャー面と向かって話ができるというのはとても重要だと感じたのだ。 フルリモートワークになると出社は月１回とかになるだろうか、大きめの企業であればうまくタスクが分担できたりして
経営者になってわかったこと
起業して 8 年しか経っていないが、だらだら書いてみる。 自分の会社は従業員は片手で足りるくらいの IT 系零細企業。 税金は高い売上はすぐ入ってこない自分の給与は自分で決められる仕事は簡単に見つからない社員を雇うのは難しい経理、総務、法務、営業事務、書類仕事は多い賞与はいくら出してもいいオフィス賃貸費用は安いほうがいい銀行はとにかくお金を貸そうとしてくる資本金は銀行からお金を借りない限りどうでもいい経営の相談ができない顧問税理士は役に立たない帝国データバンクや東京商工リサーチへの登録が必要になる時がある自分宛ての投資マンション迷惑電話がくる社員の月給が低ければ低いほど経営が楽になる社員の年収は可能な限り高いほうが良い自分の年収に興味がなくなる収入を増やすのも、支出を減らすのも難しい賞与はいつ出してもいい顧問弁護士は必要だが、いつも必要なわけではない自社製品だけで会社を回すのは現実的ではな
リモートワーカー達との働き方
最近リモートワークな人とお仕事をする事が多い。自分がプロジェクトマネージャー的に働くことが多いので、リモートワークで働いている人がどうしてくれると自分が楽かということを書き出してみることにした。 殴り書きなので、読みづらいと思う。 ２つのタイプの案件でリモートワーカー達とやりとりしているので、わけて書き出す。 外貨稼ぎ案件外貨稼ぎ（社外のお手伝いをしてお金を稼ぐ）は自分がプロジェクトマネージャーとしてリードして、社外のお手伝い二名が開発担当として入ってくれている。 連絡はすべて Slack でのみ行う情報共有は Slack と GitHub で行うフェーズに分けて進捗管理完全非同期で労働するタイミングは縛っていないQA は GitHub で Markdown で質問してもらうお手伝い二人共技術的には申し分がない仕事は開発案件で、顧客とのやりとりは全て自分がやっており、お手伝いしてくれている
起業して 6 年目に突入した
時雨堂という会社を作って 6 年が経った。資本金 50 万円からスタートした会社だが、ありがたいことにまだ潰れていない。正社員は 4 名。 2015 年にリリースしたリアルタイムな音声や映像を配信するミドルウェアがちらほらと売れてきて社員の給与を賄えるところまではきた。また今は新しい自社製品としてシナリオを Lua で書ける負荷試験ツールを作っている。これはあまり売れそうにない。 自社製品自分が理想とする会社の経営方針が自社製品を前提とした考えなので、自社製品は売れなくても作っていくという方針。 売れるか売れないかは残念だけど運の要素がとても高い。今はリアルタイムな音声や映像を配信するミドルウェアである WebRTC SFU が売れているが、これも正直運の要素がとても高い。狙って出して売れたというわけではない。 狙って売れる製品を作るのは疲れる、作りたいものを作って売れるように頑張るほうが
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
HTTP API の設計方向
Discord の採用している技術