2017年6月〜2020年3月まで、Quipperという会社でEngineering Managerをやってみての振り返りです。 ここ数日こつこつと退職エントリを執筆していたのですがこのセクションが長くなりそうだったのと、単体で読まれても良さそうなので1エントリとして切り出しました。*1 マネジャーになった背景から失敗から学んだことから思いついたことをぐだぐだ書いていきますがはっきり言って個人の日記レベルなので野暮なツッコミはなしでお願いします。*2 というかこれは個人の日記ですよ〜。（ここまで防衛線） マネジャーになった背景 / 当初の役割 記憶が確かであれば2016年頃にQuipperにも評価制度が導入されたのですが、当時すでに世界に数拠点あったためCTO@Londonが全員を評価するのは難しくなっていました。可能な限り現地オフィスで現地メンバーを評価したほうが納得感も高い、ということ

Engineering Manager Meetup #2 を開催しました。 engineering-manager-meetup.connpass.com 前回は開催直後に熱と勢いだけで6,744字の雑文を書いてしまったので、今回は開催から約2週間経ってクールダウンした状態で振り返り記事を書いてみました。結果なんと5,044字に収まり、約25%の削減に成功です。 @aomoriringoさんにより振る舞われた至高のハム 3行まとめ 第1回に引き続き盛り上がりを見せたことで再現性があるとわかった 回を重ねることやBYOB*1など、主体的参加を促す工夫ができそう 第3回はプレゼンありの形式でやります。2018-12-14(金) connpass ページはこちらです Engineering Manager Meetup とは? イベント開催の動機や趣旨については Engineering Man

海外と日本でのソフトウェア開発職の文化を振り返ってみた – reyabe – Medium を読んだ。 全体としてとても面白く読ませていただいた中で、特に気になるところがあったのでそれに関する所感を書いてみる。「エンジニアのチーム構成・組織構成」というパートだ。 ちなみに、どちらが良い悪いみたいな話でもなければ同記事に対する異論反論でもない、ということは初めに強調しておきます。 ヨーロッパの開発チーム構成 同記事の「エンジニアのチーム構成・組織構成」に以下のようにある。 それに対し、ヨーロッパの開発チームはよりプロジェクト・プロダクトを実現するための一時的なタスクフォースという意識の方が強いと思います。あるプロジェクトが完了して次に進む際にメンバーがシャッフルするのも普通で、場合によってはプロジェクトではなくタスク単位で、あるタスクをこなすスキルを持つエンジニアが必要であればその人が一時的

この半年間はソフトウェアエンジニアとしてのアウトプットに積極的になるよう意識的に行動してみたので振り返ってみます。長くなってしまったので3行でまとめるとこんな感じです。 成長と刺激を求めて OSS contribution や登壇やイベント運営を頑張ってみた 成長したかはわからないが、知り合いが増えたりして刺激を受けることが多くなった これからも続けていくが持続可能なペースにしたい この半年間、登壇とかイベント運営とかに積極的になるよう"試験運用-セルフコントロール-"してきたのでそろそろ振り返ってまとめたい— 広島の粗大ゴミ (@ohbarye) 2018年9月27日 だいたい2018年上半期の話ですが一部期間外の話もあります。 なぜアウトプットを増やすか 唐突ですが、現職では日常の業務を漫然と続けるだけで成長するフェーズは終わったのかなぁと思っています。新しく何ができるか、何をすべきか

もう2週間も前のことというのに驚きつつ、ISUCON8に出場して予選敗退した記録。来年に向けたメモ。 チーム編成 メンバーは2人で、両名とも「ふだんやらないことをやりたい」という動機で初参加した。 @RyotaKatoh 機械学習エンジニア GoによるWebアプリも書ける Webアプリをチューニングするようなのは「ふだんやらないこと」なのでアプリのコード変更をやることに @ohbarye Webエンジニア Ruby on RailsによるWebアプリ、ReactなどによるSPAがメイン業務 Golangやインフラまわりは「ふだんやらないこと」なのでh2oやmariadbを見ることに Golang力は、前日までにTour of Goを流し読みした程度 選択言語はGolang。 チーム名 sayotan は参加できなかった第三のメンバー名から。 結果 さきに結果を書くとBest Score:

過熱する採用市場の盛り上がりにあわせて感じたことについて言語化を試みているが未だ納得解が得られずにいる。書きかけの Scrapbox は随時更新していくとして、現時点での dump をとっておく。 誰がジュニアを育てるのか - ohbarye 主にソフトウェアエンジニア採用の文脈で「誰がジュニアを育てるのか」ということについて。 *1 「優秀な人間だけを採る」という採用戦略 著名テック企業が自社の採用戦略について語った本が出版されるたびに話題になる中で「優秀な人間だけを採る」というのが採用戦略として認知されるようになってきたのを感じる。Netflixの最強人事戦略やWork Rules!あたりが代表的…かどうかは知らないがあくまで自分が読んだ中の代表。世には同じことを謳う書籍や記事がもっとたくさんあるかもしれない。 ※「優秀」という言葉を定義するのは難しく、そしてまた常に相対的なものだが、

Engineering Manager Meetup をやります - valid,invalidで宣言した通り Engineering Manager Meetup #1 をやりました。本記事では感想と振り返りを、イベント運営者と参加者の両視点から忘れないうちに記しておきたいと思います。 connpass.com 本記事の主な想定対象読者はイベントに参加されなかった方です。#em_meetup ハッシュタグ を目にして興味が湧いた方や、Engineering Manager Slack に入っているがイベントには来られなかった方々に""現場の様子""をお伝えするのが目的です。 （参加された方にとっては既知のことばかりかもしれませんが、イベントを追体験したり主催者の思考をのぞき見することで楽しめる可能性があります） 3行で要約すると 気づいたら6,000字以上も書きなぐっていたので要約しまし

詳細の確認および参加申し込みは以下のページからお願いします。早速定員になってしまったようなのですが増枠も検討中です。 (追記) 40名に増枠しました。 connpass.com 動機 いちエンジニアリングマネージャとして、エンジニアリングマネージャ・エンジニアリングマネジメントに興味・関心・知見・意見・失敗談・一家言ある方々と話してみたい。 "エンジニアリングマネージャ"の曖昧性 イベント概要欄に書いたとおり、（少なくとも自分が観測しているWebサービス業界隈では）エンジニアリングマネージャ職について統一された定義・見解を見ることはほとんどありません。 エンジニアリングマネージャというポジションは組織が成熟する過程において戦略的または偶発的に発生しており、会社や人それぞれによって思い描く姿やその実態・運用が異なるようです。*1 また、スタートアップ初期においては必要性が認識されることはあま

Cybozu Meetup で聞いた採用文脈でのブログ運用の話と、Quipper のブログ再開の話です。*1 Quipper のブログ再開 所属する Quipper でも最近プロダクトチームのブログを再開しました。 quipper.hatenablog.com 自分も早速記事を書き、本日公開されました。 quipper.hatenablog.com 目的は中長期的な採用活動の活性化 目的は中長期的な採用活動の活性化です。具体的には、中高生向け教育事業という性質柄「Quipper が何をやっているか」が候補者（エンジニア）にとって分かり辛いという課題の解消と、エンジニアブランディングイメージの構築を目指します。 続けていくための方針 再開するにあたってどのように運用するのが望ましいかを社内で議論し、おおむね以下のような方針を定めました。 blog は当番制で書く blog 書くのは必ず業務の

「転職が成功か失敗か決まるのは(退職|転職)エントリを書いた時じゃない、入社から半年経ってからだ」とうそぶきつつ大した振り返りもせず早2年… というわけで Quipper に転職してちょうど2年が経過したので自身のことを中心に振り返ってみる。 2年前 思えばよく採用されたな…と思う、タイミングが良かった。現在は採用のハードルが上がっているので今の Quipper に2年前の俺が応募したら不採用になるだろうなと思う。これはチームの成長の証左でもあるので良いことだ。 転職まで 当時の俺はSIer (システムインテグレーター) に勤務する新卒3年目の SE (システムエンジニア) で、1年目はちょっとした Java の研修というトンネルを抜けるとそこはテスト仕様書と人力テストの国…。技術力を高めたいと主張して色々仕事を振ってもらってもコードを書く時間は半分も無かった。日曜プログラマとしてたまにコ

review 待ちの Pull Request 一覧を Slack に定期的に通知する仕組みを作ってみた。 完成品 以下の画像は朝11時 JST に自分のチームのレビュー待ちリストを表示している様。Slack の絵文字で「いまレビューしてますよ〜」「merged!」みたいな表現をするのはエンジニアしぐさだ。 private repo だと味気ない（かつ業務情報なのでモザイクだらけだ）が、public repo の PR だと Slack が自動的に展開してくれるのでよりファビュラスに見える。 仕組み 3行で書くと… review-waiting-list-bot という Slack bot が Heroku にデプロイされている*1 メンションされると GitHub API を叩いてプルリクエストを収集し、まとめて Slack に post する 定期的に実行する仕組みは Slack のリ

先週日本にインドネシアのプロダクトマネージャーが来た時に「レビューに時間がかかりがち」「結果として開発のリードタイムが予測しづらくなっている」という悩みを相談してくれた。そのときに「コードレビューを会話しながら行う取り組み - Hatena Developer Blogとかどうですかね、日本のチームでも “レビュー会” ってのをやっていますよ」と伝えようとしたが日本語の記事を渡すのも気が引けたので「あとでまとめておく」ってことにして社内向けに “Encouragement of Review Meeting” という snippet を書いた。 これを日本語でも書き直してみる。 背景 最近プロダクトマネージャーと開発者間でレビューに関してこんな感じの問題があるらしい。 ~ ある日 ~ マネージャ「進捗どう？」 開発者「だいたい終わってレビュー待ちの状態かな」 マネージャ「オッケー」 ~ 別

Quipper のエンジニア採用には必ず候補者の同僚となる人*1が参加する。いつからかはわからないが自分が候補者として採用面接を受けた昨年の7月頃にはそうなっており、今では自分が採用側として履歴書を読み、面接に参加し、コードレビューを行うようになった。 コードレビューについては以下を参照。 Quipper のエンジニア採用プロセス コードテスト編 - @kyanny's blog - 応募直後のレジュメを見て下す判断や、面接の時間内での行われる会話の内容や質問は基本的に各自に委ねられている。事前に得られた候補者の情報から面接前に「今の採用方針は○○だから、こういうところを今回は見てみよう」「この経験を掘り下げてみよう」程度の認識合わせをすることはあるが、とりわけシステマティックな進行に沿っているわけではない。 そういうわけでこれまで数十名の候補者のレジュメを見て十数人程度の候補者と会ってき

前に社内チャットで流れてて初めて知った。 他人の変更を上書きするおそれのある git push --force でなく、最後に fetch したタイミング以降に他人が push していたら失敗する git push --force-with-lease を使う方が良い。 --force considered harmful; understanding git's --force-with-lease - Atlassian Developers Quipper では GitHub flow のような開発フローを採用している。 各開発者が feature branch を作成し、master / develop branch へ pull request を作る流れだ。 他人と修正箇所が重なってコンフリクトした際には rebase が必要で、 rebase 後の内容を push する際には