サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
大谷翔平
daiksy.hatenablog.jp
仕事のひとつとして、技術組織におけるタレントマネジメントに取り組んでおり、勉強したことを簡単にまとめておく。 タレントマネジメントと一口に言っても、その類型にはいろいろとあり、マッキンゼーの"War for Talent"が書籍も出版されていてよく知られている。これは、簡単に説明すると、社員を成果の発揮度でA, B, Cに位置づけ、組織をAの人材で充足し、Cはなるべく数を減らす、という戦略をとる。選別の要素の強いマネジメント手法であり、あまり日本型の人事管理には馴染まない。そもそも、組織のすべてをA人材で満たす必要はあるのか、A人材のみで充足するためのコストに見合うのか、といった議論もある。 マッキンゼーの"War for Talent"は選別的なアプローチであり、逆に人材すべてをタレントとみなすマネジメントは、包摂アプローチと分類される。 他にもタレントマネジメントの類型はいろいろとある
はてなにエンジニアリングマネージャとして入社して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章 スクラムのスケーリングと大規模の難しさ アジャイルコーチになんの前提もなく「スクラムをスケールするにはどうす
コーチズクリニックとは? こちらのスライドが詳しい。 speakerdeck.com Regional Scrum Gatheringや、スクラムフェスなどのカンファレンスで設けられる相談の場 カンファレンス参加者が、同じくカンファレンスに参加しているアジャイルコーチに個別相談ができる アジャイルコーチは、自分の得意分野と、カンファレンスのセッションなどに参加していない時間を表明しておく 相談者はそれを見て、自分の相談内容に答えてくれそうなコーチを指名して相談する これを社内でもはじめてみた ぼくの勤める会社にスクラムマスターギルドという集まりがある。毎週1回、30分程度集まって、各チームのスクラムマスターやアジャイルコーチが知見を交換したり、悩みを相談したりする場がある。気軽に相談ができて良い場なのだが、もう少し踏み込んだがっつりした相談をしたいときがある、と意見があった。 そこで、社内
リモートワークは会議室という物理的な制約がないので、ミーティングし放題だ。加えて、オフィスでその人の席まで歩いていってちょっと声をかける、ということができないので、そういうことをしたい場合は30分のテレビ会議を設定する、というようなことになる。 マネージャーという仕事をしていると、前述のような状況とあいまって1日の大半がミーティングで埋め尽くされてしまう。 たとえば、自分の勤務時間範囲のカレンダーから、「定例ミーティング」だけを抽出してみても以下のような有様だ。 このように、10時から16時までのコアタイムは定例ミーティングで埋め尽くされている。これに、採用面接であるとか、突発的な相談ごと、四半期ごとのミーティングなどが数少ない隙間をさらに埋めていく。 ミーティングによって生じるコンテキストスイッチに脳は破壊され、ミーティングの合間の30分間はお手洗いや次のミーティングの準備、あるいは脳を
いよいよ RSGT2022が迫ってきましたね! これはRSGT2022を待ちわびるアドベントカレンダーの記事です。 qiita.com RSGT 2022では、1月5日の14時からRoomCにて「Scrum@Scaleの理論と実装 - 組織をリファクタリングしながらスケールする」というお話をさせていただきます。 Scrum@Scaleを採用して運用しているチームに今年になって参画し、そこでの取り組みや「Scrum@Scaleってどういうものなの?」といったお話をさせてもらう予定です。 スクラムマスターとしての7ヶ月 さて、ぼくは2021年5月に今の会社にエンジニアリングマネージャーとして入社しました。現在のミッションは、Scrum@Scaleで運用されている部門全体を統括して、その開発プロセスを整えていくのが仕事です。他にも、社内にスクラムを横展開したり、採用・育成などエンジニアリングマネ
これは Chatwork Advent Calendar 2日目のエントリです。 また、このエントリの公開日翌日に開催される"だいくしーのスクラムBar #1" で取り扱うテーマについての詳細な解説記事も兼ねています。 chatwork.connpass.com スクラムマスターって何をする人なの? 本項ではこれについて少し考えてみたいと思います。また、ぼく自身が普段どういうことを考えながらスクラムイベントや、その他の仕事をしているか、なども書いてみようと思います。 スクラムマスターは、ソフトウェア開発に関する他の職種と比べても、具体的な職務内容がわかりづらい役割なのかな、と思います。少し乱暴な言い方をしてしまうと、デザイナーがいなければデザインはできないし、プログラマーがいなければアプリケーションコードを書くのはとても困難です。しかし、スクラムマスターがいなくても別に開発はできます。 そ
アジャイル開発をはじめて体験すると、いろいろな考え方を身につけるために苦労をすることがあります。 特に、相対見積もりや、ベロシティによる経験主義的な見通しの取り方について、実際に経験せずに理解するのは難しいようです。 そこで今日は、日常生活の中で馴染みの深い考え方を使って、説明を試みてみたいと思います。 「コース定数」でアジャイルな見積もりを考えてみる 国民的な娯楽である登山をやられる人なら誰もが知っている「コース定数」という考え方があります。みなさんもご存知かと思いますが、簡単に解説します。 山は、事前の計画がとても重要でありつつも、実際に登ってみないとコースの状態や、自分の体力がその山に適しているのかがわかりづらい遊びです。そういう意味では、経験主義的なアプローチが必要なソフトウェア開発に似ているとも言えます。 交通機関やレスキューの体制が整備されている街中と違い、山は自分の体がすべて
会社でひとつのチームのスクラムマスターをやっていて、デイリースクラムがオンラインということもあってか、なんとなくだらだらと終わっていくのが気になっていた。 前職では、いつのころからかデイリースクラムの終わりに掛け声をやって終わるという流れだったので、それを今のチームでもやってみることにした。 具体的には、デイリースクラムの最後に、ぼくが「今日も1日がんばるぞー」と声をかけるので、メンバー全員がそれにあわせて両手をあげながら「オーッ!」と発声するというやつ。 こういうノリが苦手な人もいるだろうから、嫌なら反対してもいいよ、という感じで伝えると、とくに反対意見がなかったので続けることにした。 やってみると、やはりなんとなくメリハリが生まれて、元気になる気がする。 Twitterでそんな話をしているとこんなリプがあった。 ボーイスカウトには班(チーム)の掛け声的な班呼というものがあったりするので
新しい会社に入社して1ヶ月半経った。 今回はエンジニアリングマネージャとしてのポジションでの採用で、過去4回の転職はすべてアプリケーションエンジニアとしての採用だったので、その差分に若干戸惑っている。時勢的にフルリモートワークというのも大きい...。 "成果"が見えにくい仕事に対する実感をどのように得るか まずひとつは、"成果"に対する手応えが異なること。エンジニア採用であれば、「入社最速RTA!!」などと言いながら、とりあえず小さなタスクを拾って入社後1週間以内くらいに自分の出した最初のプルリクエストがマージされれば、「最初のステップは超えた」という実感を得ることができた。 マネージメント職では、そのようなわかりやすい成果が見えづらい。そもそも、自分の打ち手が効果を発揮するのが翌月、みたいなリードタイムも珍しくないので、自分はちゃんと給料分働けているのだろうか、とまぁまぁ不安になる。そこ
コロナ前にたびたび集まって酒を飲んでいた友人たちと、このご時勢で集まれなくなったのだが、彼らはなにやら最近登山に熱中しているらしい。そんな様子をしばらく対岸から眺めていた。 事の起こりは3月の末。その友人たちと琵琶湖疏水を大津から蹴上まで歩くハイキングが計画された。長らくの在宅勤務の運動不足解消に、近頃は自宅の近所を1~2時間歩くなどをしていたのだが、毎回同じようなコースを歩き続けて飽きていたので、気分転換にとても楽しみにしていた。 そのうち、友人たちは疎水歩きの前座として2, 3時間ほど登山をするのだという。京都から大文字山を越えて大津まで行き、そこで自分と合流するのだとか。いったい登山とはそれほど楽しいものなのか。物は試しに、自分もその行程に混ぜてもらうことにした。 どうせやるならと登山靴とハイキング用ザックを買い、参加したその様子がこれである。 大文字山・如意ヶ岳・長等山 / だいく
Nexus, Scrum@Scale, LeSS, SAFeなど、スクラムチームをスケーリングする手法はたくさん存在する。 しかし、アジャイルコーチなどに、「スクラムをスケールするにはどうすればいいですか?」と聞くと「そもそもスケールをするな」と言われることもある。ぼくも基本的にはこれに同意する。 コンパクトな職能横断型のチームで、短いサイクルで高速に、安定したペースで開発をする。これをずっと続けることができるのならばそれが一番良い。 なのになぜ、人々はスクラムチームをスケールしたくなるのか。なぜこんなにたくさんのスケーリング手法が存在するのだろうか? そういうことを考えてみた。 最初から人がたくさん必要な場合 そもそも最初からスケールされたチームでやりたいパターンがある。大規模な開発などはそうだろう。 小さくローンチして、インクリメンタルにユーザーフィードバックを受けながら開発できれば理
12/22(火)に発売の書籍、『わかばちゃんと学ぶサーバー監視』と、それに先駆けて本の前半部分を技術書典で頒布した『マンガでわかるサーバー監視入門』を監修させていただきました。 わかばちゃんと学ぶ サーバー監視 作者:湊川あい発売日: 2020/12/22メディア: 単行本(ソフトカバー) ここでは本の宣伝をかねて、監修って何をやったの? みたいな裏話を書こうと思います。 きっかけは? ぼくは普段Mackerelというサーバー監視SaaSの開発チームのディレクターをしています。あるとき、著者の湊川さんと出版社の編集者さんから監修のご相談をいただき、お引き受けすることになりました。扱っているプロダクトの性質上、半分仕事みたいなものなのですが、仕事自体は個人でお請けした仕事という形です。 湊川さんからいただいたお話は、当初からMackerelを中心に据えてサーバー監視を説明する本にしたい、とい
社内勉強会で発表した内容を外向けに編集して書きます。 ぼくが勤める会社では、エンジニアメンターという制度があります。 developer.hatenastaff.com エンジニアメンターは定期的に1on1を開催するのですが、1on1は突き詰めて考えていくととても難しいものです。それこそちゃんとやろうと思うと、コーチングの専門的なスキルが必要だったりするわけですが、エンジニアメンターが全員プロ並みのコーチングスキルを保有する必要があるかというと、そんなことは無いと思っています (マネージャーなどの管理職であればそれなりにちゃんと勉強しておいてほしいですが)。 そこで、社内勉強会でエンジニアメンター向けに、このくらいのポイントを抑えておけばいいですよ、というのを伝えました。 ポイントは2つだけ エンジニアメンター制度における1on1は、コーチングなどの専門的なスキルを学んで取り組まなければな
はやいものでもう12月。今年もアドベントカレンダーがはじまりました。 本エントリは、Mackerelアドベントカレンダー2020の初日です。 監視は難しい Mackerelがローンチしてから6年が経ちました。この6年間、ぼくもほぼMackerelに関わる仕事をし続けています。6年前と比べて、多少はソフトウェア開発・運用の現場でも、監視の民主化みたいなものが浸透してきたかな、というのは感じつつあります。devopsというワードがバズワードではなく、エンジニア文化をあらわす一般的な用語として認知されつつあるのもそのあらわれでしょうか。 Mackerelを導入すれば、簡単に監視をはじめられますよ、と我々はお客さんに対して説明するわけですが、そうはいってもやはりまだまだ難しいところもあると思います。6年前に当時アプリケーションエンジニアとして正式ローンチ2ヶ月後にチームにジョインした当初のぼくなど
チーム全員フルリモートワークになって間も無く2ヶ月になろうとしている。 この傾向そのものは今後段階的に弱まっていくだろうが、リモートワークの取り組みは以前よりも促進されていくのだろう。 元々自分のチームは新しい取り組みに前向きなチームで、いろいろなチャレンジをこれまでにもやってきたが、この2ヶ月はさらにハイペースで様々なチャレンジを行ってきた。この2ヶ月を振り返って、その取り組みを書いておこうと思う。 夕会を新しく導入 チームではこれまで、昼の休み時間明けにデイリースクラムを担う昼会をやっていたが、これに就業時間直前の30分の夕会を取り入れた。 任意参加で、雑談をするための会。毎日時間になるとSlackにチャンネルにGoogle MeetのURLが流れてくる。 オフィスワークがゼロになり、これまでオフィスに集っているメンバー同士の雑談がなくなったことを補うのが目的。 ただ、これまでにも同様
ワーキングアグリーメント(Working Agreement)をご存知だろうか。 チームにはさまざまな暗黙の了解がある。たとえば、毎日14:00から昼会(デイリースクラム)をしますよ、とか、実装に着手する前にデザインドキュメントをこのフォルダに作ってレビューに出しますよ、とか、そういうやつである。 ワーキングアグリーメントは、こうした暗黙の了解を明文化し、チーム全員で合意を得ることを言う。 slide.meguro.ryuzee.com スクラムチームは、メンバーに自律的に振る舞うことを要求する反面、メンバーに非常に大きな裁量が与えられる。メンバーは基本的に与えられた裁量の範囲であれば、プロダクトのゴールを達成するために何をしてもよい。しかし、我々はチームとして仕事をしているわけなので、チームとしてアウトプットを出すためには個人の自由を制限するようなルールも必要である。たとえば、いくらメン
最近の感染症対策による社会情勢で、リモートでの対応が可能なものはそうしましょう、という雰囲気がある。 ぼくもここ数日、特に会社に行く強い必要性がない日は、通勤による感染リスクを気にして自宅で仕事をしている。通勤する場合は40分ほど電車に乗る必要があるので、混雑はしていないにしてもまぁまぁ気になるからだ。 自分が所属しているチームはリモートワークは慣れたもので、フルリモートの人も1人いるし、他のメンバーも日によってはぼくのようにスポットで自宅で仕事をすることもある。 職場だけではなく、たとえば自分がスタッフとして関わっているカンファレンスや、コミュニティのミーティングなどは、リモートで開催されることが多い。そもそもスタッフの居住地が日本全国に散らばっていて、物理的に集まることが難しいからだ。これももう慣れたもの。 このように、リモートでの仕事やミーティングにはなんの抵抗もない、と思っていたが
ぼくがディレクターを勤めているMackerel開発チームも最近だんだん大所帯になってきた。 エンジニアやSREの他にも、デザイナ、セールス、CREなど職種もさまざま。 同一職種同士は毎日顔をあわせているけど、他職種の人とは案外接点がなかったりするので、相互理解を深めるアクティビティを試してみた。 今回試したのは、"Welcome to My World"というアクティビティ。詳細は『ゲームストーミング』という書籍で紹介されている。 ゲームストーミング ―会議、チーム、プロジェクトを成功へと導く87のゲーム 作者: Dave Gray,Sunni Brown,James Macanufo,野村恭彦,武舎広幸,武舎るみ出版社/メーカー: オライリージャパン発売日: 2011/08/20メディア: 単行本(ソフトカバー)購入: 9人 クリック: 164回この商品を含むブログ (31件) を見る
ありがとうございます。 出典 pic.twitter.com/XBXMywX8A4— Takafumi Yoshida (@zephiransas) 2019年4月9日
今期の目標設定を決めましょう、というときに、よく「〇〇の機能を期日どおりにリリースする」と書きたくなりがち。ぼくも以前はよく書いていた。 マネージャの仕事をそれなりの期間やっていくうちに、この考え方はまったく意味がないな、と思うようになった。 リリース日を遵守する、というのは、プロダクトのビジネス価値を生み出す要素の一つにすぎない。期初にたてた予算が、この日にリリースされることを前提に計画されている、とか、競合製品よりはやく価値を出すためにはどうしてもこの時期にリリースしたい、といった感じだろう。 なのでリリース日を目標にするのはなんの問題もない。当然そのように振る舞うべきだ。ただ、これが評価に結びつくととたんに破滅する。 リリース日遵守を基準点。遅延すると減点、前倒しで加点。こんなふうにしてしまうと最悪。 開発を進めるうちに、どうしてもリリース日に間に合いそうにない。スコープを絞って間に
先日、社内でとあるチームからチームビルディングの依頼を受けました。 チームリーダーから要件をヒアリングしたところ、チームの特性としては以下のように整理することができました。 期間限定の短期決戦プロジェクトチーム 各チームから精鋭が集められた混成チーム チームビルディングということで、最初は無難にドラッカー風エクササイズをやろうかとも考えました。しかし、前述のような文化的背景が異なるチームから集まった短期決戦型のチームでは、もう少しコントラストの強い自己認識が必要ではないかと判断し、別の手段をとることにしました。それが、「カルチャーマップ」です。 「カルチャーマップ」は、エリン・メイヤーさんが著書『異文化理解力』で提唱した、多国籍チームの相互理解を深めるツールです。異なる国の人々がチームワークをするために必要と考えられる8項目について、それぞれの特性をマッピングします。国レベルで、文化的背景
普段自分のチームや会社に閉じこもって現実と向き合い続けていると、よそのチームや会社がすごくキラキラして見えたりする。 そんなのは当たり前のことで、わざわざ自分たちのチームの辛さをアピールする理由などない。当然成功体験や、キラキラ部分だけ切り取って外に見せているだけだ。 転職を何度か経験すると分かるのだけど、転職直後はそのキラキラ部分を強烈に浴びることで異常な幸福感や高揚を得られるが、半年もすると現実が押し寄せてくることになる。 なので現実そのものとなるべく楽しく向き合っていこう。しんどいのは皆一緒なのだ。
昨日、以下のツイートをしたところそこそこ反響があった。 自分は今、コード書かずにマネジメントしかしてなくて、そんなポジションの人にそれほど価値ないでしょ、とか思ってしまうけど、こういうポジションの人がいないチームの話とか聞くと、やっぱりいたほうがいいんじゃないか、と思うし、ほとぼりが冷めるとまた自分は無価値のように思えてしまう。— だいくしー (@daiksy) February 18, 2019 エンジニアマネージャってなんか実績を示しづらいので、世の中の数多のマネージャ職に埋もれて、自分にスポットが当たりづらい、結果、キャリアに不安が拭えない、みたいなとこないです?— だいくしー (@daiksy) February 18, 2019 そこで、もう少し悩みを掘り下げてみる。 通勤電車内でiPhoneのメモに雑に書き並べただけなので、まとまりはない。 モダンなデベロッパー文化をチーム内で
このエントリは Engineering Manager アドベントカレンダー 12日目の記事です。 昨日は newtaさんのエンジニアリングマネージャのスキル習得 でした。 先日、DevLOVE関西 Engineering Manager を語ろうというイベントで1on1についてお話しました。 基本的にはスライドを見ていただければわかると思いますが、ある観点についてもう少し掘り下げようと思います。 対象読者は「人見知りでなんとなく1on1に苦手意識を持っているマネージャ」です。まさにぼくのことなのですが。 なぜ1on1に苦手意識があるのか 1on1に意味はあるのか? ぼくは普段の人付き合いに対しては人見知りですが、仕事のうえで必要なコミュニケーションはそれほど苦もなくこなせます。しかしどうにも1on1だけはずっと苦手意識がありました。それはなぜなのか。 ひとつは「メンバーが1on1に価値を
次のページ
このページを最初にブックマークしてみませんか?
『だいくしー(@daiksy)のはてなブログ』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く