アルムナイ採用体験記 (株式会社はてなに2回目の入社をしました) - だいくしー(@daiksy)のはてなブログ
2024年5月1日から、株式会社はてなで組織・基盤開発本部のエンジニアリングマネージャとして働き始めました。 2014年から、2021年まで社員だった時代があるため、いわゆる出戻りという形になります。 一度退職した会社に再び入社する、というのは、通常の転職活動と違った悩みなどもあり、自分も今回の転職に際して「アルムナイ採用」などのキーワードでいくつか参考にした記事がありました。 最近は身近な事例も耳にするとはいえ、まだまだ通常の転職と比べてアルムナイ採用は例が少ない気がするので、せっかくなので体験記を書いておこうと思います。 基本的には自分の個別の事例ですので、世間一般のアルムナイ採用の実態とは異なる箇所もあることをご承知おきください。 戻ろうと思ったきっかけ もともと最初にはてなを辞めた理由が、自分の新しいキャリアを志したチャレンジという側面が強かったため、辞めた直後からなんとなく「機会
エンジニアリングマネージャとして会社にジョインするのは難しい - だいくしー(@daiksy)のはてなブログ
新しい会社に入社して1ヶ月半経った。 今回はエンジニアリングマネージャとしてのポジションでの採用で、過去4回の転職はすべてアプリケーションエンジニアとしての採用だったので、その差分に若干戸惑っている。時勢的にフルリモートワークというのも大きい...。 "成果"が見えにくい仕事に対する実感をどのように得るか まずひとつは、"成果"に対する手応えが異なること。エンジニア採用であれば、「入社最速RTA！！」などと言いながら、とりあえず小さなタスクを拾って入社後1週間以内くらいに自分の出した最初のプルリクエストがマージされれば、「最初のステップは超えた」という実感を得ることができた。 マネージメント職では、そのようなわかりやすい成果が見えづらい。そもそも、自分の打ち手が効果を発揮するのが翌月、みたいなリードタイムも珍しくないので、自分はちゃんと給料分働けているのだろうか、とまぁまぁ不安になる。そこ
そのリリース日そんなに大事ですか？ - だいくしー(@daiksy)のはてなブログ
今期の目標設定を決めましょう、というときに、よく「〇〇の機能を期日どおりにリリースする」と書きたくなりがち。ぼくも以前はよく書いていた。 マネージャの仕事をそれなりの期間やっていくうちに、この考え方はまったく意味がないな、と思うようになった。 リリース日を遵守する、というのは、プロダクトのビジネス価値を生み出す要素の一つにすぎない。期初にたてた予算が、この日にリリースされることを前提に計画されている、とか、競合製品よりはやく価値を出すためにはどうしてもこの時期にリリースしたい、といった感じだろう。 なのでリリース日を目標にするのはなんの問題もない。当然そのように振る舞うべきだ。ただ、これが評価に結びつくととたんに破滅する。 リリース日遵守を基準点。遅延すると減点、前倒しで加点。こんなふうにしてしまうと最悪。 開発を進めるうちに、どうしてもリリース日に間に合いそうにない。スコープを絞って間に
毎週1時間のモブプログラミング枠を運用したところ、とても良いという話 - だいくしー(@daiksy)のはてなブログ
およそ一月前くらいに、同僚の id:hitode909 さんとモブプログラミングをやってみようということになった。 hitode909さんとはチームは別なのだけれど、最近週一で別チームに行ってペアプロなどをしつつ、知見の横展開や課題の発見などをやろうという試みをされていて、ではせっかくなので、と自分たちのチームに招いて軽くお試しでモブプロをやってみた。 blog.sushi.money モブプログラミングとは、ペアプログラミングをチーム全員にまで拡大したようなもので、1つのプログラムをプロダクトオーナーも交えたチーム全員で取り組む形式である。 セミナールームにエンジニア8人ほどで集まって、大画面ディスプレイにソースコードを共有しつつ、「コードを書く人（ドライバ）」と「それ以外の人（ナビゲータ）」とで1つの課題に取り組んでいく。 実装をチーム全員で取り組むため、知見が共有できたり、設計上の課
Scala福岡で、Play Frameworkをどうやって安全にバージョンアップしたかを話してきました - だいくしー(@daiksy)のはてなブログ
scala.connpass.com Scala福岡で登壇機会をいただき、お話してきました。 ぼくたちが運用・開発しているMackerel というプロダクトで、2度実施したPlay Frameworkのバージョンアップで得た知見を元に、アプリケーションフレームワークの更新をどうすれば安全にやれるだろうか、という観点でのお話でした。 あえて技術的な側面にはあまりフォーカスせずに、プロジェクトマネジメントの視座からお話することで、ScalaやPlayにかぎらず参考になるような発表になればいいな、ということを意識しました。他の言語の世界をあまり詳しく知らないので、意図通りの発表になったかどうかはわかりませんが…。 Twitterを見たところ、おおむね好評なようでよかったです。 サービスに機能追加しながら運用しつつ、フレームワークやライブラリのバージョンアップについて行くのまじで大変なので、このセ
勉強会の無断欠席は永久になくならないから僕らが工夫しよう - だいくしー(@daiksy)のはてなブログ
photo by E R I mollifier.hatenablog.com ITコミュニティ界隈で定期的に話題になるこの問題。 定期的に出る、ということは、無断欠席は永遠になくならないと思ってよさそうだ。 そもそも他人の行動を制御するのは不可能なので、制御可能な自分たちの運営を工夫して解決し、関係者全員が幸せになれる方法を考えよう。 有料とかブラックリストとかほんとに有効？ この話題でいつも意見として出るのが、前金制キャンセル不可の有料制にしてはどうか、とか、無断欠席者のリストを共有する、とかいった話。 ただ、ブラックリスト作ってもリストに載ってない無断キャンセルなんて無限に存在し続ける。 有料制も、会場によっては営利目的とみなされて使用料がそれによって跳ね上がったりする。 そもそも、無断キャンセルによって補欠登録になってしまっていた人の参加の機会が奪われるのを何とかしたい、というのが
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
