大吉祥寺.pmの登壇資料です https://kichijojipm.connpass.com/event/314917/
こんにちは、しんざきです。週に一回ファミコン版のイーアルカンフーを遊ぶ習慣がもう15年くらい続いておりまして、そろそろ一度知見を集積しようかと思っているところです。面白いですよね、イーアルカンフー。 この記事で書きたいのは、大体以下のようなことです。 ・「評価されやすいエンジニア」とは、「ちゃんと自分の成果を言語化してアピール出来るエンジニア」です ・「アピール」というと苦手意識を持つ人が多いのですが、必要なのは自分を大きく見せることではなく、具体的な達成状況の可視化です ・「自分の成果を言語化出来るか」というのは、日々の仕事で能力を発揮する上でもとても大事です ・成果を言語化する上では、ちゃんと「ストーリー」を考えることも大事です ・ストーリーといっても、別にありもしない物語を作れという話ではなく、組織が持っているビジョンや方向性に合致する成果になっているか、という話です ・特に新人さん
NTT Com Open TechLunch #7「エンジニアリングマネージャー と 目標設定」の登壇資料です。20分くらいの短いセッションなので網羅的ではありません 2. 吉羽龍太郎 / Yoshiba Ryutaro アジャイル開発、DevOps、クラウドコンピューティング、インフラ構築自 動化、、組織改革を中心にオンサイトでのコンサルティングとトレーニン グを提供。Scrum Alliance認定スクラムトレーナー(Regional, CST-R) チームコーチ(CTC) / 認定スクラムプロフェショナル(CSP) / 認定スク ラムマスター(CSM) / 認定スクラムプロダクトオーナー(CSPO) 2
ホーム ニュース プレスリリース 謙虚なリーダーのもとで心理的安全性が高まりメンバーが本領発揮しやすくなる―職場においてリーダーの謙虚さと心理的安全性が果たす役割― 東京大学 発表のポイント 日本の企業において、リーダーの謙虚さが心理的安全性を介してプレゼンティーズムに影響することがわかりました。 チーム単位で働く職場において、リーダーの謙虚さ、心理的安全性、そしてプレゼンティーズムの3変数がどのように関係しているか初めて明らかにしました。 メンバーが活躍できる職場の人的環境や文化的条件を考え、介入をデザインする上で示唆に富む結果といえます。 謙虚なリーダーシップは、心理的安全性を介してプレゼンティーズムと関連する 発表概要 東京大学先端科学技術研究センターの松尾朗子特任助教、熊谷晋一郎准教授らの研究グループは、複数の業種の日本企業を対象に調査を実施し、リーダーの謙虚さが高まると心理的安全
本記事は、Engineering Manager Advent Calenderの1日目です。 はじめに エンジニアリングマネージャ(EM)と呼ばれる職務を設置する企業が増えてきました。 私たちの主催したイベントEOF2019でも700名近い方に参加していだき、また多くの方にご協力いただき成功裏に終わることができました。 EM Meetup/EM.FMなどのムーブメントの中心の一翼を担わせていただき、その高まりを感じる一方で不安も感じます。このエンジニアリングマネージャという職務は非常に多岐にわたるケースが存在していますし、必要だとされるスキルもまちまちです。そして、多くの場合、その企業のステージや状況ごとに求めるものは違います。また、求めていることを明文化することすらされていないケースも存在します。 このことから、エンジニアリングマネージメント自体が一時的な潮流として消費され、消えていっ
プロダクトマネージャーカンファレンス 2023 Track A 15:35~ LIVE 50min プロダクトと事業を無限にスケールするための最強のロードマップの作り方 https://2023.pmconf.jp/session/zBfEEEcp 近年、多くのプロダクトマネジメントに関する書籍が執筆され、日本でもプロダクトマネジメントが定着しつつある。特に課題発見からMVPローンチ、PMFまでのプロセスは、アジャイル開発関連の書籍の拡充あって、充実してきていると言える。一方で、一度PMFを迎えたプロダクトを更に進化させるためのロードマップの作り方については、未だ確立した方法論があるとは言えず、世界中で議論が続いている。本セッションでは、従来のロードマップの課題と近年議論されている対策を振り返り、その上で、プロダクトと事業を無限にスケールするための新しい考え方を導入し、状況に合わせて変更可
はじめに 私のチームは、リモートワーク中心の開発チームです。 そのチームに新人が配属された時に、私のチームで行っている新人育成のプラクティスのうち、比較的ユニーク(だと思っている)プラクティスを抜粋して紹介します。 少しでも参考になれば幸いです。 リモートワークの知見を説明 新人に対して、チームで行っているリモートワークを快適に行うための知見を紹介しています。 特に、「今から通話いいですか」をすっ飛ばしてビデオ通話を開始する文化であることを共有します。 詳細は以下を参照ください。 インセプションデッキの説明 インセプションデッキとは、プロダクトづくりに関わるメンバーが各々の意見を持ち寄って共通認識をつくり出すための大事な質問に対してメンバー皆で議論して決めた回答です。 詳細は以下を参照ください。 インセプションデッキ | Agile Studio 私のチームでは、以下のテンプレートを利用し
"ソフトウェアアーキテクトの挑戦 技術選定を成功させるために" の登壇資料です。 https://offers.connpass.com/event/289340/
自分はDMMプラットフォーム内のマイクロサービスアーキテクトグループという組織の責任者をしているが、 最初に比べると組織がそれっぽく拡大したこともあり、 ここ最近テックリードを立てる機会が増えてきた。 一度自分がテックリードに求める役割と適切なチームサイズについてアウトプットしてみようと思う。 DMMプラットフォームのマイクロサービスアーキテクトグループとは? pospomeがテックリードに求める役割 技術領域をリードする プロジェクトマネージメント 他チームとのコミュニケーション チームメンバーの評価 なんだかんだで総合力 pospomeがテックリードに求めない役割 ピープルマネージメント よく分からない政治的なコミュニケーション 適切なチームサイズについて 新規チーム設立を考慮する場合 おまけ:テックリードに求める役割と適切なチームサイズ以外のあれこれ No.2 の重要性 立場が人を作
組織内のメンバーを「リソース」として見始めると、それを100%使い切ることにばかり注力してしまいます。リソースの稼働率を下げることは、すなわち、生産性を下げること。マネージャーは、まるで強迫観念に取り憑かれたように、そのような考えに囚われます。 自社でのソフトウェアプロダクト開発において、その対象は特に、開発者に強く向けられます。その理由は明らかでしょう。バックログに積み上がり続けるアイデアをソフトウェアに変えられるのは、開発者だけです。より多く、できる限り早く、アイデアを市場投入したい。彼らに空き時間という無駄を作らせてしまうわけにはいかない。 しかし、そのような努力が、必ずしも良い結果につながるとは限りません。むしろ、開発者の稼働率を高めすぎたことが、リードタイムに悪影響を与えているかもしれないのです。そして言うまでもなく、アイデアの市場投入が延びれば延びるほど、ユーザーにとってもビジ
今日,社内勉強会で話す機会があり,過去1年間を振り返りつつ「プロジェクトをリードする技術」というタイトルにした.今回は参加者がエンジニアだけじゃなく,ビジネスチームのメンバーもいたため,できる限り,技術的な用語を使わないようにした.質疑応答とディスカッションもあり,1時間非常にワクワクした時間だった. 関連する領域 僕がプロジェクトをリードするときに意識しているのは,スクラムなど特定のプラクティスに依存しすぎないことで,チームの特性によって,関連する様々な領域からプラクティスを集めている.ザッと挙げるだけでも,こんなにたくさんある. チームビルディング ファシリテーション マネージメント 3.0 アジャイル (スクラム / カンバン / XP) 組織論 育成 心理学 メンタリング プロジェクトマネジメント 資料 過去1年間に取り組んだことを全て詰め込んだ!プレイングマネージャーとして頑張っ
今日は社内勉強会で「計画する技術」というタイトルで発表をした. 前から少し「計画」のところに課題感があって,そのあたりの知識を組織に広めて欲しいというオーダーもあったため,僕が日々考えていることを言語化して,発表することにした.僕は今までに様々な「計画」の経験があり,実際に今の組織でも難易度の高いプロジェクトを何度も計画し,遂行してきたため,「計画」に対する信頼残高は増えているのではないかと思う. 発表資料 意識したこと 今回,発表資料を作るときに意識したことが2個あった.他にも話したいことはたくさんあったけど,組織マネジメントの話はまた別でしようと思って,あくまで「計画」に特化した話にした. 明日からすぐに使える話をする 開発プロセスに依存しない話をする 1. 明日からすぐに使える話をする 原理原則すぎる話や,難しい法則の話は控えるようにした.そういう話をしてしまうと,その場では「おー,
昨日,ヒカリエで開催された勉強会「F.O.X Meetup」に参加して,発表をしてきた.勉強会のテーマが「スタートアップのチームビルド」だったため,今回は「さぁ!今すぐプロジェクトリーダーに立候補しよう」というタイトルにした.発表資料の公開と合わせて,補足をまとめる. 発表資料 プロジェクトをリードする技術 今回の発表資料は,4月に公開した社内勉強会資料「プロジェクトをリードする技術」のアップデート版という位置付けで,合わせて学べるように作った.コンテンツもカブりすぎないように考えて,今回新しく盛り込んだコンテンツも多くある. 「プロジェクトをリードする技術」を公開して以来,多くのスタートアップ/プロダクトチームからオファー/相談があり,できる限りのアドバイスをさせてもらった経緯もあったので,特に需要がありそうなテーマである「タスク管理」と「チームビルディング」にフォーカスした. kaka
今週,社内で「技術的負債」をテーマにしたイベントがあり,トーク枠で発表をしてきた.タイトルは「技術的負債を "なるべく" 作らないためのコツ」で,意図的に技術の話をせずに,エモ系のストーリーに仕上げた. 特に伝えたかった部分は最後の「組織パフォーマンス」を改善する Tips で,雑談の重要さ,質問の重要さ,相互理解の重要さ,表情の重要さなどを語った.その中でも「ノンバーバルなコミュニケーション」の Tips はイベント中も気になっていて,発表者がもっと気持ちよく話せるように反応しましょー!と,緊張をほぐすようなアプローチもした. もっと「組織パフォーマンス」を改善していきましょ!!! 発表資料 関連記事 「組織パフォーマンス」を改善する Tips はコーチングの文脈からもインスパイアされていて,コーチングを学ぶならまずこの本から読むのが良いのではないかなと思う. kakakakakku.h
4プロダクトを成功させようと悪戦苦闘しているものの、プロダクトの行く末についてプロダクトオーナーやプロダクトマネージャといった一部の人の意思決定に依存しすぎてしまっていると悩んでいるチームが、彼らと共にプロダクトマネジメントを実行できるようにするセッションです。「プロダクトオーナーがボトルネック」という状況から、おさらばしましょう。 概要 https://confengine.com/conferences/regional-scrum-gathering-tokyo-2023/proposal/17655 発表者 https://twitter.com/_N_A_ https://note.com/mryy
この記事はEngineering Management Advent Calendar 2022の7日目です. 今はエンジニアリングマネージャ(EM)としてエンジニアリングマネジメントの4領域(プロダクト・プロジェクト・テクノロジ・ピープル)すべてを見ていますが, それ以前は長い間テックリードをやっていました. その経験を活かして, 最近は後進を育ててテックリードあるいは「弱いEM」*1をできる人材を増やそうとしています(これ自体がピープルマネジメントの一環ですね). テックリードを育てるためにやっていることの全容を詳細に書くと本が1冊書けるくらいになってしまうと思うので, その中でも再利用可能そうな(と言うより再利用可能にしたいと目論んでいる)「テックリード養成講座」について紹介したいと思います. Memeplex.appで生成した, テックなリードが養成されるイメージ 経緯 僕自身は,
背景 ゴリゴリ系エンジニア、pageoです。 TwitterでMtgのあるべき姿についてツイートしたところ、ぼちぼちRT/いいねをもらえたので記事を書くことにしました。(お友達欲しいのでフォローしてください🙏) 最近大手クライアントとのPJに関わることが増えてきたのですが、事前アジェンダ共有なしに急にMtgが開催されるなどの無法地帯な場面に何度か遭遇したので、今回の記事では"Mtgの型"のあるべきについて自分の見解をまとめてみました。 はじめに Mtgの型 以下の章で紹介する"Mtgの型"はMtgというより議事録の書き方に寄っていますが、以下の章に書かれたことを実践することにより劇的にMtgの生産性は上がると思うので、この記事を機に是非自分/組織全体の"Mtgの型"について議論や検討をしてみてください。 いきなり結論 "Mtgの型"で説明する"教え"は以下の4つだけです 第一教: ~アジ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く