久しぶりに転職をした。 理由は「上司がクソ・年収も上がらない」という至極単純なもの。 自分は人手不足と言われているエンジニア業界でも、人が居ないと嘆かれている言語のエンジニアである。 正直に言って、今までは求人に乗っかればそれなりに内定を取れたので、そんな感じでいくだろうとタカをくくっていた。 ところが、今回の転職はめちゃくちゃ難航した。 受けたカジュアル面談は20社近く。 約半数の選考に進み、スキルチェックで落とされたのが3社、面接で落ちたのが2社、内定獲得したが辞退したところが3社。 打率3割は高いと思うかもしれないが、経験者なら誰でもOKのSESなので自慢にならないんだ。すまんな。 最終的には良さげなところを見つけ転職は幕を閉じたが、かけた期間はおよそ6ヶ月。 それをぼちぼち忙しい業務の合間と土日に行っていたので、もう身も心もすっかり摩耗した。 ようやく落ち着いて新しい環境にも慣れた

プロダクト開発人材の副業転職プラットフォーム Offers を運営する株式会社 overflow VPoE の あほむ でございます。 今回は Offers エンジニアリングチーム[1]においてリーダーやマネージャーといった職務をどのように捉えているかについて紹介させてください。なにかのご縁があって弊社にご興味をもってくださった方のご参考になれば幸いです！ エンジニアリング組織のリーダー、マネージャーの扱い 所属する組織の中で「リーダーシップを発揮してほしい」とか「リーダー経験がないとこれ以上評価できない」とかのコミュニケーションをとった/とられたことがある方も少なくないのではないでしょうか。 こういったコミュニケーションの背景には 「組織としてリーダーシップを発揮できる人材を欲している」 という意図や 「評価上の分かりやすい材料を欲している」 などの事情があると考えられます。 そんなこと

最近デザインエンジニアという職種の知名度が上がってきましたよね。このアドベントカレンダーでも何人かデザインエンジニアについて書いています。 今回は僕が考えるデザインエンジニアに必要なことを5つまとめてみました。他にもみなさんが考えるデザインエンジニア像があればぜひコメントください。 アプリケーションの実装とデザインの知識・経験があること アプリケーションの実装にはWebかモバイルかなどいくつかの方法がありますが、2021年現在日本国内の求人を見るとWebフロントエンドの開発経験が求められることが多いようです。肩書に「エンジニア」とつくことから軸足はエンジニア側にあり、一定以上の開発経験や最新情報についてキャッチアップしていける能力が必要です。 その中でもCSS、アクセシビリティ、ウェブフォントなどの知識があるとより良いと思います。これらはデザインと開発両方の知識が必要になる分野でありユーザ

この記事は Goodpatch Advent Calendar 2021 の12日目です。 今回はFigmaのPluginであるFigma Tokensを使ってみて実感した恩恵や、実際にどのように利用したかを書いていきます。 はじめに フロントエンジニアの責務の一つとしてUI実装（UIの実現）があります。 UI実装はFigmaなどのデザインファイルを設計書として実装していきます。しかしながら、デザイナーも人間なのでデザインファイルにミスがあることもあります。また、デザイナーとエンジニアが並走してプロジェクトを進めていく場合はデザインファイルの変更がたびたび起こることもあり、都度デザイナーとコミュニケーションをとりながらコードを修正しなければなりません。 このような状況を考えると、UI実現の責務をフロントエンドエンジニアだけが受け持つのは荷が重く、クオリティ低下につながる危険性があるのではな

【ゴールデンウィーク営業のお知らせ】 2024年4月27日(土)～2024年5月6日（月）の期間中、GWのため休業とさせていただきます。 ※4月30日（火）、5月1日(水)、2日(木)は通常営業いたします。 ※休業期間中にいただいた審査申請については、結果をお返しするために数営業日いただくことをご了承ください。 「エンジニアリング・マネージャー（以下、EM）が自分に務まるだろうか」 「専門性を尖らせていくか、マネジメント能力を磨くか迷っている」 誰もが悩む将来のキャリア。大切な選択だからこそ、その仕事についてしっかりと把握した上で、希望する道を歩みたいですよね。 しかし、EMなどマネジメント職の実態は、なかなか語られる機会がありません。 そこで今回は、EMを経てVPoE（Vice President of Engineering）補佐として活躍する中西さんと、2020年からEMを務めている

メリークリスマス！heyでCTOをやっている藤村です。ということで、これからエンジニアになる・いまエンジニアをしているみなさんに個人的に読んでほしい本をご紹介します。これを読んでおけばソフトウェア・エンジニアとして網羅的な基礎が身につく、とかいうセレクトではなく、あくまで個人的に読んでもらえると嬉しいな！というものを選びました。 ソフトウェア開発基礎編リー・コープランド『はじめて学ぶソフトウェアのテスト技法 』 テストの本です。昨今RSpec、XUnit系など自動テストのツールはすっかり普及し、ソフトウェアにテストコードをつけるのは当たり前の世の中になりました。しかし！テストケースをどう設計するか、何をテストすべきか、について体系的に学んだことがない、という方も実はいらっしゃるのでは。 この本はそういったソフトウェア・テスト一般についての教科書です。ここの知識はソフトウェア・エンジニアとし

古川です。本籍の会社ではシニアソフトウェアエンジニアとグループマネージャの兼任、ニジボックスではデベロップメント室というところの室長をやっています。 今日は宣伝に近いのですが、以下のようなイベントをやるので、その触りとしてどういう話をしたいかをここに書こうと思っています。 ビジネス&クリエイティブ 持続的な組織の成長とは？ チーム構築とビジネスグロースの両立を考える シニアソフトウェアエンジニア その名の通りエンジニアの中でシニアロールです。以下のようなことをやっています。 便利ライブラリ作り 設計の技術的な相談に乗る エンジニアコミュニティを社内に立ち上げて勉強会開く グループマネージャ マネージャの中でも私のやっていることはいわゆるエンジニアリングマネージャです。エキスパートなメンバーが多いので、彼らメンバーのキャリアの相談に乗ったり、誰と誰を組ませてお互いを成長させるか考えたりしてい

最初にお断りしておくと、このエントリは驚くほど僕固有の私的な話に終止するので、他の人の参考にはならないでしょう。 ICというのはIndividual Contributorの略で、最近だとHashiCorp創業者のあのMitchell Hashimoto氏が、HashiCorp社内でICになるというのも話題になりました。日本でも、こにふぁーさんがそういう動きをしていたりして、ちょいちょい聞くようになってきた印象です。 今回の僕の転職は、言ってしまえば、自分が培ってきたソフトウェアエンジニアとしてのスキルを活かして世界の舞台で戦いたいという気持ちを抑えきれなかった、という幼稚な理由です。自分が求めているものがLaunchableにはあるように感じて入社しました。 振り返ってみると、最近の自分の転職における決め手は「自分を一番必要としてくれるところ」という側面が強かったと感じています。その結果

新浪剛史サントリーホールディングス社長による「45歳定年」が話題です。下記ニュースがよく纏まっていますが人材流動化、終身雇用・年功序列・退職金制度の見直し、解雇規制の緩和ムード醸成など様々な解釈が溢れています。 個人の見解としてはキャリアの多様性はあるべきですし、IT界隈を見る限り大学は専門性を身につけるというより教養を身につけるのが日本の大学であるため、入社後に0スタートで教育し育てていく（TwitterではJTC - Japan Traditional Companyなどと呼ばれている）往年の日本企業の労働スタイルにははっきりとした必要性があると感じています。そのメリットを活かしながら生き残って頂きたいと考えていますが、どうも総合職の終身雇用まで踏まえると事情は違うようです。 一方、ITエンジニアはどうなるかというと全く事情は異なってきています。今回はITエンジニア界隈における45歳定

@sunaot です。前に一緒に働いていた同僚からこんな質問が来ました。 組織が肥大化しすぎてアレコレうまく行かない事が増えてきたので『ユニコーン企業のひみつ』を読みました。 他にも他社の事例とかも見ていたりするのですが組織の布陣とか参考になるおすすめの書籍などありますか？ 今はマネージャーをやっていて組織の設計に困っているようです。回答をするために考えてみたのですが、開発組織の組織デザインをピンポイントで語った本というのがありません。『ユニコーン企業のひみつ』は Web のサービス会社のチーム開発について語った良い本なのですが、組織論ではないためほしいところとやや違ってきそうです*1。 そこで、同じような悩みを抱えている人に向けてサービス会社の開発組織の組織デザインについて、実際に6年以上試行錯誤してきた立場から考えるべき観点というのをまとめてみようと思います。 結論から言ってしまうと、

こんにちは。ソウゾウの Software Engineer / Engineering Manager の@motokieeです。連載：「メルカリShops」プレオープンまでの開発の裏側の4日目を担当します。 4日目は、ソウゾウがどのような体制でメルカリShopsを開発しているかについて、Team Topologiesの解説を交えてお送りします。 はじめに チームの在り方には様々な形がありたくさんの議論が交わされていると思います。自分自身も以前いた会社はもちろん、メルカリに入ってからも旧ソウゾウ、JP(日本事業)、メルペイとの関わり合いなど様々なチーム構成を見てきました。 タイトルにあるTeam Topologiesですが、https://teamtopologies.com/ では以下のように定義されています。 ​​Team Topologies is the leading appro

どこへ行ったんでしょう？。2019年までは「経験社数は3社まで」「年齢は35歳まで」と経営層が注文をつけても何とかなりましたが今は昔。面談手法とか役に立たないほど母集団形成ができない現状についてです。 各人材紹介、媒体、各社エンジニア採用担当のみなさんと情報交換する中で見えてきた中堅エンジニアの行先についてお話します。 30代中堅ITエンジニアは観測範囲では ・コンサルになった ・ユニコーン、GAFAに吸われた ・シード期のスタートアップでメンバーになった ・フリーランスになった という具合。 その他目撃情報求む。 — 久松剛 (@makaibito) June 24, 2021 ・30代中盤まで ・3社以下経験 という採用フィルターについては個人的に 「昔厳守する企業ありましたね」 「懐かしいですね」 と秒で切って捨てるレベルになってる。 — 久松剛 (@makaibito) July

執行役員 VP of Engineering 兼技術部長の @hsbt です。PS4 の Ghost of Tsushima が面白くて、毎日仕事が終わると対馬にいく毎日です。 2020年7月より、GMOペパボ(以下、ペパボ)では、パートナー(GMOインターネットグループでの従業員の呼称)全員の評価の制度と報酬をアップデートしました。エンジニアについても同様に従来の制度をベースにしながらアップデートを行っています。ペパボのエンジニア職位制度は2015年に導入した制度をベースとしながら2020 年までの 5 年間に主に以下に示すアップデートを行いました。 シニア(以上の)エンジニアの評価基準の細分化(例: 4.1等級-4.4等級など) シニア以上の報酬の大幅な増額 エンジニアリングマネージャ(テクニカルリード、チーフテクニカルリード)の導入 先日、エンジニアの評価について、ベースとなる制度へ

こんにちは、デザイナーの佐野大河 @sn_taiga です。今日はエンジニアといい感じに連携したいデザイナーの取り組みについて話します。 社内でC2Cというデザイナー同士で学びを共有し合う場があり、そこで話した内容を社外向けにまとめました。 👉 C2Cについて詳しく書かれている記事はこちら チームのエンジニアにヒアリングしてみた画面を設計するときや仕様を詰めるとき、伝えるとき、動作検証をするときなどなど、日々デザイン業務に取り組む上でエンジニアとコミュニケーションを取るシーンは多いと思います。 そんな中自分が「エンジニアが開発しやすいように」よかれと思ってやっていることを付箋に書き出し、チームのエンジニアにヒアリングをしてみました。 良いと思った付箋に印を付けてもらい、その理由等を聞きました💬 「エンジニアが開発しやすいように」というテーマで書き出してみたものの、むしろデザイナーがエン

Original：I think I might be a design engineer…（2021-02-17）by Trys Mudford この記事はデザインエンジニアリングについてのシリーズの一部です。Web開発者の役割の変化やデザインとエンジニアリングの違いについて議論していきたいと思います。長くなりそうだったので、この記事を補足するために Prototyping、Systemised design foundationsとThe designer & developer relationshipに記事を分けました。それでは始めましょう。 数年前から、自分がWeb開発のどの領域に当てはまるのか考えてきました。自分のキャリアを振り返れば、ある種の仕事に収束しているのを感じていましたが、それが何という名前なのか、今までは分かりませんでした。 Web開発者はWebサイトを構築するのか

(Show Noteは後日更新します)

これは何 私が所属している株式会社エイチームでは社内勉強会を自由に開ける制度があります。 エンジニア向けにデザインの基礎をレクチャーする会を開いたのですがせっかくだったらオープンにしようと思い、投稿しました。 今回の勉強会では「Webサービスを作る」レベルまでは踏み込めませんでしたが、ちょっとしたUIを作る際の手助けにはなれる気がしています。 なお、勉強会用に書いた原稿なので書き言葉としてあまり適切でない箇所もあります。 ご了承ください。 また、この研修の次の年に行った研修も記事として投稿しています。 設計の話 はじめに：デザイン業務の内訳とよくある誤解 デザイン業務の内訳 まず最初に設計の考え方をレクチャーするのですが、その前に1つ。 普段デザイナーが行っている業務について簡単に説明します。 後の方で話す内容と繋がってくるので、ちょっと本筋から外れますが聞いてください。 話を分かりやすく

本記事は、Engineering Manager Advent Calenderの１日目です。 はじめに エンジニアリングマネージャ(EM)と呼ばれる職務を設置する企業が増えてきました。 私たちの主催したイベントEOF2019でも700名近い方に参加していだき、また多くの方にご協力いただき成功裏に終わることができました。 EM Meetup/EM.FMなどのムーブメントの中心の一翼を担わせていただき、その高まりを感じる一方で不安も感じます。このエンジニアリングマネージャという職務は非常に多岐にわたるケースが存在していますし、必要だとされるスキルもまちまちです。そして、多くの場合、その企業のステージや状況ごとに求めるものは違います。また、求めていることを明文化することすらされていないケースも存在します。 このことから、エンジニアリングマネージメント自体が一時的な潮流として消費され、消えていっ

こちらが伝えた内容から不要なことを邪推しないというか、文字通りに「真っ直ぐ」である人は、望ましい行動に最短経路で向かっていくので効率的な行動を選択していくな、と感じます。「なにかわからないことがあったら、すぐに質問してくださいね」と言われたときに、実際にすぐに質問できる人はどんどん前に進んでいきます。余計なことを考えない分、リソース効率がよいのでしょう。 ぼく個人は、人間はもともと素直な生き物なんじゃないかと思っています。それが、イヤな体験を重ねるたびに少しずつ防衛的になって、だんだんと素直さに蓋をしてしまうケースがあるイメージです。「それくらい自分で調べろ、いちいち質問するな」と怒鳴られるようなことがあったら「すぐに質問してね」と言われてもなかなか実行に移せなくなりそうですよね。そういう人は「自分は、そういう状況である」というのを自覚することから始めるとよいでしょう。「質問してよかった」