イーロン・マスクが YouTube チャネルでスペース X のテキサス工場スターベースの中を歩き回りながらロケット製造や電気自動車について説明しているのを観た。ツイートしたこの件。 これがめちゃくちゃに示唆に富んでいて面白かった。この日のイーロン・マスクは饒舌で楽しそうなので、かなり魅入ってしまった。きっと彼はカンファレンスや会議室の中でインタビューを受けるよりも、工場でみんながロケット作ったり作業している場で語った方が情熱を込めていろいろ説明してくれるんだと思う。 この中で製造工程の話があって、これはロケット製造などの特定分野だけでなく、IT やその他の分野にでも当てはまる普遍的な知見だと思ったので意訳してみた。ざっとビデオを観て印象に残った部分だけを意訳した。あくまで大枠で言ってることをまとめただけなので、もし詳細に興味があればぜひビデオを観てイーロン・マスクの話を直接聞いて確認してく
「のどが渇いた」というユーザーに何を出す？ ユーザーの「欲しい」に惑わされない、本当のインサイトを見つけるUXデザイン・UXリサーチ
2022年9月13日 株式会社メンバーズ ポップインサイトカンパニーでのウェビナーのスライドです。「ユーザーが欲しいと言った機能をつけたのに使われない！」という経験はありませんか。プロダクトをつくるとき「ユーザーの心理を理解しよう」とよく言われます。しかし、ユーザーに言われたままやることと、ユーザーが本当に望んでいることは異なります。「UXデザイン・UXリサーチ」は、ユーザーを理解するための専門技術です。ユーザーインタビューやユーザビリティテストを用いてファクトを集めることで、ユーザーの表面的な言葉に惑わされない、本当のインサイトにたどりつくことができます。かんたんなワークも交えながら、体系的に解説いたします。Read less
界隈がざわつくほど超進化したPMBOK第7版の解説【プロジェクトマネジメント】｜Miz Kushida
・・・ ・不確実性パフォーマンス・ドメインについて加筆しました ・テーラリングについて加筆しました ・適応課題について補足を追加しました。 はじめにPMBOKといえば、PMIが世界中のプロマネの実務家から意見を集めてプロジェクトマネジメントについて知識体系化している分厚い本、というイメージです。 いや、でした。。。以前の第6版までは（7版からはすごく薄い）。 2021年8月に第7版が発表されると（ただし、日本語版はもっと先）公式からアナウンスがありましたが、本家サイトに行ってみると英語版は既に購入できる状態でしたので早速電子版を購入し読みましたので解説したいと思います。 一応前置きしておきますと、僕はPMPホルダーではありません。外資系にいるときにPMBOKをベースとしたプロジェクトマネジメントを実施したり、国内企業ではCMMI レベル5（最高レベル）を運用したりバージョンアップ対応を経験
会社の体制が大きく変わり、カオスの中に少しの静寂（暇）ができました。特に日々執行に勤しんでいる方々は皆そうだと思いますが、色んなこと考えているのにそのプロセスをアウトプットする機会があまりなく、結果や結論、最終的な決断のみが共有されるため、サクセッションプランに対する有効な情報を残すことも出来ていないことと思います。僕もその一人。 この時間を有効に活用するため、頭の中にあるイメージと考え方をここに、時間の許す限り吐き出していこうと思います。時折、言葉が足りないところも前提条件やバイアスの記述が足りないところもあるかと思いますが、混沌とした頭の中を曝け出すプロセスにはつきものですので、大目に見ながら読んでいただけると幸いです。 財務諸表と同じように見える化する会社は財務諸表によって経営されるものなので、経営者たるもの財務諸表を見ながら戦略を立てるべきであると僕は考えています。数字以外信じない
いまこそ「良い仕様書」がチームの生産性の鍵となる。ので、仕様書に含めたい 14 のポイントについてまとめました。｜Fritz | Lead Product Manager @ Mercari
いまこそ「良い仕様書」がチームの生産性の鍵となる。ので、仕様書に含めたい 14 のポイントについてまとめました。 こんにちは、フリッツ です。今回はプロダクトマネージャーの日課とも言える「仕様書」について。自分にとっては PM 業の施策実行フェーズにおいて最も重要な仕事のひとつであり、最も心躍り、最も興奮する瞬間です。 PM になってかなりの時間が経ちましたが、「仕様書」への力の入れようは減るどころか、「もっと気合を入れなければ。」と感じる一方。在宅勤務が（たぶん） IT 業界のニュースタンダードとなっていくいま、なおさら「仕様書」の重要性を訴えたい今日この頃です。 ということで、今回は ・ 良い仕様書がもたらす 5 つの効果 ・ 仕様書の重要性が増していく 2 つの理由 ・ 仕様書に含めたい 14 の項目・実戦編 ・ 仕様書作成時に心に留めたい 3 つのこと ・ 具体的な仕様書サンプル（
ウクライナ軍に入隊したアジャイルコーチが、さまざまなメソッドを駆使して中隊長としてのリーダーシップを実現した話（前編）
ウクライナ軍に入隊したアジャイルコーチが、さまざまなメソッドを駆使して中隊長としてのリーダーシップを実現した話（前編） アジャイル開発の代表的な方法論であるスクラムをテーマに、都内で1月に開催されたイベント「Regional Scrum Gathering Tokyo 2024」で、経験豊富なアジャイル開発のエキスパートとしてウクライナを拠点にアジャイルコンサルタントをしていたドミトロ・ヤーマク（Dmytro Yarmak）氏が、ロシア軍の侵攻後にウクライナ軍に入隊し、中隊長としてリーダーシップを発揮するためにさまざまなメソッドを駆使して軍隊の組織を変革していった経験を語ったセッション「A True Story of Agile Coaching in Ukrainian Armed Forces」が行われました。 軍隊という、企業とは異なる構造や目的を備えた組織で、しかも多くの民間人が入
「プロジェクトマネジメントの基本が全部わかる本」は序盤から『交渉』について書いてるところが良いと思った - フジイユウジ::ドットネット
「プロジェクトマネジメントの基本が全部わかる本」を買ったら、注文ミスして2冊頼んでしまったんだけど、結果的にはむしろ2冊買ってよかった、という話を書きます。 「プロジェクトマネジメントの基本が全部わかる本」 （ @paradisemaker 著）が届いたー。 なんか注文ミスって2冊届いたけど、1冊は誰かに読ませるとき用にしようw pic.twitter.com/evnrXtssm8 — フジイユウジ (@fujii_yuji) 2022年11月10日 制作/開発をするメンバーはいるけどプロジェクトマネジメントは得意ではなくて雑になってしまっているという制作/開発会社も多いと思うのですが、僕もそういう会社からどうしたらいいのか相談されたり、PMの育成の話をすることがあります。 (肩書としてPMだったことはないんだけど、僕も20年くらいPdM的な仕事をやってるんで相談されることがそれなりにある
よく、仕様書を書いていなくて、書いてみたいけど、具体的な仕様書がネット上に落ちてなくってこまってるって相談を受けるので 「仕様書の記載内容のイメージ」を作りました！ ※前提として「現在仕様書を書いていない、自社開発のMVP検証前後のフェーズのスタートアップ向け」に書いています。PMが仕様書、エンジニアがDesign Docを書く分担です。 ついでに、システム開発の基礎である「システム開発のV字モデルをベースにした設計書の紹介」も含めてまとめてみましたー！ 大規模開発に使われたり、古くからあるフレームワークなので、スタートアップの方だと、システム開発のV字モデルの概念やそれにあわせた成果物を知らない人が多いけど、「要件定義書」と「設計書」を全てドキュメント化するとどうなるかを理解した上で、「仕様書」として情報を削る方が、考慮漏れ防止やエンジニアがやっている設計内容の理解につながるので、全体を
突然ですが、ここに一つのプロダクトがあるとします。 そのプロダクトを見つめる視線には様々な種類があります。 そのプロダクトを利用しているユーザーの視点、利用していないが存在は知っているという人の視点、それをつくるデザイナーの視点、プロダクトを運営している会社経営者の視点… もしあなたがデザイナーであれば、デザイナーの視点だけが唯一自分で体感できる「主観」で、それ以外はすべて「客観」となります。 主観と客観のスイッチング プロダクトデザイナーはユーザーの期待通りに正しく動くしくみを設計し、「このプロダクトを利用した時に、ユーザーの生活はどう変化していくのだろうか？」と問いを立てながらアウトプットを評価していきます。 自らの考える理想像をデザインしながら、一方でそれに触れるユーザーの様子を想像する…プロダクトデザイナーは主観と客観を電気のスイッチのように瞬時に切り替えることに長けた人が多いイメ
プロダクトマネジメントと事業開発に関する私的な振り返り - 下町柚子黄昏記 by @yuzutas0
TL;DR 企画力が…欲しい… pic.twitter.com/hJfr0qNv7T— ゆずたそ (@yuzutas0) 2020年11月19日 試行錯誤の瓦礫の記録です。 はじめに もくじ TL;DR はじめに もくじ 以前書いた記事 前提・免責 アイデア 1日1案（やってよかったこと） 1stスクリーニング（やってよかったこと） コミュニケーション チームへのリスペクト（やってよかったこと） 話す <<< 聞く（改善余地あり） 即決する（やってよかったこと） 自分で各論まで見る（やってよかったこと） 発散→収束でディスカッション（改善余地あり） イラストで話す（改善余地あり） 日次ミーティング（やってよかったこと） 議事録を書く（改善余地あり） 得た情報を共有する（改善余地あり） 想定納期を示す（改善余地あり） カレンダー招待＆日程確約コメントを転記（改善余地あり） プロセス管理 仮説
今やあらゆる場面で必要とされるプロジェクトのノウハウを、300件以上成功させてきたプロフェッショナルがこっそりお伝えします。 先日、仕事で関わっている方から、「結局、プロマネって何ができないといけないんですかね？」という質問をされたので、その場でざっくり洗い出してみました。 世の中には PMBOK や ITSS, PRINCE2 などのスキル標準を定めたものはありますが、これらは大規模システム開発を志向しており、概念として抽象度が高いためベースの知識として利用できる環境は残念ながら非常に少ないという現実があります（もしこれらを利用できる環境にいるならとても幸せなことです）。 少なくとも日本で実施される一般的なプロジェクトは PMBOK や ITSS を元に共通認識を整備するどころか、「限られた予算で1年でクライアントのシステムを刷新する必要がある」とか、「社長の思いつきで何も決まっていない
本記事は、Engineering Manager Advent Calenderの１日目です。 はじめに エンジニアリングマネージャ(EM)と呼ばれる職務を設置する企業が増えてきました。 私たちの主催したイベントEOF2019でも700名近い方に参加していだき、また多くの方にご協力いただき成功裏に終わることができました。 EM Meetup/EM.FMなどのムーブメントの中心の一翼を担わせていただき、その高まりを感じる一方で不安も感じます。このエンジニアリングマネージャという職務は非常に多岐にわたるケースが存在していますし、必要だとされるスキルもまちまちです。そして、多くの場合、その企業のステージや状況ごとに求めるものは違います。また、求めていることを明文化することすらされていないケースも存在します。 このことから、エンジニアリングマネージメント自体が一時的な潮流として消費され、消えていっ
Founder Customer Fitこのセクションについて解決したい課題を見つけよう顧客を決めようリーンキャンバスを書こうミッションを決めようCustomer Problem Fitこのセクションについてペルソナを立てよう共感マップをつくろうカスタマージャーニーマップをつくろう課題仮説を整理しようプロブレムインタビューをしようProblem Solution FitこのセクションについてPEST分析をしようフックモデルを定義しようプロトタイプをつくろう解決策仮説を整理しようソリューションインタビューをしようSolution Product Fitこのセクションについて名前をつけようユーザーストーリーマップをつくろうMVPを構築しようMVP仮説を整理しようMVPインタビューをしようProduct Market Fitこのセクションについてグロースサイクルを定義しよう利用規約をつくろうプロ
プロダクトマネジメントのコーチをしています。プロダクト開発の中でもGPT4を使うケースが増え、相談されることが増えてきました。 ChatGPTのGPT4を用いた際の、専門家として信用できる精度で推論させるための工夫の一部を紹介します。精度が必要な専門職かつ中級者向けになると思います。「機密情報の入力をどうさけるか」といった運用の話は今回はしません。 やったことと起きたこと一通り論文を読んで試したり、試行錯誤しました。 その結果、専門家として業務レベルで使える程度のものができるようになってきました。 クライアントのプロンプトを添削する仕事も増えつつあります。副作用として、日本語なのに日本語と感じられない自然言語に目覚めてきました。この片鱗についてお話しします。 分かったこと分かったこととして、精度を業務レベルで用いるためにまずはじめにとりくむことは下記です。 ・接待モードを切る ・指示の質が
プロダクトマネージャーという仕事はビジネス・デザイン・エンジニアすべてのスキルが求められる総合格闘技のような仕事です。その分、やることも多く忙しくなりがち。 しかし、再現性の高いプロセスというのは仕事が変わってもそのまま活用できます。その代表例がフレームワークです。 今回は世の中に数あるフレームワークのうち、プロダクトマネージャー・事業開発者が絶対知っておいた方が良いと判断したものを厳選してみました。 プロダクトマネージャー向けフレームワーク4選1. Product Prioritization Frameworkhttps://www.product-frameworks.com/Gusto-Product-Prioritization.htmlこちらはもうプロダクトマネージャーであれば無意識に考えていてほしいくらいシンプル、かつ大事なフレームワークです。 expected：期待値の大き
最近は仕事をするとき必ずNotionを触っていますので、仕事をする=Notionを使う、と言っても過言ではありません。Notionの素晴らしい点は、私のように複数社で顧問をしていても、必要な業務によってカスタマイズができることです。 日々Notionを使う中で「プロダクトマネージャーが圧倒的に仕事しやすくなるテンプレートを作りたい！」と思ったのが始まりです。そんな中いろいろ探してみたところ、Notionのテンプレート自体はすでに色々なものがありますが、現実問題としてToo much（情報が多すぎる）ものもあれば、逆に情報が足りないものもあり最適解がありませんでした。 そこで、プロのプロダクトマネージャーとしてこれを使っておけば間違いない！というものをキュレーションして整理しました。そのテンプレートの使い方を解説します。 ※テンプレートはページ下部からご利用になれます プロダクトマネージャー
「私考える人、あなた作業する人」を越えて、プロダクトマネジメントがあたりまえになるチームを明日から実現していく方法/product management rsgt2023
4プロダクトを成功させようと悪戦苦闘しているものの、プロダクトの行く末についてプロダクトオーナーやプロダクトマネージャといった一部の人の意思決定に依存しすぎてしまっていると悩んでいるチームが、彼らと共にプロダクトマネジメントを実行できるようにするセッションです。「プロダクトオーナーがボトルネック」という状況から、おさらばしましょう。 概要 https://confengine.com/conferences/regional-scrum-gathering-tokyo-2023/proposal/17655 発表者 https://twitter.com/_N_A_ https://note.com/mryy
こんなエンジニアリングマネージャだから仕事がしやすいんだなぁと思う10個のこと - Mitsuyuki.Shiiba
最近、毎日のようにEMのいくおさん（ @dora_e_m ）とTwitterXでわちゃわちゃしてる。彼のポストを見ていると、ガンプラをつくるかビールを飲むかしかしていないように見えるが、それで合っている。 という冗談はおいといて真面目な話をすると、エンジニアとしての僕は彼と仕事ができている今の時間のことを本当に貴重な時間だと思っている。とにかく仕事がしやすいし、いろいろな気づきを与えてくれるおかげで、自分自身の成長も感じている。 エンジニアリングマネージャとしての知識が豊富でスキルが高いというのはもちろん、人との接し方や日常的なふるまいもとても尊敬できるものなのだ。 そこで今日は、僕が彼とこの3ヶ月間仕事をしていて、やりやすい・尊敬していると感じていることの中から10個だけ簡単に紹介しようと思う。僕からいくおさんへの日頃の感謝の気持ちをあらためて書いておこうと思っただけとも言う（ふだんから
「マネージャーは1時間単位でタスクにあたるが、エンジニアはまとまった半日単位の時間がある方が良い」話について - SaaSベンチャーで働くエンタープライズ部長のブログ
タイトルは、ポール・グレアム氏（Yコンビネーター）の「メイカー（作り手）のスケジュールとマネージャーのスケジュール」(Maker's Schedule, Manager's Schedule) からの引用です。 マネージャーは多くのミーティングをこなすなど、1時間単位でタスクにあたりますが、エンジニア（プログラマ）は最低でもまとまった半日単位の時間を作業に必要とする、と書かれています。 paulgraham.com 日本語訳 note.com エンジニア上がりのプロダクトマネージャーとして開発もプロダクトマネジメントも並行してこなしてきたのですが、意思決定のためのミーティングスケジュール、自身が開発を行うためのスケジュールをやりくりするバランスに腐心していました。 自身のタイムマネジメントで特に感じた点として、ミーティングとミーティングの間に1時間が3コマある時の開発生産性と、3時間まとま
プロダクトマネジメントを学びたい人、プロダクトマネージャーにおすすめの書籍です。 以下、記載した書籍のリストです ## Product Management ### プロダクトマネジメントを広く理解する 「プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける」オライリージャパン (2020/10/26) https://www.amazon.co.jp/dp/4873119251/ 「プロダクトマネジメントのすべて 事業戦略・IT開発・UXデザイン・マーケティングからチーム・組織運営まで」翔泳社 (2021/3/3) https://www.amazon.co.jp/dp/4798166391/ 「INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント」日本能率協会マネジメントセンター (2019/11/1) https://www.amazon.co.jp/dp/4
Google、プロジェクト管理のための新ノーコードツール「Tables」発表。リスト／カンバン／チケット管理／マップなど柔軟なビュー、Botによる作業自動化など
Tablesは、プロジェクト管理や業務管理のためのタスクトラッキングツールです。 スプレッドシート形式のデータをベースに、リスト形式での表示やカンバン、チケット管理、マップなど柔軟なビューや、イベントをきっかけに動作するBotによる自動化などを特長としています。 タスク形式の表示例。 Botは、例えば未終了のタスク一覧をチーム全員に毎週末メールで送信するといった定期的な作業や、ステータスの変更をトリガーとしたデータ操作などの作業をあらかじめ定義することで自動化できる機能を備えています。これらの定義はノーコードで可能。 またGoogle ChatやSlackなどとの連携、Google Formからのデータの自動流し込みなど、他のツールとの統合も可能になっているとのこと。 このTablesの担当ゼネラルマネージャ Tim Gleason氏は、プロジェクト管理を効率化するためにTablesを開発
プロダクトの成功に必要な 3 つのステージと 20 のタスクについて：現場の動き方をまとめました｜Fritz | Lead Product Manager @ Mercari
こんにちは、フリッツ です。プロダクトマネージャー（以下 PM）になってから相当の年月が経ち、特に、現職の US メルカリにおいては「 UIUX 強化型 PM 」として認知されるようになりました（ありがたい）。 ただ、最近は自分があまりにもいま持っているスキル・経験に立脚しすぎているなぁ、と感じており、強みの分野を広げようとお勉強中。 ということで、旅の序盤として、本記事では「プロダクトの成功」を導くために必要とされる、問題定義・優先順位決定・実行 という 3 つのステージを PM 視点から 20 項目にわけてみました。できるかぎり、（自分の今までの）現場の動き方に沿うようにまとめました。割と基本的な内容ではありつつも、特に実行のパートにおいては、現場で役立つような個人的知見を多少含められたはず…。 プロダクトに関わる方、および・駆け出し～数年目の PM の方のお役に立てる記事になっていれ
エンジニアリングマネージャー必読の翻訳書 7選
Dec 8, 2021 マネージャーとしてチームを率いる際、自分が正しくチームをマネージメントできているのか？ 誰か偉大なマネージャーに教えを請いたいと思う人は多いのではないでしょうか？ 一方で、現場でマネージメントに関する手厚い指導を受けられる機会は少なく、日々の業務に忙殺されてしまうのが現実かと思います。 そんな中、海外の上司や同僚から勧められた書籍からは非常に多くの事を学ぶ事ができました。 どの書籍も非常に多くの批評を経て評価されており、秀でた著作は翻訳されています。 日本で日本語で書かれた書籍も読みやすく、血肉になります。 一方で翻訳書はクセはあるものの、日本からは得づらい情報や面白いエピソードを提供してくれます。 また書かれている内容を共通の概念としてグローバルなマネジメントチームと会話できるというのも助かる点でした。 今回は自分が読んできたマネージメントに関する翻訳書の中で特に
訳者注 本記事は、Dan Schmidt 氏のブログ記事「A Visual Vocabulary for Product Building」をご本人の許可のもと日本語訳したものです。 ninjinkunさん、Koshiro Kumikoさんにレビューにご協力いただきました。的確かつ、建設的で思いやりのあるアドバイスとフィードバックに感謝します。 同一著者の関連記事としてこちらもぜひ合わせてご覧ください：【翻訳】プロダクトマネジメントトライアングル 以下、翻訳本文です。 プロダクトビルダー（訳注：プロダクトをつくる人たち）が自分のプロダクトに当てはめられるような、成功するプロダクトをつくる方程式はありません。これは、プロダクトが置かれている常に変化するコンテキストに、プロダクトづくりの詳細が大きく左右されるからです。あるプロダクトで成功した戦略が別のプロダクトではまったくあわないこともありま
[いわゆる退職エントリ] Microsoft を辞めることにしました（あるいはサポートエンジニア → Product Marketing Manager になるまでなど） - Qiita
[いわゆる退職エントリ] Microsoft を辞めることにしました（あるいはサポートエンジニア → Product Marketing Manager になるまでなど）退職エントリ 皆さんごきげんよう。ういこうと申します。 これまで日本マイクロソフト株式会社で Azure のフロントエンド領域を中心としたサービスの Product Marketing Manager をしておりましたが、6/30 日をもって退職することとなりました。 きっと Microsoft 界隈以外では、あなたどなた？という感じだと思いますので、少し自己紹介と、退職エントリ（のようなもの）を書くことにした理由を紹介させてください。ちょっと、いや...かな～り長いので、おやつでも食べながら読むものがないなーというときや、今エンジニアなんだけど、マーケティングなど、テクニカル ロール外の職種に転換しようと思ってる、あるい
![[いわゆる退職エントリ] Microsoft を辞めることにしました（あるいはサポートエンジニア → Product Marketing Manager になるまでなど） - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/bc81715cecfdae25ce86937791cb887e21778600/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCJUUzJTgxJTg0JUUzJTgyJThGJUUzJTgyJTg2JUUzJTgyJThCJUU5JTgwJTgwJUU4JTgxJUI3JUUzJTgyJUE4JUUzJTgzJUIzJUUzJTgzJTg4JUUzJTgzJUFBJTVEJTIwTWljcm9zb2Z0JTIwJUUzJTgyJTkyJUU4JUJFJTlFJUUzJTgyJTgxJUUzJTgyJThCJUUzJTgxJTkzJUUzJTgxJUE4JUUzJTgxJUFCJUUzJTgxJTk3JUUzJTgxJUJFJUUzJTgxJTk3JUUzJTgxJTlGJUVGJUJDJTg4JUUzJTgxJTgyJUUzJTgyJThCJUUzJTgxJTg0JUUzJTgxJUFGJUUzJTgyJUI1JUUzJTgzJTlEJUUzJTgzJUJDJUUzJTgzJTg4JUUzJTgyJUE4JUUzJTgzJUIzJUUzJTgyJUI4JUUzJTgzJThCJUUzJTgyJUEyJTIwJUUyJTg2JTkyJTIwUHJvZHVjdCUyME1hcmtlJUUyJTgwJUE2JnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz00ODU2YTNjNjM3NjI0ZTkwZTcxMzcxN2FjOTBhNTYzOA%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDB1aWtvdSZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9MDAyMDkxYmJhMGU4MzM4ODkxOTkyOTBhYjNmZGE2MWI%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3Db4afdd848b8c2478ef90e07d4b10533a)
PMBOKとはPMBOKは「Project Management Body of Knowledge」の略語で、日本語に訳すと「プロジェクトマネジメントの知識体系」です。読み方は「ピンボック」です。米国のプロジェクトマネジメント協会（PMI）が1986年にPMBOKのガイドブックの初版を刊行してから、ほぼ4年ごとに改訂され今では「プロジェクトマネジメントの世界標準」とされています。 本来「PMBOK」は体系そのものを指しますが、PMBOKのガイドブック「PMBOK GUIDE」を指す言葉としても用いられています。 【参考】PMI日本支部 2017年に発刊されたPMBOKの第6版はA4判750ページの大冊でしたが、第7版は250ページと1/3のボリュームになりました。目次の構成もガラリと変わっています。この大改訂にショックを受けたのが、プロジェクトマネジメント協会が主催するPMP試験（プロジ
本稿は Gergely Orosz 氏によって書かれた次の記事の日本語翻訳です。著者に翻訳の許可を得て公開しています。 blog.pragmaticengineer.com また本稿は DeepL Pro を使って下訳したものに手を加えています。日本語翻訳の不具合または誤訳については Gergely Orosz 氏ではなく、本稿のコメント欄にお願いします。 著者も機械翻訳を下地にしたやり方に関心をもたれたようです。 The article translated to Japanese: https://t.co/4uynyyhm4E The author was transparent and noted that the article is a modification of an ML-translated article. This person managed to transl
システム思考とプロダクトマネジメント ※プロダクトオーナー祭り2021 Spring - PO祭り2021Springでの登壇資料です https://postudy.connpass.com/event/202404/
企業でWebアプリケーションエンジニアとして働き始めて2年と4ヶ月ほど経ちました。様々な仕事を経て、自分が向いていることや楽しく感じることが徐々に明らかになり、数年後になりたい像がぼんやりと浮かび上がってきました。そして、その将来像が世間的には「エンジニアリングマネージャー」（以降EM）と呼ばれていることもわかってきました。この記事では、EMについて自分が周囲から受け取った知識を整理するとともに、そこに向けてどんな戦略を取ろうとしているかをまとめてみます。マネージャーというとネガティブなイメージも拭えませんが、EMは年を重ねて吸い込まれるものではなく、積極的に取りに行くに値する面白いポジションであると思います。この記事を読んでEMに魅力を感じる同世代の仲間が増えると嬉しく思います。 EMについての理解 エンジニアリングマネージャーという職務についてのオーバービューは、広木大地さんによるエン
普通はプロジェクトマネージメントなんてできない
しんざき氏の記事を読んだ。 https://blog.tinect.jp/?p=81116 要は家庭運営は「プロジェクト」であるのだから適切なプロジェクト運営を行う必要がある、という趣旨で内容については概ね同意ではあるのだが、これを実践しようとするには大きな問題がある。 普通の人は「プロジェクトマネージメント」なんてできないのだ。 私はいろいろな会社の小さめのプロジェクトに参加して開発を請け負うエンジニアなのだが、まともなプロジェクト責任者に当たるのは20%もない。 ここでいう「まともな」というのは、 ・タスクを適切な粒度に分解できる ・タスク同士の前後関係を把握してスケジュールを組める ・品質、コスト、納期を考慮とした優先度付けができる という、プロジェクトマネージメントを行うにあたっての最低限のスキルがある人である。 もちろん優秀な人が集まる大企業であれば多くの人が簡単にこなせるだろう
これまで私はプロダクトマネジメントやデザインディレクションを行う立場として、BtoBにBtoC、iOSにAndroidにWebにWatchOSにIoT、ゼロイチにグロース。様々な分野、プラットフォーム、フェーズでサービスを開発する機会に恵まれてきました。 その中で一緒にチームを組んだフロントエンド、サーバーサイド、iOS、Android、インフラ、データ、様々なエンジニアの方を思い出しながら「ああ、心強いな」と感じた色々なタイプの特徴を、リスペクトの想いを持って、プロダクトマネージャーやデザイナーの視点でまとめてみました。 それではいってみましょう。 目的にフォーカスしている 要件をただ実装するのではなく、ビジネスの目的はなにか、ユーザーが真に求めているものはなにか、なにがサービスの生死を分けるのか、技術は目的を達成するための手段だと客観的に捉え、真の目的に対して解決策を提案し続けてくれる
万能ツール「Notion」共同創設者のIvan Zhaoが考える、プロダクト、採用、バリューのポイントを直接インタビュー
ALL STAR SAAS FUNDのメールマガジン「ALL STAR SAAS NEWSLETTER」購読登録受付中ALL STAR SAAS FUNDがお届けする 最新SaaSニュース、ブログ記事情報を配信するSaaS業界にいる方は必見のメールマガジン！ このツールを定義することは難しい。Notionは、半ば苦し紛れのように「万能ツール」や「生産ツール」と呼ばれる。ただ、俯瞰して見ると、言い得て妙でもあり、そうとしか呼べないともいえる。つまり、それこそが、Notionの魅力なのだ。 世界中で、熱心なユーザーを増やし続けるNotion。高まるのは愛情だけではない。2020年4月には約54億円を調達し、大胆な発展を見せる。今回は、共同創設者であるIvan Zhaoさんに、前田ヒロがその成り立ちや組織運営などを聞いた。 Notionは、京都で再生した 前田：今日はお時間をいただき、ありがとう
はじめにこれは何？ 数カ月間マーケット調査、商談をして見えてきた日本とグローバルでSaaSプロダクトに求められることの違いを紹介する 誰向けの記事？ グローバルで利用されるプロダクト開発に興味のあるPdM, エンジニアの方 まとめると？ 競合がエグい。日本はプロ野球で、グローバルはメジャーリーグみたいなイメージ。プロダクトは広く浅く→狭く深くに要件が変わる。 エコシステム、SaaS市場の成熟度の違いから、インテグレーションファーストになる 時差や人件費の違いがプロダクトに影響を与え、セルフサービス前提の設計になる 伝えたいこと グローバルで使われるSaaSプロダクトづくり（＝メジャーで野球する）、そしてそこで勝つためのプロダクト・開発組織づくりに経営者として本気で取り組みます。 メジャーで勝利するために、優秀なメンバーが集まり、切磋琢磨し、成長できる環境。勝ち筋も見えています。他ではできな
チームで成果を出すためには心理的安全性が必要で、そのためには礼節とHRTが不可欠だ、という話をしました | DevelopersIO
事業開発部の塩谷 (@kwappa) です。 クラスメソッドの関連会社であるアノテーション株式会社の研修として依頼を受け、チームと心理的安全性、それに礼節というテーマで話をしてきました。 スライド 概要 ここしばらく重点的に書いたり喋ったりしている、心理的安全性とその土台となる礼節がテーマです。昨年のDevelopers.IO Tokyo 2019でのセッション『3つの「Re」〜ソフトウェアの信頼性を高めるためにぼくたちができること〜』 をベースに、発表時間が少し長くなったので各要素の解説を丁寧にしつつ、全体の流れを整理しています。 また、エンジニアに特化した部分をはがすことも意識しています。チームで仕事をするのはエンジニアに限ったことではないですし、昨年末からOpsチームのスクラムマスターをやっていることも影響しています。ともすると「仕事 = コードを書く」という意識に傾きがちな自分への
解像度を上げる 🔬
2023 年 4 月にアップデートしました。 ビジネスにおいて「解像度が足りない」という言葉が使われるようになりました。この解像度という概念を、深さ、広さ、構造、時間の4つの軸で整理して、それぞれでどうやって解像度を上げれば良いのかについて解説しています。 このスライドを使ったYouTube での解説動画はこちら (2023年4月版) 東京大学 FoundX の各種リソース •FoundX Review - 起業家向けノウハウ情報 •FoundX Resource - 整理された記事の紹介 •FoundX Online School - 30以上の学習ビデオ教材 •FoundX Founders Program - 個室の無償提供とコミュニティ
はじめに エンジニアリングマネージャーとは? メンバーのサポート・育成・評価 メンバーの状態観察 目標設定・人事評価 後進の育成 日常の労務管理 開発 プロダクトマネジメント エンジニアリングのリーダーシップ 採用・採用広報・アドバイザーの招聘 採用 採用広報 アドバイザーの招聘 他社との情報交換 終わりに はじめに 今流行りの Meetyを使って社外の方とお話しする機会を作っているのですが、「エンジニアリングマネージャーとしてどんなことをしているのですか?」という質問を何度かいただいたので、自分の整理のためにも日々の具体的な行動・活動をまとめてみます。 私はRetty株式会社でtoC Web開発/toB Web開発 両方をみているエンジニアリングマネージャーであり、この記事を書いた2021年9月時点では20名弱のマネジメントを務めています。エンジニアリングマネージャーとなってからは2年が
フューチャーアドベントカレンダー2020の24日目です。 はじめに フューチャーに入ってテックリード（社内だとアーキリーダーと呼ぶことも多い）のような役割をし始めて4,5年ほど経過しました。 いくつかの案件を回して自分なりに汎化・パターン化してきた部分も増えてきたので、気を付けていることをまとめました。 テックリードとは エンジニアのためのマネジメントキャリアパス――テックリードからCTOまでマネジメントスキル向上ガイド によると、以下のように説明されています。 テックリードはエンジニアの階層におけるランクのひとつではなく、シニアのレベルに達したエンジニアが担うことのできる職責群である 技術的なプロジェクトの管理者 部下に効率良く仕事を割り振って自身の負担を適宜軽減するよ う心がける チーム全体の生産性に照準を定め、しかるべき成果を上げるよう全力を尽くさなければならない 管理やリーダーシッ
道の真ん中をきれいにするプロジェクトマネジメント～イケてるチームになるための10原則～ - Qiita
はじめに 私が好きな江戸の小話的なものに、こういったものがあります。 江戸下町では、道向かいのそれぞれが軒先を掃くときに、道の真ん中よりもちょっと向こうまで掃くのがならわしだったそうです。両側の人がそれぞれ真ん中よりも向こうまで掃くので、道の真ん中が一番きれいになる、というお話です。 近年こうした「江戸しぐさ」のようなお話は、真偽のほどが定かではないとして、流布することに批判もあるようです。実際この話も正直事実かどうかは全くわかりません。 ただお互い完璧ではない他人同士が肩寄せ合って共に生きる知恵といいますか、プロジェクトへの参画姿勢について良い示唆を与えてくれる話だと思い、その前提で使っています。 実際私が関わる案件のキックオフでもお客様や関係者によくこの話をするのですが、「キックオフでの『道の真ん中の話』、他の現場でも最近してるんですよ」とお客様やパートナー様から言っていただけたことが
2022/08/04 開発PM勉強会vol.13の登壇資料です。
2019年10月10日に発売した、及川卓也の著書『ソフトウェア・ファースト あらゆるビジネスを一変させる最強戦略』。このnoteでは、出版の経緯や書籍づくりの裏話、発刊時に削った原稿の公開など、制作にまつわるさまざまな情報を発信していきます。 こんにちは、及川卓也のマネージャーの酒井と申します。今でこそ多くの方にご愛読いただいている『ソフトウェア・ファースト』ですが、制作中はプロダクト開発におけるアンチパターンをいろいろやってしまいました。この経験は、その後の私たちの仕事で「これ、進研ゼミでやったやつだ！」的な効力を発揮し、立ち止まって考える機会を与えてくれています。どれもあるあるで、皆さまのお仕事を振り返る際にもお役に立てるのではないかと思い、整理してみました。 ここからは、酒井真弓著『ルポ 日本のDX最前線』（集英社インターナショナル）を再構成してお届けます。 筆者（酒井）は独立を機に
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
イーロン・マスクのロケット製造５つのステップがサイコーだった
CTOの頭の中：技術を財務で表現する｜Shin Takeuchi｜note
仕様書の参考例と、こんな内容を仕様書に最低書くといいというお話｜田辺めぐみ
主観と客観を切り替える鍛錬｜Miwa Kuramitsu
一人前のプロマネってどんな人？ プロジェクトマネジメントのスキルセットとは - 誰も教えてくれないプロマネのコツ
エンジニアリングマネージャ/プロダクトマネージャのための知識体系と読書ガイド - Qiita
プロダクトマネジメント入門: 失敗しないプロダクトの作り方を学ぼう
ChatGPTでstep by stepもロールプレイもやめたらプロダクト開発で使える精度になったよ｜MRYY
事業開発者・プロダクトマネージャーが知っておくべきフレームワーク7選｜Shin
プロダクトマネージャーの仕事を10倍快適にするNotion活用法【テンプレート公開】｜Shin
プロダクトマネジメントを学ぶための推しの書籍
【翻訳】 図解 プロダクトづくりの構造 - ykmc09 blog
PMBOKとは？第7版でPMBOKの内容が劇的に変更された理由
(翻訳) ビッグテックのプロジェクトマネジメントとスクラム不在の謎 - forest book
システム思考とプロダクトマネジメント
エンジニアリングマネージャーを目指す若者の戦略 - yigarashiのブログ
同じチームにいて最高に心強かったエンジニアの特徴をまとめてみた - Qiita
進出して分かった日本とアメリカのSaaSプロダクトニーズの違い
エンジニアリングマネージャーとしてどんなことをしているのか？ - tuneの日記
テックリードになって気をつけていること - Qiita
チームで盛り上げる ファシリテーション
及川卓也の『ソフトウェア・ファースト』というアンチパターン｜ソフトウェア・ファースト制作委員会
tosonline.jp
fkmconsulting.jp
gigazine.net
jp.eporner.com
clay.byduringinside.shop
houkei-kaiketu.hatenablog.com