エンジニアリングマネージャーのロードマップ
「エンジニアの管理職」の時代 かつては「課長/部長/リーダー」とだけ呼ばれていた。 「とりあえずマネージャやってね」の時代 マネジメント職になりたがらない技術者たち。 技術の現場から離れるとおいて行かれるのではないかという恐怖。 役割定義があいまい。各社で異なる状況。 ポータブルスキルが身につかないのではないかという懸念。 エンジニアリングマネージャーの登場 2018年頃から「エンジニアリングマネージャー（EM）」という肩書きが普及 人材育成・技術戦略・プロジェクト管理・プロダクト連携の専門職 ジョブディスクリプションや求められる知識・スキルも次第に明確に。 エンジニア"リング"マネージャ エンジニアのマネージャ EMコミュニティの活性化 2018年頃より活発化 EM Meetup（毎回多くのEMが参加） EM.FM（累計再生数10万回超） Engineering Manager Adve
うまくいかないスプリントレビューと、うまくいくスプリントレビュー
2025/02/27 https://distributed-agile-team.connpass.com/event/342568/ 分散アジャイルチームについて考える会 にて発表した資料です！
ドキュメンテーションを文化にする〜コミュニケーションの「ハブ」作りに取り組んだ4年間～ - MonotaRO Tech Blog
はじめに こんにちは。プラットフォームエンジニアリング部門の池田（@progrhyme）です。 この記事では、モノタロウのテック系の部門で筆者が取り組んできた「ドキュメンテーションプロジェクト」について、下の目次の流れに沿って紹介していきます。 【目次】 はじめに 「ドキュメンテーションプロジェクト」とは プロジェクト発足の背景 ねらい（まとめ） 何をやったか ドキュメンテーションの促進 Confluence → Googleドキュメントへの移行 その結果どうだったか 上手く行ったこと 上手く行かなかったこと まとめ 「ドキュメンテーションプロジェクト」とは 初めに、プロジェクトの概要について簡単に説明します。 このプロジェクトのミッション（＝目標）は主に以下の2つです。 ドキュメンテーションを通してプロジェクト内外のコミュニケーションを効率化し、業務プロセスの効率を上げる 社内のドキュメ
フルリモートで相手に気持ちよく仕事をしてもらうためのコツあれこれ
社内のプチ発表に使った資料です。 文章のコツ 前置き フルリモートでは、文章でのやり取りがメインになる。 なので、文章がヒドいと「この人と仕事するのキツイ」と思われちゃう😢 そう思われないための色々思ったことを自戒メモ。 なるべく箇条書きにする
帽子を交換するふりかえり - KAKEHASHI Tech Blog
こんにちは。ソフトウェアエンジニアの椎葉（@bufferings）です。最近実施したオリジナルのふりかえりがよかったので紹介します。 いつもはエンジニアリングマネージャの小田中さん（@dora_e_m）が、そのときのチームの状況に合わせたふりかえりの手法を用意してくれていて、毎週違うふりかえりをみんなで楽しんでいるのですが、今回は小田中さんが不在だったので私がファシリテーションをしてみることにしました。 どんなふりかえりをしようかなと ふりかえりカタログ を眺めていたところ Six Thinking Hats が目に止まり「これをアレンジして『帽子の交換』をすると、今のチームにちょうどいいかもしれないな」と感じて、今回のふりかえり手法を思いつきました。 カケハシはリモートファーストの会社で、私の所属するチームもフルリモートで開発に取り組んでいます。そのため、今回のふりかえりもオンラインホワ
Conventional CommitsとCHANGELOGの自動生成でリリースのユーザ影響をわかりやすくした話 - ドワンゴ教育サービス開発者ブログ
ドワンゴ教育事業 バックエンドエンジニアのtakuminishです。 現在、私は教材入稿ツールの開発チームに所属しています。 教材入稿ツールは昨年の2023年06月に社内向けに正式リリースされた比較的新しいツールであり、リリース当初はリリースノートに関する運用について検討が進んでいませんでした。 リリースノートは開発メンバーが手動で作成しており、内容も前回リリース後にマージされたPRタイトルとリンクを箇条書きで記載しているだけの簡素なものでした。 また、PRタイトルのフォーマットも存在しなかったため、英語で記載されたタイトルと日本語で記載されたタイトルが混在している、ユーザ影響度がタイトルからわからないといった問題もありました。 そこで、教材入稿ツール開発チームではリリースノートの運用として、Conventional Commitsを導入するとともに、conventional-change
組織を変える5つの対話
対話を変えれば組織文化も変わる―。組織内の対話を変えることで、アジャイルな組織文化を築くための実践的な方法を解説します。 オープンな自己表現と相手への理解を促進する「対話診断」を使い、信頼と心理的安全性を築きながら共通の目標に向かって進むための会話の進め方を紹介します。5つの対話ステップ（信頼の構築、心理的安全性の確立、目的の共有、コミットメントの構築、説明責任の遂行）を実例とともに解説し、日々のコミュニケーションを通じて組織内のエネルギーを高めて革新を促す方法を提案します。 迅速な意思決定と主体性を育むアジャイルな組織文化への変革を目指すリーダーやチームメンバー必携の一冊です。 推薦の言葉 はじめに 第I部 1章 ソフトウェア工場からの脱却 1.1 ソフトウェア工場での労働 1.2 アジャイル：人間駆動の開発 1.3 リーンソフトウェア：チームを強化する 1.4 DevOps：運用担当も
テキストコミュニケーションで意識していること｜ymdkit
リモートワークで仕事をしていると、Slack や Teams といった何かしらのチャットツールでコミュニケーションを取ることが多い。そうやって仕事を続けていく中で「こう伝えたらよりスムーズに話が進んだかな...」という後悔は多々あり、日々試行錯誤を続けている。 そうやって試行錯誤を続けていく中である程度テキストコミュニケーションを取る上でのフォーマットが定まってきた気がするので、箇条書きでまとめてみようと思う。（随時更新予定） prefix （接頭辞）をつける文章の先頭にその文章の目的がわかるような prefix をつけて、何のためにポストしたかを一目で分かりやすくする。例えば以下のような prefix をつけることがある。 【質問】→ 相手の返信が欲しい時 【共有】→ 返信は不要だが、内容は把握しておいてほしい時 【メモ】→ 返信不要で、後から検索できるよう残しておきたい時 箇条書きする
正直であることから始める / Start by being honest.
RSGT 2024 Day 2 スポンサーセッション
SREエンジニアが組織改善プロジェクトを立ち上げてみた - ぐるなびをちょっと良くするエンジニアブログ
こんにちは。データ・AI戦略部 SREチームの小野です。普段は部内のシステムに対し、SRE推進活動を行っています。直近では、データエンジニアと協力してデータ基盤周りの改善に取り組んでいます。 <SREの主な仕事> IaC化(Terraform/Terraform Cloud Business)の導入・推進 SLI/SLOの導入・推進 ポストモーテムの導入・推進 アプリケーションデプロイ基盤の導入・推進 ツールやAPIの設計・開発 インフラ設計・開発・運用 トイル削除・システムの自動化 データ基盤改善 一般的なSREエンジニアは、インフラ関連の業務が中心になると思います。しかし、データ・AI戦略部のSREチームは、開発を含めた幅広い仕事をします。やりたいことがあり、手をあげればそれを後押ししてくれる雰囲気の職場です。 今回は、SREエンジニアである私が、組織改善プロジェクトを立ち上げた話をお
マネージャー＆リーダー向け 社内トレーニング / Training of management and leadership for Stockmark
ストックマークの社内研修の公開版※資料です。 （※実際に研修で利用したものとは異なります）
なぜ雑談が重要か - stmn tech blog
これはなに？ こんにちは、リファクタリング大好きなミノ駆動です。2023年7月より株式会社スタメンにジョインしました。 コミュニケーションには会議体やテキストベースなど様々な手段があります。 その中で雑談がなぜ重要であるかについて、私の考えを記したものです。 大事な前提 〜目的と手段の関係〜 人々の活動には目的があります。そして目的を満たすための手段を追い求めています（ここでいう手段とはシステムであったり情報であったり、「目的の役に立つもの」と考えてください）。 目的と手段の関係性を次の図で表現します。目的と手段それぞれの円の重なりが大きいほど、目的に対して相応しい手段である、ということをここでは表します。 この図を使った例を出します。 今の時期、だんだん暑くなってきましたね。「暑さを解消したい」という目的に対して、「扇風機を点ける」「エアコンを点ける」「かき氷を食べる」「南極に送り込む」
リモート開発を助ける「思いやりのある文章」の書き方 - ROUTE06 Tech Blog
新しいプロジェクトに参加してローカル環境を作り始めると、何かとエラーに遭遇します。 また、設計や実装について開発者に相談したり、コードレビューを依頼することもありますね。 開発者が近くにいれば、（それなりに、程よいタイミングを見計らって）話しかけて、エラーの原因を調べてもらったり、設計方法をホワイトボードにスケッチしながら相談できますが、リモート開発ではそうはいきません。 リモート開発で成果を上げるためには、このブログのように何の装飾もインタラクティブ性もない文章で、自分の状況や相談したい事柄を正確に伝える必要があります。 とはいえ私は昔、「文章がわかりにくい」と毎日、毎日上司にフィードバックをもらうくらいには文章を書くのが下手くそでした。今もわかりやすい文章が書けている自信はありません。 それでも、これまでに何度か、議論が好転したり、プロジェクトが前に進むきっかけとなる文章を書けたことが
心理的安全性の育て方 - Innovator Japan Engineers’ Blog
こんにちは、CTOの山岡（@hiro_y）です。ここ数年「心理的安全性」という言葉を目にすることが増えました。Web上の記事でも、書店に並ぶ書籍でも。 自分も何度か「心理的安全性」って大事だよね〜と話した記憶があるのですが、実際のところ「心理的安全性」とは何でしょう。大切なのは誰もが同意するでしょうが、皆が思い描く「心理的安全性」が達成された状態は少しずつ違っていたりしないでしょうか。 ちなみに似たような感じで扱われる言葉に「コミュニケーション」があると思っていて、大切なことは否定できないけど具体的に何を指しているかは人それぞれ、という…。最近はなるべく「コミュニケーション」という言葉を使わないようにしてみています。 さて、話を戻します。「心理的安全性」とはそもそも何なのでしょうか。自分なりに考えた結果としては、「状態を指す言葉ではあるけれど直接は作れないもの」です。どのような状態かという
チームに浸透させるのが近年では難しくなっている - id:onk のはてなブログ
昨日「動いたけどチームメンバーを説得するのが面倒で、秘蔵のブランチになってしまう」って言ったけど、この気持ちはどこから出てくるのか。 分かりやすい Cons があると、反発が予想できて、その反発を解決するところまで労力を割くほどの気持ちが無いので困る。「直ちに問題になるわけじゃないが、どちらかというとやった方がいい、でもリスクもある」という選択肢を選べずにズルズルと現状維持に向かう圧力は、ある。チームの同質性が高いうちはほとんど困らないんだが、人数が増えたり、別の職種が増えたりするごとに「面倒」さはどうしても増していく。 我々の信念として以下を持ってはいるが、現状維持に向かう圧力がある中で変化を加えるのはそこそこ労力が要り、閾値を超えると変化が発生しなくなってしまう。 業務・開発フローは「変えることは無条件に正しい」くらいに思って良いと思っています。 素早く変えてもし仮にダメだったら素早く
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://www.ipa.go.jp/archive/files/000065172.pdf
仕事を前に進めるためのコツ - 判断と決断と共有 / Aim for the goal
コミュニティを育てて会社を変える
スクラムマスターやマネージャーのための信頼構築につながる傾聴の技術
エンジニアリングマネージャーの理想と現実
