IT 系パッケージメーカーの零細企業経営者場合

いつか書こうと思っていたので雑に書いていく。

要約

基本的に人の意見は参考にならない、聞く必要ない。自分の考えを信じたほうがいい。

ただし、IT 系の企業経営者で信頼できるなら人が身近にいるのであれば、意見交換はしたほうがいい。最近全く会えてないが、ヴェルクの田向さんSigfoss の森さんから頂いた意見はとても役に立った。

社外の人間の意見は参考にはならない

自分が起業したときに苦労したので、書いておくが、この記事も参考にならないと思ったほうがいい。

思い立ってすぐに起業したので、ほとんど知識がなかった。いろいろな人の意見を聞いてみたが、実際に経営してみると全く参考にならなかった。

助成金の話ばかりする人

これは最初に契約した税理士が良くなかっただけかもしれないが、基本的に助成金の話しかしてこない。助成金の仲介手数料が目当てなんだろう。

ちなみに助成金に関しては社員時代に一度助成金を使った事業のお手伝いをして本当に最悪な経験をしたので二度と関わるまいと決めていたので、助成金関連の事業には可能な限り関わらないようにしている。

ちなみに今の税理士は「高いサーバ買えば助成金が出る場合もあります」以外のことは一切言ってこない。よくわかっている。

カスタマイズしない自社製品なんて儲からないからやめろと言ってくる人

これはよく言われた。カスタマイズしたほうが儲かると。「別に儲ける必要はないんですよ」って言うと小バカにされた。

人は成功体験にしがみつくということを学んだ。

海外に目を向けろと言ってくる人

自分は英語がさっぱりできないので、日本国内だけでビジネスをやっているが「日本はオワコンなので、海外に打って出ないとダメ」と言われたた。

海外とビジネスするというのは自分には全く想像できないし、リスクしかないように思える。

正直、日本語ですらうまくやりとりができない日本の企業がいるのに海外とか無理だなと思っている。

資金調達しろといってくる人

なにをやるにしても「資金調達」ありきの話をしてくる。色々提案してくるが「そんなお金はない」っていっても「お金を稼ぐ時間なんて無駄だ、調達して攻めるべき」と言われた。

そもそも人とうまくやれないという、社会人不適合者ということで起業してるのに、調達して色々意見言われる時点で無理。

調達している人の意見は正直環境が違いすぎて何の参考にもならない。普通に世界線が違うので関わらないほうがいい。

銀行から借りろといってくる人

「無借金はだめ、お金を借りていることは大事」というのは年配の方に多かったが、お金借りる予定もないし銀行嫌いなので、受け入れられないという話をした。

「銀行は困った時に助けてくれる」と言われたが、むしろ困った時に厳しい話しか今まで聞いていないのなにを言ってるのかわからなかった。

あと別に IT 系は投資がほぼいらないのでそもそも借り入れ自体が不要。

営業を雇えと言ってくる人

自社製品が売れていないときに言われた。売れないのは営業を雇わないからだ。まず売り込みをしないとダメだと言われたが、「誰にでも売りたい製品」ではない時点で営業は別にいらないという説明をしたが「そんな甘い考えじゃ失敗する」と言われた。

ウェブサイト / Twitter / Discord / Gist で宣伝して売るという考えは受け入れられなかった。

人を増やせと言ってくる人

自分が結構忙しく働いてる時に言われた。今も忙しいが「人を増やすとコミュニケーションコストが高くなる」といっても理解してもらえなかった。

時雨堂は「ほっといてもなんかする人」だけを雇っているため管理コストがほぼ0なのだが、マネージャーを雇えと言われた。

実際、起業して見ると「売上を上げる=人を雇う」という考えの人がとても多いことに驚いた。皆、ほっといて売れるような製品をつくりたくはないらしい。

社会に還元しろと言ってくる人

一番めんどくさかった。一社だけで儲けるのはやめろといいながら、打ち合わせしようとしてきたりするし、自分に都合のいい話ばかりする人たち。

結局何がしたかったのかわからなかった。いい反面教師になった。

社員をもっと働かせろと言ってくる人

時雨堂が 6 時間労働になったあたりで言われた。社員は替えがきくとか意味がわからない事を言っていた。

たくさんの時間働いて成果をたくさん出せるのはそれは才能なので、誰もが真似できるものでもないと思っている。

経営者がコード書くなと言ってくる人

想像以上に言われる。自分が好き勝手にコードを書いて生きていくために起業したのに何を言ってるのか。

うまくいくとなにも言われなくなる

面白いもので、時雨堂コトハジメとかである程度うまくいってることをオープンにするとなにも言われなくなる。

社員の意見はとても重要

基本的に自分で方針は決めるが、悩んでるときは必ず社員たちに相談することにしてる。自分の考えが良くないことも多々あった。相談できる社員を雇うことが大事。

まとめ

結構なにも考えず上からの意見を言われることが多いので聞かないほうがいい。成功経験に引っ張られている考えがほとんどだった。

自分の考えを信じたほうがいい。もちろん、この記事の意見も参考にするべきではない。

terurou はどうなんだろうとふったら書いてくれたので紹介。


今年に入ってから自社製品向けのオンラインドキュメントを改善していくのを本格化しようと思い、自社製品向けの Sphinx テーマを開発しています。

自社でオンラインドキュメントツールに投資するというのはあまりないと思うので、その話を雑に書いていきます。

なぜドキュメントなのか

実際、ドキュメントツールに投資する話はほとんど聞かないと思います。自社でも「やっと投資できるような状況になった」というのが正しいです。

今まではなんとか自社製品で利益を出すというのが目標だったのですが、ありがたいことに、自社製品の売り上げで会社が回るようになってきました。そこで投資先を考えた結果、「既存のお客様が頻繁に利用するドキュメントを便利にする」ということにしました。

ドキュメントが使いづらいというのはとてもストレスを感じます。特に弊社製品はミドルウェアやその SDK という事もあり、ドキュメントありきです。ドキュメントが使いづらいということは自社製品が使いづらいということになるからです。

なぜ Sphinx なのか

もともと Sphinx を使っていた理由は、自分が reStructuredText (rst) に慣れていたというのが理由です。Python を利用していたこともあり、Sphinx を使う前から rst に慣れ親しんでいました。

もちろん Sphinx 以外のオンラインドキュメントツール(サービスを含む)も検討しました。

ただ、決め手としてはラムダノートの鹿野さんから「オンラインドキュメントであれば Sphinx 一択だと思う、特に rst に慣れているなら」というアドバイスを頂いたのが決め手でした。

また自前でホスティングしたいというのもありました。その点 Sphinx は Netlify との相性が良く、気軽にデプロイできます。

既存の Sphinx テーマへの不満

現時点では Read the Docs の Sphinx テーマを利用していますが、いくつか課題があります。

  • デザインやレイアウトが好きではない
  • 日本語との相性が悪い

そのため、自分たちにとって使いやすい Sphinx テーマを用意することにしました。

Sphinx コミッター小宮さんの招聘

残念ながら社内には Sphinx に詳しい社員はいません。そのため専門家のアドバイスが欲しいと思ったときに目を付けたのが「プラチナスポンサー」です。

時雨堂は Sphinx コミッター小宮さんのプラチナスポンサーです。このスポンサー特典として小宮さんの「答えられる範囲」で Sphinx のアドバイスがもらえるというのがあります。

小宮さんに弊社 Slack に参加頂き Sphinx テーマ開発時に Sphinx のアドバイスをしてもらえないか打診したところ快諾頂きました。

Sphinx テーマ作り

フロントエンドを普段担当している社員にお願いすることにしました。小宮さんとも面識があり(むしろ元同僚)、連携に困らないと思ったからです。

社員にお願いしたことは以下の通りです。

Image for post
Image for post
readme.com の Algolia を利用した rebar3 の検索機能
  • Apache License 2.0 でオープンソースとして公開できるようにして欲しい
  • 将来的に Algolia の検索部分は拡張として外に出してオープンソースとして公開して欲しい

検索機能

Sphinx の検索機能は残念ながら頑張れてるとは言えないと思います。そこで検索サービスを組み込むことにしました。ここは費用を払っても問題ないと判断しました。

いろいろドキュメント検索サービスを調べましたが、 readme.com が採用している Algolia が日本語にも対応しておりかなりよさそうと判断しました。

Algolia を Sphinx テーマに組み込む事で、検索が便利になるだろうと判断しました。

公開に向けて

現在テーマを少しずつ作成中です。特に隠すことはないのですでにオープンソースとして GitHub に公開しています。

小宮さんからは「この仕組みを実現したい場合は、何をすべきか」という的確なアドバイスをもらえており、本当に助けられています。


2021 年 1 月版

時雨堂では 2020 年 3 月から従業員を全員フルリモート勤務に切り替えています。一カ所に集まり、顔を合わせて仕事をする事がとても重要という考えのもとで作った会社がフルリモートになりそろそろ 1 年経過しそうなので、雑にまとめていきます。

会社としてやってることや自分がやってることごちゃ混ぜです。

定期的に追記していく予定です。そのうち Gist へ移動するかも。

社外との打ち合わせ

オンラインのみ。オフラインは一切行っていない。もともと社外との打ち合わせは少なかったので問題は出ていない。

社内の打ち合わせ

自社製品を利用してオンラインで打ち合わせ、オフラインは一切行っていない。また「皆で話をする」や「常時接続する」というのはやっていない。自分が必要なメンバーを集めて話す。

基本的に全員が(同じ自社製品の仕事ではあるが)独立している仕事をしているので打ち合わせをする必要が少ない。

中長期的なタスクをお願いする

やってもらうタスクを中長期的(数ヶ月単位)にして、できるだけ連携を不要にしている。

もちろん短期的なタスクもあるが、それは Slack や GitHub Issues でやりとりすればできるレベルに抑えている。

例えばリファクタリングや新しいライブラリの導入、時間のかかる機能改善、調査から必要な新機能対応など。

売り上げを諦める=会社を忙しくしない

売り上げを上げるためにやっている事をやらないようにした。それよりは余裕を持たせる方向にシフトした。いろいろしんどい中、会社自体を忙しくしないようにすることにした。

もともとキャッシュフローを健全型に寄せてる経営をしてるが、より健全型に寄せるようにした。

もともと何かあった時のためにと、会社にお金を貯めており、それは今だと判断した。今はため込んだお金を使うターン。

休めるときはさくっと休んでもらう

ちょっと調子悪いかなとか、無理しないようにしてもらった。もともと無理するメンバーではないが、そこはあえてお願いしている。

定時に上がってもらう

リモートワークだと遅くまで働きがちというが、それは単にマネージメントしている人がタスク管理に失敗してるだけなので論外。

また明日も元気よく働いてもらうために意識的に定時に上がってもらう。

ドキュメント>コード

自分はコードを書くよりもドキュメントを書く事をすることを優先した。一ヶ月ほとんどコードを書いていないとかの時もあった。コードを書くのは社員に任せて、とにかくドキュメントを重視することにした。

自社製品ドキュメントは決まってる事をよりわかりやすく使いやすく書くだけなので、誰とも会話しなくてもいい。

総務の負担を減らす

零細企業の総務は本当にやるべき事が多いので、できるだけサポートに入るようにしている。今までは全部任せっきりでも問題なかったが少しでも負荷を減らせるようにしている。リモートでフルタイム総務はしんどすぎる。

齟齬が増えやすいのを前提に話す

リモートは伝わりにくい、というのを前提に話すようにした。今までであれば「口頭で雑に終わらせていた」ものを全部 GitHub Issues 経由にしたりした。お互いの負担を減らすための仕組みを積極的に導入している。

追記予定


IT 系零細企業経営者の場合

プログラミングの本はほとんど読んできていない。プロトコル解説やプロジェクトマネージメントの本ばかり読んでる。特にプロジェクトマネージメントは他の人がどう考えているのかを手っ取り早くしれて良い。

Python 2 系な上に、とても古いので初心者にはオススメはできない。この本は目次を見てもらえればわかるが一通りのことが一冊で学べたので他の本をほとんど読まなくて良かった。とにかく何でも書いてある。特にモジュールと例外の章はオススメ。

最初は原著を読んでいたが、途中で日本語版に切り替えた。とにかく翻訳が素晴らしい。読みやすいしわかりやすい。ボロボロになるまでひたすら読んだ。この本を完全に理解すれば Erlang/OTP でご飯が食べられるようになる。

多くのツール、手法そして概念がその解決策として取り上げられているが、それだけでは解決しない。プロジェクトを形成するのは人であり、プロジェクトマネジメントに人が占める要因は決して小さくないからだ。本書は、その「人」についてフォーカスを当ててプロジェクトマネジメントを語っている

今、自社で製品を提供していく上で何よりも役に立っている本。一人では何もできないことを学べる。

自分はデマルコ信者なのでデマルコ関連は全部読むことをオススメしておきたい。

現代のアプリケーションエンジニアは、UIやデータ処理、開発言語、プラットフォームの仕様や癖だけでなく、サーバやネットワークについても、上から下まで、表から裏まで広く知ることを求められます。本書は「ブラウザ」に関連し、インターネットで使用されるさまざまなネットワーク技術をまとめたものです

レビューワーの方から頂いて読んだのだが、本当に良い本で衝撃を受けた。定期的にオススメしている。オライリーの方に「本当に良い本ですよね!!!!!」って熱く語ったら「そんなに売れてないんですよ … 」って悲しい反応をされたことがあるので、ぜひ読んでみて欲しい。損はさせない。

実際に TLS を実装する必要があり手に取った本。知りたいことはほとんど書いてあって衝撃を受けた。本当に細かいことまで書いてあってとても良かった。

ただ、今はもっと良い本が出ているので、読まなくてもいい。


WebRTC で getUserMedia を利用してカメラから映像ストリームを取得するとカメラのランプが点滅します。

このカメラのランプってミュートするだけでは消えません。デバイスを掴んでいる限りはカメラのランプはついたままになります。

カメラをミュートにしたにもかかわらずカメラのランプがついてるのはとても気持ち悪いと思います。

カメラをミュートにしたときはカメラのランプも消えて欲しい、つまりデバイスを一度開放して欲しいという需要があると思います。

実はこれ WebRTC 的にはちょっとだけですが、めんどくさい機能なので、自社製品の WebRTC SFU Sora の JavaScript SDK のヘルパー機能として、用意しました。

SDK に依存しない仕組みとして用意したので、Sora を利用していなくても活用できます。

ちなみに、この機能を実現するキモは replaceTrack という機能ですので、もし良ければ調べてみて下さい。

Sora JavaScript SDK では今後もアプリを開発するにあたって Sora JavaScript SDK に依存しない、WebRTC の getUserMedia や RTCPeerConnection に関するちょっと便利なヘルパー関数を増やしていこうと思っています。


これは 2021 年 1 月現在、検討中の機能です

2020 年末に最新の WebRTC SFU Sora をリリースしました。録画周りの課題をいろいろ解決し、サイマルキャストを正式版機能としてリリースしました。まだまだやるべき事はありますが、基本的には改善フェーズに入ったと考えています。

インターコネクト機能

Sora は「単独で動くミドルウェア」として単体での性能、単体での機能を改善してきました。ただ、単体ではどうしても改善できないのが「多拠点に Sora を置いて利用したい」という要望です。

簡単に言えば複数の Sora を一つの Sora として見なす機能です。

現時点の Sora は 東京、ブラジル、アメリカ、イギリスそれぞれに Sora を立てた場合、現時点では「どこかの Sora」に集まる必要がありますが、それを不要にします。皆が東京に住んでいればいいですが、東京、ブラジル、アメリカ、イギリスに住んでいたとしても、皆が東京の Sora を利用する必要があります。

インターコネクト機能はそれぞれの Sora を相互接続させることで、東京の人は東京の Sora へ、アメリカの人はアメリカの Sora へ繋いで 良くなります。

例えば AWS では「異なるAWS リージョン内の 2 つの EC2 インスタンス間のトラフィックは、その 2 つのインスタンスが存在する VPC 間にインターリージョン VPC ピアリング接続が存在する場合、AWS ネットワーク内に留まります」と書かれています。もちろん AWS ネットワークに依存しますが、インターネットよりは明らかに安定したネットワークが利用されるため遠く離れた拠点同士でも安定して利用できるようになります。

この機能は国内外問わずに拠点を持つ大企業から多く要望を頂いています。

副産物としての大規模配信

インターコネクト機能の副産物として大規模配信がついてきます。

例えば東京に複数の Sora を立てて、それらをインターコネクト機能を利用し相互接続させることで、複数の Sora を 1 つの Sora として扱えます。

1 つの Sora が 4K@30 の映像を 100 接続まで配信できるとしたら、100 台用意することで 4K@30 を超低遅延で 1 万ユーザに配信することが可能になります。どの Sora に繋いでも良いので、運用も少しだけですが、楽になると思います。

実現可能かどうか

可能だとは思います。ただ安定的に商用環境で利用できるようにするのにはとても大変だと思います。

そのために負荷試験ツールや監視ツールを育てていく必要があると思います。課題は山ほどありますが、取り組んでいきます。


2020 年 12 月、2021 年 1 月版

WebRTC 関連でどんなことをやっているか、やっていこうかというのを書いていこうと思います。時雨堂が WebRTC で何をやろうとしているのかの可視化です。

毎月書いていこうと考えています。時雨堂の WebRTC 製品に興味がある方は読んでみていただけると嬉しいです。

今後 WebRTC SFU Sora は独立して書くことにしました。WebRTC SFU Sora については以下をご確認ください。

宣伝

時雨堂の CTO である SUZUKI Tetsuya が個人で WebRTC ネイティブライブラリガイド for iOS and Androidという解説書を書きました。主に libwebrtc をモバイルで活用するという内容になるとのことです。 CTO は WebRTC SFU Sora …


2020 年 12 月、2021 年 1 月版

今年もよろしくお願いします。今回は 2020 年 12 月と 2021 年 1 月版をセットにしました。

リリース

リリース方針

Sora は毎年 6 月と 12 月に大きめのリリースを行います。それ以外はバグ修正などがメインとなります。

2020.3 リリース

2020 年 12 月に 2020.3 をリリースしました。詳細は別に書いていますのでそちらをどうぞ。

2021.1 リリース予定

2021 年 6 月 頭に 2021.1 のリリースを予定しています。大きな機能は今のところ 1 つ位で、基本的には既存機能の改善を予定しています。

  • インターコネクト機能 (Sora と Sora を接続可能にする)
  • DataChannel 機能 / DataChannel シグナリング機能

インターコネクト機能

まだ検討段階ですが、Sora と Sora を接続できるような仕組みを用意しようと考えています。 …


サブスクリプション方式のサービスに限定している。

似たようなサービスを使ってる人で「え、これ使ってないの?」というのがあったら是非コメントで教えていただけると嬉しい。

または皆さんが使っているサービスを是非教えて欲しい。

価格は税込と税別が混ざってるので注意。

DeepL Pro

月 750 円 (年払い)

これなしではもうやっていけないくらい。

Gyazo Pro

月 490 円

今まで出会った中で最高のサービスの1つだと思う。

iCloud 200G

月 400 円

バックアップ用途。

Google Drive ストレージ 100G

年 2500 円

昔からの Gmail ユーザなので容量がたらないため。

Feedly Pro

年 50 ドル

まだ RSS の人なので。RSS を読むのは Reeder というのをずっと使ってる。Reeder 5 が出たのでアップグレードした。

Dropbox Plus

月 9.99 ドル (年払い)

開始してから払ってる。上位プランは自分には不要。容量は余ってる。

Amazon プライム

年 4900 円

Amazon プライムビデオがメイン。

Pocket Premium

年 4500 円

あとで読むサービスとしては頑張ってる方。もうこれしか手がないのでは。

GitHub Pro

月 4 ドル

勉強用コードのバックアップ用として。

Apple Music

月 980 円

開始してから払っている。iTunes Match が Apple Music に統合されたの知らなかった。

Medium Partner Program

年 50 ドル

メンバー限定記事は書いていない。ブログ利用料として払っている。

Netflix

月 1200 円

見たいときに見れるのは大事。

YouTube Premium

月 1550 円

広告が得意ではないので本当に素晴らしい。最高なのでぜひ契約することをおすすめする。

Discord Nitro

年 99.99 ドル

Discord 愛用しているので。


C++ 向けの MP4 ライブラリを Apache License 2.0 で GitHub に公開しました。

モチベーション

  • WebRTC SFU Sora が出力した録画ファイルを Hisui で合成した際に MP4 出力したい
  • WebRTC Native Client Momo に MP4 録画機能をつけたい
  • WebRTC SFU Sora に MP4 出力機能を付けるためにノウハウがほしい

開発

Sora から出力した録画ファイルを合成する Recording Composition Tool Hisui を開発してもらっている haruyama に Hisui 開発の一部としてお願いしました。cpp-mp4 は Hisui でもがっつり使います。

要件

要件は「 MP4 (VP8,VP9/Opus, AAC) が利用できる」に絞りました。将来的に AV1 に対応予定です。ただし H.264 や H.265 は自社で利用することがないため、現時点では想定から外しています。

cpp-mp4 で生成した MP4 ファイルはブラウザ上での利用を想定しているため、Safari で再生できる MP4(VP9/AAC) に対応するのが要件です。さらに Chrome や Firefox では MP4 (VP9/Opus) へも含めました。

abema/go-mp4

cpp-mp4 の開発にあたり ABEMA さんが公開されている go-mp4 をとても参考にさせていただきました。本当にありがとうございます。

開発中にいくつか go-mp4 にフィードバックができました。

リリース

正式なリリースは 1 月を予定しています。

今後

AV1 対応を予定しています。あとはバグフィックス対応で、枯れさせていければと思います。

About

V

Erlang/OTP / 時雨堂 / WebRTC / E2EE

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store