プロダクトマネージャー必読！吉羽龍太郎が教える4つのCOREスキル | ITエンジニア向けのトレンド情報
プロダクトマネージャーとして成功するための道を模索するあなたに贈る成長ガイド。理想と現実が交錯する厳しいフィールドで、どのようにスキルと視点を磨き、チームやプロダクトをリードするのか。その秘訣を詳細に解説します。 この記事は、2023年9月5日発売 『プロダクトマネージャーのしごと 第2版 ―1日目から使える実践ガイド』共同訳者の吉羽 龍太郎氏 による connpass勉強会 を再編集し、記事化したものです。 すべてにおいて「銀の弾丸」は存在しない 「 ◯◯の成功事例やベストプラクティスを教えて欲しい」と頻繁に質問されます。最先端の調査研究や他社の輝かしい成功事例を聞きつけると、手当たり次第に導入したくなることを「シャイニー・オブジェクト症候群」と呼びますが、人間の心理として十分に理解できる一方、まずはすべてにおいて「銀の弾丸」が存在しないことを冷静に受け入れましょう。 ベストプラクティス
プロダクト開発チームの分断に立ち向かう - yigarashiのブログ
先日のRSGT2023で以下の発表がありました。「自分がそれほどプロダクト開発に興味がないことに気づく」は自分自身にも心当たりがありますし、プロダクト開発チームのリアルを言語化した発表だと思いました。この発表では、そうした言語化を受けてどうするのかについては深く触れられておらず、回答は聴衆に委ねられていることから、さらに議論を広げてみようと思います。 実際問題、真に興味を持つのは大変 現代のプロダクトマネジメントは、ひとつの深遠な専門領域になっていると思います。「本が1冊書ける」なんてレベルではありません。何百冊、何千冊と書ける世界です。そうした専門知識を組み合わせ、市場とユーザーとプロダクトを徹底的に分析し、データに基づいて仮説検証を繰り返し、それを自分のプロダクトに接続する方法を捻り出して、ようやく少し尤もらしい方向に近づきます。とても過酷な領域です。 ここにエンジニアが越境して興味を
人の出入りがある前提でチームをどう設計するか？ 信頼残高が足りない組織が、持続可能性を高めた「仕組み」
「プロダクトマネージャーカンファレンス 2021」は、プロダクトマネジメントに携わる人たちが共に学び、切磋琢磨することを目的に開催されるイベントです。ここでユニファ株式会社の山口氏が登壇。続いて、信頼残高の構築と人の出入りがある前提のチームの設計について話します。前回はこちらから。 信頼残高が足りない問題の分析 山口隆広氏：人はなんとかなりました。次は組織と信頼残高を積むというところで、まだまだ終わりません。 でもどうしようと。信頼残高が足りないという問題があって、とはいえ課題も把握しなければいけないと思ったので、少しショートカットしようと思いました。 もともと組織にいて、信頼残高がものすごく高くて、ファシリテーション能力も高いメンバーがいたので、その人にいろいろ聞いて、1on1してきてほしいという話をしました。もちろんそのメンバーが密告者みたいな扱いをされると申し訳ないので、ある程度匿名
ブルシットプロダクトからチームを守れ! ｢顧客が本当に必要だったもの｣を追求するプロダクトマネジメントを実現するぞ
ユーザーから見て、ただひどいだけでなく、開発したり販売する人たち自身がプロダクトに価値がないと感じており、また買ってもらうことに罪悪感を感じるようなプロダクトやサービスをブルシットプロダクトと呼びましょう。 ブルシットプロダクトとは何か、どのようにして生まれるのか、なにをすれば解消されるのか、顧客が「顧客が本当に必要だったもの」を実現しつづけるプロダクト組織に向けて、組織システムの成長の観点からお話しします。 Regional Scrum Gathering Tokyo 2022 概要 https://confengine.com/conferences/regional-scrum-gathering-tokyo-2022/proposal/16109 発表者 https://twitter.com/_N_A_ https://note.com/mryy/n/n6f01561a6253
プロダクトマネジメントと事業開発に関する私的な振り返り - 下町柚子黄昏記 by @yuzutas0
TL;DR 企画力が…欲しい… pic.twitter.com/hJfr0qNv7T— ゆずたそ (@yuzutas0) 2020年11月19日 試行錯誤の瓦礫の記録です。 はじめに もくじ TL;DR はじめに もくじ 以前書いた記事 前提・免責 アイデア 1日1案（やってよかったこと） 1stスクリーニング（やってよかったこと） コミュニケーション チームへのリスペクト（やってよかったこと） 話す <<< 聞く（改善余地あり） 即決する（やってよかったこと） 自分で各論まで見る（やってよかったこと） 発散→収束でディスカッション（改善余地あり） イラストで話す（改善余地あり） 日次ミーティング（やってよかったこと） 議事録を書く（改善余地あり） 得た情報を共有する（改善余地あり） 想定納期を示す（改善余地あり） カレンダー招待＆日程確約コメントを転記（改善余地あり） プロセス管理 仮説
エンジニアが事業に寄り添うことで、結果的に技術的負債が減る話 - エス・エム・エス エンジニア テックブログ
高齢社会に適した情報インフラを構築・提供する株式会社エス・エム・エスで、エンジニアをしている三田淳一です。2020年1月に入社し、介護事業者向け経営支援サービス『カイポケ』の開発を担当しています。 今回、エス・エム・エスの開発体制がどうなっているのか。開発体制が変わることによって、どのような変化が生まれているのかについて紹介していきたいと思います。 エンジニアと事業がフラットではない環境で生じる課題 ソフトウェアシステムの開発組織は、事業やサービスの企画・運営などを担う事業側からリクエストがエンジニアに下りてきて、エンジニアはそれに沿って開発するという、トップダウンのような構造になっていることがほとんどです。事業側とエンジニア側で、優劣がある状態ですね。 こうした環境では、自分のチームのメリット効率を優先して行動し、他のチームに対して非協力的になることも起こりやすくなります。例えば、事業側
プロダクトに必要なスキルを10年維持するために――「スキルマップ」と「ソフトウェア式年遷宮」
プロダクトを長期運用するには、必要な知識やスキルをいかにチーム内でとどめておくかという視点が必要になります。本稿では、はてなの「Mackerel」というプロダクトで培った経験をもとに、「スキルマップ」と「ソフトウェア式年遷宮」という2つのアプローチを紹介します。（編集部） プロダクトチームにおけるスキル維持の難しさ プロダクトの運用には、さまざまな知識やスキルが必要です。プロダクトに対するドメイン知識や、プロダクトを実装するために用いているプログラミング言語。アプリケーションフレームワークやミドルウェア、インフラなど数え上げればキリがありません。プロダクトを長い期間運用していくためには、これらの知識やスキルをどのようにチーム内にとどめておくか、ということを考えていく必要があります。 これらは、さまざまな要因でチームから失われていきます。改修や機能追加などで頻繁に手が入るところは良いのですが
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
