プロダクトマネジメントを体系化したクライテリアです。企業がプロダクトを成功に導くために必要な要素を多角的かつ具体的に記載してあります。対象はプロダクトマネージャー個人ではなくプロダクトを取り巻くチームとし、プロダクトマネジメント全体をスコープにしています。
![プロダクトマネジメントクライテリア](https://cdn-ak-scissors.b.st-hatena.com/image/square/fc47983e5ae3d9c4bd1ffbd611b53c65fa090c76/height=288;version=1;width=512/https%3A%2F%2Fs3.amazonaws.com%2Fsuper-notion%2Fimages%2Ffdd67445-6d38-4516-93bc-715f64301a7c.png)
このnoteでは、プロジェクトマネジメント(以下、プロマネと略記)のおすすめ本をマトリックス図に整理してご紹介します。 ◆変更履歴◆ 2024.05.07 初版公開 ◆今後追加予定◆ ※追加のお知らせはX(@coffee_nomimasu)にて行います ・プロジェクトマネジメントの基本が全部わかる本 ・プロジェクトマネジメントの本物の実力がつく本 ・驚異のプロジェクト実行術 準備編 ・驚異のプロジェクト実行術 実践編 ・プロジェクト・シン・エヴァンゲリオン プロマネ本を探すときの悩み筆者の本棚にあるプロマネ本プロマネ本を探すとき、多くの方は「プロジェクトマネジメント おすすめ 本」などとキーワード検索して、 プロジェクトマネジメントのおすすめ本を紹介! プロジェクトマネージャーが読むべきおすすめ本〇〇選! プロジェクトマネジメントおすすめ本ランキング! などのサイトを見ながら自分に合いそう
はじめに 今回プロダクトマネージャーの動きを行っていく中で、新しい気づきがあったので記事としてまとめました。 プロダクトマネジメントをプロダクトマネージャーだけで行わない プロダクトマネジメントとは、プロダクトを成功に導く考えであり、これはプロダクト作りに関わる人であれば必ず必要になってくるものです。 つまり、プロダクトマネジメントとは特定の誰かが行うアクションではなく、チームや組織全体で行っていくものだと考えています。 プロダクトマネージャーの役割 プロダクトマネージャーの主の役割とは、もちろんプロダクトマネジメントを行うことです。 しかし、プロダクトマネジメントが行えている状態を組織として目指すためには 「プロダクトマネジメントをすること」だけではなく「プロダクトマネジメントができる組織づくり」も行う必要があると考えています。 そのためには、プロダクトマネージャーとして、「プロダクトマ
プロダクトマネジメントで大切なことは「何を作るかを決めること」とされがちだが、ピープルマネジメントこそがコアであるという話を書く。 ※ この話はソフトウェアのプロダクトかつ、複数人のチームを想定して書かれている プロダクトマネジメントを「プロダクトのゴールを達成させるための全ての活動」と定義すると、「何を作るか」「どう作るか」という部分は当然に大切である。 とはいえ、これらはリソースをどのように活用していくかという部分が前提にある。プロダクト作りには何らかのリソースが必要だからだ。 つまりは、「現在保持している、もしくは今後獲得していくリソースをいかに活用してプロダクトのゴールを達成していくか」という部分が、プロダクトマネジメントのコアな部分といえる。 さて、リソースの中で一番大きなものは何だろうか。リソースといえばヒトモノカネであるが、ソフトウェア開発では当然にヒトの比重が大きい。ヒトが
この記事はなにか最近知った「エフェクチュエーション(Effectuation)」という経営理論が、自分の中でとてもしっくりいくものだったので、自分なりの解説も兼ねて、記事として残しておきたいなと思いました。 エフェクチュエーションは、狭義的に見れば経営上の理論ですが、実際にはより広い範囲に適応可能な、「不確実性の高い環境に置かれた人の行動全般に関する理論」と言えるのではないかと思います。例えば、以前、新しい職場に転職するなどで見知らぬ環境に置かれることになった場合にどのように適応するかについての自分なりの考えを、"新しい環境でバリューが出せずに悩んでいる場合の解決法"という記事で紹介しました。当該記事の執筆当時はエフェクチュエーション理論は知りませんでしたが、今振り返って読み返すと、かなり共通する要素があるように感じます。 また、ここ数年、自分自身が、これまでとは全く新しい環境に身を置き、
みなさんこんにちは。@ryuzeeです。 2023年10月17日に行われたオンラインイベント「プロダクトマネージャーのしごと - Forkwell Library #33」の登壇資料を公開します。 内容は、新刊書籍『プロダクトマネージャーのしごと』に関するものなのですが、30分という時間で全部を網羅的に紹介するのは無理ですし、ぜひ本書を読んでいただきたいので、僕が気に入っているところと、本書全体を通して中心にある考え方を紹介しました。 ちなみに書籍は16章から構成されていて、そのなかで特に自分が好きなのは「7章 「ベストプラクティス」のワーストなところ」です。 職業柄、日頃から「プロダクトマネジメントではどんなフレームワークを使うといいですか?」「プロダクトマネジメントの日本での成功事例を教えてください」「プロダクトマネジメントのベストプラクティスを教えてください」のような質問をたびたびい
こんにちは、AWS事業本部マイグレーショングループ プロジェクトマネージャーの松浦です。 「プロジェクトマネージャーとしてもっと強くなりたいぜ」と日々思っている次第です。 そんな時、こんな素敵な本を目にしたので読んでみました!結論、素晴らしかったので感想です。 書籍情報 タイトル : プロジェクトマネジメントの基本が全部わかる本 交渉・タスクマネジメント・計画立案から見積り・契約・要件定義・設計・テスト・保守改善まで 著者 : 橋本 将功 出版社 : 翔泳社 出版日 : 2022/11/08 出版社の書籍情報リンク 目次 序章 プロジェクトマネジメントのスキルの全体像 第1章 プロジェクトとはなにか―基本的な知識と考え方をおさえよう 第2章 交渉―適切なパートナーシップを築こう 第3章 タスクマネジメント―チームでパスワークをしよう 第4章 プロジェクト計画―目標や進め方を決めよう 第5章
編集・発行元 独立行政法人情報処理推進機構(IPA) 社会基盤センター 発行日 2019年12月20日 サイズ B5変形判 ページ数 498ページ ISBN 978-4-905318-72-9 定価 2,500円(税込) 書籍概要 概要 デジタル技術を活用して企業のビジネスを変革し、自社の競争力を高めていく「デジタル・トランスフォーメーション(DX)」が注目を集めるなか、従来のようなITベンダやシステム部門が中心になって要件定義をすすめるスタイルから、業務部門のユーザが主体的に関与するスタイルへの変革の必要性が増しています。 システムの要件を定義する責任は、構築されたシステムを利用してビジネスに貢献する役目を負うユーザにあると言われています。しかしながら、システム開発の遅延の過半は要件定義の失敗にあると言われるように、要件定義においては、その過程で様々な問題に直面します。 そこでIPAでは
はじめに 最近プロジェクトマネジメント関連の仕事をする機会が増え、(駆け出しですが)要件定義や設計関連の業務もするようになったので、私の経験を基に要件定義の具体的なプロセスや考え方について、まとめていきます。 この記事の対象者 要件定義の基本や思考プロセスを学びたい人 エンジニアからプロジェクトマネジメントをやりたい人 ビジネスサイドとエンジニアサイドのコミニュケーション能力を向上させたい人 具体的な事例を通して要件定義を学びたい人 前提 紹介する内容はあくまで一例であり、プロジェクトやチームの状況に応じて調整が必要 あくまで自分(駆け出しPM)の経験に基づいた内容を言語化しています プロジェクト規模は10名〜20名のWebアプリ開発を想定しています システム開発の全体像 一般的なシステム開発のプロジェクトは下記のフェーズで進んでいきます。 ※ コンサルの領域だと要件定義の前に企画構想とい
Have you been in any of these situations? Managers make decisions that’s out of their leagues and everyone else in the team ends up paying for it. Knowledgeable people passively observe without bothering to contribute. Sometimes they are denied access to the room. Developers act like code monkeys, throwing the code over a metaphorical wall for the QA to test and “DevOps” to run. In “you build it,
プロジェクトマネジメントといえば「進捗確認」と思っている人も沢山いると思いますが、私は進捗確認という行為そのものに否定的です。 このエントリでは、進捗確認という行為がいかに無意味であるかという話および、進捗管理として行うべきことを書いていきます。 誰かのプロジェクトマネジメントの参考になればと思います。 ※ 進捗管理が不要という話ではありません 進捗確認の定義このエントリでの進捗確認は下記の定義とします。 複数人が関わるプロジェクト等において、プロジェクト等をマネジメントするべき立場にある人間が、プロジェクトの所属メンバーに対してタスクの進捗状況を口頭・テキスト等で直接確認する行為 少し難しい言葉で書きましたが「進捗どう?」といった質問およびその回答からなる一連の流れだと思ってください。 なぜ進捗を確認したくなるのかプロジェクトマネージャー(PM)の仕事のひとつに納期の管理というものがあり
要約: 日本で文系営業職からキャリアをスタートし、アメリカに渡ったのちにGoogleのエンジニア系職種であるProduct Managerになった人の話です。 このnoteは、へぇそんなキャリアもあるんだ〜という一つの参考に、また、現状打破のために何かしたいけど何をすればいいのと思っている方へ、なにかシェアできたらと思いいろいろと書きました。長いです。 まずかんたんに私の経歴を。 慶應義塾大学環境情報学部卒業 →リクルートキャリアで法人向け転職支援事業の営業 (n年) →Google日本法人で大手法人向け広告営業 (4年) →Google日本法人で大手法人向け広告プロダクトスペシャリスト (2年) →Google米国本社でGlobal Product Lead (4年) 福島県で高校時代までを過ごし、留学経験もなく、リクルートキャリアで営業として楽しく働いていましたが、頑張っていたら運よく
Regional Scrum Gathering Tokyo2023 の中の moyiyuya さんの「私考える人、あなた作業する人」というセッションが大きな反響を呼んでいました。 スクラムを導入してチームとして一体感をもってプロダクト開発をよりうまくやっていきたかったはずなのに、いつの間にか「私考える人、あなた作業する人」という関係性ができてしまっていた、という相談を受けることがあります。 なぜこのような「私考える人、あなた作業する人」という関係性が生まれてしまうかについて、コミュニケーションの観点で考えてみます。 プロダクトオーナーと開発者の堺目 「私考える人、あなた作業する人」のような関係性が生まれてしまっているチームでは、開発者からプロダクトオーナーに対するコミュニケーションが以下のようになっていることが多いです。 プロダクトバックログを出してくれたらつくります 仕様を決めてくれた
この記事は、以下サイトの機械翻訳です。 何を作るか(あるいは次に何を作るか)を決めることは、プロダクトマネージャーの仕事の中で最も重要な部分の一つです。インパクトを与えるチャンスは何度もありません。だからこそ、賢く選択して、チャンスを最大限に生かすことが重要なのです。 プロダクトの優先順位を決めるには、さまざまな要素を考慮する必要があります。しかし、何よりもまず、お客様の真の問題を解決することを優先しなければなりません。多くの企業では、このプロダクト開発の基本方針が守られていません。おそらく、価値よりも革新性を優先しているからでしょう。私たちは皆、自分たちが最先端の先駆者であると他人に思われたいと思っていますが、市場が求めているのは必ずしもそうではありません。 市場が求めているのは、すでに機能しているものを適度に改良することだったりします。究極のゲームチェンジャーを追い求めるのではなく、フ
プロダクトマネージャーに求められる本質、事業成長に貢献するための具体的な心得についてディスカッションをするイベントが、株式会社フライルの主催で開催されました。今回のゲストは、SaaSやアプリ、Web3など幅広い領域で、長年プロダクトマネジメントに携わり、プロダクト開発コミュニティ「PM Club」の運営をしている佐々木真氏。プロダクトマネージャーに必要なスキルや考え方を語りました。全5回。2回目は、佐々木氏がPMスキルの言語化に挑戦している理由について。前回はこちら。 「課題を特定する」ためにPMがやるべきこととは? 財部優一氏(以下、財部):「課題を特定する」というのは、具体的にプロダクトマネージャーはどんなことをするべきなんでしょうか? 佐々木真氏(以下、佐々木):例えば、「プロダクトを作る」と一口に言っても考えることがけっこういっぱいあるんですよね。まずは、ユーザーを決めなければいけ
4プロダクトを成功させようと悪戦苦闘しているものの、プロダクトの行く末についてプロダクトオーナーやプロダクトマネージャといった一部の人の意思決定に依存しすぎてしまっていると悩んでいるチームが、彼らと共にプロダクトマネジメントを実行できるようにするセッションです。「プロダクトオーナーがボトルネック」という状況から、おさらばしましょう。 概要 https://confengine.com/conferences/regional-scrum-gathering-tokyo-2023/proposal/17655 発表者 https://twitter.com/_N_A_ https://note.com/mryy
各位 Scrum.orgにて公開されている「Scrum Guide Companion for Leaders」を代表の長沢智治が共訳にて日本語翻訳し、日本語翻訳版『リーダーのための「スクラムガイド」手引き』として、Scrum.orgに提供し、公開されましたので、お知らせいたします。 また、同タイミングにて、「ビジネスアジリティのための投資戦略」も同様に日本語翻訳版が公開されました。 リーダーのための「スクラムガイド」手引き スクラムガイドは、複雑な問題に対応するフレームワークのルールとして浸透していますが、リーダーシップの役目を担うステークホルダーの一人としてどのように支援し、役目を果たすのかは、キャッチアップが難しい面があります。そこで、「Scrum Guide Companion for Leaders」では、文字通りスクラムガイドをリーダー層の理解促進と、スクラムチームの支援を的確
昨年10月にIPA(情報処理推進機構)の国家資格『プロジェクトマネージャ試験』を受験しました。 年が明けて「そういえば合格発表はいつだったっけ?」とIPAのサイトを見に行ったら、昨年12月下旬には合格発表がされていて、無くさずに持っていた受験票の情報を使ってチェックしたら、合格していたのでした。結構厳しいかと思っていたので、新年早々かなり驚いてしまい声が出たので、家族には変な目で見られました。 ※午前1は免除。午前2と午後1は60点以上で合格、午後2は4段階でAが必須 この記事では、非エンジニアの私がどうしてプロジェクトマネージャ試験を受験をしようとしたのか、どのような勉強をしたのかを紹介します。どなたかの参考になれば幸いです。 受験のきっかけ 2週間(20時間)しか勉強しなかった背景 勉強計画の策定 各試験のリソース配分 午前2(試験時間40分) 勉強時間 3時間 午後1(試験時間90分
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く