タグ

ブックマーク / f-shin.net (8)

  • 今考えているエンジニアの生存戦略について | F's Garage

    BASE社のオフィスが最近増床しましてイベントスペース的な余裕がある今のうちにイベントをやろうということで、転職エージェントのアイムファクトリーさんとの共催でこんな話をさせていただきました。 この話を思い出したのは、まつもとゆきひろさんの素敵なお話の記事を読んだからでありまして、Ruby書いたことないけどRuby書いた人の講演に行った – みたぬメモ、おお、そういえば、俺も同じタイトルでしゃべってたなと、お恥ずかしながら共有させていただければと。 僕の場合は、どっちかというと普通の会社員として生きていくための生存戦略かもしれないですね。 スライドだけでどこまでご理解いただけるかは不明ですが。 むしろ、会場で質問をしていただける方々が多数いらっしゃいまして、そっちでの受け答えのほうが全然面白かったかなって個人的には思っています。 (あと、今思い出した。元Klab CTOの仙石さんのFaceb

    今考えているエンジニアの生存戦略について | F's Garage
  • 「なぜ優秀なエンジニアを低待遇で採用してはいけないか」に対する感想の下書き | F's Garage

    まとまってないけど,まあいいや.頭の中にあったものをつらつら書いてみる ・成長している企業では,担い手としての「優秀なプログラマ」が不足するのはデフォルト.それ故,どの会社も採用活動には力を入れている. ・では,何故,利益が十分に出ている企業にエンジニア採用が寡占化しないか?というと,その会社の基準に満たないエンジニアは入社できないから.もしくは何かの理由で退職しているから. ・一部上場で高く評価されてる企業の利益率は「ボロ儲け」に近い.サーバがお金を稼いでくれるので相対的に人員の数は少なくても良いというのがネットビジネスの特徴.だからレバレッジを産んでくれる優秀なエンジニアが必要なのだが,利益が十分に出ているなら,全員のエンジニアに2000万円でも3000万円でも払うことは不可能ではないが,一部上場のCTOクラスとかを除いて,世の中,多分そうなってない.何故? ・また,多くの企業では,他

    「なぜ優秀なエンジニアを低待遇で採用してはいけないか」に対する感想の下書き | F's Garage
  • 誰と働いているかという視野のエンジニア評価軸について | F's Garage

    うだうだ記事を書く。あんまりブロガーさんのように、懇切丁寧に説明する意識はない。うざかったら途中で離脱推奨です。 とある理由で、番のデータを修正することになった。休日だったので僕が対応したのだが、その部分のデータ修正の経験がなかったので、ソースコードから調べて依存関係を解決するSQLを書き、Slackを通じてコードレビューをお願いして、無事修正タスクは完了した。 所要時間は、作業開始から40分。 日常的にソースコードをいじっていて、データ構造を熟知しているメンバーなら、5分もかからないで終わる作業だろう。もしそうならば、8倍の速度差が生まれている。 その8倍の速度差が顧客満足度に影響をおよぼすのであれば、その人は、僕よりも8倍速で得られる顧客満足度の分だけ、仕事ができると評価ができる。 その人材がいれば5分、いなければ40分。この差はとても大きい。その差が大きいと思うのであれば、そういう

    誰と働いているかという視野のエンジニア評価軸について | F's Garage
  • モバツイの経験から考えたCTOの3つの心得 | F's Garage

    元nanpi wadapさん呼びかけのイベント。CTOだったNightに登壇しました。 今もCTO職をやらせてもらってるけど、それより前のモバツイ時代のCEO/CTOの話をさせていただきました。 一旦、ネットにもプレゼン資料をアップしてみたのですが、イベント内容がCTOを辞めた理由やぶっちゃけ話を話せという趣旨だったので、どちらかというと「こうすればよかった」という取らぬ狸的な話になったので、イベント会場の文脈では良かったのですが、ネットに公開するのは気がはばかられたので、朝起きてやっぱり資料を消しました。 夜中に見ることができた100人ぐらいの方々はラッキーだったということで。 で、記事も一旦非表示にしてみたのですが、都合の良い所だけは公開しようと思いまして、今後、CTOをやっている人ややりたい人に、このイベントで話した内容から抽出した、3つのCTOの心得なる遺言を偉そうに書いておきます

    モバツイの経験から考えたCTOの3つの心得 | F's Garage
  • PHPを使う成長するサービスにおけるエンジニア採用の視点 | F's Garage

    BASEは、昨年末のメルカリ社との関係性が高まったことを期に改めて採用を強めている。中心となるのは、強力に事業を推進するところにコミットしてくれるエンジニアの募集だ。 先日、リブセンスの桂さんに当社にお越しいただいて、結構ハードな対談を収録した。 BASEえふしん×リブセンス桂 CTO対談(前編)―今求められるエンジニアは、自分の会社から「はみ出ている人」― 桂さん、バシバシ、突っ込んでくるもんだからついついハードな発言をしているかもしれない。 最近、思っているのがどうやってPHPを扱う会社で優れた人材に来ていただけるか?という部分。 PHPは、多分、今も昔も中心なんだか周縁なんだかわからない立ち位置にいる。PHPPHP市場だけで捉えると、高トラフィックなサービスを経験するという、「良い経験をしてきたエンジニア」は、藤さんところのグリー社、グリー出身者、最初からPHPを活用していたYa

    PHPを使う成長するサービスにおけるエンジニア採用の視点 | F's Garage
  • 教育でも使われている「デザイン思考」を商標登録される気持ち悪さ | F's Garage

    最近、バズワードになっている「デザイン思考」という言葉があるが、英語で言うと「Design Thinking」だ。そんな一般名詞の組み合わせを博報堂の関連会社であるTBWA\HAKUHODOという広告代理店が商標申請しているとのこと。 デザイン思考という言葉に特別な思い入れがあるわけではないが、大学院のカリキュラムとして聞いている立場だし、リーンスタートアップのリーンなサイクルのキモになる考え方でもあるため、この言葉を商標登録されるのはすごく気持ちが悪い。 何故気持ちが悪いかというと、それがどういう意図であろうが、商標や特許は「独占するためのもの」だからだ。 だから、その所有者の立ち位置や存在そのものがリスクになる。 ネット系開発者に馴染みがあるものだとスマホアプリのUIでよく使われている「画面を引っ張って更新」機能のプルダウンリフレッシュは、Twitterが買収したアプリの作者が発明した

    教育でも使われている「デザイン思考」を商標登録される気持ち悪さ | F's Garage
  • MVCにおけるcontrollerクラスの役割は時代と共に変わって行く | F's Garage

    昔、JavaのフレームワークであるStrutsも出てくる前、MVCモデルにおけるControllerの役割というのは、 「ロジックもデータも見ない現場監督のような役割」 と学んだ。だから昔、ServletではMVCアーキテクチャを学んだ時に、こんなControllerを書いていた。 [とりあえずRequestオブジェクトを受け取る] | [validationロジックに引き渡す。データの中身は見ない] | [例外が発生したらエラーView処理クラスに引き渡す。何のエラーかは細かく知らない] | [次にロジック処理クラスに渡す。最終的にDBのテーブルとマッピングしたデータはJavaBeansというデータクラスが保持する] | [例外が発生したらエラーView処理クラスに引き渡す。何のエラーかは細かく知らない] | [Viewの生成オブジェクトにJavaBeansを渡す] | [Viewオブジ

    MVCにおけるcontrollerクラスの役割は時代と共に変わって行く | F's Garage
  • Webのフレームワークの価値ってなんだろなって改めて思う。 | F's Garage

    この記事ね。ちょいと炎上してるけど、言ってることはわかるんですね。 今すぐ辞めて欲しい、「Ruby on Rails勉強してます」「CakePHP勉強してます」 タイトルが誤解を生んだので妙な方向になってるようですが、要するにRailsやCakeを使うための学習コストを払おうとして悶々としてるくらいなら、普通のHTMLSQLを使ってPHPなどを書けるようになってから、フレームワーク勉強したほうがいいんじゃね?ということだと思います。 ノーフレームワークのPHPって、ある意味、学びの材料としての粒度として最適なのかなって最近思ったりしています。 例えば個人的にフレームワークで過剰かもなって思うものに「オートリンク作成」「オートフォーム作成」の2つの機能があります。 オートフォーム作成は、それこそSmartyの頃からありますけど使ったことがなくて、何故にHTML生成を特殊な関数に置き換える必

    Webのフレームワークの価値ってなんだろなって改めて思う。 | F's Garage
  • 1