よくエンジニア採用についての相談が来るので書いておく。 ひとことでエンジニアと言っても経験レベルは多々あって、どういうエンジニアを採用したいによっても戦略は変わってくるだろう。 １．超スーパーエンジニアに難題を解決してほしい ２．そこまでスキルはなくとも普通にコード書ける人に手伝ってほしい ３．未経験で勉強しながらでもいいから一緒に手伝ってほしい 大体のエンジニア採用で困っているという人たちは、このレベル感がわからないし、スーパーマンがすべて解決してくれるだろう的ノリで期待をするが、エンジニアだって人間である。その人が時間と労力を捧げるに値する対価（お金、経験、マインド）が満たされなければお手伝いしたいと思う人はいない。そのため自分たちが提供可能な経験価値はなんなのか？を考えておくことは必須である。 Q. このビジネスにエンジニアが関わることで、その人は何が得られるのか？ そして、その気持

次世代教育フォーラムというデジハリのイベントに登壇させてもらった。 オープニングが稲見先生の基調講演から始まるというKMD生としても胸熱な展開。 僕はその３セッション目のG’s Academyとしてのセッション。G’s責任者の児玉さんがモデレータで山崎先生と僕が話す場でした。 まず、お題として「何故エンジニアが不足しているのか？」という質問。 毎日、なんらかしらの採用面接に携わっている身としてつくづく思うのだが、「エンジニアは足りなくて当たり前」という感覚を持っている。 雇用側という立場で「何故足りないのか？」と聞かれれば、「お断りもしてるし、断られてもいる、採用で妥協してはいけないので、我々のフェーズにおいて採用できるレンジは極めて狭い」ということだと思う。 それがチームフィッティングであったり、スキルレベルであったり。スキルレベルと言っても、人によってフェーズはまちまちで、まず完成して

転職で新しい分野にチャレンジしたい時には、少なくとも、その分野にチャレンジしていて、多少なりともアウトプットは作るべきだし、そのクオリティが高いことが転職可能性を大きく引き上げる。 例えば、僕らの仕事が旋盤加工だとか機械加工とか、そもそも試すのに設備が必要な業種だったら、工業高校や機械科などで一切やってない限り、完全にゼロから育てていくしかないと思うけど、Webやアプリは開発ツールや情報が無償やほぼ無料で公開されているので「何もやっていない」というのは、少なくとも無知か、入社してからも勉強しませんって言ってるようなものなので、そのどっちに思われても転職可能性を大きく下げてしまって難しいんじゃないかな。 もしライバルがいて、一方が無料の環境を生かして勉強してます、もう一方は忙しくて手を付けてません、ちょっといじった程度です。であれば、特別な資格や家柄、コネなどに無関係に前者が採用されやすいの

寝る前にお酒を飲むような記事です。期待しないでください。wadapさんの記事を読んでいたわけですが、 日本のエンジニアの地位をあげるために 読んでて全然関係ない話を思いついちゃったんです。結構学生のタイミングでどうするかって重要だなって思ったんですが、 自分が学生の頃を思い起こすと、よく考えたらなんの理由もなく「がんばらないふり」をしていたかもしれないです。 僕を含むスタートアップの人達は、学生時代から頑張っている人も多いし、社会人でもチャレンジしなきゃ！って言ったりしちゃってますが、僕は理由なく「IBMって大変らしいよ」とか「外資系は途中で人生見えちゃうみたいよ」みたいに、バイト先で知り合ったオッサンに聞かされた言説に流されたりして、無難に生きる方法だけを考えていたような気がします。 少なくとも、自らチャレンジをするような空気感は僕にはなかった。どこでもいいから、そこそこの会社に入社して

あの金額は「採用が確定していない」上に、他社と競いあう分「面接の権利を得るためのチケット」でもあるので、それが高止まりしようがしまいが、書類審査における 「採用可能上限金額」 を示したものとも言える。 候補者が自分の希望年収を入れるかどうかは、ポーカーでオールインを使うか否かみたいな戦略性の問題であるが、金額を入れない場合に「いくらで指名されるのか？」という部分には、多少なりとも、そこに書いてある社名の印象が影響する。会社が著名であるかどうかで絶対値は変わるし、似たようなフェーズの会社が同じような投資フェーズであったり大企業であれば高い金額が入札されやすくなるであろう。 ところが仮に高い金額になった場合、その金額に見合う形で実際に採用するかは面接をしてから決まるわけだから、いわゆる相場感は、「採用されたか否か」のフラグがないと正しい相場は示さない。 まして転職ドラフトは、提示額に対する90

FacebookのタイムラインにUXライターという職種名の話が流れて来ました。 新しい職種としての「UXライター」 ようはテキストライティング重要ですよねという話なのですが、今までのWebデザインの人は、まさかテキストライティングを無視して、ボタンの色とかサイズだけでA/Bテストしてたんですかね？それA/Bテストの意味ない。 とはいえ、テキストライティングとビジュアルデザインの役割がわかれていていじれないという、Dev vs Opsのような組織論的悩みもあったりします。 そんなことを思い出してると、懐かしいことを思い出すわけです。 August 09, 2004 テキストライティングも情報設計のうち。 一般的なワークフローとして、すごく奇妙な役割分担がWeb制作の常識として定着しているような感じがしています。ハナから文章が設計分野に入るのを諦めている、捨てているとでも言いますか。デザイナー

とてもよいサービスでしたが勉強させてもらいました。思わず自分のサーバにインストールしてみようかなと思いましたが、ご飯食べながら考えた結果、現時点の感想は、「素人お断り」というものなんで、あんまり広めたくないな、と。 理由は「リモートフォローされた書き込みの削除ができないから」 「Twitterという慣れ親しんだUI構造をパクった分散ネットワークサービス」としては中途半端過ぎると思います。 twitterもリアルタイムの削除は相当苦労されたと思います。昔の一時期トラブってた頃は、そう簡単にツイートは消えませんでしたからね。ツイ消しなんて通用しなかった時代もありました。ローカルであっても分散DB構造？のデータの削除は大変です（単純に当時は削除キューが詰まってただけかも）。 正常系としてデータを足すのは誰にでもできる。削除や変更をちゃんと考えるところまでがシステムだと思う。 メンヘラツイートが削

いつものごとく，どちらの方の記事だったか失念してしまいましたが，エンジニアの生産性が出来る人とできない人で１０倍違うという言説に対して，コードの生産性やスピードが１０倍あることが重要なんじゃなくて，「問題解決できるかできないか」なんだよ！というお話，その通りだよなぁと思って拝見しておりました． 逆に言えば，無事是名馬でコードを増やすことができたり，サービスを守っていく人材も超重要というわけで，単純に「評価軸が一つではない」ということを示しているのかもしれません．SIerさんが前者が評価されないという言説が本当だったら，解決すべき問題とマッチしてなくて，そういう人材はいらないんですよ． 大きな問題に対する解決力を持っているけど，例えば体が弱くて長時間は働けないエンジニアと，問題解決力にそこまでの瞬発力は持っていないけど，普通に会社で働けるエンジニア．双方が評価され，リスペクトしあえる関係性と

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

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

「きっと何者にもなれない自分というエンジニアとしての生存戦略」 という記事が僕の周りでbuzzってた。読んだ限り、そのままでいいんだよ、と、恐縮ながら声をかけてあげたいと思ったわけですが、３点ばかし思うところがあったので雑で恐縮ですが書いてみます。 １．自分は何をしたいのか？願望を持つ重要性 「きっと何者にもなれないエンジニアの生存戦略」として以下の項目を挙げられていた。 1.有名OSSにContributeする。 2.起業する。 3.CxOとしてJoinする。 4.副業として顧問になる。 5.サービスを立ち上げる。 これのいくつか大部分は、「自分がこうしたい」という強い気持ちが必要なので、それがないなら無理に焦らないほうが良い。 OSSでContributeしてる人に話を聞くと、必要に迫られてやったという話をよく聞きます。つまり、issueがあるかないかで変わってくるでしょう。残念ながら

自分は「評価されていない」「信頼されてない」と思ってしまうケースにおいて、いくつか、「社会人として、うまく生きるためのテクニック」がある。 僕も、過去、この言葉に思いなやなんでいた経験はあるし、今でも人格要素として持っているので、この感覚にある「どうしたら良いか分からない感」は非常によくわかる。 なお、これは誰かからのヒントを元に、別のケースにおいて該当するかもと思ったので、誰に対して言いたいという他意はないので、というエクスキューズを前に置いておきますね。 この記事のきっかけは以下の記事でした。 「知力」は生まれつき備わったものなのか？自信過剰になることで人は成長を止めてしまうことが判明 これの記事に対するGroove X林さんのノートが全公開だったので、大切な部分を参考にさせてもらうと、 ＞「他人との比較」→「劣等感」→「思い込み」→「保守的」 ＞このループに入ると、成長が止まって、時

この話、誰に言っても通じない話なのですが、 かつての名作にストリートファイター２ってゲームありますよね。 僕は、そんなに得意なゲームじゃないんですけど、ゲームセンターの対戦プレイでこれをやると喧嘩になるという戦い方があるそうです。 それが、 「最速の足払いをひたすら使って、相手の大技を封じる」 というものです。スト２が面白いのは、大技は相手に巨大なダメージを与えられますが、技を繰り広げる前に、ちょっとしたダメージしか与えられない小技である足払いを食らうと、大技が出せなくなってしまう作りになっています。 それ故に、ひたすら足払いで防御することで、相手に徐々にダメージを与えていくという技があります。 何せ、技を出そうとすると、足払いで潰されるわけですから、姑息な技とイライラされるので、対戦で足払いで勝つと喧嘩になることもあるそうです。 似たようなことが、僕らの日常のタスクマネジメントにおいても

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

開発内製をしている組織が、業務委託で外部の方の力を借りて開発をお願いするというケースにおいて、発注者側が業務委託で仕事をお願いする時に思ってることを書いてみようと思う。 エンジニアで独立心が高い人であれば、技術顧問だけじゃなくても、部分的な工数を切り売りして複数のプロジェクトに関わりあいたい気持ちもあったりと思うので、そういう人に向けても一助になれば幸いです。 前提条件 ここ背景的な追記事項なんですが、基本的な対象者は、「社員になってもらえたら超ラッキーみたいな人が、すでにフリーランスだったり、自分の会社を持っていて、別の仕事もやっている」という先方都合が上位なケースにおいて、業務委託でのみ契約に至る時に考えたりしたこと、という前提条件を追加しておきます。 ちょっと一般化して書いてみたら、もっと世界が広かったようで、そちらの世界の方で誤解を生んでいるケースもあるように思えました。それは純粋

（言葉遊びみたいな記事を書きますね。その上、用語の使い方が間違ってたらごめんなさい。） 一時期、フルスタックエンジニアって言葉流行りましたよね。ふと、要件どこまでだっけ？と思って調べようと思ったんですが、日本語で調べると、妄想が暴走してロクな話が出てこなそうなので、英語の方で調べてみるとわかりやすい。 What is a Full Stack developer? Server, Network, and Hosting Environment. Data Modeling Business Logic API layer / Action Layer / MVC User Interface User Experience Understanding what the customer and the business need. 個人的には、ネットワーク監視やデプロイなどのインフラ運用

wantedlyで、CTOから新入社員にむけてのメッセージというブログを書いたのですが、 新入社員の転職戦略 by 藤川 真一えふしん | BASE株式会社 内容的には、普通の会社員の生き方の話であって、改めてよくよく考えると「CTOから」と書いてあるのだから、もしかして期待されてることが違うんじゃないかと思ったので、もう少し技術寄りのバージョンをここに書いてみます。 お題は「ソフトウエアエンジニアは時間外に勉強をすべきか？」ということに触れてみたいと思います。 エンジニア採用系の記事が増えたことで、少し過激な表現として「ソフトウエアエンジニアは、時間外に勉強すべき！」という言説がネットで出回っていて、これについて賛否両論あるようなので、議論してみたいと思います。先に書いておくと、この文章、長くなってしまいました。 そして、この記事の結論を先に書くと「他人を出し抜く機会が時間外にこそある」

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

CTOという役割について 〜 IVS CTO Night & Day 2015 Winter powered by AWSに行ってきた。 IVS CTO Night & Day 2015 Winter powered by AWSに行ってきました。 過去３回、全部参加してるんですが、個人的には一番良かった。 イベントクオリティも高かったけど、個人的に壁にぶつかっていたということなのかもしれない。自分の中での疑問や仮説を持った中での他のCTO職、管理職の人たちの意見はビシバシ心に刺さる。そんな３日間でした。 イベントの中でアンカンファレンスというコーナーがあって、そこではいくつかのアジェンダについて数人で議論するのですが、「経営者としてCTOがすべきこと」という議論が非常に面白かった。そもそも「経営チームにおけるCTOの存在意義って何？」という、そもそも論の部分が整理されたのが大きいw 事業