2023/6/16付の人事異動で正式にエンジニアリングマネージャー（以下EM）になりました。2021/8に「エンジニアリングマネージャーを目指す若者の戦略」という記事を書いて明確にEMを目指し始め、2022/12には「EMキャリアを切り拓く「最強の現場リーダー」という働き方」という記事でEMに近づく様子を書きました。さらにそこから半年余り、ついに会社からも正式にEMと呼ばれることになりました。実際には3ヶ月ほど前から強くEMを志向した動きにはなっていましたが、やはり正式な職位は特別なもので、キャリアにおける重要な実績をひとつ解除したと感じています。 これほどEMというロールを志向し色々とやってきたのですから、EMとしての振る舞いもさぞスムーズに立ち上がるかと思いきや、実際にEMとして動くのは非常に難しいことでした。書籍やブログ記事を読んで頭で理解したEMという働き方と、自分がチームでEMと

この記事は、Engineering Manager Advent Calendar 2020の23日目の記事す。 組織は個人で成り立っている これまで様々なチームや組織を見てきて、一つたどり着いた結論として、個人を無視してチームや組織を成り立たせることは不可能だということだ。 一人ひとり様々な事情を抱えてそのチームや組織に参画している。 そのプロダクトが好きで本気で良くしたいと思っている人もいれば、技術力を高めたいと思ってそのチームでの開発を足がかりにしている人もいれば、お金をもらっているので何でもやりますという人もいる。 チームに色々な人がいるのは当然なことで、目的が何であれ、何かしらの縁があってそのチームに参画している。 個人の事情を全く考えずに、チームや組織という単位で常に意思決定しているようであれば、もしかしたらものごとを単純化しすぎてしまっているかもしれない。 個人のキャリアに寄

【ハンズオン】RemixでTODOアプリを作ってReactの違いを体感しよう【TypeScript/Supabase/TailwindCSS】TypeScriptハンズオンRemixtailwindcssSupabase はじめに Reactを使っていてステートがクライアントとサーバーで辻褄が合わなくなった そんな経験がReactをある程度使ったことがある人はおそらく経験したことがあるはずです。 Reactにおいて状態管理は誰でも使いやすく直感的である半面、クライアントとサーバーの状態を意識する必要が有ります。 どのタイミングでステートの変更をサーバーでも行うのか難しく思う場面もしばしばあります。 今回は最近巷でReactと並んで見かけるようになったRemixについてハンズオン形式で学べるような記事を書いていきます。 ハンズオンを通してRemixの特徴であったり、SupabaseやTail

こんにちは @glassmonekeyです。 Ubie 株式会社に転職してあっという間に二ヶ月が立ちました。 現在私は toC 向けのアプリケーションに配信する施策を入稿・管理するシステム「案件管理システム」の開発チームに所属しています。 そのチーム内で現在、私はテックリードというロールで、日々の開発を一人のエンジニアとして進めつつもチームの生産性改善、技術的な意思決定のファシリテーションなどに取り組んでいます。 今回のエントリでは、何かと話題となるエンジニアリングの生産性ですが、テックリードとしてどのように向き合ったのか、どのように改善し今後どうしていくのか？を紹介します。 生産性の定義 前提として生産性を正しく計測することは難しく、それこそ生産性を下げる行為だと私は考えています。 @hiroki_daichiさんの開発生産性について議論する前に知っておきたいことに詳細は譲るとして、一般

先日「育児など家庭の色々があって自分の時間が確保できなくなった。技術力を高めるための勉強ができなくて不安。」みたいな話を聞いた この悩みの直接的な解決方法としては先人の様々な体験談および対策みたいなものが世に出回っているからご家庭の状況に応じて参照すればいい思う 子育てと開発を両立するコツは「無理をしないこと」。パパ／ママエンジニアの働き方とは 子育てを支える技術 ─ フルスタックお父さんとエンジニアとしての成長を両立させるには ITエンジニアと子育てと勉強と それよりも「技術力を高めるための勉強ができなくて不安」という点が個人的には気になった 技術力とは何か？技術力が高くないとなぜ不安なのか？みたいな話 技術力は特に明確な定義があるわけではない 例えば著名なOSSにコミットしているとか低レイヤーのプロトコルやインフラをバリバリ実装してるとか競プロで上位勢だとか、挙げ始めたらキリがなく、そ

メルカリでやっていたこと 自分がメルカリに入社したのは2017年12月で、SET(Software Engineer in Test)というポジションに応募して採用されました。 SETはその名の通りテストに対する課題を解決するための役割なのですが、当時のSETチームはテストの実装を行うわけではなく、開発環境や検証環境の運用やCI/CDツールの導入・サポートなどを主な役割としていました。 自分がSETとして応募したのは、前職までの経験で機能開発にやや飽きており、エンジニアとして品質の改善をテーマとして扱っていきたいと考えていたためでした。通常の機能開発ではプロジェクトの要件や期日に沿って開発することが求められますが、SETの業務には要件や期日はなく、何をいつどのように解決するかを自分で判断する必要がありました。チームメンバーやプロジェクトメンバーと話し合い、コードを見ながら現在の開発・運用状

8月1日に株式会社diniiに入社していました。前回の投稿 ののち、5月頃から就職活動を始めており、多くの会社の方やエージェントの方に面談の機会を作っていただきました。最終的にdiniiに入社することを決めましたが、自分の体がたくさんあれば入社したいと思う会社も多く、とても悩みながら決断しました。お時間を取っていただいたのに辞退した会社の方にはとても申し訳ないですが、自分のエンジニア人生の中で何かまたご縁があればと思っています。 就職活動について 今回の就職活動では、LinkedIn, Findy, Wantedly, リクルートダイレクトスカウトを主に利用していました。以前の転職活動では元々関心のあった企業の中からすぐに選考に進んでいたのですが、今回は幅広く企業の情報を集めた上で選考に進む企業を選んでいきたいと思っていたため、少しでも気になる企業や案件があれば積極的に面談を依頼していまし

Vue Fes Japan 2023のスポンサーセッションにて、クラウドサイン エンジニアの篠田が登壇した際の資料です。 イベントURL：https://vuefes.jp/2023/sponsor-sessions/cloudsign ■ セッション内で紹介されていた資料のご紹介 ・プラットフォームチームの設立について 『組織・プロセス・技術 - フロントエンドの生産性向上への複眼的アプローチ』 https://speakerdeck.com/bengo4com/20230921 ・バージョンアップの対応を小さく始めた取り組み 『CloudSign の社内用管理画面を Vue2.7 に移行した話』 https://creators.bengo4.com/entry/2023/03/27/083000 ■ クラウドサインプロダクト組織について https://www.cloudsign.j

600ページ以上あり結構長いので方針としては第１部だけは一通り読んでみて、その先は各章結論から読んでいき、気になった部分だけ遡って拾い読みしていく戦略でいく方が良さそう。

みなさん、こんにちは！PMのBNBN（ぶんぶん）です。自分は2人子どもがいるのですが、この前初めてパパ友とLINE交換して一緒に遊びました。公園で虫取りに出掛けたのですが、子ども達よりパパ達の方が楽しんでいて、最後は子どものことを忘れてセミ取りしてました。 さて、そんな夏真っ盛りの7月12日にリリースしたメンバーシップサービス「B/43プラス」を出すまでに、どんな風に「コアユーザーが本当に欲しかったもの」を探したかを書いてみます。 この記事の想定読者 新機能開発に携わるPM、エンジニア、リサーチャー ユーザーが本当に欲しかったものを探すことが多いPM、リサーチャー 「良いユーザー体験」と「収益化」の狭間で苦悩するPM B/43とは・B/43プラスとは B/43（ビー ヨンサン）は、使いすぎが防げるチャージ式のVisaプリペイドカードと、残高と支出がひと目でわかるアプリがセットになったサービ

勉強できない人は他の仕事やれって言ってるけど、こいつら無意識に他の職業の人は勉強してないと見下してるんやろうな。 本当に視野が狭いと思う。 コイツラはプログラミングやらなんやらの知識を身につけることしか勉強と考えてない (あえて技術とは言わない)。 勉強だって色々なものがあるわ。 英語や資格の勉強はもちろん勉強だし、経理であれば会計分野の法律改正、医療であれば新しい治療•診断•薬剤、接客業やコールセンターであれば新商品の知識。 企画やマーケティングであればここ数年サブスクビジネスの書籍読んでる人も多いだろうし、自己啓発で本読んでるのだってそれも勉強。 業界の法律やルールなんかも勉強してる人は多いやろ。 勉強会だって社内や業界でやってる。 そして新しい機器、システム、オペレーションなんかはどんな職種でもある。 こういうのはさ、ITエンジニアが「我々は勉強してるんだ！」なんて主張する以前に他の

はじめに エンジニアとして成長し、「つよつよエンジニア」と呼ばれて周囲から評価されるエンジニアになりたいという若手エンジニアや学生の方は多くいると思います。 私は今までで数百人以上のエンジニアと一緒に仕事をしており、その中にはベンチャーや上場企業でCTO/VPoT/テックリードといった役職についている「つよつよエンジニア」も多くいます。 (かくいう私も組織マネジメント力よりは技術力を評価されてCTOをしていますし、今もコードを書いています)。 「つよつよエンジニアになるためにはどのようなアクションをとればいいか」という視点で述べられていることは多くても「成果物にどのような特徴があるのか」という観点で述べられていることはあまり無い印象です。 成果物の特徴さえわかれば、まだ自身がそのレベルまで到達できていなくても、成果物のレベルを引き上げることができます。 （世阿弥の「風姿花伝」でも「真似る」

国税庁「会社標本調査（2019年度）」によると、日本国内の法人の数は約275万社あるとされています。この統計から単純計算すると、日本には約275万人の「社長」がいることになります。 さらに「経営者」となると「企業の経営方針や経営計画を立案・決定し、経営に関するすべての責任を持つ人の総称」となって対象が拡がります。ザックリ500-1000万人くらいの規模感になるのではないでしょうか。 これを正とするなら、15歳以上の就業者と完全失業者を合わせた日本の労働力人口は2022年で 6902万人（総務省）なので、全労働者に対して7-14%くらいの数の経営者が日本国内に存在することになります。大雑把に言えば、仕事の中で出会う10人に1人は経営者ということです。 そんな経営者、一般的に取り扱いが難しい人材という印象があります。 気分屋で我儘。人に従うのが嫌い。一貫性がなく意見がコロコロ変わる。思い込みが

app router とは next.js で使用できるファイルシステムベースのルーターです。以前は pages router というものがありましたが、そちらの進化系といえます。 ポイントは error.tsx や loading.tsx などの決められた名前でコンポーネントを作成することで、エラーバウンダリーやサスペンスなどの機能が簡単に利用できるようになったことです。 これにより開発速度が上がり、面倒な実装はフレームワークに任せることができます。 また、内部で RSC を使用しており、これとサスペンスにより、コンポーネントレベルで SSR と CSR を組み合わせられるようになりました。 今回はそういった機能の、弊社プロダクトにおける使用例を紹介します。 使用技術 error.tsx エラーバウンダリーです。fallback コンポーネントを書くだけで ok です。 import {

2023-08-02 What's "Next" JS Meetup

意思決定できる人は進める手順の型みたいなものを持っているように見える。逆に意思決定が遅かったりできなかったりする人は、進めるときに型のうちの何かが欠けているのかもしれない。 体系化された話は書籍で語られつくされているとは思うが、思考整理のために雑にまとめてみる。 最後は決めるだけだという考えを持つ 目的や満たしたいことを明確にする 最終的な決め方や期日を明確にする 選択肢を広げて考える 今は意思決定しない、という意思決定も選択肢に入れる 意思決定の軸を明確にする 軸をもとに定量/定性データを集める 軸をもとに選択肢を評価する 自分はこうしたいという"推し"を決めてたたき台にする ここまでの話をドキュメントにしている ここまでのプロセスに時間をかけない 意見を聞く人を見定めてフィードバックをもらう 最初に明確にした決め方で意思決定する 意思決定できない場合は決め方と期日と意思決定軸を再定義す

React v18.0 has broken ground by introducing a long-awaited feature: Concurrency! Unfortunately, despite a deluge of resources explaining how to use it, explanations of how it works are sparse. As it is a low-level feature, it’s not critical to understand React’s idea of concurrency, but it doesn’t hurt! This post does not attempt to exhaustively document React’s Concurrent API and best practices.

先日 フロントエンドの Monorepo をやめてリポジトリ分割したワケ というブログがバズっていた。そのおかげか、Twitter でもモノレポに関する言及がちょこちょこあった。一家言あるドメインなので書きたい。ただの一家言(a.k.a お気持ち)なのでぜひ皆さんの意見も聞いてみたい。 tl;dr 別に自分はどっち派とかではなく、どっちも選ぶ。強いて言うならリポジトリ分割派で、依存更新がしんどくなったら monorepo 派。 免責 モノレポに対する一家言を書きたいだけであって、内容自体はフロントエンドの Monorepo をやめてリポジトリ分割したワケ と全く関係なく、そのブログで述べられている施策については何も言及しません。ただ一つ言及するとしたら肉の部位がコードネームに採用されているのは良いと思いました。🍖🍖🍖 モノレポにしたくなる状態の前提にあるもの 前提は元記事と同じように

＜追記しました＞ みんな子育てを難しく考えすぎ。逆に俺みたいに20歳で結婚して「どうにかなるだろ」と育てたけど 今、その娘が20歳を迎えた。小学校に入るまでは嫁に専業主婦としてやってもらって 俺が倍働いた。小学校に入学してからは嫁もパートに行きだして家計も安定 趣味だったゲームも旅行も我慢して夫婦で育て上げたけど、わりと適当にやってきた まあ確かに目を離しちゃ駄目とか、言動で子供に影響が出るとか考えだしたらキリがないくらい心配だろうけど 自分自身が子供の頃を思い出してほしいが親が24時間ついてくれてたわけじゃなかったろ？ むしろ子供に影響を与える要素として一番大きいのは親じゃなく、周りの友達だよ 家に遊びに来たときにそいつらに目を向けるのが重要。話しかけてどんな子か観察する 子供と友達を連れてキャンプとか軽いドライブに行ってみる。物を運ぶのを手伝うのか？どう動くのか？とかね 観察する限り、

「プログラムを設計するときに行った技術的な判断や選択が、後日大きな制約となる」これはプログラマなら誰しも経験したことのあることでしょう。本書は、そんなプログラミングにおける各種の設計上の選択について、トレードオフの内容やそれがどのような誤りを招きうるのかという点を踏まえて紹介する書籍です。 コードの重複、エラーや例外処理、柔軟性と複雑性のバランスのようなコードレベルの選択から、APIの設計、時刻の扱い、データローカリティのようなシステム寄りの話題、またライブラリの選択、分散システムの一貫性と原子性、バージョニングのようなより抽象度の高い内容まで、さまざまなシチュエーションにおけるトレードオフの実態と、その失敗例をとり上げます。 本書は日々のプログラミングにおける解決策のヒントを得るだけでなく、より幅広い設計上の知見を広める上でも役に立つでしょう。 正誤表 ここで紹介する正誤表には、書籍発行