ウェビナー『CTOとVPoEが語る、採用とオンボーディング で失敗しないためのベストプラクティス』での発表資料です。 オンボーディングにおいて 注意すべき力学について共有しつつ、 チームとして工夫していることをご紹介しています。新入社員=中途入社の社員さんを"主に"想定しています。 【運営しているサービス情報】 - ITエンジニアの方向け - https://lapras.com - エンジニア採用したい企業の方向け - https://scout.lapras.com

先日、『質の高い課題解決できる人が「こうすべき」を主張すべきだけど、それが苦手な人も多いからチームで解決したら良いのでは』という雑な考えを書いたのですが、僕のブログにしては多くの人に読んでもらえました。 読んでくれた人、ありがとうー fujii-yuji.net ただ、この記事へのコメントで「質の高い決定ができない上司や社長はダメだろ」みたいな意見もそれなりに多くあって、けっこう驚いたのですよね。 僕が雑に書いたわかりにくい文章だったことが原因で誤解されてしまったのでしょうけれど、今日は補足として「部下がやれることを上司もやれる必用はないですよね」的な話を書きます。 上司が「自分ではできないからお前に頼むわ」と言ってくれたお陰で、"上司のして欲しいこと探し"をしなくて済んだ。 僕が若いころお世話になった上司はよく「自分ではできないからお前に頼むわ」と言っていました。 実際のところ、その上司

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

ストックマークの社内研修の公開版※資料です。 （※実際に研修で利用したものとは異なります）

AWS DevDay 2023 登壇資料

1on1 で伝えたので外にも書いておく。 プロダクトやチーム、メンバーのフェーズ まず現状分析。 自プロダクトは PPM で言う花形、金のなる木、問題児、負け犬のいずれに当たるのか 勢い MAX でめっちゃ盛り上げるのか、地味に役割を達成するのか。自チーム全集中なのか他チームのフォローに回るのかみたいな方針が変わる 自チームは エラスティックリーダーシップ で言うサバイバルモード、学習モード、自己組織化モードのいずれに当たるのか チームを改善しなければいけないのか、プロダクトだけを見ていて良いのか。チームで改善できるのか、リーダーや外部の強い意志が必要なのか 各メンバーは、期待される役割において SL理論 で言うとどのフェーズなのか 指示的行動が必要だとマイクロマネジメントすることになり、マネージャ/メンター的な人/行動を増やす必要がある 役割を網羅しているか こういう軸で考えていることが

こんにちは。バクラク申請・経費精算チームでエンジニアリングマネージャーをしているsh_komineです。 7月はLayerXエンジニアブログを活発にしよう月間 ということで、今日は最近自分が「開発チームのマネージャーとして意識しているチームのCapability 」について話をしようと思います。LayerXのテックブログでは数少ないマネジメント系の話です。 私自身、エンジニアリングマネージャー歴自体は1年ほどなので、まだまだ足りない面もあると思いますが、誰かの参考になればと思います。 開発チームとCapabilityの定義 開発チームの単位もいろいろとありますが、基本的にはチームとして意思決定し、開発活動を続ける最小単位のチームを想定しています。開発エンジニアにプロダクトマネージャー、チームによってはデザイナーやQAなども含みます。自分の場合は職能横断型のプロダクト・顧客に向き合うチームを

タイトルそのままのエントリーです. 気がつけば現職含めて「エンジニアのマネジメント」を行う職種を6年ちょいやらせてもらっています. マネジメントをする・しないを含めてキャリアパスどうする? マネジメントをやるとして何を教科書にしたら? 今どきの開発スタンス・マネジメントってどうしたら? みたいな悩みや迷い（&やっぱコードを書くエンジニアの仕事良さそうという脱マネジメントの検討*1）は常にありますが, 今年はそれに応えてくれる良著3冊に出会いました. スタッフエンジニア エンジニアのためのマネジメント入門 人が増えても速くならない 以上の3冊です. この3冊です（結論） スタッフエンジニア　マネジメントを超えるリーダーシップ 作者:Will Larson日経BPAmazon エンジニアのためのマネジメント入門 作者:佐藤 大典技術評論社Amazon 人が増えても速くならない ～変化を抱擁せよ

プロジェクトマネジメントといえば「進捗確認」と思っている人も沢山いると思いますが、私は進捗確認という行為そのものに否定的です。 このエントリでは、進捗確認という行為がいかに無意味であるかという話および、進捗管理として行うべきことを書いていきます。 誰かのプロジェクトマネジメントの参考になればと思います。 ※ 進捗管理が不要という話ではありません 進捗確認の定義このエントリでの進捗確認は下記の定義とします。 複数人が関わるプロジェクト等において、プロジェクト等をマネジメントするべき立場にある人間が、プロジェクトの所属メンバーに対してタスクの進捗状況を口頭・テキスト等で直接確認する行為 少し難しい言葉で書きましたが「進捗どう？」といった質問およびその回答からなる一連の流れだと思ってください。 なぜ進捗を確認したくなるのかプロジェクトマネージャー（PM）の仕事のひとつに納期の管理というものがあり

みなさんこんにちは。ジメジメとした日が続きますがいかがお過ごしでしょうか。SmartHRのプロダクトマネージャーryopenguinです。 今回は、私が複数のプロダクトチームを経験して学んだ「兼務のコツと反省」をお届けします。 「プロダクトに対してPMが少ない」「PMの採用に苦労している」といったみなさまの参考になれば幸いです。 なぜ兼務をはじめたか 2022年9月から、私はタレントマネジメントプロダクト「従業員サーベイ」と、現在未公開の新しいプロダクトのPMを兼務しています。 弊社では、単一のプロダクトに注力するのではなく、連携を前提に複数のプロダクトを提供する「マルチプロダクト」化を進めています。昨年の夏ごろ、とある新規プロダクトが必要と判断され、開発チームを組成することになりました。 弊社の新規プロダクトはSmartHR基本機能との連携が前提であり、その基礎的な知識が必要です。さらに

NTT Comの技術顧問が「目標設定の基本」について講演する「エンジニアリングマネージャーと目標設定」。ここで株式会社アトラクタ Founder兼CTO / アジャイルコーチ兼NTT Comの技術顧問の吉羽氏が登壇。目標設定のやり方とその運用方法について話します。 「定量的に判断できる目標が良い目標」なのかはまぁまぁ怪しい話 吉羽龍太郎氏：さて、本題に入っていきたいと思います。今日はどういう方が（このセッションを）聞いているかはわからないんですが、目標設定の時に、特に上司の方からよく言われる話ってこういう話なのかなと思います。 「目標を設定する時は、達成できたかどうかを定量的に判断できるようにしましょう」。「定量的に判断できる目標が良い目標なんだ」と。（言われたことがある方は）リアクションとかで教えてくれるとうれしいです。 僕もいろいろな会社に勤めましたが、若い頃とかによく言われた記憶があ

前提 この記事は内製開発をしているSaaSの中の人であるエンジニアが、SaaSの内製ソフトウェア開発をする上での話として書いています。 前ふり 「スクラムで生産性は上がらないしリリーススケジュールが狂いまくりなんですよ」 「何が原因なんですか？どうすればいいんですか？」 という相談を受けました。 NDAを書いてから、どれどれとチームの状況を見てみました。 該当チームのスプリントゴール 該当チームのスプリントゴールはこんな感じでした。 QAフェーズのプロジェクトAを、QA作業を完了してリリースできる状態まで進める 実装フェーズのプロジェクトBを、フィーチャーの実装率を50%まで進める 設計フェーズのプロジェクトCを、要確認な点を除いて実装レディーな状態まで進める スプリントゴールが3つありますね。とても面白いですね。 思わずボンドルド卿みたいな反応をしたくなりますがここは先に進みましょう。

ビジネスリサーチラボ主催のセミナーより、曖昧な状況に対してどの程度寛容であるかを表す「曖昧さ耐性」をテーマに、ビジネスリサーチラボ 代表取締役の伊達洋駆氏、コンサルティングフェローの神谷俊氏が登壇した回の模様をお届けします。本記事では神谷氏より、「曖昧さ耐性が高い人」の育て方について語られました。 “曖昧さ耐性”が高い人は、何を見ているのか？ 伊達洋駆氏（以下、伊達）：では、神谷さんにバトンタッチしたいと思います。よろしくお願いします。 神谷俊氏（以下、神谷）：伊達さん、ありがとうございました。みなさん、こんにちは。株式会社エスノグラファーの神谷俊と申します。後半パートは、今から20分間ぐらいお時間をいただいて、私からレクチャーをさせていただきます。 先ほどもあったように（質問を）すでにいくつかいただいてますが、私のパートでも聞いてみたいことなどあれば、よろしくお願いします。 さて、私のパ

転職・求人情報サイトのtype エンジニアtype 働き方 良かれと思ってやったのに…元Google人事が説く、日本の管理職がやりがちなエンジニアの心理的安全性を下げるNG行動四つ 2023.05.12 働き方 GoogleCEOチーム ここ数年で「心理的安全性」という言葉の認知が広がっている。 特に、人材不足が課題となっているIT業界においては、エンジニアのエンゲージメントを高めたり、離職率を下げたりするために心理的安全性の高い職場づくりに取り組むマネジャーも多いのではないだろうか。 しかし、「心理的安全性の高い組織」を、「対立のない組織」「チームみんなの仲が良い組織」だと考えているとしたら、認識のアップデートが必要だ。 「エンジニアが意欲的に働ける組織とは、何に対しても『いいね、いいね』と肯定することを良しとする『Nice』なチームではなく、時には否定することも恐れず、率直な意見のやり

NLP2024 参加報告LT ~RAGの生成評価と懇親戦略~ / nlp2024_attendee_presentation_LT_masuda

## 概要 エンジニアのキャリアパスの1つに「マネジメント」があります。エンジニアリングマネージャーとも呼ばれるこの仕事は、エンジニアにとっては多くの場合未知の領域です。その領域はいくつもの専門領域から成り、学ばなければならないことは多分にあります。本セッションでは、『エンジニアのためのマネジメント入門』で取り上げた「マネジメントの領域」を紹介して、各領域を解説します。 ## イベント https://forkwell.connpass.com/event/276110/

イノベーション イノベーションを起こすためのスキルを習得し、業務に活かす方法を学びます。

はじめに ちょっとつぶやいたら思いのほか需要がありそうだったので、簡単にまとめておきます。 おことわり これを書いておけば、すべての不幸を避けられるというものではありません 提出先との関係性次第では、書かないほうがいいこともあるかも 私自身が普段提案している内容が、すべて記載されているわけでもありません（うろ覚えで書いてたり、大人の事情） これを流用しておこったすべての事項について、何らかの責任をとることはできません 本稿では請負による開発を想定しています でも共有することで、この業界の不幸が減ればいいなということでつらつら書いてみます。 他にもあるようなら、Twitterなりコメントなりで提案してもらえると嬉しいです。 前提条件を書く目的 見積・提案書通りに、実施するために必要な条件を明確にする 条件を逸脱したときに、どうなるのかハッキリさせる 上記は概ねつぎのとおり 実現が不可能になる

7/27（水）19:00~地味PM meetupの登壇資料です。 ▼口頭でお話しした内容も補足しているnote版はこちら https://note.com/mignon53/n/na2a050e6db81