2024年5月1日から、株式会社はてなで組織・基盤開発本部のエンジニアリングマネージャとして働き始めました。 2014年から、2021年まで社員だった時代があるため、いわゆる出戻りという形になります。 一度退職した会社に再び入社する、というのは、通常の転職活動と違った悩みなどもあり、自分も今回の転職に際して「アルムナイ採用」などのキーワードでいくつか参考にした記事がありました。 最近は身近な事例も耳にするとはいえ、まだまだ通常の転職と比べてアルムナイ採用は例が少ない気がするので、せっかくなので体験記を書いておこうと思います。 基本的には自分の個別の事例ですので、世間一般のアルムナイ採用の実態とは異なる箇所もあることをご承知おきください。 戻ろうと思ったきっかけ もともと最初にはてなを辞めた理由が、自分の新しいキャリアを志したチャレンジという側面が強かったため、辞めた直後からなんとなく「機会

こんにちは！estieでビジネス部門の責任者をしている束原です。 2024年になりましたね。estieは決算月が12月なのですが、毎年期初に「今年こそが勝負の年だ」と言っている気がしており、それに対して「ガハハ」と笑い合えるメンバーで仕事ができているのが最高に楽しいなと日々痛感しております。 さて、こちらは事業の立ち上げ（事業開発）に関する記事です。 この記事に書いてあること estieでは「仮説検証」をやめようと思っている話 事業開発の成分の8割は営業だという話 かなり極論が並んでいますが(笑)、事業開発を進める上でとても重要だと考えているので、ご興味のある方は少しお付き合いください。 to Bスタートアップは仮説検証をやめようという話 「仮説検証って言葉が嫌いなんすよねー」と、確か弊社の事業責任者の齋藤だったか代表の平井だったかが以前社内で言ってました。 1年前くらいまで私は、その発言

今年、この話を何度か別々の人にすることがあってずっと纏めようと思っていたのだけど一年が終わってしまうので来年の自分のために今書いてしまう。 目新しいことは何一つ無いのだけど、大切なことだし、意外と社会人になってしまうと教えてもらえないことも多いみたいなのでここでまとめる。 表題のこと、つまりやりたいことを実現するために必要なことは、そんなに難しいことじゃなくて以下の条件を満たし、実行することが大事だ。 やりたいこと=課題をタスクに分解する タスクを実行できるだけのリソース（時間・お金・体力など）を割り当てる 実行する これだけなんだ。仕事だってなんだって一緒なんだけど、だけどこれを日常的に実現することが難しい。 だからどうやって実現していくか？って説明のために、自分がやってることを書く。 課題を整理する 仕事と作業は違うという話がある。 トヨタでは最初にそれを教わるらしい。 www.har

ランキング参加中プログラミング はじめに この記事では、Immutable Data Modelと呼ばれる設計手法をもとに、リレーショナル・データベースにおける、テーブル設計の話を書いています。また、今回の実践で利用する、別の考え方の背景を理解するために、Out of the tar pitという小論文の内容にも言及します。 「状態とは何か？」というややこしい話がたくさん出てきますし、データベースのテーブル設計についての話であることから、たくさんのSQLが出てきます。なので、データモデリングとか状態管理とか、特にSQLとかに興味がない人には面白くないと思います。 そのあたりに興味ある方は、読んでみて欲しいです。 Immutable Data Modelを、実際のアプリケーションで使うデータベースに採用するにあたり、どういう考え方で、どのようにテーブルを構成したか、自分なりの経験を書いていま

VP of Engineeringのid:Songmuです。このエントリーは株式会社ヘンリー Advent Calendar 2023、最終日の記事です。 ヘンリーは今年、本丸の病院向け電子カルテ・レセコンシステムのサービスを開始し、順調に事業が立ち上がっています。早くも業界でもユニークなポジションを獲得し、注目度も上がっています。 そんな中アクセルを踏む決断をし、来年は組織として100人採用に踏み切ることになりました。 ビジネスを勝ち切るためのアクセルを踏むフェーズにおいて、自分がVPoEとして採用や組織開発に主体的にチャレンジできる立場にいることは喜ばしいことです。その中で自分が考えていることを書き出していきます。 公器を志向すること 「面白法人でありながら上場することに意味と面白さがある」 2011年頃、当時私が所属していたカヤック社で代表の柳澤さんが度々こう言っていました。カヤック

こんにちは。株式会社エス・エム・エス で「カイポケ」という SaaS の Engineering Manager をやっている酒井です。Engineering Manager Advent Calendar 2023 の21日目向けの記事を書きます。 「難しいですね〜」と言ってしまう私 みなさんは、日々マネジメントの現場で組織課題を思考している時など、何か難しい問題に向き合っている時に、「いや〜難しいですね〜」というようなことを口にしていませんか？私はよくします。 会議などで「いや〜難しいですね〜」と言って時が過ぎ、「一旦時間も来ましたし…また次回考えましょう…じゃあ、おつかれさまでした………」これです。 いつも「難しいですね〜」を言ってしまって気がつくのですが、「難しいですね〜」を言っている瞬間は多分自分がその問題に本気で向き合っていない状態なんだと思います。別に言ってはいけない NG

この記事はスターフェスティバル Advent Calendar 2023 9 日目の記事です。 qiita.com 最近社内で可読性について会話をするタイミングがあり、可読性について思っていることを言語化してみるか〜と思ったので書いてみます。 可読性って難しいしよくわからないよね〜 この記事では、可読性という単語をコードの把握しやすさといった認知負荷的な意味だったり誤読しにくさみたいな意味で使っています。 メンタルモデルに起因するものなのか、そうではないのかを意識する メンタルモデル? メンタルモデルというものは「XXとはこういうもの」や「こうしたらこうなるはず」のような人それぞれが持つ思い込みみたいなものだと理解しています。 コードを読んで理解するときのメンタルモデルは、これまでのプログラミングに関する経験や知識、そのロジックが解こうとしている問題についての理解、自然言語自体の理解などの

こんにちは、@ikkitangです。 この記事はスターフェスティバル Advent Calendar 2023の17日目の記事です。 昨日はnano72mknさんのdivで作るボタンはボタンぽい何かでした。 初心者なので、良くやった記憶がありますねぇ・・（白目。 nano72mknさんはフロントエンドで困ったらだいたいnano72mknさんに聞けば何か解決するのでは、とめちゃくちゃ皆に頼られてる方ですが、フロントエンドにおいてアクセシビリティや開発のメンテナンス性など色々な観点でフロントエンドと向き合われているのですが、今回もそのような話で良かったですね。 余談ですが、今回弊社からフロントエンドカンファレンス沖縄に3名のエンジニアが登壇してくれたのですが、昨日・明日・明々後日とその登壇したエンジニアの記事が続くので是非ウォッチしてみてください。 今回の記事の内容 コードの自動生成の活用事例

Engineering Manager Advent Calendar 2023 15日目の記事です。 KyashでEngineering Managerとして1年半、VP of Enginneringとして2年やってきました。 体系的な話は HIGH OUTPUT MANAGEMENT や エンジニアリング組織論への招待、エンジニアリングマネージャーのしごと といった素晴らしい書籍にまとまっているので、自分はケーススタディとしてVPoEになってからの具体的な意思決定の記録を残しておきます。EMの時の話は過去にまとめています。 KyashでEngineering Managerとしてやってきたこと / やっていくこと - Konifar's WIP Engineering Managerをやめた - Konifar's WIP 先に書いておくと、綺麗にうまくいった / いっているという話は

日本PostgreSQLユーザ会（以下、JPUG）から来ました @soudai1025 です。 この記事は PostgreSQL Advent Calendar 2023 シリーズ 1 の 5 日目の記事です。 www.postgresql.jp PostgreSQLユーザ会って？ JPUGはNPO法人です。 目的もちゃんと明記されています。 本会は日本におけるPostgreSQLの普及と発展を主な目的とします。具体的には以下の活動を行います。 1. PostgreSQLの研究開発および普及促進 2. PostgreSQLに関する情報の公開 3. 会員相互および外部との技術的・人間的交流 www.postgresql.jp NPO法人だと何が違うの？ １番大きなところはお金の管理を透明性を持って管理していることです。 後述する活動費を協賛会員様*1の協賛会費から捻出して管理しています。 ど

こんにちは、SRE チーム マネージャーの TksYamaguchi です。 こちらの記事はGunosy Advent Calendar 2023の3日目の記事です。 前回の記事は森田さんの LLM 論文の探し方でした。 概要 SRE チームは、シニアエンジニアとジュニアエンジニアで構成されているチームで、チーム内の技術的な知識の偏りの解消や、知識のタコツボ化の解消を目的として読書会をしてきました。 その過程でいろいろな読書会のパターンを行ってきましたので、その結果を共有します。 概要 読書会開始前の SRE チームの課題感 読書会 のやり方の整理と評価の観点 やり方 評価の観点 当日音読・Slack に投下する方式 実際のまとめ 方式詳細 評価 メリット デメリット 事前に読んで Miro*1 に付箋・当日議論する方式 実際のまとめ 方式詳細 評価 メリット デメリット 当日黙読・その場

ブックサンタという企画で、ジュール・ヴェルヌの『十五少年漂流記』を寄付してきました。年末ですね。 スターフェスティバル Advent Calendar 2023 の2日目の記事です。よろしくお願いします。 スターフェスティバルに入社して4年が経とうとしています。昨年まではソフトウェアエンジニアとして開発に従事しておりましたが、今年からはロールが替わって Kitchen Success プロジェクトのプロジェクトリーダーとなりました。経験の枯渇しないことでお馴染みのスタフェスです。大変ありがたいことです。それにしても、プロジェクトリーダーってなんだ。 勢い込んでアドベントカレンダーの枠をいただいたものの、ネタがなにも浮かびません。二年間の休暇でも貰うことができるなら、なにかいい感じのトピックを捻り出せそうなものなんですが。あいにくそんな時間はありません。 だから今回はふりかえり記事のようなも

ISUCON13に参加した。 我々のアプローチ、当日の話なんかはチームメイトが書くだろうから自分はざっくり、ここまで1年間チームを組んでくれたチームメイトとの歩みについて書いて行こうと思う。 とはいえ、気になる人もいるかもしれないから置いておく。 github.com チームの始まり 2022/07/23 ISUCON12に出場した自分と @tetsuzawa はFailでscore無しとなり予選敗退した。 新卒1年目の@tetsuzawaが「来年も出ましょう。準備、できることは全部やるんで。」と言って来年も出るか。ってことが決まった。 二人で出たチームの課題は自律したガンガンコードを書けるGoのプロフェッショナルが足りないこと。 だからその日のうちに、ISUCON 12では出題側に回っていて、絶対来年のチームが決まっていない @mackee_w を誘った。 そして当日の反省会をしていた田

TypeScript プロジェクトのコンパイルのボトルネックを調査・解消してみた話 はじめに こんにちは。エンジニアの辻󠄀です。 私は社内のとある TypeScript プロジェクトで開発業務を行っていました。 ある日、新たに関数の実装を追加しようとしたその時、tsserver（TypeScript の language server）による補完候補がなかなか表示されないことに気づいたのです。 どうやら、コンパイルの時間が非常に長くなっていたことが原因のようです。 この記事では、tsc のコンパイルにおけるボトルネックを調査する方法と、そこで適用した２つの改善方法について紹介します。 コンパイル時間が低下する原因はプロジェクトの性質によって大きく異なるため、ここで述べる改善方法が任意のプロジェクトに有効だとは言えませんが、少なくとも調査方法については役に立つのではないかと思います。 ボト

「システム運用アンチパターン」を読んだ❗️ サブタイトルに「エンジニアが DevOps で解決する組織・自動化・コミュニケーション」と書いてある通り，迅速に改善を積み重ねつつサービスの価値をユーザーに提供するときに，どういう組織の振る舞いが「悪くて」どういう組織の振る舞いが「良いか」というアプローチを DevOps 視点で学べる良い一冊だった📕 システム運用アンチパターン ―エンジニアがDevOpsで解決する組織・自動化・コミュニケーション 作者:Jeffery D. SmithオライリージャパンAmazon 個人的に本書が特に刺さりそうだなーと思った読者層は，比較的レガシーな開発組織にいて「何かうまくいってない」や「何となく今のままではダメそう」とは思うけど，具体的にどう改善したら良いかというアイデアは浮かんでこないような開発責任者や肩書に関係なくもっと良い組織にしたいと感じているエン

先日開催された吉祥寺.pm18で「ぼくがかんがえたさいきょうのSoR/SoEあーきてくちゃ」というテーマで発表をしてきました。 そのイベントレポート兼発表補足です。 イベント概要 kichijojipm.connpass.com スライド speakerdeck.com 発表内容の補足 Twitterやはてブ等でいくつかご意見いただいているので、それについて現時点で僕が考えていることを補足させていただこうと思います。ひとつ言い訳させてもらえるなら、今回は時間が短すぎたので結構前提となる説明（エヴァンスさんの DDD を僕がどう捉えているか、CQRS とは何か、等）を省略したところが多すぎたかなっていうのがあり、特に当日いらっしゃらずスライドだけを見ていただいた方には余計にわかりにくかったかもしれないので、ここで FAQ 形式で補足させてもらえればと思います。 整合性に関しては DDD でい

⚡️ 25x faster — Switch from npm install to bun install in any Node.js project to make your installations up to 25x faster. https://bun.sh/docs/cli/install という記述を見かけて直感的に、そうはならんやろと思ったものの実際にベンチマークをしているのでどういうことなのかを気になって調べた。 A global install cache. bun installを実行すると ~/.bun/install/cache/ 以下にnpmレジストリからダウンロードされたファイルの実体が展開されキャッシュされる(--cache-dirでパスを変更できる)。 キャッシュにはパッケージのバージョンごとのディレクトリとlatestのシンボリックリンクがある。こ

データ構造をimmutableにしたい、イベントは起きたことをそのまま記録したい、更には監査の観点から修正させたくない、という人類の夢と希望に対して、「だってそれじゃあ現場は回らないんだよ」という例外運用のバランスをどこで取っていくか？というのは昨日・今日出てきた話ではないんですよ— magnoliak🍧 (@magnolia_k_) 2021年11月28日 所謂、業務システムの設計の一番肝心なところって、「起きた事実をありのまま記録する」っていう要件と、実際の運用がそうなっていない現実との戦いなんじゃないかって みんなそうしたいんだよ、でもできないんだよっていう— magnoliak🍧 (@magnolia_k_) 2021年11月28日 「データを活用しよう」って言い出しても、「活用できるように維持していましたっけ？」みたいな話も同じなんだけど、とにかく例外との戦いなんですよ— m

自分は、仕事でScalaを数年間・プライベートな経験を含めると10年弱のScalaの経験がある、そこそこの熟練Scalaエンジニアだ。チームにメンバーが入ってきたり他人に勧めるたびにScalaの環境構築を教えている一方、最新の知見を反映した記事が無くて他人に勧めづらかったので、自分が書くことにした。 現在ある記事 けっこう古びている 覚えながら書かれていることが多いのでやや曖昧な箇所がある(でもありがとう！) 最新のツールが利用できておらず無駄が多い 網羅的でない 今回目指す内容 最新の知見を活用して最短距離を目指す 何もない状況から一通りのツールが揃う所を目指す Scalaの環境構築は年を追うごとに簡単になってきているので、大多数の読者は引っかからずに進めるようになっているはず。 Scalaは基本的にJVMで動作する言語だ。このため環境構築にはJVMのセットアップも含まれるのだが、それに