タグ

マネジメントに関するswfzのブックマーク (30)

  • 教育は静かに終わりを告げようとしている|Jay@副業する心臓の医者

    最近話題のやりがい問題について、思うところがある。 山課長の裏note, 裏ラジオでも語られていた内容だ。 若手の方は絶対にこれらのコンテンツに触れた方が良い。 今の時代を勝ち抜くのに必要なエッセンスが凝縮されている。 僕は30代半ばで、山課長よりおそらく一世代若い。 僕らの世代はギリギリハードワークが許されたが、すぐ下の世代から働き方改革丸出しといった感じの世代である。 30半ばの「ようやく自立した若手」の立場から私見を述べたいと思う。 ++++++++++ 最近は「ライフワークバランス」や「働き方改革」といったいわゆる労働に対するネガティブな動きが盛んだ。 今の新人にとってみればもはや上記の概念は常識になっている。 ただ、断言する。 正直、上司はうんざりしている。 自分たちの享受していない制度の、よくわからないプレッシャーに戸惑っていると言ってもよい。 僕らの業界でいえば「研修医」

    教育は静かに終わりを告げようとしている|Jay@副業する心臓の医者
  • Keeper of the Seven Keys 〜Four Keysとあと3つ〜

    Mutation Testingを活用して テスト品質を考える /introduction to mutation testing

    Keeper of the Seven Keys 〜Four Keysとあと3つ〜
  • 技術戦略策定のための Fact 収集術 - スタディサプリ Product Team Blog

    こんにちは。@chaspy です。プロダクト開発部の技術戦略グループのマネージャをしています。 技術戦略グループでは、日頃開発する上での課題の投げ込みや議論、解決するための計画をボトムアップで行っています。技術戦略グループの活動については過去のアウトプットもご覧ください。 blog.studysapuri.jp また、稿のテーマである、組織やシステムの状況を把握するための Fact 収集については技術戦略 DevOps WG が担当しています。以前発表した資料もご覧ください。 このように、技術戦略グループではエンジニア1人1人が課題だと思うことを表明、宣言し、その課題をトリアージすること、および課題を評価するための Fact の発見・提供を行う仕組みが組織としてボトムアップで行える状態になっています。一方、開発部長として、事業戦略と結びつける形で技術戦略を策定する際には、現場のエンジニア

    技術戦略策定のための Fact 収集術 - スタディサプリ Product Team Blog
  • メンバー1人1人のスキルアップを促す「等級(グレード)」と「給与テーブル」|風音屋(かざねや)

    風音屋(@Kazaneya_PR)では、メンバー1人1人のスキル水準をモニタリングし、さらなる成長を促すための仕組みとして「等級(グレード)」を設定しています。プロフェッショナル人材が少しでも正当な評価とフィードバックを受けられるように試行錯誤を経てきました。 採用選考を進める中で「自分の場合はどのくらいのグレードになるのか?」というご質問をいただく機会が多々あります。この記事では、どういった考え方でグレードを設計・運用しているのかを、給与テーブルとセットで解説します。 注意事項クライアントワークを担当するAnalytics部門を想定した内容となっています。Backoffice部門の給与テーブルは試行錯誤中ですが、ベースとなる考え方は同じような形に落ち着くはずです。 人事周りのルールは今後変わっていく可能性があります。最新状況についてはカジュアル面談でお問い合わせください。 すべての人にと

    メンバー1人1人のスキルアップを促す「等級(グレード)」と「給与テーブル」|風音屋(かざねや)
  • 開発生産性フレームワークSPACEについての覚書|dora_e_m

    はじめに自分たちのチームがどういう状態なのか推定するための指標として、開発生産性フレームワークSPACEの活用を試みているところです。いまのところは概要記事を読んで、元の論文をざっくり読んで、それをもとに「自分たちで追いかけるならこういう指標かな?」って考えて、チームに共有して、みんなでどうするといいだろうねって考える段階。だからnoteとかにまとめるのは、もうすこしカッチリ言語化できたり、その指標を追うことで何か変化が起こったタイミングにしようと思っていました。 先日参加した「EMゆるミートアップ vol.6〜LT会〜」で、HACOBUのけんにぃさんが「チーム実績をSPACEで表現してみるチャレンジ」という発表をされていました。なぜSPACEで表現してみようと思ったのか、何に気をつけているのかなどがコンパクトにまとまった良いLT資料なのでぜひ目を通していただいたのですが、この発表を聞いて

    開発生産性フレームワークSPACEについての覚書|dora_e_m
  • こんなエンジニアリングマネージャだから仕事がしやすいんだなぁと思う10個のこと - Mitsuyuki.Shiiba

    最近、毎日のようにEMのいくおさん( @dora_e_m )とTwitterXでわちゃわちゃしてる。彼のポストを見ていると、ガンプラをつくるかビールを飲むかしかしていないように見えるが、それで合っている。 という冗談はおいといて真面目な話をすると、エンジニアとしての僕は彼と仕事ができている今の時間のことを当に貴重な時間だと思っている。とにかく仕事がしやすいし、いろいろな気づきを与えてくれるおかげで、自分自身の成長も感じている。 エンジニアリングマネージャとしての知識が豊富でスキルが高いというのはもちろん、人との接し方や日常的なふるまいもとても尊敬できるものなのだ。 そこで今日は、僕が彼とこの3ヶ月間仕事をしていて、やりやすい・尊敬していると感じていることの中から10個だけ簡単に紹介しようと思う。僕からいくおさんへの日頃の感謝の気持ちをあらためて書いておこうと思っただけとも言う(ふだんから

    こんなエンジニアリングマネージャだから仕事がしやすいんだなぁと思う10個のこと - Mitsuyuki.Shiiba
  • プレイングマネージャーになるために。そして自律的なチームとは何か - Tabelog Tech Blog

    初めまして。 ウェブ開発部のオペレーションチームでエンジニアリングマネージャーをしております。HAと申します。 エンジニアリングマネージャーとして試行錯誤の毎日を過ごしていますが、その中で採用にも関わっております。採用の中で求職者の方から今後のキャリアビジョンをお伺いしているのですが、「プレイングマネージャー」を挙げる方が一定数いらっしゃるなという印象です。 やはりこの業界はプログラミングを始めとした技術が好きという方が多く、そこからは離れたくないという想いを持っているのだと感じます。 しかしながら!プレイングマネージャーとは中々に難しい役割だなと私は思っておりまして、検索すると一部辛い文字がサジェストされます。 私も経験があるのでひじょーーーーーーーーーーーーーーーーに良くわかります。 当時の経験というか、エピソードを1つお話しします。 序章 プレイングマネージャーへの挑戦と失敗 201

    プレイングマネージャーになるために。そして自律的なチームとは何か - Tabelog Tech Blog
  • 定量評価疲弊しませんか?~Well-beingと生産性指標を組み合わせた エンジニアリングメトリクスプログラムについて~

    Developers Summit 2023 登壇資料 https://event.shoeisha.jp/devsumi/20230209/session/4171/ overflowは、副業転職サービス「Offers(オファーズ)」の開発、運用を行っています。 サービスの提供を開始してから3年。サービスの拡大に合わせ、組織も比例して成長してきました。 その中で、組織の成長に伴い、どのように生産性指標を開発に取り入れていったか。 取り入れていった結果、状態把握から逸脱し何が起きたか。そして、その後どのようにして改善していっているかご紹介します。 私達が行ってきたことを例に(反省として)、数値に踊らされずに正しく運用する方法を考えるきっかけになれば幸いです。 ▼関連リンク Offers:https://offers.jp/ Offers MGR(オファーズマネージャー):https://

    定量評価疲弊しませんか?~Well-beingと生産性指標を組み合わせた エンジニアリングメトリクスプログラムについて~
  • エンジニアリングマネージャーが手懐けるべき荒ぶる四天王 - STORES Product Blog

    この記事は「STORES Advent Calendar 2022」 12/17の記事です。また、「Engineering Manager Advent Calendar 2022」 カレンダー2の12/17の記事でもあります。 こんにちは!STORES エンジニアリング室の塩谷(@kwappa)です。この記事では、エンジニアリングマネージャーの中に棲んでいる「荒ぶる四天王」について考え、うまくつきあい、あわよくば手懐けてしまおう、という試みについてお伝えします。 エンジニアリングマネージャーのしごと この記事をご覧の方でしたら、今年8月にオライリーから発売された『エンジニアリングマネージャーのしごと』という書籍に興味がある、もしくはもう読んだのではないでしょうか。エンジニアリングマネージャー(以下EM)という重要だが定義がふわっとした仕事にどう取り組んだらいいかのガイドとなる、とてもいい

    エンジニアリングマネージャーが手懐けるべき荒ぶる四天王 - STORES Product Blog
  • 組織マネジメントのあれこれ|nishiba

    トピック部下への任せ方 部下の視座の上げ方 なぜ書くのか?最近、部下と話していて言語化が進んだのでメモとして書いておく。また、いつもどおり書きなぐりの文章です。推敲などはしていません。 前置き今回あえて部下という言葉を使っています。普段は部下という言葉よりもメンバーという言葉を使います。今回は上司と部下の関係であり、上司として私が気づいたことを書くので明確に部下という言葉を使っています。 部下への任せ方仕事を任せることは非常に難しいと思っていた。しかし、難しいと感じる場面が最近減った気がする。その理由を考えたのでメモとして残す。 私は1年ほど前に今の会社に転職した。今は執行役員/VPoEを担っている。入社当初からずっとマネジャーという立場である。最初は研究開発部の副部長という立場であり、数カ月後に部長、その数カ月後にVPoE、さらに数カ月後に執行役員になった。なので、全く現場のことや配下に

    組織マネジメントのあれこれ|nishiba
  • マネージャーとNegative Capability - scrapbox - hotchemi

    Negative Capabilityという概念を最近知った。詩人ジョン・キーツが提唱したとされている用語で「事実や理由を性急に求めず、不確実さや不思議さ、懐疑の中にいられる能力」を意味する。対義語はPositive Capabilityで、所謂課題解決能力の事。 我が身に翻ってみると思い当たる事が多く、特にマネージャーをやっているとこの能力の有用性を感じずにはいられない。例えばよく目にするのは以下の様な事象だ。 新しく入ってきたマネージャーが成果を出そうと張り切って色々提案するが、芯を外していたり合意を得られてなかったりで現場でハレーションが起きる ある問題を解決する為に新しいツールを導入するが、新しいツールが更なる問題を引き起こし以前より状況が悪化する 組織内で色々改善活動を試みるが、すぐには効果が出ず反応も芳しくないので心が折れてしまう これらはpositive capability

    マネージャーとNegative Capability - scrapbox - hotchemi
  • 「便利になる」だけでは人は動かないし、「当事者意識をもってくれる人」はめちゃ貴重だという話

    この記事で書きたいことは、大筋下記のようなことです。 ・「これは問題だ」「だから改善したい」と、自分ごととして真剣に考えてくれる人というのは極めて希少です ・ただ「便利になる」というだけでは誰も動かないし、どんなにいいものを作っても使ってもらえません ・当事者意識を「持ってもらう」ということは基的に出来ません ・当事者意識を持っている人を別に探し出すことで、なんとか状況を打開出来る場合もあります ・だから、「この人は当事者意識を持ってくれている/くれていない」を嗅ぎ分ける能力はとても重要です よろしくお願いします。 さて、書きたいことは最初に全部書いてしまったので、後はざっくばらんにいきましょう。 以前にも書いたことがありますが、私はかつて、システム開発の会社に勤めていました。 社員数は4桁に届かないくらいで、SI案件とSES案件が大体半々くらい、自社業務と客先常駐も大体半々くらいという

    「便利になる」だけでは人は動かないし、「当事者意識をもってくれる人」はめちゃ貴重だという話
  • エンジニアの"有害な振る舞い"への対処法 - Qiita

    記事の続編として、自分が有害な振る舞いをしないようにする改善の取り組みを扱った記事も書いてます。 エンジニア上司が"有害な振る舞い"を改善する方法 ※「難しい人」は概念として用い説明するのに便利な言葉でしたが、誤解を生じたり、記事のポリシーに沿わない使用(難しい人というラベリングを特定個人に適用する使い方)が容易にされてしまいそうだと分かりました。そのような誤用を防ぐことを最優先とするため、代わりに「有害な振る舞い」という表現を使用し、人ではなく振る舞いに着目するタイトル及び文章に変更致しました。 はじめに 以下の記事を読んだ際に「難しい人」という表現が何となく面白い響きで印象に残ったので、これを機に自分の考えを今までの経験をもとに書きたいと思います。 “難しい人”が1人入ると、チームの生産性は30〜40%低下する 対抗せずに、場の「安心感」を作るための3つの条件 - ログミーBiz

    エンジニアの"有害な振る舞い"への対処法 - Qiita
  • 10年エンジニアリングマネージャーをやって気づいた4つの大事なポイント 【EMはもっと自由でいい】 - MonotaRO Tech Blog

    はじめに ※この記事はEngineering Manager Advent Calendar の22日目の記事になります。前日はmtx2sさんの技術的負債に対するマネジメントの記事でした。個人的には「負債上限」「負債ベースライン」の考え方良かったです。 こんにちは。モノタロウでエンジニア組織のマネージャーをしております普川(@taipuka0)です。 自分は前職から通算10年以上してエンジニアリングマネージャーを続けた後、現在モノタロウでは8人のEMのみなさんと日々ソフトウェア・エンジニアリングの現場でマネージャーとして課題解決に向き合っています。これまで色々な壁にあたり、試行錯誤を繰り返して来ました。EMの難しさを痛感したことも多々ありました。 なぜEMが難しいのか?その一つとして、エンジニアからEMにジョブチェンジした際のギャップというのがあると思います。同じチーム、現場にいたとしても

    10年エンジニアリングマネージャーをやって気づいた4つの大事なポイント 【EMはもっと自由でいい】 - MonotaRO Tech Blog
  • Noを伝える技術 #pmconf2021

    mROS 2: yet another runtime environment onto embedded devices

    Noを伝える技術 #pmconf2021
  • レビューの仕方

    Open8 勉強会で発表したレビューの仕方と心理的安全性の話しです。

    レビューの仕方
  • LIFULLでの1on1: 「特に話したいことはありません」を解決した話 - LIFULL Creators Blog

    こんにちは。LIFULLのプロダクトエンジニアリング部の野澤です。エンジニアリングマネージャーをやっています。 LIFULLでは組織構造として部の下に「ユニット」があり、その下に「グループ」がぶら下がっています。 今期からは私はユニット長を拝命し、間接マネジメントを行うようになりました。 マネジメント業務の中でも1on1は部下のモチベーション維持やキャリア形成、戦略理解を促進させるために重要な手法です。 グループ長時代も1on1はやっておりましたが、間接マネジメントをやるにあたり、メンバーからは相談がしにくくなってしまったようで、「特に話したいことはありません」となってしまうことが増えていきました。 そこで改めて1on1を有意義にするためにはどうしたらいいか考えてみました。この記事ではそのための取り組みを紹介できればと思います。 LIFULLでの1on1 1on1は今やいろんな業界や会社で

    LIFULLでの1on1: 「特に話したいことはありません」を解決した話 - LIFULL Creators Blog
  • マネジメントは経験でもセンスでもない。「型」を学んで実行するのみ。|長村禎庸@EVeM

    はじめにベンチャー企業でのマネージャー歴約10年ですが、10年経ってベンチャー企業に必要なマネジメントノウハウを体系化して、その体系化したものを人に教える仕事をしてます。 体系的にマネジメントを教わることなく、何かが起こるたびに都度経験から学んだり、上司から薫陶を得たり、書籍で学んだりしながら10年掛けて学びました。そして、それら断片的な学びをつなげて体系化しました。 体系化してみたら何のことはない、これが実行できれば必ず成果は出ます。 そして、経験が浅い新米マネージャーであっても、マニュアルを元に徹底的にトレーニングされれば実行できるようになります。 マネジメントは経験でもセンスでもなく、業務マニュアルとして「型」化し実行可能です。 (マニュアルはベンチャーに特化しています。ベンチャーという特殊なシチュエーションにフォーカスしなければ業務マニュアルのような各論ではなく一般論に終始して

    マネジメントは経験でもセンスでもない。「型」を学んで実行するのみ。|長村禎庸@EVeM
  • よいミーティングの作り方 - 弥生開発者ブログ

    こんにちは、Misoca開発チームの黒曜(@kokuyouwind)です。 ついにECS execできるようになったことに咽び泣いていますが、今日の記事は全然関係ない話です。 社内向けに「どうすれば質の高いミーティングを作れるか」を検討した読み物記事を書いていたのですが、社外に出しても問題ない内容だったので開発者ブログに載せることになりました。 割と社内では評判が良かったので、参考になる部分があれば幸いです。 目次 目次 はじめに 要点 よいミーティングとは ミーティングとは よいミーティングの条件 目的の達成度 達成度と時間のバランス 効率の良いミーティング ミーティングの準備 ミーティングの目的とゴールを明確にする ミーティングの参加者を決める ミーティングの前提情報を洗い出す ミーティングの進行方法を決める ミーティングの実施 ファシリテーターの役割 タイムキーパーの役割 参加者の役

    よいミーティングの作り方 - 弥生開発者ブログ
  • Whyとは何か?を言語化してみる|Naofumi Tsuchiya / Goodpatch

    Whyとは一体何なのか 🧐近年、多くの会社で聞かれるようになった「Why」の重要性。 Goodpatchも例に漏れず、会社のカルチャーの根底に「Why」があります。 今となってはWhyって大事だよねーと抽象的概念で重要性が伝わりますが、実はWhyとは何かという言語化はあまりされてないことが多いと思っています。 今日はそんなWhyを少しだけ深掘って自分なりに言語化してみたいと思います。 Goodpatchが創業期から大事にしているWhyから考える文化GoodpatchがWhyという言葉に触れたのは創業から2年ほど経った時期でした。当時は会社のビジョンもミッションもまだ明文化されておらず、社員は30名近くになりつつあり、メンバーがこの会社はどこに向かっているのかという声がが聞こえ始めた時でした。 そんな時にある人からサイモン・シネックの「優れたリーダーはどうやって行動を促すか」というTEDの

    Whyとは何か?を言語化してみる|Naofumi Tsuchiya / Goodpatch