2013 年 3 月 8 日に時雨堂を創業し、2024 年 3 月 8 日で時雨堂創業 11 年、そして 12 年目にはいりました。あっという間です。 起業のきっかけは、ある経営者に「貴方がどんなに一生懸命に製品を作ってもそれは会社のものでしかないので、自分の会社を持って自分の製品を作って、売った方がいい」といわれた事なんですが、それから 11 年立ちました。 起業したときから状況も大きく変わりました。自社製品の売り上げだけで会社が回っています。今後の時雨堂について雑に書いて行きます。 少人数でスケールする製品を作り続ける時雨堂はパッケージソフトウェアのサブスクリプションで稼いでいる会社です。営業もいないため、買いたいといってくれる企業に売るだけです。 社員が社内にあるライセンス発行サーバーに Tailscale でリモートで繋いでライセンス (JSON ファイル) を発行し、ライセンスフ

HashiCorp が OSI オープンソース・ライセンス のソフトウェア (以降 OSS) 製品を Mozilla Public License 2.0 (以降 MPL) から Business Source License 1.1 (以降 BUSL) にライセンス変更して話題になっています。 自社は主力製品はクローズドソース、それ以外は Apache License 2.0 で OSS として公開という戦略をとっていることもあり、 BUSL について自分の考えを雑に書いておこうと思います。 法律の専門家ではないので、間違いもあると思います。きっちり理解したい人は弁護士に相談しましょう。

かなり雑に書いてるので、雑に読んでください。 Bun が Zig で開発されていることを知り、そこから Zig を調べてみています。 調べていくと自分が求めていた言語っぽいというのがあり、社外では学生に QUIC や TLS 1.3 を Zig で OSS を開発してもらうお仕事を出したり、社内では実際に採用に向けて調査を進めています。 そもそもの目的自分の会社では Erlang VM を利用した製品をメインに利用しています。ただ Erlang VM 遅いんです。少なくとも暗号処理であれば Rust の方が 2 倍ほど速いです。Erlang VM 自体 JIT を採用したり、いろいろ頑張ってくれているのですが劇的な高速化というのは今すぐには難しいのが現実です。 そこで NIFs (Native Implemented Functions) を使って頑張るという戦略があります。早い話が Er

自社製品の SaaS をリリースしたのですが、自分の中でのテーマは「低コスト高可用性を実現する」でした。設計に入る前にいろいろ検証して、なんとか自分がやりたかったことができたので雑に書いてみます。雑に読んでください。 低コスト単純に「低価格でサービスを提供したいから」です。維持や運用コストが高くなればなるほどサービスの価格も高くなります。 サービス自体の低コストを実現すれば、価格面での競争力を得ます。もともとの自社パッケージ製品は機能や性能、可用性では負ける要素はないので、勝負は価格面という認識し、そこをどう実現するかを設計の第一としました。 少人数関わる人間が増えれば増えるほど人件費も増え、さらにサービスの価格は高くなります。 そのため、今回はとにかく少人数で開発、運用できることを目標にしました。目指すのはサーバーが 100 台規模になったとしても片手で足りる人数でなんとかなるサービスで

時雨堂は 9 月が期末です。ただ、色々やる事が山積みなので、少し早いですが振り返っていきます。 粛々と改善し続けた 1 年時雨堂の 8 期は、自社製品を粛々と改善し続けました。特にプロジェクトマネージャーが参戦してくれてからは、劇的に改善が進みました。 クローズド製品は自分、OSS 製品はプロジェクトマネージャーと担当を分けられたのも大きかったです。 WebRTC SFU Sora 、Sora SDK 、Momo 、Zakuro 、Hisui、webrtc-build など多くの OSS 製品を改善することができました。 方針通りには進んだ前期に上げた会社の方針は以下の通りです。 主力製品である Sora を採用したくなる OSS の提供実際、既存の OSS だけでなく新しい OSS を提供することもできました。 WebRTC SFU Sora 向けの負荷試験ツール ZakuroWebRT

いつか書こうと思っていたので雑に書いていく。 要約基本的に人の意見は参考にならない、聞く必要ない。自分の考えを信じたほうがいい。 ただし、IT 系の企業経営者で信頼できるなら人が身近にいるのであれば、意見交換はしたほうがいい。最近全く会えてないが、ヴェルクの田向さんと Sigfoss の森さんから頂いた意見はとても役に立った。 社外の人間の意見は参考にはならない自分が起業したときに苦労したので、書いておくが、この記事も参考にならないと思ったほうがいい。 思い立ってすぐに起業したので、ほとんど知識がなかった。いろいろな人の意見を聞いてみたが、実際に経営してみると全く参考にならなかった。 助成金の話ばかりする人これは最初に契約した税理士が良くなかっただけかもしれないが、基本的に助成金の話しかしてこない。助成金の仲介手数料が目当てなんだろう。 ちなみに助成金に関しては社員時代に一度助成金を使った

時雨堂は企業か開発する OSS としていくつかのリポジトリを GitHub に公開しています。これらを継続的に開発するためになにをしているかを書いていきます。 まとめOSS に利益を期待しないコミュニティや社外の人と仲良くするOSS に理解のある人だけを社員として雇う前提オープンソースのライセンスは Apache License 2.0ソースコードはオープン、開発はクローズコミュニティは Discord のみOSS の定義“オープンソースの定義” を前提としています。 時雨堂が OSS 採用しているライセンスである Apache License 2.0 は OSI 承認オープンソースライセンスです。 そのため時雨堂が公開している OSS は Apache License 2.0 のもと、利用可能です。 ソースコードはオープン、開発はクローズド 時雨堂の OSS の開発方針は Lua の開発

2020 年 1 月から株式会社ZIZAI の IRIAM で「雑談するおっさん」をしています。なにをやったか、なにをやってるかを書いていこうと思います。ちなみに自分の本業は開発者です。 まずお手伝いする上で条件を出しました。 サーバ/インフラに関する技術決定権採用判断権組織改善権評価改善権結果としては偉い人から「何やっても構いません、全部おまかせします」って返ってきました。 さて、やったこと、やってることを箇条書きで書いてみました。技術的な話の詳細は内緒なので書きません。 Twitter での定期的な採用告知自分への Slack DM の禁止自分への返信はスレッド禁止（好み問題）可能な限り即決断する自分だけでは決断できない場合はいつまでに判断する旨を伝えるSlack のパブリックで #shiguredo を作ってもらい、自分とはそこでのみ会話するエンジニアの上下関係の削除プライベートに対

WebRTC コミュニティの問題これ以外にも webrtc-discuss や react-native-webrtc などのコミュニティでもドキュメントを読めば分かる質問、回答を書いても反応がない、助けて！とだけ書かれた投稿などがとても多いです。 この理由は OSS よくあるといえばそれまでなんですが、それ以外にも問題があると思っています。 WebRTC って音声や映像をリアルタイムに送受信する技術なわけですが、誰が見てもわかるんです。音が来ないもすぐわかるし、映像が遅延してる、表示されないもすぐわかってしまうんです。 つまり技術者じゃなくても問題が起きていることに気づけてしまうんです。 で「なんか音声が流れてこない！このソフトウェアは問題だ！」となってしまうわけです。 これに対応する場合、作者たちは「WebRTC という技術の難しさをよくわかっていない人たち」へ無料のサポートを提供しな

Ayame という WebRTC P2P 向けのシグナリングサーバを公開して 1 年過ぎて、色々わかったことがあるので、まとめて、さらに今後どうしていくかを書いていきます。 前提時雨堂では Ayame をビジネスに繋げるきは全くありません。あくまで「WebRTC で P2P」をできる限り使いやすく、簡単にしていくという思いがあります。 また得られた情報をできるだけアウトプットすることで、 WebRTC 界隈への貢献をしていきたいとも思っています。閉じた世界で自分たちだけが利益を得るというのはその市場を狭めてしまうと考えているからです。 利益は WebRTC SFU であげる前提です。P2P が好き、WebRTC が広まって欲しいという気持ちで WebRTC P2P 向けシグナリングサーバを公開しています。 WebRTC P2P はビジネスとして難しいWebRTC P2P 向けのシグナリング

ミドルウェアのパッケージ製品で賞与もまかなえるようになるまでやったことを自分のメモ代わりにまとめていきます。 ここでの賞与というのは一人一千万円以上を前提としています。 こちらのアップデート版です。 まずは動くものをユーザが増えたらとか、こんな事業に使ってほしいからとかではなく、単にこの機能は必要だろうという単純な理由で実装計画だけ立てて、あとは淡々と研究開発を行って、検証作業をしていきます。 うまく動いたらあとは正式リリースに向けて実装を進めていくというスタイルです。当たり前ですがいきなり実装するのではなく、まずは動くものをという考えで進めてみています。 動くものがあると興味を持ってもらいやすいです。 リリース前の開発状況を公開するステルスで開発して、タイミングを見てリリースするほど競合がいる世界で戦っているわけではないので、少しでも自社に乗せる機能が研究開発レベルでも実現できたら公開す

期末が 9 月なので残り 3 ヶ月切りました、振り返りは何度やってもいい、ということで少し早いですが振り返ることにしました。 秋の時代 豊作の秋今期はなぜか馬車馬のように働いた前期の過去最高の売上をさくっと超えてしまう予定です。自社製品の売上は前期比で現時点で 1.5 倍で、もう少し増えそうです。 想定とは大きく異なりますが、会社的にはとても良い結果になりそうです。経営者的にはまったく機能していないことがよくわかります。 方針通りには進んだ前期の始まりに掲げた会社の方針は以下のとおりです。 今期は新規のお手伝いする場合は WebRTC や負荷試験など時雨堂が今後やっていこうとしている方向に絞って受け、それ以外は自社製品にコミットしていくという方針を取っていきますこの方針はほぼ守れています。 WebRTC と負荷試験以外の仕事はほぼ受けていません。それ以外の仕事はお手伝いしてくれている める

ありがたいことに自社製品が多くの企業に導入して頂けており、自社製品の売上だけで食べていけるようになりました。 今までは自社製品だけでは食べていけなかったため、外のお手伝いをしていました。ただ自社製品だけで食べていけるようになったのは経営者としてはじめてなので、どうしてみてるかを書いていきます。 会社の状況従業員たちの給与と会社の維持にかかる費用はすでに自社製品の売上で十分まかなえています。普通に賞与も出せるレベルです。 自社製品はパッケージ製品のため、運用などはありません。労働時間は 6 時間の定時労働、土日祝日、年末年始はお休みです。残業はお手伝い系の仕事が忙しくなるとありますが、自社製品に関しては皆無です。 パッケージ製品の開発方針機能より品質重視という方針をとっています。またカスタマイズは受けていません。そのため、自社製品に関しては顧客との調整などは発生しません。サポートの問い合わせ

Amazon.co.jp： 町工場の全社員が残業ゼロで年収６００万円以上もらえる理由 eBook: 吉原博: Kindleストア 前提そもそも町工場を詳しくしらないので、とても勉強になりました。自分はずっと IT にいるということもあり、仕入れや在庫、設備あたりの知識がほぼ経験ありません。なのでその辺については、勘違いなどあるかもしれませんのでご注意ください。 自分と違う考えの部分が書かれているところをピックアップして書いてみています。 単に自分の考えとの比較でしかないので、どっちが正解とかはないと思っています。 給与と賞与給与は実力性、賞与は皆一緒という方式でやっているようです。ただ評価の話がほぼ書かれていなかったので、おそらく社長の独断で決めているのではないでしょうか。 賞与は手取りで 100 万円、現金払い。最大値が決まってるのがとても違和感がありました。そもそも利益が出ているなら賞

WebRTC QUIC Client/Server が WebTransport として再出発したようなのでまとめておく。 一般的な説明についてはいかが詳しいので以下を読むのをおすすめしたい。

自社で開発しているミドルウェアパッケージ製品のリリース頻度をどうすれば下げられるかというのが最近の自分の中での課題になっている。 パッケージ製品というのは自社で動かすわけではなく、顧客の環境で動かすわけでアップデート頻度が高い場合、作業負担を強いることになる。 そこでできるだけリリース頻度を下げていきたいと考えているが、なかなか難しいので、どうやってみているかを書いていきたい。 現在のリリース頻度リリースは Ubuntu を真似して 4 月と 10 月で、年 2 回がリリース。致命的なバグ修正や、ブラウザアップデートによる不具合対応などは、修正ができ次第すぐにリリースしている。 クライアント側のバージョンアップへの対応自社製品は WebRTC という技術を使っており、これはブラウザに搭載されている機能の一つになる。ただ Chrome は 6 週間ごと、 Firefox は 6–8 週間ごと

まず、この記事では、STADIA で快適にゲームができるかどうかという話はしません。技術的にどうなの？というのを想像込みで書いていきます。 誰だよお前、って言われそうなので … 自分は WebRTC の通信部分と QUIC スタックの実装をフルスクラッチでしており、日本で多くの会社に採用されている WebRTC を利用したミドルウェア製品の開発者です。WebRTC を利用して 4K@30 をサーバ経由で配信というのを実現したりしています。 利用している技術STADIA が利用している通信技術は WebRTC (と QUIC)です。これは Project Stream という STADIA リリース前に公開された実験的プロジェクトがまさにそうでした。Project Stream の VP である Majd Bakar 氏がインタビューで回答しています。 Project Stream は 10

IT 系零細企業を経営していて、特定の技術に強いと外から思われ始めると無償での技術情報の搾取を目的とした問い合わせが多くなる。 自分は残念ながら無償で技術情報の搾取をされた経験があるので、注意喚起として書いておく。この悪しき習慣を潰したい。 情報交換をしたいこのフレーズがメールの文章に含まれていた場合は、とても注意すべきだ。殆どの場合であなたの会社の方が情報を持っており、相手は無償で技術的な情報を得たいと考えていることが多い。 技術の分野の世界はとても狭いので、ほんとうの意味で情報交換を申し込んで来る人はあなたがすでに知っている人の可能性が高い。全く知らない人が情報交換を持ちかけてくるのはまず疑ったほうがいい。 知らない会社から「情報交換をしたい」と言われたら、丁重にお断りをするべきだ。情報交換をしたいと言ってきた会社から仕事につながった経験はまったくない。彼らは一方的な搾取を望んでいるだ

資金調達していない零細 IT 企業を経営していると抜け出せなくなる受託開発の罠ですが、罠にはまるパターンと、そして自分がどんな方法で罠にはまらないように経営しているのか書いていきます。 前提そもそも受託開発が目的の会社であれば、罠にどっぷりハマって問題はないので、ここでは自社サービスなり自社製品をメインとする会社を前提とします。 経営者が全力で稼いで、社員が自社製品やるパターンや、その逆あったりはここに当てはまりません。当てはまるのは自社製品やりたいけどお金を稼がないといけないといってずるずる行くパターンを受託開発の罠としています。 自転車操業調達していない零細 IT 企業は基本的に自転車操業になります。会社にお金がないと当たり前ですがキャッシュフローが苦しくなるため、受託開発を行いお金を稼ぐようになります。 受託開発は毎月契約でお金をもらって開発リソースを提供するタイプと、いくらでお願い