タグ

ブックマーク / voluntas.medium.com (31)

  • 経営者になってわかったこと

    起業して 8 年しか経っていないが、だらだら書いてみる。 自分の会社は従業員は片手で足りるくらいの IT 系零細企業。 税金は高い売上はすぐ入ってこない自分の給与は自分で決められる仕事は簡単に見つからない社員を雇うのは難しい経理、総務、法務、営業事務、書類仕事は多い賞与はいくら出してもいいオフィス賃貸費用は安いほうがいい銀行はとにかくお金を貸そうとしてくる資金は銀行からお金を借りない限りどうでもいい経営の相談ができない顧問税理士は役に立たない帝国データバンクや東京商工リサーチへの登録が必要になる時がある自分宛ての投資マンション迷惑電話がくる社員の月給が低ければ低いほど経営が楽になる社員の年収は可能な限り高いほうが良い自分の年収に興味がなくなる収入を増やすのも、支出を減らすのも難しい賞与はいつ出してもいい顧問弁護士は必要だが、いつも必要なわけではない自社製品だけで会社を回すのは現実的ではな

  • GitHub Sponsors から Open Collective へ

  • 時雨堂創業 12 年目

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

    t2y-1979
    t2y-1979 2024/03/10
    素晴らしいと思う
  • Business Source License 1.1

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

  • パッケージ製品のクラウド版を公開して1ヶ月で利益がでるまで

    ポエムです。 自社パッケージ製品のクラウド版を提供して1ヶ月で利益が出たので、どんな感じだったのかを時系列で雑に書いていきます。 前提従業員が片手で足りる人数の零細企業パッケージ製品で充分な利益を出しているパッケージ製品のクラウド化 (2022 年 1 月)自社では WebRTC に関連するミドルウェアのパッケージ製品を提供しており、これが主力商品となっています。パッケージ製品ということで運用はお客様にしてもらいます。閉じた環境でも使えるため多くのお客様に使って頂いています。 パッケージ製品の開発が落ち着いてきたこともあり、クラウド化としてとして提供することにしました。 目的としてはパッケージ運用したくないという企業の取り込みです。またパッケージは年間ライセンスですが、クラウド版は月額利用モデルにすることで、収入の安定化です。 無料のサービスで検証 (2022 年 1–3 月)まずやったこ

    t2y-1979
    t2y-1979 2023/01/30
    利益がでるまで経費をなるべくかけないという戦略にみえる
  • GitHub Sponsors の枠を広げた

    今までも GitHub Sponsors で、OSS 開発者のスポンサーになってきていましたが、より OSS に貢献していきたいと考えていたので、追加で 3 名の OSS 開発者のスポンサーになりました。 Ulf WigerErlang/OTP を触っていてこの名前を知らない人はいないと思います。時雨堂では彼の開発した gproc というライブラリを長年利用させて頂いております。ふとみたら彼が GitHub Sponsors を有効にしていたので、さっそくスポンサーとして支援させていただく事にしました。

  • 企業で OSS のスポンサーや災害支援の寄付をする意味

  • 零細企業経営にはほとんどの意見が参考にならなかった話

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

  • 企業 OSS を継続開発するためにやっていること

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

  • 海外のOSS なWebRTC SFU 開発者たちがコミュニティに絶望してる話

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

  • 2019 年にお金を払ったサービス

  • 顧客のビジネスを奪わない

    時雨堂という会社は WebRTC 関連のミドルウェアを開発、販売して利益を上げています。会社として絶対にやらないと決めていることがあります。それが「顧客のビジネスを奪わない」という事です。 情報が集まる時雨堂の主力商品である「WebRTC SFU Sora」という WebRTC 関連のミドルウェアはありがたいことに、かなり多くの顧客に使って頂いています。 ミドルウェアを販売するということは「そのミドルウェアを利用したビジネスの情報」が集まってくるということです。ここで絶対にやってはならないと考えているのは「このサービスはうちでも作れそうだし作ってしまおう」です。 ビジネスを奪わない顧客のビジネスを奪うというのはあってはならない事だと考えています。時雨堂はあくまで「ミドルウェア」を提供する会社であって、それを利用したビジネスは協力はするけど、単独で提供してはなりません。 たとえば時雨堂が「W

  • 自社製品だけで賞与も出せるようになるまでやったこと

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

    t2y-1979
    t2y-1979 2019/09/04
    すごいなぁ
  • 町工場の全社員が残業ゼロで年収600万円以上もらえる理由

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

    t2y-1979
    t2y-1979 2019/05/10
    想像で書くので間違っているかもしれないけど、優秀な人は町工場に応募しない。優秀ではない従業員でいかに経営するかの術ではないかな?小さい sier に近そう?
  • 自社製品で食べていけるようになるまでやったこと

    ミドルウェアのパッケージ製品でべていけるようになるまでやったことを自分のメモ代わりにまとめておきます。 製品の事業計画を明確にしない自分が想定したとおりに行くことが少ないこともあり事業計画を書いたりしません。日々の状況を見ながら判断をしていくということをしています。そのため中長期的な計画は品質の向上くらいにしておき、機能追加に関してはその度々に考えて実装していくのが一番です。 変化が早い分野でもあるので、事業計画を用意するメリットが零細企業にはないと考えています。 リリース前の開発進捗を共有するステルスはデメリットが多いと判断し、今開発しているもの開発中の状況などを共有しました。これは「製品をステルスで開発して、出したとしても買ってもらうまでの時間がかかる」と考えたからです。 それよりはあの会社があんなの作ってるそろそろ出るらしいと思ってもらえたほうが検討してもらいやすくなります。 今、

    t2y-1979
    t2y-1979 2019/01/09
    公開する必要のない資料をずっと更新し続けているのがすごいなぁと思う
  • 評価制度について – V – Medium

    評価制度について年一回、自分の考えを書いていくということをやっていくことにする。 自社の評価制度評価制度自体がないので、評価は行っていない。給与も同じで賞与も同じ。詳細を知りたい方は評価制度の無い評価制度という資料があるので見てもらいたい。 従業員が数名であることもあり、評価制度がない状況でうまく回っている。実際社員に聞いても評価制度がないのは働きやすいとのこと。 会社の事業に対してコミットし、会社の利益がでれば賞与として還元される。この仕組で困っていない。 評価制度に対する考え上司による評価、経営者による評価、全方位評価、様々な評価を受けてきたが、残念ながらどれも満足した評価制度だったことはない。 評価制度は「その評価制度」をハックする仕組みがあるのが問題だと考えている。自分はどうもその評価制度をハックするのがうまいようで、今の所不当な評価をされたことはない。 ただ、ハックできない人が評

  • 集中力のない人の戦略

    集中力がないといろいろなところで苦労します。とりわけ苦労したのが学校です。学校では決められた時間で学ぶ授業、決められた時間で問題を解き結果を出す試験があります。これが当に集中力のない自分には地獄でした。とにかく決められた時間で何かをするというのがとても苦手でした。 恐ろしいほど集中力がなく、決められた時間の中で結果を出すことができない自分がどうやって仕事をしているのかという話を書いてきます。 ダラダラ継続する結論を先にいうと「人の何倍も時間をかけて、常に変化する分野ピンポイントにダラダラと継続する」という戦略を取ることにしました。 継続といえばカッコイイですが所詮は「ダラダラ」です。つまり気分が乗ったときだけダラダラとやっていきます。 ただ、ダラダラやるのも1年、5年、10年と続ければ結果は出ます、多分。 また、常に変化する分野であれば集中力よりも、継続が求められるはずだとも考えました。

  • コードを書き続ける

    「開発者は経営者になったらコードを書くのやめて、経営に集中すべき」という考え方を聞いたことがある人はいるだろうか? 自分はこの考えを持っていた経営者の元で働いていたことがあるので、強く印象に残っている。そして優秀な開発者たちが無理やりコードを書く時間を取り上げられ、経営者とされていったのを何度か見ている。 ここに書くのは自分の経験談であり、こうすべきとかではない。そしてなにより自分は死ぬまでコードを書き続けたいと考えているタイプであるということだ。 伝えたいことは一つだけでコードを書き続けたい経営者からコードを書くのを取り上げるのが良い方法だと思わないということだ。 また、経営者だから偉そうにコードを書くとかは当たり前だがなしだ。経営者関係なく、ただの開発者としてコードを書くという前提のお話。 開発者と経営者起業して 5 年が過ぎた。経営者としても 5 年、開発者としても 5 年。社員をし

    コードを書き続ける
  • フルリモートワークを諦めた

    正社員のフルリモートワーク採用を目標としていたが諦めた。 現在、自社では週1出社それ以外は自宅からのリモートワーク社員がいる。一緒に働いて感じたことはフルリモートワークの場合はうまくやっていくことはかなり難しいだろうと感じたことだ。 自社では自社パッケージ製品を開発している。この開発には双方向のコミニュケーションがかなり必要になる。特に顔を突き合わせて話すというのがとても重要になる。さらに感覚的な話も多くなりがちだ。 実際、週1出社してる社員とはよく話をする。仕事の話、雑談。当に色々話をする。 特に自社は社員も少なく1社員が担う範囲も多く、意思疎通がとても重要になる。これが週1出社してもらうだけで、かなり違う。ギャーギャー面と向かって話ができるというのはとても重要だと感じたのだ。 フルリモートワークになると出社は月1回とかになるだろうか、大きめの企業であればうまくタスクが分担できたりして

  • リモートワークとの付き合い方

    A very smart man versus a very smart machine. Can an undisputed board game king conquer artificial intelligence? Watch… NetflixAlphaGo が話題になっているので Netflix を再契約して見てみた。とても良かった。 見ていて思ったのが DeepMind 社の社員たちが事ある毎にホワイトボードやメモ帳を持って議論をしていた。 もちろんこれはドキュメンタリーなので、全部が全部そうではないとおもうが、とにかく顔を合わせて、その場にいて議論をしているように見えた。 働く場所は同じ場所で、皆ヘッドフォンをして作業をしていたし、スタンディングデスクもあった。ただとにかく顔を合わせて話をしているのが印象的だった。 自分のリモートワークに対する考えちょと書き出してみる

    t2y-1979
    t2y-1979 2018/01/22
    オフィス内の雑談や空気感を共有するためにずっとライブストリーミングをするという職場もあるらしい