集中力のない人の戦略
集中力がないといろいろなところで苦労します。とりわけ苦労したのが学校です。学校では決められた時間で学ぶ授業、決められた時間で問題を解き結果を出す試験があります。これが本当に集中力のない自分には地獄でした。とにかく決められた時間で何かをするというのがとても苦手でした。 恐ろしいほど集中力がなく、決められた時間の中で結果を出すことができない自分がどうやって仕事をしているのかという話を書いてきます。 ダラダラ継続する結論を先にいうと「人の何倍も時間をかけて、常に変化する分野ピンポイントにダラダラと継続する」という戦略を取ることにしました。 継続といえばカッコイイですが所詮は「ダラダラ」です。つまり気分が乗ったときだけダラダラとやっていきます。 ただ、ダラダラやるのも１年、５年、１０年と続ければ結果は出ます、多分。 また、常に変化する分野であれば集中力よりも、継続が求められるはずだとも考えました。
同時接続 700 万、秒間 2 万通という Nintendo Switch 向けプッシュ通知システム NPNS の資料を読んで
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 を学び始めた頃にはすでにありまし
コードを書き続ける
「開発者は経営者になったらコードを書くのやめて、経営に集中すべき」という考え方を聞いたことがある人はいるだろうか？ 自分はこの考えを持っていた経営者の元で働いていたことがあるので、強く印象に残っている。そして優秀な開発者たちが無理やりコードを書く時間を取り上げられ、経営者とされていったのを何度か見ている。 ここに書くのは自分の経験談であり、こうすべきとかではない。そしてなにより自分は死ぬまでコードを書き続けたいと考えているタイプであるということだ。 伝えたいことは一つだけでコードを書き続けたい経営者からコードを書くのを取り上げるのが良い方法だと思わないということだ。 また、経営者だから偉そうにコードを書くとかは当たり前だがなしだ。経営者関係なく、ただの開発者としてコードを書くという前提のお話。 開発者と経営者起業して 5 年が過ぎた。経営者としても 5 年、開発者としても 5 年。社員をし
「俺はもっと年収高くていいはずだ」
このおちあいさんの悩みは自分が社員のときに感じていたので、書いてみました。 自分の知見としては「自分の給与を自分で決められるようになった」タイミングでこの卑しい自尊心はなくなりました。 自分の場合、この卑しい自尊心は「結果を出しているにもかかわらず、給与が上がらない」と「自分が期待する評価を会社から得られていない」の２つが合わさって発生していたように思えます。 起業して自分の給与を自分で決められるようになってこの２つについて考える必要がなくなり、この卑しい自尊心はなくなりました。 自分の会社であれば結果を出したら自分の役員報酬はいかようにもできます。会社が利益を挙げられていれば高くし、利益が出ていなければ０円にすればいいだけです。何も悩む必要はありません。 ちなみに今はは自分の役員報酬は税理士に決められているくらい、興味がありません。 さらに期待する評価についても会社からの評価が社会からの
採用事例の重要性
自社製品をリリースしてから、採用事例は製品の機能よりも強いというのを実感している。 実は採用事例自分はあまり重要視してはいないかった。もちろん無いよりはあったほうがいいだろうとは思っていたので採用事例「なし」の場合は「あり」よりも価格が高くなるという仕組みだけ考えた。 採用事例公開できる場合は 60 万円採用事例公開ができない場合は 84 万円採用事例が公開できない場合は多めにお金がもらえると嬉しい、その程度の考えだった。 採用事例が何よりも重要そんな中、採用事例が何よりも重要という考えを打ち出したのは一人の社員だ。 その社員が採用事例を重要視した第一の理由は顧客は採用事例をみて、自分たちがやりたいことと似ている事例を探し、この製品を買えばいいのかどうかを判断するという考えだ。 この考えは的中した。打ち合わせや問い合わせで「〜という感じで使いたい」が採用事例の中から選ばれる事が多かった。
フルリモートワークを諦めた
正社員のフルリモートワーク採用を目標としていたが諦めた。 現在、自社では週１出社それ以外は自宅からのリモートワーク社員がいる。一緒に働いて感じたことはフルリモートワークの場合はうまくやっていくことはかなり難しいだろうと感じたことだ。 自社では自社パッケージ製品を開発している。この開発には双方向のコミニュケーションがかなり必要になる。特に顔を突き合わせて話すというのがとても重要になる。さらに感覚的な話も多くなりがちだ。 実際、週１出社してる社員とはよく話をする。仕事の話、雑談。本当に色々話をする。 特に自社は社員も少なく１社員が担う範囲も多く、意思疎通がとても重要になる。これが週１出社してもらうだけで、かなり違う。ギャーギャー面と向かって話ができるというのはとても重要だと感じたのだ。 フルリモートワークになると出社は月１回とかになるだろうか、大きめの企業であればうまくタスクが分担できたりして
経営者になってわかったこと
起業して 8 年しか経っていないが、だらだら書いてみる。 自分の会社は従業員は片手で足りるくらいの IT 系零細企業。 税金は高い売上はすぐ入ってこない自分の給与は自分で決められる仕事は簡単に見つからない社員を雇うのは難しい経理、総務、法務、営業事務、書類仕事は多い賞与はいくら出してもいいオフィス賃貸費用は安いほうがいい銀行はとにかくお金を貸そうとしてくる資本金は銀行からお金を借りない限りどうでもいい経営の相談ができない顧問税理士は役に立たない帝国データバンクや東京商工リサーチへの登録が必要になる時がある自分宛ての投資マンション迷惑電話がくる社員の月給が低ければ低いほど経営が楽になる社員の年収は可能な限り高いほうが良い自分の年収に興味がなくなる収入を増やすのも、支出を減らすのも難しい賞与はいつ出してもいい顧問弁護士は必要だが、いつも必要なわけではない自社製品だけで会社を回すのは現実的ではな
製品品質と評価制度
時雨堂には自社製品の検証を専門に行う社員がいる。具体的な指示は特になく「自社製品の検証よろしく」しかお願いしていない。 朝会社に来てから夜帰るまで、特に何か言われることもない。負荷試験をしていたり、ロングラン試験をしかけたり、異常系の検証をしたり。つまり何をやってもいい。 成果報告も一切不要。コミットログをみて検証したり、ドキュメントを見て検証したり。ドキュメントはわかりにくい部分を修正。 ちなみに製品にバグを見つけた場合はパッチをチャットに貼ってくる。製品の修正は開発者がやれということらしい。 勘違いしてもらいたくないのが、担当している社員はコードはゴリゴリかけるし、AWS や GCP といったクラウドも使える。さらには社内ネットワークを構築したり、自社サーバの運用などもできる。 コードが書けないから検証を専門にしているとかではない。検証で利用する WebSocket クライアントは 1
カスタマイズしないとどうなるか
続き。自社製品のミドルウェアでカスタマイズをしないと実際にどうなるかを書いていく。 カスタマイズの相談をされた場合一切対応していない事を伝える。メールが返ってこない事が多い。そのためビジネスチャンスを逃している可能性は高いが、カスタマイズをするリスクのほうが高いため問題ない。 カスタマイズを要求していくる会社から相手にされなくなる。 注文から提供までメールにて申込書を送り、記載して返送してもらう総務が社内に立っているライセンスサーバでライセンスを発行する製品のダウンロード URL とライセンスファイルをメールで送る終わり。製品の提供まで 30 分くらい。自社製品は最小ライセンスの費用が 60 万円/年なので 30 分で 60 万円の売上になる。これが毎年。 この後はサポートのお仕事。 サポート対応全ての顧客が同じ製品を利用しており、自社製品は最新版を利用していることがサポートを受ける前提と
FPGA に手を出してみた (2)
PynqをあくまでもFPGAとして利用する方向けに、Vivado上でプロジェクトを作成しPynqに乗っている4つのLEDを光らせる手順を説明します。… Vivado を利用して PYNQ で利用可能なビットストリームを生成するというのを目標に、上の記事を写経。ただうまくいかずビットストリームが生成されなかった。たぶん何かがわかっていない。 Vivado には PYNQ のボードファイルが入っていないのは寂しかった。 とにかく GUI だなーというお気持ち。覚えゲー感が凄い。 Windows と PYNQ-Z1USB を Windows PC 側にさしたら認識してあっけなかった。Vivado からも見えてた。 FPGAの原理と構成最初からゆっくり読み始めた。詳しすぎる分、意味がほとんどわからない。 一つ一つ単語の意味をまとめて整理して、進めている。詳しすぎていい本というのに久々に出会った。
IT 系零細企業は何に投資すべきか
正社員 5 人未満の IT 系零細企業を経営して 5 年たったので、何に投資して、何に投資しなかったかを振り返る事にした。 それぞれの会社で色々あるだろうから、これはあくまで自社がこうした、こうしているという話である。それ以上の意味はない。 投資すべき事社員の給与何よりも社員の給与が一番の投資先。人は一定額以上の給与を貰っていれば労働に対するモチベーションが下がりにくくなる。 何よりお金はあって困らない、そして無いと困る。 もちろん会社が儲かっている前提。自社は月給と賞与の比率が 3:7 くらいで賞与が多い。そのため、会社が儲かったら賞与を沢山だす。とにかく税理士と総務に「社員に賞与出しすぎです、この辺でお願いします（実話）」って言われるくらいまで出す。 そのかわり会社が貧乏な時は賞与は一切ださない、というか出せない。ここを理解した前提で入社してもらってる。 とにかく会社に多めに残すくらい
YouTube が WebRTC 配信に対応した
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 に変換してくれるので、スケーラビリティを気にする必要はない。もちろん
“二番煎じやるなら全力で” と戦う
知り合いの経営者に言われた二番煎じやるなら全力でという言葉が強く心に残っている。ここで言う二番煎じというのは簡単に言えば、似たような製品やサービスを作って行くという話である。 二番煎じをやるということは、ある程度その市場が儲かっており、二番煎じだとしても利益が出る可能性が高いということだろう。 二番煎じの強みは「考えなくていいこと」であることは間違いないと思う。すでに市場を先に走っている相手がいるわけだから、まずはそれと似たような製品を出せばいい。で、それをやるなら全力でやれという話。 相手は先行者がいないため、色々考えることがあるが、二番煎じをやる場合は先行者の模倣をしながら先行者が実現していなことを足していけばいい。 むしろ二番煎じをやると決めた以上は、なんとなく作ってなんとなく儲けるのではなく全力でやれという話。 本題さて、二番煎じをしろというはなしではなく、自社の場合は二番煎じをさ
起業して 6 年目に突入した
時雨堂という会社を作って 6 年が経った。資本金 50 万円からスタートした会社だが、ありがたいことにまだ潰れていない。正社員は 4 名。 2015 年にリリースしたリアルタイムな音声や映像を配信するミドルウェアがちらほらと売れてきて社員の給与を賄えるところまではきた。また今は新しい自社製品としてシナリオを Lua で書ける負荷試験ツールを作っている。これはあまり売れそうにない。 自社製品自分が理想とする会社の経営方針が自社製品を前提とした考えなので、自社製品は売れなくても作っていくという方針。 売れるか売れないかは残念だけど運の要素がとても高い。今はリアルタイムな音声や映像を配信するミドルウェアである WebRTC SFU が売れているが、これも正直運の要素がとても高い。狙って出して売れたというわけではない。 狙って売れる製品を作るのは疲れる、作りたいものを作って売れるように頑張るほうが
WebRTC スタック Python 実装の紹介
このライブラリはとてもシンプルに書かれており、 WebRTC がどのように機能しているのかを理解したい人にぴったりです。 また Python のエコシステムに乗っかっているので Python から気軽に利用できます。なにより libwebrtc を使っていないのは負荷をとても下げています。libwebrtc は闇しかありません。 このライブラリの素晴らしい点はいくつもあるのですが、何よりコードがとてもキレイです。そして丁寧に書かれています。 また、MediaChannel 向けに libvpx や libopus をラップしてくれており、現時点では音声の配信までできるようです。 DataChannel は双方向でやりとりまでできるところまで作られています。SCTP は自前です、偉い。 ちなみに DTLS (openssl)や SRTP (libsrtp)は外部ライブラリを使っておりますが、
Django に再入門している
こんなウェブアプリがほしいという仕様書を書くのだが、結局プロトタイプを作ってデモを見せたほうが早い。 Django を使ってプロトタイプを作れる能力を身につけることにした。Django 歴は無駄に長くて 10 年以上だが、プロダクションで利用したのは片手で数えられるほど。 プロトタイプを作るにあたってヤクの毛狩りをしないように、いくつかルールを考えてみた。 データベースは SQLite を利用する可能な限りサードパーティライブラリを使わないコードの量をできるだけ少なくするデザインを一切当てないHTML は適当に書く可能な限り JavaScript は使わない効率が悪くても気にしないデプロイは誰かに丸投げする速度重視であって、これらのコードは捨てる前提。プロダクションを作る時に参考にしてもらえたらラッキー程度にする。 自分が慣れていない技術を使う時はとにかく、メモを残すことにしている。単に検
リモートワークとの付き合い方
A very smart man versus a very smart machine. Can an undisputed board game king conquer artificial intelligence? Watch… Netflix の AlphaGo が話題になっているので Netflix を再契約して見てみた。とても良かった。 見ていて思ったのが DeepMind 社の社員たちが事ある毎にホワイトボードやメモ帳を持って議論をしていた。 もちろんこれはドキュメンタリーなので、全部が全部そうではないとおもうが、とにかく顔を合わせて、その場にいて議論をしているように見えた。 働く場所は同じ場所で、皆ヘッドフォンをして作業をしていたし、スタンディングデスクもあった。ただとにかく顔を合わせて話をしているのが印象的だった。 自分のリモートワークに対する考えちょと書き出してみる
時雨堂 2017 年振り返り
今年 1 年を振り返ってみた。時雨堂とはなんぞやという人は時雨堂コトハジメでも読んでみていただければ。 これは、スタートアップではない、台東区にある小さな IT 会社の振り返りです。 自社製品が売れ始めたリコー様の導入を皮切りに、スクウェアエニックス様、ソフトバンク様といった大手企業に導入されたり、pixiv 様やタイトー様のようなお絵かき配信やネットクレーンなどに採用されたりと、できすぎたくらい採用していただいた。他にも事例公開ができないお客様も含め、多くのお客様に採用していただいたのは本当に感慨深い。 個人的にはフロンティアリンク様の開発担当者とお会い出来たことがとても嬉しかった。自社製品を社長が反対した中、ゴリ押しで採用してくれたとのことだった。本当にありがたい。 製品を購入いただいた方はほぼウェブサイトを見てからの問い合わせで、評価版を 1 ヶ月触っていただいて採用していただいたこ
リファクタリング
自分はリファクタリングが好きなので、リファクタリングに対する考えとかを書いてみる事にした。 前提としては自社製品、さらにパッケージソフトウェアのためデプロイは存在しない。リリースは一ヶ月に一回程度。ソースコードは 10 万行未満。 自分がリファクタリングするのは機能追加に飽きた時。ペーストしては月１回程度で、多い方だと思う。よく飽きる。 リファクタリングをする時はまず、コードを端から端まで読みながらコメントをしていくところから始める。その後、またコードを端から端まで読みながらコメントを読みつつ、どんなリファクタリングをするか決めていく。そして、決めたらブランチを切って作業。 とにかく、手を付けるコードを読むことが重要だと思っている。人間は適当なものでコードを適当に理解している事が多いので、一度頭を空っぽにしてコードを読むと「この辺は大丈夫」と思っていた部分も全然大丈夫じゃないことがある。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
OpenSora プロジェクトへの思い