質の低い決定しかできない上司や社長に「どうしますか」と決定を丸投げするのは悪手だよ(パート2) - フジイユウジ::ドットネット
以前、質の高い打ち手を選択できる人が判断をせず、質の低い決定しかできないような上司や社長に「どうしますか」と委ねるのはチームがダメになる要因なんよという記事を書いたのですが、今日はその逆で課題解決に必要な能力と情報を持っている人が判断をしなくても上手くいったことについて雑に語ります。 先日、会議に参加してたんですよ。 その会議では、ある課題をどう解決するか話し合って打ち手を決定するというものだったのですが、参加者のひとりが僕より明らかに専門性を持っているプロフェッショナルだったのですね。 なので僕は「どうするかは専門性のある人に決めてもらった方が質の高い意思決定になるし、僕は相手がそれをしやすいよう情報を渡すような役割に徹しよう」と考えていました。 しかし、実際の会議を進めてみると、一番質の高い打ち手を決められる能力があるはずの人が「フジイさんどうするか決めて欲しいです。」と言ってくるので
経営の”踊り場”問題 - Yamotty Blog
2016 - 12 - 28 経営の”踊り場”問題 プロダクト-プロダクトマネージャー 本記事は「経営の踊り場問題」と勝手に呼んでいる問題とその対策について、わざわざクリスマスの夜に行った4つのツイートをまとめ・補記したもの。主にスタートアップや新規事業など「急速な成長」を前提とした組織体を想定している。 停滞期に起きること 踊り場を抜けるにはユーザーやプロダクトと向き合い切る以外に解はないと思ってるんだけど、「これまで順調に伸びて来た売り上げがストップ」みたいな状況は社内の雰囲気を悪くする。 結果、マネジメントが組織や人間関係の問題にフォーカスしがちに。これを「経営の踊り場問題」と呼んでる。→続 — Yamotty (@yamotty3) December 25, 2016 踊り場が目線を内に向ける リリースした直後は底にいるので、サービスは伸びるしかない。難しいのは伸ばし続けること。ふ
プロダクトマネジメントプロセス概要
より価値を届けていくためにどのようにプロダクトマネジメントをすればよいのか？をまとめてみました。
プロダクトマネジメントは多くのソフトウェア企業が重要だと認識している役割だ。それにもかかわらず、「 プロダクトマネジメント」を正確な言葉で定義することは驚くほど難しい。自らを「プロダクトマネージャー」と呼ぶ人々は、企業ごとに全く違うこと… 記事によれば、プロダクトマネージャーはこれらの領域を健全に機能させることが役割であり、 機能がなければ自分で役割を演じたり、補う方法を見つける （たとえばデザイナーがいなければ、自分でデザインを行ったりデザイナーを雇う）「開発者-ビジネス」「ビジネス-顧客」「顧客-開発者」の融合領域における、各種の複雑さや衝突、トレードオフの統合を行うといったことが PM の職責であると理解しています。 逆に言えば、これらを俯瞰して見ることができる能力が PM には求められています。そうした意味で、PM は様々なことを広く学び、組織やビジネスの変化に柔軟に対応できる必要
プロダクトマネジメント
本書は、顧客に価値を届けるプロダクトを作り出すプロダクトマネジメントについて学ぶ本です。プロダクトマネジメントを理解することで、企業がビジネス目標を達成しながら、顧客の課題を解決する方法を解説します。はじめにプロダクトマネージャーの役割と責任を定義し、優れた意思決定を促す戦略の立て方を紹介します。実験と最適化によって作るべきプロダクトを決めるプロセスを解説し、最後にプロダクト主導の組織を支えるための文化や方針を紹介します。 市場で競争力を維持するには、組織はアウトプットよりもアウトカム（成果）に焦点を当てた顧客中心の方針を採用する必要があります。アウトプットを重視してしまう企業は、顧客のニーズではなくスケジュールを優先し不要な機能をリリースする「ビルドトラップ」に陥ります。 このビルドトラップを避け、顧客の課題にフォーカスするプロダクトマネジメントの原則を解説する本書は、規模の大小を問わず
はじめに PMの実態 よくあるケースと処方箋について PMが全部把握したいマンになっているケース 処方箋 PMがタスク持ちすぎなケース 処方箋 PMがコミュニケーションのハブになっているケース 処方箋 おわりに はじめに プロダクトマネージャーをやっていると楽しい一方で、MTGや問い合わせ多くて、忙しすぎるという声をよく聞きます。 そこで本来集中すべきことは何かと、それを阻害する忙しさにどう対処するべきかまとめてみました。 PMの実態 組織内でPMが大変そうと思われる。周りからなりたくない職種と思われるのは危ないサインだと思います。 プロダクトマネージャーというとミニCEOと呼ばれたり、花形とか言われますが、実態としては割と忙殺されていて、職場でも「あの人すごいと思うんだけど、なりたいかと言われると、、、」 みたいに見られているのが多いんじゃないかと思います。 PMが忙しいパターンとそれぞ
中島氏、イヌ氏の自己紹介 椿原ばっきー氏（以下、椿原）：まず1人ずつ紹介します。まず中島さんです。よろしくお願いします。中島さん、自己紹介をお願いしてもよろしいでしょうか？ 中島悠輔氏（以下、中島）：はい。はじめまして。中島悠輔と申します。株式会社SEVENRICH Accountingというところで、今はクリニック向けのシステムのプロダクトマネージャーを本業（として）やっています。ご縁があってLboseさんの副業PMの求人を拝見した時に「ぜひお話をうかがってみたいです」というところから、このようにしてお仕事を頂戴するところに今はなっています。 椿原：ありがとうございます。具体的な案件の話はあとであらためてちょっとしようかなと思うので。 中島：よろしくお願いします。 椿原：続きまして、（お名前が）斬新ですね（笑）。イヌさん。 イヌ氏（以下、イヌ）：はじめまして。イヌと申します。すみません、
IDEOの女性ビジネスデザイナーが語る、誰も教えてくれないプロダクトマネージャーの本当の役割【寄稿】 - BRIDGE（ブリッジ）テクノロジー＆スタートアップ情報
Rohini Vibhaさんは、IDEOのビジネスデザイナーです。Twitter アカウントは、@rohinivibha。本記事は、Mediumへの投稿記事をRohiniさんから許可を得て翻訳したものです。元の英語記事もどうぞ。 世の中にプロダクトマネージャーを目指す人が増えていると思うのは、私だけだろうか。私自身がプロダクトマネージャーを務めているから、そう感じるのかもしれない。それにしても、最近はコンサルタント、MBA候補生、エンジニア、誰もかれもがプロダクトマネージャーを目指している気がする。 もしこれが事実で、もし本当に、”誰も”がプロダクトマネージャーになりたいと望んでいたとしても驚くには至らない。確たる技術を極めることなく務まる役割なのだから。プロダクトマネージャーになるためにデータモデルの作り方を知っている必要はないし、コーディングができる必要もなければ、Webサイトをデザイ
SI案件でアジャイル開発を進めるときの勘所
みなさんこんにちは。@ryuzeeです。 10月に発売となった『プロダクトマネジメント - ビルドトラップを避け顧客に価値を届ける』ですが、まだお読みになっていない方是非よろしくお願いします。 また、ここ数か月新しい書籍の翻訳に取り組んでいて、来年の春くらいには発売になるかと思います。この本も楽しい本だと思うので是非楽しみにお待ち下さい。 さて、先日、プライベート講演で、SIのコンテキストでアジャイル開発を進める場合に、どのような点に気をつけておくとよいかを話して来ました。 汎用的な内容で読者の方の参考になるかと思いますので、資料を公開しておきます。 以下、資料だけ見てもわからない方向けの解説です。 TL;DR（結論）SI案件でアジャイル開発を適用する場合、顧客側がアジャイルを正しく理解していない可能性があるので、案件開始前に教育すべしステークホルダーマネジメントは重要。これはウォーターフ
実は相性が悪い「開発生産性」と「アジャイル」。うまくいかない開発を好転させるためにPMがやるべきこととは【ryuzee|吉羽龍太郎】
TOPインタビュー実は相性が悪い「開発生産性」と「アジャイル」。うまくいかない開発を好転させるためにPMがやるべきこととは【ryuzee|吉羽龍太郎】 実は相性が悪い「開発生産性」と「アジャイル」。うまくいかない開発を好転させるためにPMがやるべきこととは【ryuzee|吉羽龍太郎】 2024年3月26日 株式会社アトラクタ Founder兼CTO／アジャイルコーチ 吉羽 龍太郎 1973年生まれ。野村総合研究所、Amazon Web Servicesなどを経て、2016年1月から現職。アジャイル開発、DevOps、クラウドコンピューティング、組織開発を中心としたコンサルティングやトレーニングを専門とする。著書に『SCRUM BOOT CAMP THE BOOK』（翔泳社）、訳書に『チームトポロジー』（日本能率協会マネジメントセンター）、『プロダクトマネージャーのしごと』『エンジニアリング
依頼、調整、合意、承認、etc. こういったコミュニケーションがチーム境界を越えて頻発すると、ソフトウェアプロダクト開発のフローは遅々として進まなくなります。いずれも、機能追加や機能改善を進める上でのクリティカルパスを引き伸ばす要因を生み出すからです。 機能追加や機能改善といったひとつひとつの開発は、アイデアを生み出し、それを価値に変えるまでのフローです。フローが進む過程で、組織内の様々な人の手で、様々なタスクが実行されます。その全てを1つのチームで完結することは、プロダクトの規模が大きくなるほど困難になり、より多くの人々が関わるようになります。そこに、チーム境界を越えた「依頼、調整、合意、承認」といったコミュニケーションが発生するのです。 開発フローのクリティカルパスを悪化させるこのようなコミュニケーションの頻度をどれだけ減らせるか。組織設計、チーム設計で最も注視すべき観点の1つは、そこ
Udemyで夏のビッグセール開催！ 話題の生成系AIからプロダクトマネジメントまで、新たな得意分野を見つけよう - はてなニュース
※夏のビッグセール、およびキャンペーンは終了しました。ご応募ありがとうございました。なお、Udemyの講座修了者を対象とした「学習応援キャンペーン」は9月30日まで実施中です。 オンライン学習プラットフォーム「Udemy」では、2023年8月22日（火）から夏のビッグセールを開催します。対象の講座が1,200円から購入可能と、なかなかチャレンジできなかった新しい領域を学習するにはとってもお得なチャンス。 今回のセール対象講座から、ChatGPTやMidjourneyといった話題の生成系AI、その基礎となる大規模言語モデル（LLM）の入門や実装を扱う講座といった人気のトピックに加えて、アプリケーション開発やプロジェクトマネジメント、さらには英語学習など、ステップアップを目指すITエンジニアにオススメの中級から上級の講座もピックアップして紹介します。 Udemyで勉強を始めたいけれど、いろいろ
この記事は Kyash Advent Calendar 2021 2日目の記事です。 2020年1月から2021年6月まで、1年半ほどKyashでEngineering Managerをやっていました。2021年7月からはロールを変えて、QAチームのいちメンバーとしてAPIのテストやテストの効率化に取り組んでいます。 EMをやめた経緯とやめた後の所感を備忘として残しておきます。 EMとしてやっていたこと 2020年にやってきたことは去年まとめました。 konifar.hatenablog.com 2021年は、共有口座やイマすぐ入金、セブン銀行出金などのリリースに向けてMobile / サーバーサイド / QAのチームでプロジェクトを進めたり、プロダクト開発フローを整えたり、エンジニア採用のリードをしたりしていました。 EMをやめるきっかけ そんな中で、3月くらいに「なんだか最近仕事が面白
Engineering Managerをエンジニアのマネージャーとするのはやめませんか？ - Unknown Error
この記事はEngineering Manager Advent Calendar 2018の9日目の記事です。 vol.2もあるので、是非こちらも見てください。 私は常日頃、Engineering Manager(EM)がいない問題について危機感を覚えている。 これはEMという役割が正しく認知されておらず、魅力が伝わっていないことが根本の原因にあると考えている。*1 だから、EMの魅力を伝えるPodcast EM.FMを広木さんと始めた。*2 このPodcastでは、EMが何を考えているのか、EMも人間だから悩みながらやっていること、EMが何に喜びを感じるのか、などを語っている。メインパーソナリティは広木さんと私だが、Quipper EMの大庭さん(id:ohbarye)、元Googleの及川さん(id:takoratta)、VOYAGE GROUP CTOの小賀さんにもゲストとして過去に
プロダクト作りにはさまざまな「罠」がある。機能の開発とリリースに集中してしまい、顧客の本当の課題、プロダクトの本当の価値がおざなりになってしまう状況のことを「ビルドトラップ」と言い、プロダクトを開発する組織において陥りやすい「罠」の一つだ。なぜこの問題が起こるのか。どうすれば、本質的なプロダクト作りに立ち戻れるのか。『プロダクトマネジメント――ビルドトラップを避け顧客に価値を届ける』の訳者であり、アジャイル開発や組織改革のトレーニングなどを行う専門家、吉羽龍太郎氏が語った。 大事なのはアウトプットではなく、アウトカムとインパクト 吉羽氏はアジャイル開発やDevOps、クラウドコンピューティング、インフラ構築自動化、組織改革を中心にオンサイトでのコンサルティングやトレーニングを提供する専門家。吉羽氏がCTOを務めるアトラクタも同様のサービスを提供している。また吉羽氏は青山大学では非常勤講師と
2021/7/28, Retty ✕ Mercari Analyst Talk Night! https://mercari.connpass.com/event/218848/
サービス開発は9割が失敗する - 6つの診断パターンからみるサービス設計がうまくなるコツ（前編） - デジタル世代のものづくり - 岸田崇志のブログ
こんにちは！ 株式会社LITALICO CTOの岸田崇志です。 記念すべき『LITALICO Engineers Advent Calendar 2016』1日目の記事となります！ LITALICOでは現在『教育×テクノロジー』での可能性を広げるべく、チャレンジを広げています。 今回は、サービスを組み立てる話をしたいと思います。 1.はじめに タイプ別にみる失敗パターン 2.基本を理解しよう！ AARRR - Pirate Metrics（海賊モデル） 3. サービスのコンセプトを設計しよう リーンキャンバスを知る リーンキャンバスについて リーンキャンバスの使い方 （おまけ）KPIを設定しよう まとめ 5.次回は… 1.はじめに サービスを立ち上げの現場では戸惑うことが多いと思います。 特に初めての場合ははなおさらです。 サービスの企画を初めてやるときに、 どうやっていいかわからない。
【書評】「プロジェクトマネジメントの基本が全部わかる本」の輪読会を開催していただいたので参加しました | DevelopersIO
コーヒーが好きな emi です。 7 月末～ 11 月末にかけて、私が所属しているチームのマネージャー 横田慎介 さん主導で「プロジェクトマネジメントの基本が全部わかる本」の輪読会を開催いただきました。おかげさまで一人では読み切れなかったであろう本が読み切れて嬉しいです。 本記事では開催いただいた輪読会の進め方と、私が「プロジェクトマネジメントの基本が全部わかる本」を読んだ感想を記載します。 既に書評ブログがありますので、詳細はこちらもご参照ください。 書籍タイトル : プロジェクトマネジメントの基本が全部わかる本 交渉・タスクマネジメント・計画立案から見積り・契約・要件定義・設計・テスト・保守改善まで 著者 : 橋本 将功 出版社 : 翔泳社 出版日 : 2022/11/08 出版社の書籍情報リンク：プロジェクトマネジメントの基本が全部わかる本 交渉・タスクマネジメント・計画立案から見積
もしあなたがLLMを使ったプロダクトを何かしら開発している、もしくは興味があるのなら、メモリを大量に積んだMac Studioの購入を検討すべきです。 対象読者NVIDIAが絶対にいいという人はこの記事の対象読者ではありません。また、用途によって、ローカルマシンによるローカルLLMが向いてる・向いてないは明確にあるので、向いてない用途にしか使わない人も対象読者ではありません。あしからず。 また、この記事は別にNVIDIAをdisる意図はありません。みんな違っていい。NVIDIAもいい選択肢ですが、Mac Studioも悪くないですよ、と言いたい。 結論LLMプロダクト開発において、今年はもはやローカルLLMを無視できない、してはいけない状況です。 LLMプロダクト開発をする会社の視点でいえば、是非とも80GB以上の十分なGPUメモリを積んだマシンを用意できるようなアジリティを持つのが望まし
この記事は、以下サイトの機械翻訳です。 何を作るか（あるいは次に何を作るか）を決めることは、プロダクトマネージャーの仕事の中で最も重要な部分の一つです。インパクトを与えるチャンスは何度もありません。だからこそ、賢く選択して、チャンスを最大限に生かすことが重要なのです。 プロダクトの優先順位を決めるには、さまざまな要素を考慮する必要があります。しかし、何よりもまず、お客様の真の問題を解決することを優先しなければなりません。多くの企業では、このプロダクト開発の基本方針が守られていません。おそらく、価値よりも革新性を優先しているからでしょう。私たちは皆、自分たちが最先端の先駆者であると他人に思われたいと思っていますが、市場が求めているのは必ずしもそうではありません。 市場が求めているのは、すでに機能しているものを適度に改良することだったりします。究極のゲームチェンジャーを追い求めるのではなく、フ
「Product Roadmaps Relaunched」（オライリー未邦訳）がプロダクトマネージャーにとって非常に良書 - SaaSベンチャーで働くエンタープライズ部長のブログ
プロダクトロードマップに関する書籍を探していたら、「Product Roadmaps Relaunched」に辿り着きました。未邦訳なので英語で読んでいったのですが、非常に良い本です。 Product Roadmaps Relaunched: How to Set Direction while Embracing Uncertainty (English Edition) 作者:Lombardo, C. Todd,McCarthy, Bruce,Ryan, Evan,Connors, MichaelO'Reilly MediaAmazon アウトカムベースのロードマップ(Outcome Based Roadmap) プロダクトマネジメントでは「アウトプット」と「アウトカム」がよく比較されます。アウトプットは出てきた機能に対して、アウトカムは提供価値であり、プロダクトマネージャーはアウトカ
プロダクト開発のユーザーを絞って考えることの重要性とsuper-specific whoの考え方 ｜PM Club
プロダクト開発において、ユーザーを絞って考えることの重要性と"super-specific who"という考え方や決め方について解説しています。
Spotifyのスケーリングアジャイル – 部隊、分隊、支部やギルドと共に歩む（Spotifyモデル）
(注)ヘンリックの許可を得てざっくり意訳しました。原文は『Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds』です。訳に対するヘルプも歓迎します。Thanks Henrik, this article is great for me. プロダクト開発をしている組織において、多角的なチーム構成を実現するのはいつもチャレンジな作業だ！ 今まで見てきた中で印象に残っている例がひとつある。それはSpotifyだ。Spotifyは3つの都市にまたがって30以上のチームにスケールしているが、アジャイルなマインドセットをキープし続けている。 Spotifyは音楽産業を一変させている魅惑的な企業だ。創業してから6年しか経っていないのに、1500万ものアクティブユーザーを抱え、400万以上の決済が行われている。また、そのプロダクトは「
自己紹介 こんにちは。田村壽英（タムラ トシヒデ）です。 freee株式会社でプロダクトマネージャーをやり始めて早くも２ヶ月が経ちました。この２ヶ月間、どのようにPMとして動けば顧客にちゃんと価値を届けられるか、そのためにどうしたらfreeeの社員が熱狂をもって働けるかを悩みながら活動してきました。この記事では現時点での悩んだ結果を共有したいと思います。 背景 PMになるつい最近まではエンジニアとしてあるプロダクトのリーダーをしていました。そのときの悩みはだいたいこんなものでした。 今やっている開発が手一杯で次何するかをちゃんと考えられない サービス利用者の本当の課題は何なのか十分に検討できないまま開発に入ってしまい、本当にこの機能でよいのか実装中にも迷いが生じた せっかく開発した新機能の魅力を営業チーム等の他のチームにちゃんと伝えられてない このような悩みがあると「このプロダクトはどこに
僕がスティーブ・ジョブズから学んだ12の教訓-ガイ・カワサキ：What I Learned From Steve Jobs - Guy Kawasaki
BY Guy Kawasaki -in Japanese スティーブ・ジョブズから学べる教訓を解説する人は数あれど、同じ屋根の下で直に彼と働いた経験者はほとんどいない。取りこぼしたり忘れたりしないよう、僕がスティーブ・ジョブズから学んだ教訓のTOP12をまとめておこう。 1. Experts are clueless エキスパートはなんにもわかっちゃいない エキスパート（記者、アナリスト、コンサルタント、銀行家、グル）は自分じゃ何も「実行」できないから人に「助言」する。君の製品のどこが悪いと口では言えるが自分じゃ何ひとついいもの作れない。どうしたら売れるか口では言えるが自分じゃ何ひとつ売れない。どうしたら素晴らしいチームにできるか口では言えるが自分じゃ秘書ひとり管理するのがやっとだ。 だいたい1980年代半ばあのエキスパート連中は「Macintoshのニ大欠点はデイジーホィールプリンター専
ryuzeeさんの記事で紹介されていたスクラムマスターを雇うときに聞いてみるとよい38個の質問 に答えてみました。 38個すべてに一度に答えていこうとするとかなりハードですが、1日1個ずつこつこつと、回答をしていっています。 この回答は、年月を重ねることに変わっていくかもしれません。 2019/12時点の回答がこちらです。 スクラムマスターの役割について 1. アジャイルマニフェストでは「プロセスやツールよりも個人と対話を」といっている。プロセスを守らせるスクラムマスターは、それとは反対のことをしているのではないか？ スクラムマスターはプロセスを順守する・させるためだけの存在ではありません。プロセスを順守する行為は「どのように行うのか（How）」を守らせることに注力してしまいがちですが、「なんのために行うのか（Why）」のほうを重視すべきです。 アジャイルにおけるチームの成功は、「よいプロ
機能を書くならバックログにまず機能だけが書かれたロードマップから見ていきましょう。時系列に沿って、どんな機能を追加するのか並んでいます。 残念ながら、多くの場合、機能開発が遅延したり、差し込み案件が発生したりして、以下のようになってしまいます。 こうなると、もうこのロードマップは信頼できません。過去の実装がここまで遅延していると、次に取り掛かる機能がいつリリースされるのか分からず、どれの優先度がもっとも高いのかも判断するのが難しくなってしまいます。 こういった「機能」に近いものは、縦長のプロダクトバックログの形式で並べ、ユーザーストーリーに分解して見積もったものを上から順番に実施していくほうがスッキリします。 では、ロードマップがなぜ必要なのかプロダクトバックログはとても良いものですが、プロダクトの中期的・長期的な未来を構想するには少し見づらくなります。特に、会社の中で中期的・長期的な方針
クックパッド検索・編成部の五十嵐啓人です。本業はレシピなどの料理検索を中心とした、主に「さがすユーザー」のサービス責任と、ユーザー数の拡大に責任を負っています。本日は部門を超えて取り組んでいる、ディレクションの役割を持つスタッフの活躍を広げるための取り組みについて紹介します。 ディレクションの役割を取り巻く当社の状況 日本のインターネットサービス界隈で「プロダクトマネージャ」の話題が盛り上がりを見せつつありますが、当社でもプロダクト開発を牽引・補佐する役割を担当しているスタッフを（名前の議論はありますが）慣習的に「ディレクター」と分類しています。 当社では、以前からエンジニアリングで活躍するスタッフについては、エンジニアマニフェストやエンジニア専用の評価制度作りなどに注力し、組織として期待するエンジニア像の言語化による職種の価値向上、およびキャリア支援を充実させてきました。しかし、エンジニ
こんにちは！ dely, Inc.でプロダクトマネージャー兼開発部ジェネラルマネージャーをしている奥原 (@okutaku0507) といいます。この記事はdely Advent Calendar 2018の2日目の投稿です。 先日は、弊社のAndroidエンジニアでマネージャーを勤めている梅森から「AWS CodeBuild+AWS SAM（Lambda）+Slackで最高なAndroid CI環境を作る」というタイトルで投稿がありました。梅森はDroidKaigi 2019にも登壇する予定です。 tech.dely.jp 弊社が運営しているレシピ動画サービスのkurashiruはよく知っているけど、開発チームは何しているのかわからないという方に、少しでも弊社の開発部のことを知っていただければ幸いです。もし、同職種や弊社に興味を持ってくれた方がいましたら、僕のtwitterのDMでも良い
両方ともPMと略されるため混同する人が多いが、プロダクトマネージャーとプロジェクトマネージャーは明確に役割が異なる。 Quoraに素晴らしく簡潔な回答があったので引用して紹介する。 Product managers own "What" and "Why". Project managers own "How" and "When". (a simplification, but generally holds true) Ian McAllister's answer to What's the difference between a Project Manager and a Product Manager? - Quora プロダクトマネージャーは、「何を作るか」「なぜ作るのか」に責任を持ち、プロジェクトマネージャーは、「いつまでに作るか」「どうやって作るか」に責任を持つ。 別の言
プロダクトマネジメント私記
2 年前にソフトウェアエンジニアからプロダクトマネージャーにロールチェンジした。ソフトウェアエンジニア時代は割と頑張れてたし成果を出せてた気がするのだけど、プロダクトマネージャーになってからは正直かなり苦戦した。プロダクトマネージャー 3 年目を迎えてようやく仕事に自信が持てるようになってきた気がするので、振り返りを兼ねて、これから同じようにプロダクトマネージャーにコンバートしたいと思っている人の役に立てばと思って書きます。 Table of Contents プロダクトマネージャーになった理由 プロダクトマネージャーの役割 1. 何がユーザーの問題かを特定する 2. その問題を解決する製品を定義する 3. 製品がリリースされるまで開発チームに帯同し、リリースを成し遂げる 4. 製品が「正解」であったかの評価を行う 実際になってみてのギャップ プロダクトマネジメントの認知度が原因？ 一体型
Engineering Managerを廃止して1年経ちました - Akatsuki Hackers Lab | 株式会社アカツキ（Akatsuki Inc.)
こんにちは、ゆのん(id:yunon_phys)です。このエントリーはAkatsuki Games Advent Calendar 2022の14日目の記事です。昨日はMaxBaconPowerさんの「巨大数でわかる Elixir の魅力」でした。Elixirが再帰が得意とはいえ、良くこんな題材を思いついたなと感心しました。早くふぃっしゅ数を見てみたいものです。 さて本題に入るわけですが、昨年、Engineering Manager(EM)を廃止して3つに分割したという話を書きました。そこから1年経ち、どのような状態になったのか、ふりかえりも含めて書いていきます。本記事は前回の記事を読まなくても読めるようにしていますが、更に背景理解したい方は前回の記事も読んでみてください。 hackerslab.aktsk.jp ずばりEMを無くして良かったのか これはマクロに見ると明確に良かったと思って
エンジニアリングマネージャーの最初の学び - このロールは何なのか - yigarashiのブログ
2023/6/16付の人事異動で正式にエンジニアリングマネージャー（以下EM）になりました。2021/8に「エンジニアリングマネージャーを目指す若者の戦略」という記事を書いて明確にEMを目指し始め、2022/12には「EMキャリアを切り拓く「最強の現場リーダー」という働き方」という記事でEMに近づく様子を書きました。さらにそこから半年余り、ついに会社からも正式にEMと呼ばれることになりました。実際には3ヶ月ほど前から強くEMを志向した動きにはなっていましたが、やはり正式な職位は特別なもので、キャリアにおける重要な実績をひとつ解除したと感じています。 これほどEMというロールを志向し色々とやってきたのですから、EMとしての振る舞いもさぞスムーズに立ち上がるかと思いきや、実際にEMとして動くのは非常に難しいことでした。書籍やブログ記事を読んで頭で理解したEMという働き方と、自分がチームでEMと
今、最も面白い職種は「プロダクトマネジャー」だ――及川卓也氏が説く、DX時代のIT業界サヴァイブ術：外の世界とのタッチポイントを増やせ！ - ＠IT
2025年、IT業界が変わる 経済産業省は2018年9月、デジタルテクノロジーによる企業価値の創出を目指す「デジタルトランスフォーメーション（DX）」に関する調査報告「DXレポート ～ITシステム「2025年の崖」克服とDXの本格的な展開～」を発表した。 「『DXレポート』では、デジタルで新事業を始める場合には情報システムの内製が重要になると指摘しています。この指摘が受け入れられるなら、SI企業も変わっていくはずです」と及川卓也氏は言う。 及川卓也氏 早稲田大学理工学部卒業後、日本DECに就職。営業サポート、ソフトウェア開発、研究開発に従事し、1997年からはMicrosoftでWindows製品の開発に携わる。2006年以降は、GoogleにてWeb検索のプロダクトマネジメントやChromeのエンジニアリングマネジメントなどを行う。2015年11月、技術情報共有サービス『Qiita』など
こんにちは、CPOのadachiです。 この記事は「SmartHRのプロダクトマネージャー全員でブログ書く2024」への参加記事です。25人が持ち回りで毎週記事を投稿しています。 この企画にも関連するのですが、最近社外の方から「SmartHR、PM多！」という感想をいただくことが増えてきました。もしPMが多い ＝ 裁量が小さくてつまらない環境、と思われていたら心外すぎる……許せねぇ…… そこで本稿では、なぜSmartHRには25人もPMがいるのか、一体なにを作っているのか、仲はいいのか、今後どういったオポチュニティがあるのか、といったことについて説明していきたいと思います。オポチュニティは言いたいだけです。 25人は多い？ 結論、そんなに多くないと思っています。 先日「SmartHRがARR150億円を突破、前年比150％で成長」というプレスリリースも出ましたが、私たちは現在ARR 150
Netflixがカスタマーを誰よりも理解するためのデータ分析プロセス、コンシューマー・サイエンスの紹介 - Qiita
時間がたつに連れて、私のフォーカスは、「カスタマーが何を言っているのか？」から、「まずはテストしよう！」というコンシューマー・サイエンスの態度に変わりました。私のチームのカスタマーに関するインサイトは向上し、学びの速度も上がり、何がカスタマーを喜ばせるのかについてのある仮説を形成するに至りました。 以下が、コンシューマー・サイエンスとカスタマーオブセッションのために私達が使ったリサーチの手法です。 既存のデータを使って過去と現在のカスタマーの行動を理解する。 私達の作っているものに対してカスタマーがどう反応するのかを聞くために、フォーカス・グループや一対一のインタビューやユーザーテストといったクオリティティブなリサーチをする。 カスタマーがどういった人たちなのかを、デモグラフィック（人口統計学的属性、つまり性別、年齢、住んでいる地域、所得、職業、学歴、家族構成など）、競合する製品の使用度、
Qiita 生みの親、海野弘成（@yaotti）が語る！ 良いチームを定義する2つの条件 | キャリアハック（CAREER HACK）
情報共有ツール「Qiita:Team」のプロダクトマネージャー（PM）を務める海野弘成さん。海野さんは「良いチーム＝自律的なチーム」と定義し、構成要素を共有した。 海野弘成が語った、「自律」と「心理的安全性」の重要性 ※2016年10月24日に開催された「Japan Product Manager Conference 2016」よりレポート記事をお届けします。 映し出されたスライドのタイトルは『Product Team Management』。 登壇したIncrements株式会社CEOで、情報共有ツール「Qiita:Team」のPMを務める海野弘成さんは、 自身の経験から「プロダクトマネージャー（PM）の関わるチームビルディング」に絞って発表した。セッションの冒頭で、海野さんは2つの条件を満たしているのが「良いチーム」であると定義する。 まずは「成果が出せるチーム」。プロダクトにおいて
この記事は「STORES Advent Calendar 2022」 12/17の記事です。また、「Engineering Manager Advent Calendar 2022」 カレンダー2の12/17の記事でもあります。 こんにちは！STORES エンジニアリング室の塩谷(@kwappa)です。この記事では、エンジニアリングマネージャーの中に棲んでいる「荒ぶる四天王」について考え、うまくつきあい、あわよくば手懐けてしまおう、という試みについてお伝えします。 エンジニアリングマネージャーのしごと この記事をご覧の方でしたら、今年8月にオライリーから発売された『エンジニアリングマネージャーのしごと』という書籍に興味がある、もしくはもう読んだのではないでしょうか。エンジニアリングマネージャー（以下EM）という重要だが定義がふわっとした仕事にどう取り組んだらいいかのガイドとなる、とてもいい
みなさん、こんにちは！プロダクト開発部の吉川（@yoshiyu0922）です。 現在、JMDCが保有している医療ビッグデータを活用して生活者や医療に新しい価値を提供する新規プロダクト開発チームのバックエンドを担当しております。 以前に新規プロダクト開発で採用している技術や設計についてこちらの記事で紹介しましたが、Go x GraphQL x DDDでプロダクト開発をしています。今回はプロダクトの開発が一区切りしてこれからリリースするということで、開発してみて良かったことやこうすれば良かったことを振り返りをしました。振り返りの内容は主にDDDに関することです。 DDDとは DDDとは「Domain-Driven Design」の略語でドメイン駆動設計と呼ばれるソフトウェア開発手法の一つです。問題を解決しようとする領域（ドメイン）をモデリングによってソフトウェアの設計や実装に反映させることで、
はじめに 今回プロダクトマネージャーの動きを行っていく中で、新しい気づきがあったので記事としてまとめました。 プロダクトマネジメントをプロダクトマネージャーだけで行わない プロダクトマネジメントとは、プロダクトを成功に導く考えであり、これはプロダクト作りに関わる人であれば必ず必要になってくるものです。 つまり、プロダクトマネジメントとは特定の誰かが行うアクションではなく、チームや組織全体で行っていくものだと考えています。 プロダクトマネージャーの役割 プロダクトマネージャーの主の役割とは、もちろんプロダクトマネジメントを行うことです。 しかし、プロダクトマネジメントが行えている状態を組織として目指すためには 「プロダクトマネジメントをすること」だけではなく「プロダクトマネジメントができる組織づくり」も行う必要があると考えています。 そのためには、プロダクトマネージャーとして、「プロダクトマ
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
プロダクトマネジメントトライアングルと各社の PM の職責と JD
プロダクトマネージャーはSlack（ゆとり）が大事 - hikoharu's blog
副業PMが正社員PMと同じ認識を持てるように Notionを活用して自社制作したプロジェクト管理ツール
チーム・組織デザインの良し悪しはプロダクト開発フローの効率を左右する｜mtx2s
Engineering Managerをやめた - Konifar's WIP
プロダクトマネジメントの罠「ビルドトラップ」とは？ アジャイルや組織改革の専門家、吉羽龍太郎氏が解説
メルカリにおけるA/Bテスト標準化への取り組み
LLMプロダクト開発者がMac Studioを買ってローカルLLMを触るべき理由｜erukiti
プロダクトマネジメントの優先順位付けフレームワークの究極ガイド
プロダクトマネージャーを2ヶ月やって思ったこと - Qiita
「スクラムマスターを雇うときに聞いてみるとよい38個の質問」に答える - Qiita
ロードマップに機能を書くべからず｜小城久美子 / ozyozyo
ディレクションの役割を持つスタッフの活躍を広げる取り組みについて - クックパッド開発者ブログ
「明日からプロダクトマネージャー」と言われたら - dely engineering blog
プロダクトマネージャーとプロジェクトマネージャーはどう違うのか - 小さなごちそう
なぜPMが25人も必要なのか - SmartHR Tech Blog
エンジニアリングマネージャーが手懐けるべき荒ぶる四天王 - STORES Product Blog
DDDでプロダクト開発をしたので振り返ってみた - JMDC TECH BLOG
プロダクトマネージャーの役割は「プロダクトマネジメントをすること」だけではないかも - Qiita