はてなにエンジニアリングマネージャとして入社して2ヶ月と少し経ちました。 マネージャとしての「最初の100日」もいよいよ終盤です。 note.com 入社して最初の取り組みとして、およそ100人のエンジニア全員との1on1を実施しました。 なぜ全員とやろうと思ったか イギリスの人類学者であるロビン・ダンバーによって提唱された「ダンバー数」というものがあります。 これは、人間が安定的な社会関係を維持することができる人数の認知的な上限について提案された数字です。大雑把に説明すると、人間が相互に認識しあって社会関係を築ける人数はおよそ150人程度、というものです。 要するに1つの組織でお互いに顔見知りの状態で活動ができる集団の人数上限が150人前後であるということです。 このエントリを書いている時点で、はてなのエンジニアはおよそ100人ほどいます。つまり、はてなのエンジニア組織は、まだダンバー数

出戻りとして入社して1ヶ月が経ち、試用期間の1/3が終わろうとしています。 前回のエントリにも書きましたが、「技術グループ」というチームを横断した横串のエンジニア組織の専任エンジニアリングマネージャとして仕事を開始しました。 入社前に最初の1ヶ月でここまではやりたい、と思っていたことがおおよそできたような、少し届いていないような、そういう感覚です。 具体的になにをやったのかを、簡単に書いておこうと思います。 観察と情報収集 daiksy.hatenablog.jp ↑上記エントリでも書いたように、基本的には情報収集に最も時間を使いました。 毎朝30分CTOと1on1をし、目についた端からドキュメントを読みあさり、疑問があればまたCTOとの1on1で掘り下げる。主だったMTGを見学し、ひたすら観察する。こんな感じです。 エンジニア全員1on1 エンジニア組織専任のエンジニアリングマネージャと

今の会社に入社してから10営業日目を迎えました。 前回の転職のときにも書きましたが、マネージャーとしての転職は、他の職種とは違った難しさがあるのを実感する日々です。 マネージャーの仕事は、社内の人々からさまざまな期待をされる役割ですが、リモートワークということもあっていまいち何をしているのかみんなには伝わりづらい仕事です。そこで、毎日日報を書いたり、社内チャットの分報チャンネルにこまめに雑談も含めて吐き出したり、グループウェアに文章を書いたりしています。 このような入社直後のマネージャーの様子を、社内向けにグループウェアに投稿した文章をアレンジして書いておこうと思います。世の中の新任マネージャーの参考に少しでもなりますように。 どういう役割として入社したか はてなでは、組織・基盤開発本部エンジニアリングマネージャーという役割をもって入社しました。 はてなは、はてなブログやMackerelな

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

自分がまさに中間管理職ど真ん中なので、中間管理職の仕事を可能な限り自分なりに言語化してみようと思い、ざっくばらんに思ったことを書いていく。 今回は、情報伝達について。 組織がコンパクトであれば、中間管理職など必要はない。トップの意思がダイレクトに末端までスムーズに伝わるからだ。 組織が大きくなるにつれ、情報の伝達はスムーズにいかなくなる。 帝人の元会長である安居祥策氏が、日本経済新聞に寄稿した記事で記した「√の法則」というものがある。 100人の社員に物事を理解してもらおうと思えば、√100=10 として10回同じ説明をする必要がある。 10,000人の社員が相手になれば、100回になる。 多くの人に自分の考えを理解してもらうためには、このくらい同じ説明を何度も繰り返す必要があるということだ。全社員が集まる集会で、1回説明すれば明日からすべての社員がそのように動く、ということはない。 これ

実は密かな長年の夢だったのですが、この度、技術評論社さんから単著を出版することになりました。 Scrum@Scaleの解説書で、全編書き下ろしです。 紆余曲折があり編集者さんに本を書きませんか、と打診いただいてから2年半ほどの大仕事でした。 Scrum@Scaleについてまとまった日本語の書籍は他にはなく、複数のスクラムチームで仕事をされている現場の大きな手がかりとなるはずであると自負しています。ぜひお手にとってみてください。 スクラムの拡張による組織づくり──複数のスクラムチームをScrum@Scaleで運用する 作者:粕谷 大輔技術評論社Amazon 書籍の内容について 本書はぼくが現職でScrum@Scaleを導入した際の知見を惜しみなく注ぎました。全7章の構成です。 第1章 スクラムのスケーリングと大規模の難しさ アジャイルコーチになんの前提もなく「スクラムをスケールするにはどうす

いよいよ RSGT2022が迫ってきましたね！ これはRSGT2022を待ちわびるアドベントカレンダーの記事です。 qiita.com RSGT 2022では、1月5日の14時からRoomCにて「Scrum@Scaleの理論と実装 - 組織をリファクタリングしながらスケールする」というお話をさせていただきます。 Scrum@Scaleを採用して運用しているチームに今年になって参画し、そこでの取り組みや「Scrum@Scaleってどういうものなの？」といったお話をさせてもらう予定です。 スクラムマスターとしての7ヶ月 さて、ぼくは2021年5月に今の会社にエンジニアリングマネージャーとして入社しました。現在のミッションは、Scrum@Scaleで運用されている部門全体を統括して、その開発プロセスを整えていくのが仕事です。他にも、社内にスクラムを横展開したり、採用・育成などエンジニアリングマネ

アジャイル開発をはじめて体験すると、いろいろな考え方を身につけるために苦労をすることがあります。 特に、相対見積もりや、ベロシティによる経験主義的な見通しの取り方について、実際に経験せずに理解するのは難しいようです。 そこで今日は、日常生活の中で馴染みの深い考え方を使って、説明を試みてみたいと思います。 「コース定数」でアジャイルな見積もりを考えてみる 国民的な娯楽である登山をやられる人なら誰もが知っている「コース定数」という考え方があります。みなさんもご存知かと思いますが、簡単に解説します。 山は、事前の計画がとても重要でありつつも、実際に登ってみないとコースの状態や、自分の体力がその山に適しているのかがわかりづらい遊びです。そういう意味では、経験主義的なアプローチが必要なソフトウェア開発に似ているとも言えます。 交通機関やレスキューの体制が整備されている街中と違い、山は自分の体がすべて

新しい会社に入社して1ヶ月半経った。 今回はエンジニアリングマネージャとしてのポジションでの採用で、過去4回の転職はすべてアプリケーションエンジニアとしての採用だったので、その差分に若干戸惑っている。時勢的にフルリモートワークというのも大きい...。 "成果"が見えにくい仕事に対する実感をどのように得るか まずひとつは、"成果"に対する手応えが異なること。エンジニア採用であれば、「入社最速RTA！！」などと言いながら、とりあえず小さなタスクを拾って入社後1週間以内くらいに自分の出した最初のプルリクエストがマージされれば、「最初のステップは超えた」という実感を得ることができた。 マネージメント職では、そのようなわかりやすい成果が見えづらい。そもそも、自分の打ち手が効果を発揮するのが翌月、みたいなリードタイムも珍しくないので、自分はちゃんと給料分働けているのだろうか、とまぁまぁ不安になる。そこ

Nexus, Scrum@Scale, LeSS, SAFeなど、スクラムチームをスケーリングする手法はたくさん存在する。 しかし、アジャイルコーチなどに、「スクラムをスケールするにはどうすればいいですか？」と聞くと「そもそもスケールをするな」と言われることもある。ぼくも基本的にはこれに同意する。 コンパクトな職能横断型のチームで、短いサイクルで高速に、安定したペースで開発をする。これをずっと続けることができるのならばそれが一番良い。 なのになぜ、人々はスクラムチームをスケールしたくなるのか。なぜこんなにたくさんのスケーリング手法が存在するのだろうか？ そういうことを考えてみた。 最初から人がたくさん必要な場合 そもそも最初からスケールされたチームでやりたいパターンがある。大規模な開発などはそうだろう。 小さくローンチして、インクリメンタルにユーザーフィードバックを受けながら開発できれば理