アルムナイ採用体験記 (株式会社はてなに2回目の入社をしました) - だいくしー(@daiksy)のはてなブログ
2024年5月1日から、株式会社はてなで組織・基盤開発本部のエンジニアリングマネージャとして働き始めました。 2014年から、2021年まで社員だった時代があるため、いわゆる出戻りという形になります。 一度退職した会社に再び入社する、というのは、通常の転職活動と違った悩みなどもあり、自分も今回の転職に際して「アルムナイ採用」などのキーワードでいくつか参考にした記事がありました。 最近は身近な事例も耳にするとはいえ、まだまだ通常の転職と比べてアルムナイ採用は例が少ない気がするので、せっかくなので体験記を書いておこうと思います。 基本的には自分の個別の事例ですので、世間一般のアルムナイ採用の実態とは異なる箇所もあることをご承知おきください。 戻ろうと思ったきっかけ もともと最初にはてなを辞めた理由が、自分の新しいキャリアを志したチャレンジという側面が強かったため、辞めた直後からなんとなく「機会
スクラムマスターって何をする人なの？ - だいくしー(@daiksy)のはてなブログ
これは Chatwork Advent Calendar 2日目のエントリです。 また、このエントリの公開日翌日に開催される"だいくしーのスクラムBar #1" で取り扱うテーマについての詳細な解説記事も兼ねています。 chatwork.connpass.com スクラムマスターって何をする人なの？ 本項ではこれについて少し考えてみたいと思います。また、ぼく自身が普段どういうことを考えながらスクラムイベントや、その他の仕事をしているか、なども書いてみようと思います。 スクラムマスターは、ソフトウェア開発に関する他の職種と比べても、具体的な職務内容がわかりづらい役割なのかな、と思います。少し乱暴な言い方をしてしまうと、デザイナーがいなければデザインはできないし、プログラマーがいなければアプリケーションコードを書くのはとても困難です。しかし、スクラムマスターがいなくても別に開発はできます。 そ
アジャイルな見積もりを理解する「コース定数」という概念 - だいくしー(@daiksy)のはてなブログ
アジャイル開発をはじめて体験すると、いろいろな考え方を身につけるために苦労をすることがあります。 特に、相対見積もりや、ベロシティによる経験主義的な見通しの取り方について、実際に経験せずに理解するのは難しいようです。 そこで今日は、日常生活の中で馴染みの深い考え方を使って、説明を試みてみたいと思います。 「コース定数」でアジャイルな見積もりを考えてみる 国民的な娯楽である登山をやられる人なら誰もが知っている「コース定数」という考え方があります。みなさんもご存知かと思いますが、簡単に解説します。 山は、事前の計画がとても重要でありつつも、実際に登ってみないとコースの状態や、自分の体力がその山に適しているのかがわかりづらい遊びです。そういう意味では、経験主義的なアプローチが必要なソフトウェア開発に似ているとも言えます。 交通機関やレスキューの体制が整備されている街中と違い、山は自分の体がすべて
エンジニアリングマネージャとして会社にジョインするのは難しい - だいくしー(@daiksy)のはてなブログ
新しい会社に入社して1ヶ月半経った。 今回はエンジニアリングマネージャとしてのポジションでの採用で、過去4回の転職はすべてアプリケーションエンジニアとしての採用だったので、その差分に若干戸惑っている。時勢的にフルリモートワークというのも大きい...。 "成果"が見えにくい仕事に対する実感をどのように得るか まずひとつは、"成果"に対する手応えが異なること。エンジニア採用であれば、「入社最速RTA！！」などと言いながら、とりあえず小さなタスクを拾って入社後1週間以内くらいに自分の出した最初のプルリクエストがマージされれば、「最初のステップは超えた」という実感を得ることができた。 マネージメント職では、そのようなわかりやすい成果が見えづらい。そもそも、自分の打ち手が効果を発揮するのが翌月、みたいなリードタイムも珍しくないので、自分はちゃんと給料分働けているのだろうか、とまぁまぁ不安になる。そこ
なぜスクラムチームをスケールしたくなるのか - だいくしー(@daiksy)のはてなブログ
Nexus, Scrum@Scale, LeSS, SAFeなど、スクラムチームをスケーリングする手法はたくさん存在する。 しかし、アジャイルコーチなどに、「スクラムをスケールするにはどうすればいいですか？」と聞くと「そもそもスケールをするな」と言われることもある。ぼくも基本的にはこれに同意する。 コンパクトな職能横断型のチームで、短いサイクルで高速に、安定したペースで開発をする。これをずっと続けることができるのならばそれが一番良い。 なのになぜ、人々はスクラムチームをスケールしたくなるのか。なぜこんなにたくさんのスケーリング手法が存在するのだろうか？ そういうことを考えてみた。 最初から人がたくさん必要な場合 そもそも最初からスケールされたチームでやりたいパターンがある。大規模な開発などはそうだろう。 小さくローンチして、インクリメンタルにユーザーフィードバックを受けながら開発できれば理
そのリリース日そんなに大事ですか？ - だいくしー(@daiksy)のはてなブログ
今期の目標設定を決めましょう、というときに、よく「〇〇の機能を期日どおりにリリースする」と書きたくなりがち。ぼくも以前はよく書いていた。 マネージャの仕事をそれなりの期間やっていくうちに、この考え方はまったく意味がないな、と思うようになった。 リリース日を遵守する、というのは、プロダクトのビジネス価値を生み出す要素の一つにすぎない。期初にたてた予算が、この日にリリースされることを前提に計画されている、とか、競合製品よりはやく価値を出すためにはどうしてもこの時期にリリースしたい、といった感じだろう。 なのでリリース日を目標にするのはなんの問題もない。当然そのように振る舞うべきだ。ただ、これが評価に結びつくととたんに破滅する。 リリース日遵守を基準点。遅延すると減点、前倒しで加点。こんなふうにしてしまうと最悪。 開発を進めるうちに、どうしてもリリース日に間に合いそうにない。スコープを絞って間に
機械学習プロジェクトのマネジメントの入り口 -『仕事ではじめる機械学習』を読んだ - - だいくしー(@daiksy)のはてなブログ
仕事ではじめる機械学習 作者:有賀 康顕,中山 心太,西林 孝発売日: 2018/01/16メディア: 単行本（ソフトカバー） ちょうど仕事で機械学習を用いた機能開発のプロジェクトの進行管理をしていて、目次をみたところ良さそうに思ったので読んでみました。 オライリーのEbookでPDF版を買ったのですが、まもなく紙版も出るようです。 まえがきには、CourseraのMachine Learningコースを受講するか、『ゼロからつくるディープラーニング』を読んでおくと良い、とありました。ぼくは直前に『ゼロからつくるディープラーニング』を読んだあとでしたが、いきなり1冊目に読んでも問題ないのではと思います。難しい数式などはあまり出てきません。とはいえ、ある程度の機械学習についての知識を持っているのが前提になっているので、少なくとも機械学習を取り扱う際によく出てくる用語の意味などはある程度知って
リモートワークはとても難しいという話をしてきました - だいくしー(@daiksy)のはてなブログ
"Agile Japan 2017 京都サテライト", "KANJAVA PARTY 2017" で、『リモートチームの道具箱』というタイトルのセッションでお話をさせていただきました。 connpass.com kanjava.connpass.com リモートワークに取り組んでいるチームで仕事をして3年目になりますが、リモートワークは難しいなーというのを常々思っています。 世の中はどちらかというと、リモートワークという素晴らしい取り組みをどんどん推進しようという流れに向いています。リモートワークの推進には僕も賛同するのですが、一方で、「難しさ」の部分があまりクローズアップされません。このまま、導入だけが先行してしまうと、結局「やっぱりリモートワークなんて止めたほうがいいのでは」となってしまう恐れがあって、それを懸念しています。 リモートワークは上手に使いこなせば、柔軟な働き方が促進される
はてなインターンの振り返りをYWTを使ってやってみた - だいくしー(@daiksy)のはてなブログ
今年は、はてなインターンの実行委員長という仕事をしている。 hatenacorp.jp 8月15日から9月9日までのインターンを終え、今年の教科書も公開ができた。 developer.hatenastaff.com まだもう少し委員長としての仕事が残っているが、ここで一度今年の振り返りをしようということで、実施した。 振り返り手法としてのKPTとYWT ぼくは普段、Mackerel というプロダクトの開発にかかわっている。Mackerelでは開発手法にスクラムを採用していて、2週間のスプリントごとに毎回振り返りを行っている。ここで使っているのはKPTという手法だ。 KPTはKeep, Problem, Tryの略で、2週間を振り返って、その期間でKeepしておくべき良かったこと、Problemとして議論すべき問題となること、そしてそれらを受けて次のスプリントですべきTryを決める。 K,
iPhoneを交換するときには2段階認証に注意 - だいくしー(@daiksy)のはてなブログ
先日、飲み屋でうっかりiPhone6を落としてしまい、画面がバキバキに割れてしまった。 AppleCareに加入していたため、翌日の昼休みに職場近くのクイックガレージに持って行くと、20分ほどで交換が終了。昼休み中に新品のiPhoneになった（お値段は7,800円）。 午前中に職場のMacBook Pro にフルバックアップ*1を取っていたので、帰社後復元。 ひとしきり動作確認していると、ただ1点だけ復元されていない情報があった。 Google Authenticator である。 Google Authenticatorは、オンラインアカウントの2段階認証プロセスで使われるもので、それぞれのログインアカウントに紐付ける形で時限式トークンを発行するソフトウェアである。 ログイン時にアカウントとパスワードを入力したのち、手元のスマートフォンなどでこの時限式トークンを入力してログイン完了、とい
アリスとボブはパスワードつきzipをメールに添付したりしない - 暗号技術入門を読んだ - - だいくしー(@daiksy)のはてなブログ
パスワードつきzipの添付メールと鍵配送問題 ボブのもとに届けられたアリスからのメール。このメールにはzipファイルが添付されていて解凍にパスワードが必要だ。このパスワードは、添付ファイルの後、アリスから別のメールに記載されて送られてくる。この手順により、最初のメールをイブが盗聴したとしても、イブはパスワードを知らないので添付ファイルを解凍することはできない。 一見すると安全に情報をやりとりしているようにみえるこの形式は、実はまったく安全ではない。ファイルが添付されている最初のメールが盗聴できるのであれば、当然イブは次に送られるパスワードが記載されたメールも盗聴できるからだ。 zipに施されるパスワードの強度はとりあえず気にしないこととして、この情報のやりとりは暗号におけるとても重要な問題をないがしろにしている。それは鍵配送問題と呼ばれる。 暗号の中には、かなり早い段階で「絶対に解読不可能
Scala関西Summit 2015の裏側！ - 大規模カンファレンスの作り方 - - だいくしー(@daiksy)のはてなブログ
Scala関西Summit 2015 でスタッフをやっていた。 おかげさまで大盛況で、とてもよいイベントだった。 せっかくこういう大きなイベントの最初期からスタッフとして関われたので、経緯などを書いておこうと思う。 summit.scala-kansai.org 何をやったの? 勉強会当日はメインホールの司会とパネルトークの登壇など。 準備段階ではなんかいろいろやってた。 経緯 去年のScalaMatsuri2014の会場で、今回のSummitの実行委員長となる@aa7thさんと「関西でも大きなScalaイベントやりたいね」という話などをしていた。 その後、Facebookメッセンジャーの記録によると、2014年の10月23日に@aa7thさんから「そろそろ準備を始めましょう」と何人かのメンバーに呼びかけがあり、そのときに声をかけてもらう。ここから考えると9ヶ月かかったことになるのか。。。
『実践ドメイン駆動設計』を読んでいる - だいくしー(@daiksy)のはてなブログ
『実践ドメイン駆動設計』を読んでる。まだ読んでる途中なので、読み終わったら感想が変わるかもしれないけれど、とりあえず今の時点で思ったことなどを書いておこう。 本書は「エリック・エヴァンスのドメイン駆動設計（以下エヴァンス本）」の副読書として読むのが正しい読み方ではないかな、と思った。 エヴァンス本をある種の「理論書」とするなら、こちらはタイトル通り「実践指南書」といった趣きである。 翻訳本であるが、文体は平易で非常に読みやすく、肩肘をはらずに通勤電車の中などで気軽に読める(616ページもあるので電車で読むにはKindleが必須だけど)。エヴァンス本はわりと体調を整えて読まないとすぐに眠気に襲われてしまうので、最初は本書の読みやすさに感動した。 読みやすいけれど内容は非常にしっかりしていて、DDDのエッセンスは正しく学べそうである。ただ、「ユビキタス言語」「境界づけられたコンテキスト」「集約
若者にIT業界に希望を持ってもらいたい - だいくしー(@daiksy)のはてなブログ
以前、アジャイルラジオというpodcast番組に出演させていただいた（バックナンバーはこちら）。この番組のパーソナリティの土屋さんのご紹介で、大阪情報コンピュータ専門学校というところで学生向けの講演をさせてもらう機会を得た。 1コマ90分。講演自体は約60分ということで、ここまで長丁場の登壇は初めてのこと。準備段階ではいろいろと苦労もあったがとても良い経験をすることができた。 IT業界の楽しさを伝えたかった インターネットを見ると、IT業界については否定的な意見がとても目についてしまう。長時間勤務、納期に追われる、デスマーチなどなど。こういったマイナスの意見というのは、共感も得やすいし、そもそも自虐ネタというのはネタとしてもおもしろい、ということもあって、悲しいことにこういった言説の方がインターネットでは拡散しやすい。 ただ、ネガティブな意見の方が目立ってしまう、というだけで、業界をポジテ
これをやれば誰でもできる、プレゼンの作り方 - だいくしー(@daiksy)のはてなブログ
発端 今年の頭に、講演依頼をもらった。 専門学校で、学生さん相手に業界動向やこれからのために何を学ぶべきか、といった話をしてほしいとのこと。 当然、快諾したのだが、持ち時間を尋ねたところ「90分」だという。 人前で話す経験、というのは、おそらく豊富な方だと思う。5分間のプレゼンであるライトニングトークをはじめとして、カンファレンスで40分ほどの枠をもらって喋ったこともあるし、パネルディスカッション形式の登壇も3回ほど経験がある。 だいたい年に5, 6回は、なにがしかのIT系のイベントで登壇していると思う。 が、それでも90分という持ち時間を聞いてぞっとした。ライトニングトーク18回分。カンファレンス約2回分の時間をしゃべり続けなければならないのである。 90分という持ち時間を聞いて、専門学校で開催される講演会であるから、学校の授業1コマ分の時間に相当するのだろうと気づいた。これまでだらだら
ソフトウェアエンジニアの越境 - エンジニアも営業を学べ！？ - - だいくしー(@daiksy)のはてなブログ
DevLOVEアドベントカレンダー 越境 12日目の記事です。 今年のテーマは越境。ということで、ソフトウェアエンジニアの現場における「越境」について考えてみようかと思います。 いまいち納得のいかない片方向な越境 「エンジニアも営業的な目線を持ってセールスに貢献すべきだ！」 「エンジニアも自ら企画を立案し、サービスの売上げアップに貢献すべきだ！」 多くのエンジニアが、このような物言いを苦々しい気分で聞いた経験があるのではないでしょうか。 営業職の偉い人は、エンジニアもセールスを学び、営業の視点を持て、と言う。 企画職の偉い人は、エンジニアも企画を学び、サービスを立案しろ、と言う。 ところがエンジニアリングを学ぶ営業や企画の人は少ないし、エンジニアリングを学ばない営業職や企画職が、それを理由に咎められている様子など一度も目にしたことはありません。 なぜエンジニアばかりが開発以外のスキルまで求
株式会社はてなに入社しました - だいくしー(@daiksy)のはてなブログ
11月1日付で、株式会社はてなに入社しました。 はてなに入社するということで、なるべく自社サービスを利用していこうと思い、これを機にブログもはてなブログに移行しようと思います。引き続きよろしくお願いします。 はてなでは、Mackerelの開発に携わる事になりました。前職に引き続きScalaが使われているプロダクトで、これまでの経験を活かしていきたいと思っています。 今日は入社初日でめちゃくちゃ緊張しましたが、チームメンバーの何人かとは入社前からお酒を飲んだり、勉強会などでご一緒させてもらったりしていたので、おかげで比較的スムーズにジョインできたかな、と思います。 はてなは会社としても、新しい社長の元でおもしろいフェーズにあると思っているので、良い化学反応を起こせるように頑張ろうと思います。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
