零細企業経営にはほとんどの意見が参考にならなかった話
いつか書こうと思っていたので雑に書いていく。 要約基本的に人の意見は参考にならない、聞く必要ない。自分の考えを信じたほうがいい。 ただし、IT 系の企業経営者で信頼できるなら人が身近にいるのであれば、意見交換はしたほうがいい。最近全く会えてないが、ヴェルクの田向さんと Sigfoss の森さんから頂いた意見はとても役に立った。 社外の人間の意見は参考にはならない自分が起業したときに苦労したので、書いておくが、この記事も参考にならないと思ったほうがいい。 思い立ってすぐに起業したので、ほとんど知識がなかった。いろいろな人の意見を聞いてみたが、実際に経営してみると全く参考にならなかった。 助成金の話ばかりする人これは最初に契約した税理士が良くなかっただけかもしれないが、基本的に助成金の話しかしてこない。助成金の仲介手数料が目当てなんだろう。 ちなみに助成金に関しては社員時代に一度助成金を使った
E2EE を開発していて思うこと
ここ数ヶ月は自社製品向けの End to End (Media) Encryption の設計と実装をしています。年内での提供を目標として開発を進めてい見ていますが、色々感じることがあったので雑に書いていこうと思います。 前提自分は暗号やセキュリティの専門家ではない自社製品向けの E2EE は Signal や Google Duo が利用している実績のある仕組みを採用しているE2EE や暗号の専門家を招聘し、相談しながら開発している自分の E2EE に対する考え悪意あるサービス管理者からユーザを守るために存在する機能と考えています。 Signal プロトコルはよく考えられすぎているSignal が考えた Curve25519 (x25519/ed25519) を利用した X3DH / Double Ratchet の仕組みは安全すぎると感じるくらいです。 相手からメッセージを受信するたび
フルリモートワークを諦めた
正社員のフルリモートワーク採用を目標としていたが諦めた。 現在、自社では週１出社それ以外は自宅からのリモートワーク社員がいる。一緒に働いて感じたことはフルリモートワークの場合はうまくやっていくことはかなり難しいだろうと感じたことだ。 自社では自社パッケージ製品を開発している。この開発には双方向のコミニュケーションがかなり必要になる。特に顔を突き合わせて話すというのがとても重要になる。さらに感覚的な話も多くなりがちだ。 実際、週１出社してる社員とはよく話をする。仕事の話、雑談。本当に色々話をする。 特に自社は社員も少なく１社員が担う範囲も多く、意思疎通がとても重要になる。これが週１出社してもらうだけで、かなり違う。ギャーギャー面と向かって話ができるというのはとても重要だと感じたのだ。 フルリモートワークになると出社は月１回とかになるだろうか、大きめの企業であればうまくタスクが分担できたりして
製品品質と評価制度
時雨堂には自社製品の検証を専門に行う社員がいる。具体的な指示は特になく「自社製品の検証よろしく」しかお願いしていない。 朝会社に来てから夜帰るまで、特に何か言われることもない。負荷試験をしていたり、ロングラン試験をしかけたり、異常系の検証をしたり。つまり何をやってもいい。 成果報告も一切不要。コミットログをみて検証したり、ドキュメントを見て検証したり。ドキュメントはわかりにくい部分を修正。 ちなみに製品にバグを見つけた場合はパッチをチャットに貼ってくる。製品の修正は開発者がやれということらしい。 勘違いしてもらいたくないのが、担当している社員はコードはゴリゴリかけるし、AWS や GCP といったクラウドも使える。さらには社内ネットワークを構築したり、自社サーバの運用などもできる。 コードが書けないから検証を専門にしているとかではない。検証で利用する WebSocket クライアントは 1
WebRTC を利用した配信の現実
超低遅延、高画質な配信を実現するための選択肢の一つとして WebRTC があります。 ただ WebRTC はもともと少人数で双方向の配信を前提としているため、スケールしないというのが一般的な認識です。 せっかくなので WebRTC サーバを開発・販売している立場から WebRTC を利用した配信の現実がどの程度なのかを書いていこうと思います。 P2P モデルまずは WebRTC といえば P2P なので、WebRTC の P2P 利用についてお話する必要があります。 WebRTC の P2P 利用は、配信者が視聴者分の変換を行うという負担があることから、最大でも 10 名程度までしか配信できません。 さらに、何より配信者の PC 負荷がとても高くなるため、採用は趣味のページまででしょう。 ビジネスで P2P を配信に利用するのはとても現実的ではありません。
野望
起業した時は野望はなかった。そもそも生きていければいいや程度だった。 その後、自社ビルがあったら楽しそうなんて話を顧問税理士や社員達として、自社ビルが当面の野望になった。 最近は今のような 1 日 6 時間という働き方で、社員に 4 桁万円の給与を提供したいというのが野望に加わった。 この野望を実現するためにどうしたらいいかをよく考えるようになった。 もともと自社でパッケージ製品を開発して販売した利益で会社を経営していくというのが目標だったが、思っているより短い労働時間で売上を上げるための仕組みが回っている気がする。 自社パッケージでカスタマイズしない方針のためすぐ納品可能落ちにくさを優先して開発しているため障害報告がいまのところゼロサービスではなくパッケージなので営業日対応のみ許される毎年利用料を頂くライセンス方式のため、良い製品であれば継続して利用料が毎年入ってくるドキュメントを充実さ
少機能で高機能な製品を作る
ついついやってしまいそうになるのが新しい機能の追加だが、そこは心を鬼にして本当に必要な機能なのかを考えるべきだ。 多機能な製品は市場の幅を広げると思いがちだが、そんなに簡単に市場の幅は広がらないし、多機能にすればするほど価格を上げていく必要が出てくる。 高くて多機能な製品が必要なお客さんはほんの一握りだし、もともとの市場が小さい場合は、そんなお客さんはいない可能性がある。 一度追加した機能は外せない最初のうちに色々便利な機能を追加しようと躍起になりがちだがそれらの機能は一度でも積んだらそう簡単には外せなくなる。 外せないとりあえず付けた機能をメンテナンスしていくのはなかなかしんどい。その機能が邪魔で新しい機能をつけづらい、といった問題もでてくる。 多機能は製品の寿命を縮める場合がある機能を追加すればその分だけコードが増える。さらにテストも増える。依存関係も増える。 つまり、その製品のメンテ
カスタマイズをしない
自分の会社ではパッケージ製品、つまりお客様の環境で動かして頂く製品を販売している。 そのため、カスタマイズを希望される事もある。今の機能では簡単に実現するのが難しいというのがほとんどの希望理由だ。 カスタマイズの定義は製品に対して＋アルファの何らかの特別な対応を機能を追加することという事にしておく。 結論から言うと自分の会社では一切のカスタマイズを受けないというスタンスだ。カスタマイズはメリットよりデメリットの方が多いという考え方からだ。 カスタマイズのメリットまちがいなく売り上げを上げやすい事だろう。カスタマイズが必須な場合の顧客はカスタマイズを受け付けない製品を購入しない。 さらにカスタマイズ対応ということで、追加の開発費やサポート費を手にすることができる。これは前職で十分実感できた。 ただメリットはこれしか無い。 カスタマイズのデメリット一番大きいのはコードのフォークが発生してしまう
夕凪堂という会社を作った
会社を作った。夕凪堂というテストに関するいろいろを扱う会社。 詳細は Gist にだらだらと、アイデアレベルでまとめてるので興味があれば。 もともとテストに対しては、いろいろ考えることがあるのだが、ネットワークサーバを開発していると、凄くテストが重要になる。 たとえば秒間 100 リクエストを処理出来る製品としてアピールして売っていく場合は秒間 100 リクエストの負荷がかけられるテストツールが必要になる。 さらに、開発を続けている間に製品はでぶっていく。ただしそのアピールは変更できない。となると「継続的な負荷テスト」が必要になる。 これ、難しい。いろいろ環境も状況も変わっていく中で定常的に負荷テストを行えるってコストがとても高い。夕凪堂はそこのコストを減らすためのツールを売る会社だ。 ターゲットは継続的な負荷テストを行いたい会社という狭い狭い範囲を狙っている。 もともと時雨堂でやりたかっ
WebRTC サーバを開発する理由
ブラウザ同士がやりとりする WebRTC 、当たり前だが WebRTC をサーバ側に用意することでブラウザとサーバでのやりとりを実現する事ができる。 理由はたった一つでサーバ側で配信データをコントロールすることが出来るようになるからだ。 通常の WebRTC を使って一人が複数人に配信する場合はこうなる 大きく違うのはサーバがブラウザを管理したり、データの流れを管理できるようになることだ。これはニコニコ動画の生放送をイメージして貰えば良いと思う。 もちろんサーバを経由することでサーバ側での録画も可能になる。もともとクライアント側で録画はできたが、P2P で動作されるとサーバ側での録画は難しくなるからだ。 これらの仕組みをプラットフォームとして提供しているのが tokbox だ。
Erlang/OTP + Lua の可能性
Erlang/OTP はネットワークサーバを書くのには最高の言語だと思うのだけれど、何かしらのロジックを書くのにはとても不向きだ。 そこで luerl という Erlang VM 上で動く Lua ライブラリを使う事で、ネットワークなどを Erlang/OTP で、ロジックを Lua でという実装が可能になる。 実際この仕組みを使って作ったのがゲーム用の Bot サーバ だ。 時雨堂 BOT サーバーhttps://gist.github.com/voluntas/cae671638cd104d05719 簡単に言ってしまえばボスのロジックを Lua で書ける。採用したゲームのシステムとしては ボス vs ギルドなので、ギルド分だけボスが必要で、皆違う動きをしてほしい。 Erlang/OTP の軽量プロセス一つ一つをボスにしてみた。さらにその中で Lua が動いてボスの動作を司る。 大量の
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
HTTP API の設計方向