タグ

ブックマーク / voluntas.medium.com (10)

  • 町工場の全社員が残業ゼロで年収600万円以上もらえる理由

    Amazon.co.jp: 町工場の全社員が残業ゼロで年収600万円以上もらえる理由 eBook: 吉原博: Kindleストア 前提そもそも町工場を詳しくしらないので、とても勉強になりました。自分はずっと IT にいるということもあり、仕入れや在庫、設備あたりの知識がほぼ経験ありません。なのでその辺については、勘違いなどあるかもしれませんのでご注意ください。 自分と違う考えの部分が書かれているところをピックアップして書いてみています。 単に自分の考えとの比較でしかないので、どっちが正解とかはないと思っています。 給与と賞与給与は実力性、賞与は皆一緒という方式でやっているようです。ただ評価の話がほぼ書かれていなかったので、おそらく社長の独断で決めているのではないでしょうか。 賞与は手取りで 100 万円、現金払い。最大値が決まってるのがとても違和感がありました。そもそも利益が出ているなら賞

  • 商売の脆弱性

    ソフトウェアのパッケージ販売に携わってもう 10 年以上になるが、どうもこのビジネスってずるすぎないか?ってずーっと思いながらやっているのだが、 ajiyoshi が商売の脆弱性という、うまい表現を使っていたのでパクることにして、ブログを書いてみることにした。タイトル重要。 前提自分はミドルウェアという分野のソフトウェアパッケージ製品を専門にしている開発者(あと経営者)という立場。会社を持つ前も同じ分野を担当していた。 ここでのソフトウェアのパッケージ販売というのはミドルウェア製品のパッケージ製品のサブスクリプションライセンス販売を指している。 ソフトウェアのパッケージ販売在庫が不要ほんとこれ。なんだよそれって思う。うちの例だとダウンロード URL とライセンスファイルをメールで送ってそれで納品完了。 在庫がないのに物が売れるって当に意味がわからない。ダウンロード URL から製品をダウ

    suginoy
    suginoy 2019/05/06
  • 無償での情報搾取

    IT 系零細企業を経営していて、特定の技術に強いと外から思われ始めると無償での技術情報の搾取を目的とした問い合わせが多くなる。 自分は残念ながら無償で技術情報の搾取をされた経験があるので、注意喚起として書いておく。この悪しき習慣を潰したい。 情報交換をしたいこのフレーズがメールの文章に含まれていた場合は、とても注意すべきだ。殆どの場合であなたの会社の方が情報を持っており、相手は無償で技術的な情報を得たいと考えていることが多い。 技術の分野の世界はとても狭いので、ほんとうの意味で情報交換を申し込んで来る人はあなたがすでに知っている人の可能性が高い。全く知らない人が情報交換を持ちかけてくるのはまず疑ったほうがいい。 知らない会社から「情報交換をしたい」と言われたら、丁重にお断りをするべきだ。情報交換をしたいと言ってきた会社から仕事につながった経験はまったくない。彼らは一方的な搾取を望んでいるだ

    suginoy
    suginoy 2019/01/27
  • 一方通行な「情報交換させてください」

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

    suginoy
    suginoy 2018/09/05
    「まずはお会いさせていだだき」も無くなってほしい。
  • 自分が働きたい会社にしない

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

  • Discord の採用している技術

    Discord はゲーマー向けのボイスチャットサービス。テキストチャットもできるし最近ではビデオチャットや画面共有もできるようになった。 UI はかなり Slack に似ている、モダンなデザインということなんだろう。 WebRTC 技術を利用しているということで、とても気にはなっていたが使うタイミングがなかったことからあまり追いかけていなかったが、先日ビデオチャットと画面共有が追加されたということで色々調べてみることにした。 ElectronWindows/Mac/Linux 向けのデスクトップクライアントには Electron を採用している。かなり早い段階から採用しているイメージ。Electron は Chromium ベースなので WebRTC が利用できる。WebSocket もバリバリ使ってる模様。 Electron を使うことでブラウザとほぼ変わらぬ動き、UI を再現している。

    suginoy
    suginoy 2018/04/21
  • リモートワークとの付き合い方

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

  • 自社の今期振り返りと来期に向けて

    自社の決算が 9 末、あと 2 週間ということで振り返ってみたい。 前期が投資期で、 今期は種蒔き期なんて考えていたが、運良く回収期にもなった。正直色々と想定外の期だったように思える。 自社製品を中心に振り返って、ダラダラ書いていく。 運良く自社製品が売れ始める営業がいないので、完全に問い合わせを口を開けて待つスタイルなので、いつ売れるかも運頼み。 それが 2017 年に入ってからはほぼ毎月売れて、社外のお手伝いの売上よりも多いこともあったりした。 自社製品の売上はキャッシュフロー的にとても安定するという事を、実感した 1 年だった。 大手に採用され始める公開できる範囲だとリコー、スクエニ、ソフトバンク(敬称略)という大手に採用されたのは社会的信用という面で大きかった。打ち合わせでもうちが小さい会社だから心配という話がなくなった。 製品の性能や機能、品質などだけで勝負ができるようになった。

    suginoy
    suginoy 2017/09/16
    “サポート専任を雇うという考えを捨て、開発者が直接サポートをするという方針に切り替えた。”
  • カスタマイズをしない

    自分の会社ではパッケージ製品、つまりお客様の環境で動かして頂く製品を販売している。 そのため、カスタマイズを希望される事もある。今の機能では簡単に実現するのが難しいというのがほとんどの希望理由だ。 カスタマイズの定義は製品に対して+アルファの何らかの特別な対応を機能を追加することという事にしておく。 結論から言うと自分の会社では一切のカスタマイズを受けないというスタンスだ。カスタマイズはメリットよりデメリットの方が多いという考え方からだ。 カスタマイズのメリットまちがいなく売り上げを上げやすい事だろう。カスタマイズが必須な場合の顧客はカスタマイズを受け付けない製品を購入しない。 さらにカスタマイズ対応ということで、追加の開発費やサポート費を手にすることができる。これは前職で十分実感できた。 ただメリットはこれしか無い。 カスタマイズのデメリット一番大きいのはコードのフォークが発生してしまう

    suginoy
    suginoy 2017/03/19
  • HTTP API の設計方向

    見てみると、たしかに Get 系の API だとしても POST を利用しているし、API の URL 設計に get_shared_link_file のようによく言われる REST っぽい設計は使っていなかった。 この方針は同意だ。自分は結構前に REST っぽい API を捨てることにした。だからといって REST API がダメだとかは思っていない。 一般ユーザが使う場合の API は REST API であるほうが慣れ親しんでいる場合が多いからだ。 AWS で利用されている HTTP API 仕様AWS の DynamoDB の Erlang/OTP ドライバーを書いているときに気づいたのだが、AWS の一部のサービスはかなり独特な API の仕様になっている。

    suginoy
    suginoy 2016/10/08
  • 1