「私考える人、あなた作業する人」を越えて、プロダクトマネジメントがあたりまえになるチームを明日から実現していく方法/product management rsgt2023
4プロダクトを成功させようと悪戦苦闘しているものの、プロダクトの行く末についてプロダクトオーナーやプロダクトマネージャといった一部の人の意思決定に依存しすぎてしまっていると悩んでいるチームが、彼らと共にプロダクトマネジメントを実行できるようにするセッションです。「プロダクトオーナーがボトルネック」という状況から、おさらばしましょう。 概要 https://confengine.com/conferences/regional-scrum-gathering-tokyo-2023/proposal/17655 発表者 https://twitter.com/_N_A_ https://note.com/mryy
現実世界は動的なのに静的に解こうとしている危うさのようなものへの自戒 - @i2key のBlog
Recruit Engineers Advent Calendar 2022 - Adventar 23日の記事になります。 1. 方法論は限定スコープ内における合理性の話である 書籍などで得られる概念や方法論（技術含む）は、その書籍がスコープとしている中での限定合理性の話をしており、 書籍がスコープとした範囲における論理的正しさである場合がある。 特定のスコープの中においての最適なので、実は全体からみると個別最適だったりする。 つまり、実は引いてみると非効率なことを近距離でみると効率的だと主張している場合もある。 この包含関係による概念的強さみたいなものは存在しており、例えば、制約条件理論みたいなものは、様々な概念の上位に存在しており包含していたりする(そう勝手に思っている)。スコープを決めそのスコープ内におけるボトルネックを活用しスループットを最大化させるという概念的な強さはあり、その
なぜエンジニアはマネージャーになるのに不安を覚えるのか - asken テックブログ
こんにちは。askenでエンジニアリング戦略や組織づくりを担当しているやすにしです。 マネジメントを中心にしておりまして、せっかくなのでブログでもマネジメントについて書いてみますね。 私はこれまでVPoEとしてエンジニア組織のマネジメントや、様々な会社でマネージャー向けにコーチング 1 をやってきました。そこで接してきたエンジニアリングマネージャーに共通しているのは「キャリアに悩んでいる」ということです。 例えばこのようなことです。 コーディングをしなくなり、技術的に取り残されて、エンジニアとしてやっていけなくなる感じがする 自分でやらないから成果が見えない。やっている感じがしない。 マネジメントをどうやればいいか、どう学べばいいかわからない。 マネージャーのキャリアで自分は定年（？）まで生きていけるのか？ 共通点は、色々理由を言葉にしているものの、どれもしっくりきている感じではなく、「な
エンジニアリングマネージャーとしてどんなことをしているのか？ - tuneの日記
はじめに エンジニアリングマネージャーとは? メンバーのサポート・育成・評価 メンバーの状態観察 目標設定・人事評価 後進の育成 日常の労務管理 開発 プロダクトマネジメント エンジニアリングのリーダーシップ 採用・採用広報・アドバイザーの招聘 採用 採用広報 アドバイザーの招聘 他社との情報交換 終わりに はじめに 今流行りの Meetyを使って社外の方とお話しする機会を作っているのですが、「エンジニアリングマネージャーとしてどんなことをしているのですか?」という質問を何度かいただいたので、自分の整理のためにも日々の具体的な行動・活動をまとめてみます。 私はRetty株式会社でtoC Web開発/toB Web開発 両方をみているエンジニアリングマネージャーであり、この記事を書いた2021年9月時点では20名弱のマネジメントを務めています。エンジニアリングマネージャーとなってからは2年が
体制を考えるときに意識していること - id:onk のはてなブログ
1on1 で伝えたので外にも書いておく。 プロダクトやチーム、メンバーのフェーズ まず現状分析。 自プロダクトは PPM で言う花形、金のなる木、問題児、負け犬のいずれに当たるのか 勢い MAX でめっちゃ盛り上げるのか、地味に役割を達成するのか。自チーム全集中なのか他チームのフォローに回るのかみたいな方針が変わる 自チームは エラスティックリーダーシップ で言うサバイバルモード、学習モード、自己組織化モードのいずれに当たるのか チームを改善しなければいけないのか、プロダクトだけを見ていて良いのか。チームで改善できるのか、リーダーや外部の強い意志が必要なのか 各メンバーは、期待される役割において SL理論 で言うとどのフェーズなのか 指示的行動が必要だとマイクロマネジメントすることになり、マネージャ/メンター的な人/行動を増やす必要がある 役割を網羅しているか こういう軸で考えていることが
エンジニアリングマネージャーの私的解釈と実践 - 下林明正のブログ
エンジニアリングマネージャーに関する以下のアウトプットを見かけて、現時点での自分の思考のスナップショットも取っておこうという気持ちになりました。 エンジニアリングマネージャーを目指す若者の戦略 - yigarashiのブログ テックリードの抱えるプレッシャとキャリアパス - 貳佰伍拾陸夜日記 ウェブ業界でしか働いたことがないので、ウェブ業界に限定したことを書きます。 状況認識 エンジニアリングマネージャーとは何なのかというと、業界としての具体的な合意はまだ形成されておらず模索中という認識です。 なので一人一派のエンジニアリングマネージャー像を持っており、個人によって理解に大きなブレがある状態と思います。 そうした前提の中での最大公約数的な理解に関してはやはり エンジニアリングマネージャ/プロダクトマネージャのための知識体系と読書ガイド - Qiita にまとめられたアンケート結果が役立ちま
プロジェクトマネジメント手法 vs 絶対にどうにかする覚悟 - ミネムラ珈琲ブログ
WEBサービス開発みたいな界隈でもう5年マネージャー業をしているので、おそらく人並みにはプロジェクトマネジメントの手法に触れてきている。実際やってきたこともあれば、やってはいないが事例やテクニックとして知っていることも含む。*1 そうやって過ごしてきたが、結局プロジェクトマネジメント手法よりも絶対にどうにかする覚悟、つまり精神論の方が重要だという個人的な結論に至っている。 どんなに精緻に工数とリスクを見積もって振り返りを繰り返しても、「まあ遅れてもいいや」という空気ではプロジェクトは遅延し続ける。逆に見積もりが雑でも「どうにかする覚悟」さえあればなんとか目標とした期日に間に合う。 もちろん覚悟と精神論でやっていると残業が常態化して炎上と言って差し支えない状態になるのだが、覚悟がなくて遅延したプロジェクトも最終的に炎上としか言いようのない状態になるので、同じ炎上なら期日に間に合っている方がマ
エンジニアリングマネージャとして会社にジョインするのは難しい - だいくしー(@daiksy)のはてなブログ
新しい会社に入社して1ヶ月半経った。 今回はエンジニアリングマネージャとしてのポジションでの採用で、過去4回の転職はすべてアプリケーションエンジニアとしての採用だったので、その差分に若干戸惑っている。時勢的にフルリモートワークというのも大きい...。 "成果"が見えにくい仕事に対する実感をどのように得るか まずひとつは、"成果"に対する手応えが異なること。エンジニア採用であれば、「入社最速RTA！！」などと言いながら、とりあえず小さなタスクを拾って入社後1週間以内くらいに自分の出した最初のプルリクエストがマージされれば、「最初のステップは超えた」という実感を得ることができた。 マネージメント職では、そのようなわかりやすい成果が見えづらい。そもそも、自分の打ち手が効果を発揮するのが翌月、みたいなリードタイムも珍しくないので、自分はちゃんと給料分働けているのだろうか、とまぁまぁ不安になる。そこ
プロダクトマネジメント私記
2 年前にソフトウェアエンジニアからプロダクトマネージャーにロールチェンジした。ソフトウェアエンジニア時代は割と頑張れてたし成果を出せてた気がするのだけど、プロダクトマネージャーになってからは正直かなり苦戦した。プロダクトマネージャー 3 年目を迎えてようやく仕事に自信が持てるようになってきた気がするので、振り返りを兼ねて、これから同じようにプロダクトマネージャーにコンバートしたいと思っている人の役に立てばと思って書きます。 Table of Contents プロダクトマネージャーになった理由 プロダクトマネージャーの役割 1. 何がユーザーの問題かを特定する 2. その問題を解決する製品を定義する 3. 製品がリリースされるまで開発チームに帯同し、リリースを成し遂げる 4. 製品が「正解」であったかの評価を行う 実際になってみてのギャップ プロダクトマネジメントの認知度が原因？ 一体型
自分のマネジメントのマインドセットの変化 - Konifar's ZATSU
マネジメントの仕事を始めて1年半くらい経った。日々ﾊﾁｬﾒﾁｬが押し寄せてきて泣いている場合じゃなく、落ち込んだりもしたけれどわたしは元気です。 主に気持ちの持ち方みたいなところでの変化を雑に3つくらい書いておくことにする。 自分がやる必要はない 全部やろうとせず委譲するのが大事とはわかっていても、それをやっていると「俺いる意味あるんか...？」と感じることがある。側から見るといわゆる自己組織化、適切な権限委譲が行われているということになるかもしれないが、当人は焦ってしまったりする。 自分が為すべきことを明確にして、それを達成できるのであればどんな形でもよしというマインドを持っておくとよい。メンバーを信頼して任せるというのはもちろん、自分にできないことをまわりを巻き込んで達成することも必要。極端な例だと、自分の言葉でチームメンバーのモチベーションを上げられないのであれば、別の適切な人を召喚
なぜ「できない人」ほど、人に聞けないのか。 | Books&Apps
できない人が質問をしに来ない、という傾向は、それなりにどこの会社でも見られるようである。 例えば新人が聞きに来ない、若手が聞きに来ない、あるいは「不出来なベテラン」だと、誰にも相談できなくて行き詰まる、なんて話もある。 つい先日も、あるテクノロジー系の企業で「聞きに来ないメンバー」をなんとかしたいが、どうすればよいか、という話があった。 聞くと、力量の低いメンバーの一人が、報告が苦手で、かつ聞きに来ないので、こちらがかなり監視をしているが、手間がかかってしょうがない、という。 仕事の進捗を入れたり、週報を書いたりするような社内システムもあるのだが 力量の低い人ほど入力率も低く、入力した報告の内容も拙いという。 結局、上司が直接、成果品を逐一覗いてチェックをしているそうだが、それも限界がある。 こまったこまった、という話だ。 ＊ こういった事象について 「できない人」は、「何がわからないのか
LIFULLでの1on1: 「特に話したいことはありません」を解決した話 - LIFULL Creators Blog
こんにちは。LIFULLのプロダクトエンジニアリング部の野澤です。エンジニアリングマネージャーをやっています。 LIFULLでは組織構造として部の下に「ユニット」があり、その下に「グループ」がぶら下がっています。 今期からは私はユニット長を拝命し、間接マネジメントを行うようになりました。 マネジメント業務の中でも1on1は部下のモチベーション維持やキャリア形成、戦略理解を促進させるために重要な手法です。 グループ長時代も1on1はやっておりましたが、間接マネジメントをやるにあたり、メンバーからは相談がしにくくなってしまったようで、「特に話したいことはありません」となってしまうことが増えていきました。 そこで改めて1on1を有意義にするためにはどうしたらいいか考えてみました。この記事ではそのための取り組みを紹介できればと思います。 LIFULLでの1on1 1on1は今やいろんな業界や会社で
プロダクトマネジメント入門: 失敗しないプロダクトの作り方を学ぼう
Founder Customer Fitこのセクションについて解決したい課題を見つけよう顧客を決めようリーンキャンバスを書こうミッションを決めようCustomer Problem Fitこのセクションについてペルソナを立てよう共感マップをつくろうカスタマージャーニーマップをつくろう課題仮説を整理しようプロブレムインタビューをしようProblem Solution FitこのセクションについてPEST分析をしようフックモデルを定義しようプロトタイプをつくろう解決策仮説を整理しようソリューションインタビューをしようSolution Product Fitこのセクションについて名前をつけようユーザーストーリーマップをつくろうMVPを構築しようMVP仮説を整理しようMVPインタビューをしようProduct Market Fitこのセクションについてグロースサイクルを定義しよう利用規約をつくろうプロ
1on1ミーティングとは？その意味と、効果的に行う方法 | Coral Capital
本連載はオープンソースライセンスの1つであるGPLの元に公開されている「The Eng Team Handbook」（エンジニアチーム・ハンドブック）を翻訳したものです。開発チームが効率的に仕事するために必要な「効果的な1on1の実施方法」「開発メンバーから開発マネージャーにポジションが変わるときの注意点」「パフォーマンス評価のテンプレート集」「360度評価のテンプレート」などが含まれます。 著者はStripeのエンジニアであるrayleneさんです。これがStripeのやり方と明示されているわけではありませんが、急成長するシリコンバレーのスタートアップにおけるエンジニアチームの取りまとめ方という意味で、日本のスタートアップでも参考にしていただけるのではないかと思います。オリジナルの英文の文書では、まだ未着手の項目もありますが、すでに書き終わってるものについて翻訳し、連載の形で5回に分けて
一度やめた EM にもう一度取り組むことにした話｜mootoh
これは Engineering Manager vol.2 Advent Calendar 2019 5日目の文章です。 従事していた Engineering Manager をやめるのはそこまで珍しいことではないと思いますが、同じ組織で再度やるという話はあまり聞かないように思います。キャリアの参考になれば 🙏 第一期2017/4/~2018/9 まで 2017年の頃は Engineering Manager というよりも Project Manager や Product Manager の真似事をしつつ、 Android 系の Engineering Manager としてエンジニアの採用をがんばっていた。特に海外のエンジニアに東京のメルカリにきてもらうべく活動していた。年末の時点では、4~5人の馴染みが日本語で話すチームだった。阿吽の呼吸とまでは言わないまでも、コンテキストを共有で
幻影旅団のチームマネジメントのすばらしさとそれでも鎖野郎に半壊させられた理由を考察する｜人事のなべはる
記事の中で映画、ゲーム、漫画などのネタバレが含まれているかもしれません。気になるかたは注意してお読みください。 悪の組織の心理的安全性ランキングの栄えある1位はハンターハンターの幻影旅団です！ 幻影旅団はほんとうに良いチームなのですが、ここでふと疑問に思うことがあります。それは、「ヨークシンシティ編で鎖野郎に半壊させられてるじゃん」というもの。この疑問に答えるべく、筆をとりました。 というわけでこの記事では、幻影旅団のチームマネジメントがいかに優れているか？と、優れたチームマネジメントにもかかわらずなぜ鎖野郎に半壊させられたのか？をチームビルディングの観点から考察します。ヨークシンシティ編のネタバレありまくりなので、ご了承ください。 団員どうしの仲が良く、リーダーは親しみやすい幻影旅団が他の悪の組織と大きく異なるユニークな点は、上下関係なく団員どうしの仲が良いことです。 例えば下記の描写。
「君は今日から人工知能開発部門のリーダーだ！」と言われた時の処方箋 - Qiita
いわゆる人工知能技術が巷をにぎわす昨今、人工知能を研究する部署/団体を設立するのがトレンドになっています。もちろん、部署の設立にはそれをマネジメントする人間が必要です。「その時」は突然やってきます。 「わが社でも人工知能技術を研究しビジネスに役立てるべく、新しい部門を設立することになった」 「はい」 「ひいては、君にその部門のマネジメントを任せたい」 「！？」 「将来的には100人規模にし3億円規模のビジネスにしたいと思っている(※)。まずは中期計画を作成してくれ」 「そ、それは・・・」 「部門設立のプレスリリースは来月発行される。よろしく頼むよ(肩ﾎﾟﾝｯ」 (※: 好きな数字を入れてください) (from 疾風伝説 特攻の拓) 本文書は、実際こうした事態が起こった時に役立つチェックリストとして機能するようにしてあります。具体的には、以下の構成をとっています。 設立編: 何を「目指す」の
わたしはなぜ、「プロジェクト管理」という言葉を使わないのか | タイム・コンサルタントの日誌から
旅先ではいつも、その土地のものを食べるのが習慣だ。だが、ときおり、外国で日本料理屋に入ることもある。そして、たまに面食らうような体験もする。いつだったか、アメリカの日本料理屋で食事を頼んだら、まっさきに味噌汁だけが出てきた。ふつうの街にある店で、来客はアメリカ人が多い。どうやら彼らの概念では、味噌汁はスープだから（Miso soupとよばれる）、真っ先に出すのが当然だということらしい。味噌汁を飲み終えたら、メインのおかずとご飯が出てきて、妙な気分だった。 汁物をsoupと訳するのは、もちろん正しい訳だ。だが日本語で言う汁物と、英語のスープは微妙に違う。たとえば英語では、スープは食べる（eat）という。日本人で、「味噌汁を食べる」という人は滅多にいるまい。ふつうは飲む、を使う。そして、当たり前だが、ご飯と一緒にいただくものだ。
エンジニアが「明日からマネジメントして」と言われたら
製品開発におけるマネジメントの全体感最初に結論エンジニアがマネジメント始める際には、↑のようにざっくり簡単にでいいので開発チームのマネジメントの全体像を掴んだうえで、自分がマネジメントするべき範囲を明確にして動くことをオススメしてみます。 以降、もう少し詳しく説明します。 なんで書こうと思ったかエンジニアにとってマネジメントとはなにか。突出した技術力を持った人というのがエンジニアでは花形なイメージが一般的にはあるでしょうし、マネジメントはエンジニア全員にとって必須科目ではありませんが、一定の経験、年齢、スキルになったら考えることだと思います。 しかし、エンジニアにとってマネジメントという言葉はとても曖昧。必須科目でない分、特定技術に関するものよりもずっとドキュメントや教材がすくなく、なにをやればいいかけっこうわかりにくい。 最近だとVP of Engineeringみたいなポジションがメジ
マネジメントって何すればいいの〜？1年間マネジメントに向き合ったのでまとめを書きます - Qiita
はじめに こんにちは！Supershipの永田ゆにこです！「Supership株式会社 Advent Calendar 2016」の20日目を担当します（^o^）今年は会社のやつに参加するぞ〜！ これからマネジメントやらなきゃいけない人や、同じように困ってる人にぜひ読んでほしい！めちゃくちゃ長いです。 前置きと振り返り さて、これまでは二年連続でGitに関することを書いてきました。Gitが使えるデザイナーブランディングをしていたんですね〜。いまやデザイナーの人がGit使うのは普通になってきた印象です。便利すよねえ。 去年の書いたのはこれ Gitとわたしとデザイナーと 〜2015年Gitの思い出〜 その前書いたのはこれ デザイナーがこうやってGit覚えて大好きになったよ♡ てな感じで少し前はデザイナー&ディレクターをしていたのですが、最近はだんだんプロデューサー&マネージャーぽい感じに変わっ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
