雑に書いていきます。 バックグラウンド自分のバックグラウンドスキルは以下の通り。専門はリアルタイムな通信プロトコルを利用したサーバーの設計と開発とマーケティング。 Erlang/OTPWebRTCEnd to End Encryption細かいのはこちら。 SQLGo で sqlc を使うために学ぶことにした。sqlc を採用したのは複数人数で開発するときの共通言語としては SQL の方がいいだろうというのと、SQL はどんなデータを持たせたいのかを伝えるのに便利と判断したため。 今までずっと通信系ミドルウェアの開発をしてきたこともあって SQL を学ぶ必要が無かったが、今回いい機会なのでちゃんと学ぶことにした。 まずは利用データベースを完全にしぼって TimescaleDB (PostgreSQL ベース) で利用する SQL だけを学ぶことにした。 書籍は元 SIer のガチ SQL

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

仕事を手伝ってもらっているとりいめぐみにとりあえず起業しろと無茶振りしたときに、上から目線でアドバイスしたので、書き出しておく。ちなみに出資はしていない。 前提彼女はウェブ系の UI/UX デザイナーであるが React / React Native ができるというよくわからない強みを持っている。自分が「コードが書けるデザイナーが欲しい、とにかくデザインとコード両方かけるやつが欲しい」と言い続けてつい出会えたデザイナー。 実際、今も仕事を手伝ってもらっているがデザインだけでなく機能要件ヒアリングも担当してくれており、存分に能力を発揮してくれている。 なぜ起業を進めたのか一緒に仕事してみたら、有能な社会不適合者でどう頑張っても社会に馴染めなさそうというのがある、また組織に属すよりは組織を持つ側のタイプなんだろうと感じたのもある。 実際は彼女が経営する会社がどうなっていくのか見るのが面白そうだ

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

思ったより配信方式が公式サイトでもアピールされていたのでちょっとびっくりです。「モーションデータだけを送ることで低遅延で大規模配信できる仕組みを実現したい」というのが DUO の CEO 塚本さんからの依頼でした。 フルコミットは残念ながら忙しくお手伝いできないので「配信の技術選定と設計と困ったときの相談相手」を担当しました。配信部分を担当した技術者を支えるというポジションです。あとは実現のための技術者を紹介したりもしました。 支えていた技術者から定期報告は貰っていましたが、実際リリースまではどんな感じになるかはわからず、先行体験も体験していません。 リリースされて、正直驚きました。自分で技術選定しておいてなんですが、低遅延ですし、転送量が少ないのも大きな差別化になっているようです。 とくに低遅延は 0.3–0.5 秒程度で実現できたのは技術選定が良かったと勝手に喜んでいます。 低遅延は配

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

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 を学び始めた頃にはすでにありまし

このおちあいさんの悩みは自分が社員のときに感じていたので、書いてみました。 自分の知見としては「自分の給与を自分で決められるようになった」タイミングでこの卑しい自尊心はなくなりました。 自分の場合、この卑しい自尊心は「結果を出しているにもかかわらず、給与が上がらない」と「自分が期待する評価を会社から得られていない」の２つが合わさって発生していたように思えます。 起業して自分の給与を自分で決められるようになってこの２つについて考える必要がなくなり、この卑しい自尊心はなくなりました。 自分の会社であれば結果を出したら自分の役員報酬はいかようにもできます。会社が利益を挙げられていれば高くし、利益が出ていなければ０円にすればいいだけです。何も悩む必要はありません。 ちなみに今はは自分の役員報酬は税理士に決められているくらい、興味がありません。 さらに期待する評価についても会社からの評価が社会からの

起業した時は野望はなかった。そもそも生きていければいいや程度だった。 その後、自社ビルがあったら楽しそうなんて話を顧問税理士や社員達として、自社ビルが当面の野望になった。 最近は今のような 1 日 6 時間という働き方で、社員に 4 桁万円の給与を提供したいというのが野望に加わった。 この野望を実現するためにどうしたらいいかをよく考えるようになった。 もともと自社でパッケージ製品を開発して販売した利益で会社を経営していくというのが目標だったが、思っているより短い労働時間で売上を上げるための仕組みが回っている気がする。 自社パッケージでカスタマイズしない方針のためすぐ納品可能落ちにくさを優先して開発しているため障害報告がいまのところゼロサービスではなくパッケージなので営業日対応のみ許される毎年利用料を頂くライセンス方式のため、良い製品であれば継続して利用料が毎年入ってくるドキュメントを充実さ

このエントリがとても素敵だったので。自分が考えるテックリードの役割を書いてみることにした。個人の意見なうえに、自分自身がテックリードという職を経験したことないので、完全に妄想である。 自分はコードを書くプロダクトマネージャー、たぶん。 テックリードの条件積極的にチャレンジできる困ってる人を技術力で助けられるチームの成功を意識して行動できる技術力のある雑用。コードをゴリゴリ書いて解決というイメージではない。それよりも自分の担当範囲は粛々とこなしつつ、他のメンバーが困ってる所を助ける。さらに、ボトルネックになりそうなところを早めに潰して回る。 テックリードと言う素敵な名前だけれど、むしろ裏方。 技術力をつけるためには、そのための努力は惜しまない。その技術は自分のためというよりもチームのため、チームが成功するために他の人をサポートするために使う。サポートするためには自分のタスクを早めに終わらせる

4/22 に時雨堂としては初の OSS 製品をリリースしました。 MQTT Gateway Fuji http://fuji.shiguredo.jp/ https://github.com/shiguredo/fuji 実はこれ、僕は設計だけで開発は一切していないんです。それも設計書は全部公開している Gist のみ。 時雨堂 MQTT ゲートウェイ Fuji 開発ログ https://gist.github.com/voluntas/23132cd3848af5b3ee1e 僕はプログラマーなので、普段はコード書いてますし、製品作る時はコードを書いています。むしろガンガン書きます。 ただ、今回はあえてコードを書かずに開発してみることにしました。 タスク自体は Trello で管理しました。開発者は 2 名でフルタイムではありません。むしろ 50% 以下の稼働率です。 ３人での顔を合わせ