クックパッドを退職しました - 昼メシ物語
2024年1月末まで在籍していますが昨年12月に業務は終えていて、いまは有休消化期間中です。2010年から約14年間勤めてきた、自分の生き様そのものとも言えるクックパッドを離れるのには、表現しきれないほど大きく、複雑な思いがあります。 僕がこの14年間でやってきたことを振り返ってみます。 入社 クックパッドに入社した時は新卒3年目相当で、26歳でした。もともと料理と Ruby が好きで、当時まだ珍しかった Ruby on Rails でサービス開発をしているらしいという点や、当時からネットウォッチしていた @ryo_katsuma さんが所属していること、直属の上司の井原さんが転職したことが決め手になり、体当たりで飛び込みました。当時の僕はほとんど実績もなく、入れてもらえるかギリギリのところだったと思いますが、おそらく井原さんが頑張って交渉してくれたのだと思います。本当に感謝しています。こ
ITエンジニアの習性『もらった服を親だと思って着まくる』を踏まえるとTシャツ配るのが一番の広告「これが欲しい」
Tシャツの競合は多いので、今はどのような服が求められているのか？愛用してるやつはどこが気に入ったのか？についても整理しました。
意識的に職位を下げる - id:onk のはてなブログ
僕はチーム join 時に、Docker は初手で剥がすし、GitHub Actions でやっているワークフローの全体像を把握するのを次に行う、というのを基本的にはやっている。これはシステム構成やデプロイ周りの全貌を把握するのが好きなのと、何かが起きたときにコレをやっているのといないのとで問題切り分けの精度に圧倒的な差があるからなんだけど、join 直後にやるのが最適解とは限らない場面もある。 チームの人員構成として、テックリード業を既に担っている人が居る場合、追加人員にはテックリード未満の「プラスの工数として数えられる戦力」となって欲しい。この戦力というのは、「目の前に積み上がった問題を一緒に解いて欲しい」という期待。問題と言うよりも、既にタスクになっているものを消化したい、という期待の方が大きいと思う。 そういう期待があるときには、ちんたら Docker を剥がしている場合ではなく、
技術を極める以外に何ができるのか？ カオスな環境へ飛び込んだITエンジニアのキャリアの分岐点 - Findy Engineer Lab
はじめまして。並河祐貴（@namikawa）と申します。Webテクノロジーが大好きなエンジニアなので、若い頃は技術系の書籍や雑誌記事を書く機会をたくさんいただきました。今回は自分のキャリアの話を書かせていただくということで、ずいぶんと歳を取ってきたのだなと感じています。 思い返せば、20代の頃はWebテクノロジーに強い興味を持ち、サービス開発の現場でエンジニアリングを極めたいと考えていました。そんな自分が15年ほどたった今では、まさか経営・マネジメントに近いポジションで働いているなど、1ミリも想像していませんでした。ことに最近では「自分の経験のホワイトスペース」を埋めるべく、いろいろなことに挑戦しようとしています。 これまで紆余曲折あり、決してきれいなキャリアを歩んできたわけではありません。何を考えて今のキャリアが形成されてきたのか、これからをどのように考えているのか、これまでを振り返りな
エンジニアとしてなりたい姿へ変化し続けるために ─ 多様なキャリアに挑み続けて見えたこと伝えたいこと - Findy Engineer Lab
読者の皆さんこんにちは。はじめましての方ははじめまして。合同会社もりたつ技商 代表社員、内閣官房IT総合戦略室 政府CIO補佐官、さらに株式会社Diarkis 取締役をしている久森達郎（@myfinder、まいんだー）と申します。 本記事では私の経歴を現在に至るまで、どのような技術的チャレンジをしてきたかアウトプットとともに振り返りながら、そこにある転機や挑戦についてお話ししていきたいと思います。冒頭でいきなり肩書きが3つも出てきたので混乱した方もいらっしゃるかと思いますが、それぞれの詳細は追って紹介します。 私が経験した事業領域も規模も異なる企業でのキャリアは、自分が望む方向に変化しようと挑戦してきた結果でもあります。本記事があなたにとって、多様なキャリアのあり方を知ることと、それを支えるマインドセットの獲得に多少なりとも有益な貢献ができれば幸いです。 プロの現場が知りたくてエンジニアの
エンジニアのキャリアについて【SmartHRの場合】 - SmartHR Tech Blog
こんにちは！ エンジニアマネージャーの森住（@t_morizumi）です。 現在 SmartHR は saiyo-tasukete プロジェクトの名の下、エンジニアの採用ブランディングと再び向き合っている真っ只中にあります。 「普段取り組んでいることをきちんとテックブログで発信する」という、ぐうの音も出ないほど当たり前のことが大切であることに CTO が気づいてしまったため、僕もこうして筆を取っている次第です。 さて、今回はエンジニアのキャリアについてということで、SmartHR がエンジニアのキャリアアップにどのように取り組んでいるのかをご紹介したいと思います。 SmartHR のエンジニア組織について まずは大前提として、SmartHR のエンジニア組織は以下のような構造になっています。 （※ 組織構造の概略をお伝えすることが目的のため簡略化しています） CTO がマネージャーを支え、
コードが読めるソフトウェア開発者 - As a Futurist...
僕はコードを読むのは得意な方だけど、それが過ぎてコードを書かなくてもシニアソフトウェア開発者になってしまった。実はコードをちゃんと読めるソフトウェア開発者って希少価値が高いのではないか、と思ったので自分がどんな感じでシニアになったのかをまとめてみた。似た様な人の参考になれば幸いだ。 同意。僕は未だ書く方はほとんど機会なく成果もないけど、コードを読み尽くして、負荷試験や本番で挙動を把握し続け、メトリクスでとことん確かめていった結果、Sr. Engineer になれた。 https://t.co/KXtMdEaRr8 — Ryosuke Iwanaga (@riywo) April 16, 2021 コードを書かなくてもシニアソフトウェア開発者になれた 僕は今 Amazon の Sr. Systems Development Engineer という職種で働いている。いわゆるソフトウェア開発職
優秀さについて
Twitter で医師を拾ってきて Google のソフトウェアエンジニアにするだけの簡単なお仕事 - 白のカピバラの逆極限 S.144-3 はじめに 「【転職エントリ】Googleに入社します｜Lillian｜note」という、医師から未経験で Google のソフトウェアエンジニアになった記事があります。 note.com 私は、この記事に出てくる「とある元 Google のソフトウェアエンジニア」で、面接の対策を立てました。 記事が出た当初から大反響で、私もそれなりの反応を見まして、いろいろと誤解されているなあ、と思う一方、アドバイザーはあくまでもアドバイザーだから、アドバイザーとして知りえた情報については、口をつぐむべきだと思っていました。 ただ、あまりにも誤解されており、悪影響が大きく、犠牲者も多くなってきたと思ったので、… 同僚からこれについてどう思うか、と聞かれた。元の文章が
自走できるエンジニアとは
ソフトウェアエンジニアリング界隈の言葉はとても曖昧な言葉に満ち溢れています。「自走」という言葉もそうです。でも、そういう曖昧な言葉の方が使い勝手が良いため、たとえば、ツイッターランドにはそういう曖昧な言葉がバズりまくったり、日々流れてきたりします。そうじゃなくても、「うちの職場のエンジニアには自走力が求められるんだよね」とか「転職するためには自走できる力が大切だ」みたいな言い方、度々聞いたり、むしろ話したりしていませんか？ この記事では「自走できるエンジニア」について自分なりの考えをまとめてみたいと思います。もちろんこれはあまたある解釈の中でも、僕が解釈したものに過ぎません。そういう意味ではさらに「自走」という単語を持ち出して世に混乱を投げつけるだけかもしれません。僕のただのポジショントークかもしれません。 それでよければ、「自分は自走できているのだろうか？」「自分は、うまく部下や同僚を自
優秀な技術者を追い出してしまう方法 - Qiita
若手エンジニアを不幸にしないための開発の「べからず」集 組織運営編から記事を独立させました。 優秀な技術者ほど辞めてしまいやすいのは、多くの会社に共通していることです。 この文章では、どうして優秀な技術者が辞めていってしまうのか、その理由を探るとともに、そうならないようにするための対処方法を少しずつ書き足していきたいと思っています。 マネジャーのみなさんへの前書き 会社の資産であるソースコードはきちんと管理されてますか？ 「きちんと金庫にしまってある」ではありません。 開発が進みやすく、今のソースコードはどのように品質が保たれているのかがわかるようになって 管理されてますか。 ソフトウェアの開発などで生じている課題は、どのように管理されていますか。 「去年の△月ごろに問題になっていたあの件は、結局どうなったのかい。」 「担当していた○○さんがだったら知っているんですけれども、もうやめちゃい
突然のエンジニアリングマネージャー転身。イチ技術者がGMOペパボ・取締役CTOに就くまでに学んだこと - Findy Engineer Lab
マネジメント職に就くまで マネジメント職に就いてから 最初に取り組んだマネジメント施策 エンジニア評価制度の制定 全社規模の技術投資計画の策定 計画を実行する組織の新設 「選択」後に感じたギャップ 抽象的な理解のギャップ やりたいこととスキルのギャップ ギャップにどう処したのか マネジメント職の「選択」に必要となるスキルとは おわりに ─ 「やらない」という選択肢はなかった こんにちは、栗林健太郎です。人々からは「あんちぽくん」と呼ばれています。皆様も是非、そのようにお声がけくださると幸いです。 わたくしは現在、GMOペパボ株式会社（以下、GMOペパボ）で取締役CTOを務めています。会社全体としてこれから実現するべきビジョンや方向性を示し、その実行を中心的に担うエンジニアリングおよびデザイン組織を管掌しています。また、セキュリティ事業や鹿児島拠点の立ち上げなど、新しい取り組みを行うチームを
デブサミ2020「エンジニアと人事がともに考えるエンジニア採用」講演メモ #devsumi - 元RX-7乗りの適当な日々
登壇された方 【モデレーター】金山 貴泰 氏 うるる 転職透明化らぼ コアスタッフ てぃーびー（田部井 勝彦） 氏 スタディスト Recruit Operations 伊藤 哲弥 氏 LAPRAS 事業開発マネージャー / PR 安立 沙耶佳 氏 ヌーラボ 人事 a.k.a アンジェラ 梶原 成親 氏 ヤプリ 市場背景について（伊藤さん） エンジニア側から見た採用市場 超売り手市場 技術系（IT・通信）の求人倍率、昨年8月には11倍に。 11社が1人を奪い合う状況。他職種と比べて異常事態。 今後十数年は変わらない IT人材需給 2018年は22万人不足 2030年は45万人が不足すると言われている エンジニアの質 課題解決型から価値創造型へ 先端技術（クラウド、IoT、AI等）の活用ができるエンジニアのニーズ高 一極集中の構図 満遍なくスカウトがいっているわけではなく、一部に集中している
デブサミ2020「なぜ技術力評価会の評価者はペアなのか？ー 8年半で378組の評価者ペアが835回評価した事例からみるペアの効果」講演メモ #devsumi - 元RX-7乗りの適当な日々
登壇された方 小賀 昌法 氏 VOYAGE GROUP 取締役CTO (2010〜) 日本CTO協会 理事 技術力評価会 2011年まで上長だけが評価する制度だった 技術力評価・事業貢献 現在は「ともにつくる」評価制度 色々な人が色々な他の部署の人たちを評価する風に変えていった 毎回、評価する対象者を変えていく エンジニアの技術力評価 難しいと思いますか？ 何が原因なのでしょうか？ 原因1: バイアス エンジニアに限らず、一般的にバイアスが働く ハロー効果 論理的誤差 寛大化効果 対比誤差 中心化傾向 対人関係を気にして、みんな無難に評価してしまおうとすること イメージ考課 極端化傾向 原因2: 技術の多様化 技術が多様化しており、技術マネージャーは全ての技術においてメンバーより詳しいわけではない フロントエンド、クラウド、データサイエンス、プライバシー・・・等々 原因3: 評価スキル向上
ソフトウェアエンジニアとして家を建てる仕事をはじめました
まさかソフトウェアエンジニアの自分が本業で家を建てる仕事をするとは思っても見ませんでした。２年前、DeployGateの米国オフィスを自分で施工した事をきっかけに声をかけてもらい、以来、技術アドバイザーとして携わらせて頂いていた米国の建築スタートアップ「HOMMA」に本格的に参加し、ソフトウェア・アーキテクトとしてアメリカでスマートハウスをソフトウェア面から設計して家を建てる仕事をはじめました。趣味の電子工作から初まり、深センでの独自設計ハードの少量生産、アメリカでのオフィスの施工と来て、次はまさかの本物の建売住宅の開発です。プログラミングの傍ら取り組んできた物理的な「ものづくり」のサイズがどんどん大きくなってきて楽しい限りです。制御用のファームウェアやアプリ、Webシステムを書きながら、ヘルメットを被って建設現場で大工職人さんへ施工の指示出しをしたり、信号線や電力系統の配線を設計して建築
CTOの頭の中：技術を財務で表現する｜Shin Takeuchi｜note
会社の体制が大きく変わり、カオスの中に少しの静寂（暇）ができました。特に日々執行に勤しんでいる方々は皆そうだと思いますが、色んなこと考えているのにそのプロセスをアウトプットする機会があまりなく、結果や結論、最終的な決断のみが共有されるため、サクセッションプランに対する有効な情報を残すことも出来ていないことと思います。僕もその一人。 この時間を有効に活用するため、頭の中にあるイメージと考え方をここに、時間の許す限り吐き出していこうと思います。時折、言葉が足りないところも前提条件やバイアスの記述が足りないところもあるかと思いますが、混沌とした頭の中を曝け出すプロセスにはつきものですので、大目に見ながら読んでいただけると幸いです。 財務諸表と同じように見える化する会社は財務諸表によって経営されるものなので、経営者たるもの財務諸表を見ながら戦略を立てるべきであると僕は考えています。数字以外信じない
技術的負債の上手な積み上げ方・返し方
2019年6月20日、TECH PLAY SHIBUYAにて「CTOが考える、チームで向き合う技術的負債との付き合い方」が開催されました。メドピア・SansanのCTOが、自社における技術的負債といかにして向き合ってきたか、その経緯と取り組みを語りました。（※当初登壇予定だったアイスタイルCTO竹澤氏は体調不良により欠席）。公開Q&Aには、メドピア株式会社執行役員のCTO福村彰展氏と、Sansan株式会社CTOの藤倉成太氏が登場。会場からの質問に回答します。 技術的負債を返す重要性をどう説明するか 司会者：お待たせしました。Q＆Aなんですけど、最初に、みなさん申し込みいただいたときに質問をいくつかいただいていたと思うので、そのなかで質問が多かったものを私のほうで5つぐらい取り上げさせていただいております。そのあと、会場のみなさんから質問を募集して、ディスカッションのようなかたちで進められれ
index の複数形は indexes なのか indices なのか - 猫でもわかるWebプログラミングと副業
プログラマーが覚えておきたい英単語(http://blog.livedoor.jp/lalha/archives/50165797.html)によると インデックスを表す単語の index の複数形についての表現。普通に複数形にすると indexes になりそうなものだが、公開されている API などを見ていると、indices が使われていることが多い。英英辞典などを見ると、indexes も indices も載っているので、両方とも間違いではないと思われる。 とある。 一方で、『SQLアンチパターン』では、 データベース関連の用語として用いられる場合、indexは順番に並べられた情報の集合を意味します。この場合のindexの望ましい複数形はindexesです。他の文脈では、indexはindicatorを意味することがあり、この場合の複数形はindicesです。 とある。 Webli
Google ソフトウェアエンジニアの給料の正しい情報
私は Google のソフトウェアエンジニアとして働いている。とても良い待遇で満足している。 Google の待遇が良いことはイメージとしては知られていると思うが、実際どれくらいの額なのかということはあまり知られていないように思う。そして、出回っている情報には間違っているものも多い。そこで、正しい情報を知ってもらいたいと思い、自分の給料の推移をここに記すことにした。なぜそのようなことをするかは後に述べる。 まず、Google の給料について説明するときは、以下の三要素が重要になる。「基本給」「ボーナス」「RSU」である。このうち、基本給とボーナスは一般的だが、RSU はそうではないので、説明する。例えば RSU を100万円受け取るとする。そうすると、「その時点での100万円分の Google 株を、その次の年から四年間かけて受け取る権利（ただし Google に在籍していることが条件）」
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
起業家的？！エンジニアのススメ | Developer Summit 2020
インフラエンジニアって人気ないの？