時雨堂は会社の仕組みを Gist でオープンにしている。実はあの仕組みは自分が働きたいと思う会社の仕組みではない。 時雨堂は 10:00–17:00 の定時制で 6 時間労働。さらには仕事は選べない。技術もあまり選べない。月給は安く抑えられており、賞与は保証なし。ただし儲かった場合は賞与を高めに出す。評価制度はない。 時雨堂で自分が従業員として働きたいとは思っていない。自分が従業員として働くのであれば、裁量労働で、仕事は好き勝手に選べて、給与は稼いだ分だけほしい。さらに技術は自分が使いたいものを使う。ただし食堂はあってほしい。 ではなぜ時雨堂は自分の働きたい会社になっていないのか。それは単純で自分はあくまで経営者であり、従業員ではないからだ。そして自分は社会不適合者であるため、従業員としてやっていけなかったから起業した身であるからだ。 つまり従業員としてやっていけなかった人が望む会社の仕組

先日、門脇(kdxu)とめるぽんと自分で 3 人でやっていたお手伝い案件が終わった。納期は一ヶ月前倒し、顧客の要望はほぼ全て実現という内容で、顧客も大喜び。 門脇とめるぽんはフリーランスとして仕事をしており、自分がお手伝いさせて頂いている会社（それぞれ別の会社）でふたりともフルタイムとして働いている。 そのため、平日の夜や土日が主な作業時間になる。完全非同期で作業して、うまくいったのでそれを記録しておきたい。 案件内容、技術については一切触れない。 自分はプロジェクトマネージメントのみコードは書かないプロジェクト開始前に一通りの要望は洗い出しておいた追加要件にできるだけノーを言わないロードマップを１ヶ月単位で引いた二人を作業者として雇った設計や交渉などはすべて自分が行った顧客には二人が作業者として伝えてある顧客と直接のやり取りは二人は行っていない顧客との打ち合わせにも参加してもらっていない

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

AWS Summit Tokyo 2018 で実施されたセッション資料・動画をダウンロードすることができます。（順次公開） ※AWS Summit 2018 へお申し込みいただいていない場合、別途ダウンロード申し込みが必要となります。… 【任天堂様ご登壇事例】Nintendo Switch （TM） 向けプッシュ通知システム「NPNS」AWS はよくわからないので Erlang/OTP 視点のみです。 ejabberdejabberd はフランスの ProcessOne という会社が開発している XMPP サーバです。XMPP が何かはここでは説明しません。 ejabberd は TLS や XML 周りの性能を出すため C で書かれている以外、他はすべて Erlang/OTP で書かれています。 ejabberd の歴史はとても古く、自分が Erlang を学び始めた頃にはすでにありまし

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

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

前にも似たような話は書いていたが、何度も書いて見たほうがいいと思うので、書くことにする。 WebRTC の話をする前にリアルタイムな双方向での音声や映像配信技術について話をしたい。この技術は Skype や Facetime や LINE などで気軽に利用している人が多いと思う。 リアルタイムな双方向での音声や映像配信技術の何が凄いかというと、遠くにいる人と相手の映像を見ながら会話ができることだ。それも遅延をあまり感じずに。 これは本当に凄い技術なのだが、今ではスマートフォンさえあれば気軽に体験できてしまう。距離を縮めるという意味でリアルタイムな双方向での音声や映像配信技術の需要は今後も増えていくだろう。 WebRTC はこれをブラウザさえあれば実現できるようにした技術だ。この時点で正直気が狂ってると思っている。今までは専用アプリが必要だったり、もう少し前であれば専用ハードが必要だった双方

最近リモートワークな人とお仕事をする事が多い。自分がプロジェクトマネージャー的に働くことが多いので、リモートワークで働いている人がどうしてくれると自分が楽かということを書き出してみることにした。 殴り書きなので、読みづらいと思う。 ２つのタイプの案件でリモートワーカー達とやりとりしているので、わけて書き出す。 外貨稼ぎ案件外貨稼ぎ（社外のお手伝いをしてお金を稼ぐ）は自分がプロジェクトマネージャーとしてリードして、社外のお手伝い二名が開発担当として入ってくれている。 連絡はすべて Slack でのみ行う情報共有は Slack と GitHub で行うフェーズに分けて進捗管理完全非同期で労働するタイミングは縛っていないQA は GitHub で Markdown で質問してもらうお手伝い二人共技術的には申し分がない仕事は開発案件で、顧客とのやりとりは全て自分がやっており、お手伝いしてくれている

Today we're making it easier to go live and interact with your community from your computer and phone. First, if you've… YouTube が WebRTC を利用した配信に対応した。つまり今まで YouTube で配信するには何かしらのツールが必要だったが、WebRTC を利用した配信機能を使うことでブラウザとウェブカメラだけあれば配信ができるようになる。 そう、つまり pixiv Sketch Live が実現したあの手軽な配信が YouTube でも可能になった。ただ、まだ画面共有に関してはまだできなさそうだ。 配信者はブラウザから配信して、あとは YouTube が HLS や MPEG-DASH に変換してくれるので、スケーラビリティを気にする必要はない。もちろん

Flutter は Google が提供している iOS / Android 向けのフレームワークです。Dart を書くことで両方の OS で動くアプリを書くことができます。 Flutter は iOS/Android 向けのモバイル UI フレームワークとうたっているだけあり、特徴は UI フレームワークが完備されているところです。

時雨堂という会社を作って 6 年が経った。資本金 50 万円からスタートした会社だが、ありがたいことにまだ潰れていない。正社員は 4 名。 2015 年にリリースしたリアルタイムな音声や映像を配信するミドルウェアがちらほらと売れてきて社員の給与を賄えるところまではきた。また今は新しい自社製品としてシナリオを Lua で書ける負荷試験ツールを作っている。これはあまり売れそうにない。 自社製品自分が理想とする会社の経営方針が自社製品を前提とした考えなので、自社製品は売れなくても作っていくという方針。 売れるか売れないかは残念だけど運の要素がとても高い。今はリアルタイムな音声や映像を配信するミドルウェアである WebRTC SFU が売れているが、これも正直運の要素がとても高い。狙って出して売れたというわけではない。 狙って売れる製品を作るのは疲れる、作りたいものを作って売れるように頑張るほうが

最近良く聞かれるので書いてみようと思う。 人を増やしたとしても売上が上がるビジネスモデルを取っていないというのが大きいと思う。 他にも色々考えたが、まとまりきらなかったので以下に書き出した。 起業して 4 年でやっと自社製品で社員 4 人の給与をまかなえるようにはなった。ただ、まだ 1 日 6 時間という働き方で、社員に 4 桁万円の給与を提供したいという野望は達成できていないので、今年か来年には達成したい。

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

こんなウェブアプリがほしいという仕様書を書くのだが、結局プロトタイプを作ってデモを見せたほうが早い。 Django を使ってプロトタイプを作れる能力を身につけることにした。Django 歴は無駄に長くて 10 年以上だが、プロダクションで利用したのは片手で数えられるほど。 プロトタイプを作るにあたってヤクの毛狩りをしないように、いくつかルールを考えてみた。 データベースは SQLite を利用する可能な限りサードパーティライブラリを使わないコードの量をできるだけ少なくするデザインを一切当てないHTML は適当に書く可能な限り JavaScript は使わない効率が悪くても気にしないデプロイは誰かに丸投げする

告知されていたとおり pixiv Sketch Live の配信が HLS 化されていました。遅延は約 10 秒程度といったところでしょうか。 画質も WebRTC での配信時代の高画質を保ったままで、とてもキレイです。凄いですね。 このサービスで、一番予想外だったのがブラウザから配信ができるという点がとても評判良いことです。自分にとっては WebRTC は超低遅延で音声や映像が配信できる技術という認識が強かったため、あまりブラウザから利用できる … というのはそもそも当たり前という認識でした。 pixiv Sketch Live の配信やコメント、配信してみた人の Twitter での反応を見ていると、こんなに簡単に配信ができるなんて！という反応が多くあり、自分の当たり前は他の人にとって当たり前ではないというのを実感させられました。 今回 pixiv さんが採用した WebRTC から

今年 1 年を振り返ってみた。時雨堂とはなんぞやという人は時雨堂コトハジメでも読んでみていただければ。 これは、スタートアップではない、台東区にある小さな IT 会社の振り返りです。 自社製品が売れ始めたリコー様の導入を皮切りに、スクウェアエニックス様、ソフトバンク様といった大手企業に導入されたり、pixiv 様やタイトー様のようなお絵かき配信やネットクレーンなどに採用されたりと、できすぎたくらい採用していただいた。他にも事例公開ができないお客様も含め、多くのお客様に採用していただいたのは本当に感慨深い。 個人的にはフロンティアリンク様の開発担当者とお会い出来たことがとても嬉しかった。自社製品を社長が反対した中、ゴリ押しで採用してくれたとのことだった。本当にありがたい。 製品を購入いただいた方はほぼウェブサイトを見てからの問い合わせで、評価版を 1 ヶ月触っていただいて採用していただいたこ

Real Time Messaging Protocol ( RTMP) とは、 Adobe が開発している、 Adobe Flash プレーヤーとサーバーの間で、音声・動画・データをやりとりするストリーミングのプロトコル。元々… RTMP は TCP ベース。UDP ベースの RTMFP もあるようだがあまり使われていないようだ。そもそも RTMFP は P2P で使われるので、これが WebRTC と同じ扱い。 基本的に RTMP は一方向の配信に使われているようだが、HLS/MPEG-DASH と違うのは PUSH で配信できるという仕組み。つまり遅延が少ない。 RTMP から切り替えたいお客様の話を聞く限りは 1–2 秒の遅延らしい。HLS/MPEG-DASH だと頑張れば 1–2 秒行けそうだが普通は 10 秒以上は遅延してしまう。 RTMP のメリットとして CDN が使える事

目標としていた社員の給与をすべて自社製品の売上でまかなうというのが達成できた。ということで自社製品ほんとうに売れるまでの距離が長いという話をしたい。 前提資金調達は一切していない社外のお手伝いしてお金を稼ぐ資金調達している時点で、そのビジネスに注力できるのでこの話は関係ない。 よくある話そもそも資金調達していないので、完全に社外のお手伝いに依存することになる。社外のお手伝いはいつなくなるかわからない。 社員に給与は払わなければいけないので、役員は自分の給与以上に働く必要がある。忙しくなる。自社製品作ってる暇がなくなる。 結局社外のお手伝いがメインの会社になる。 ここまでがよくある話。 社外の手伝いが忙しい会社ほど自社製品を作りたいという話を良くしている。実際は何もしていない。 自社製品を作るのが難しい誰もが売れる製品を作れるわけではない。売れる製品は正直、運の要素がかなり高いと思っている。

Twitter では何度もつぶやいていたのだけれど、自分の意見をまとめておく。 「情報交換させてください」は殆どの場合で「自分はよく知らないので、貴方ならよく知ってるんだから教えて欲しい、タダで」というパターン。つまり一方通行が多い。 何者かわからない初対面の人に「Erlang/OTP の情報交換しましょう」と言われる怖さ。いや、貴方は誰なんだ。 特にビジネスでの「情報交換させてください」はネガティブな印象しか持たれないので本当にやめたほうが良い。特に、その技術でお金を稼いでいる会社に対して大変失礼だということを理解してほしい。 普通に技術的に困っているなら「困っているので相談にのってほしい」でいいし、興味があるなら「今はわからないが興味がある」でダメなのだろうか。 一方通行な「情報交換させてください」を撲滅したい。 一方通行な「情報交換をさせてほしい」の方に「技術相談ということであれば、