「私考える人、あなた作業する人」を越えて、プロダクトマネジメントがあたりまえになるチームを明日から実現していく方法/product management rsgt2023
4プロダクトを成功させようと悪戦苦闘しているものの、プロダクトの行く末についてプロダクトオーナーやプロダクトマネージャといった一部の人の意思決定に依存しすぎてしまっていると悩んでいるチームが、彼らと共にプロダクトマネジメントを実行できるようにするセッションです。「プロダクトオーナーがボトルネック」という状況から、おさらばしましょう。 概要 https://confengine.com/conferences/regional-scrum-gathering-tokyo-2023/proposal/17655 発表者 https://twitter.com/_N_A_ https://note.com/mryy
実践プロジェクトマネジメント - SaaSベンチャーで働くエンタープライズ部長のブログ
プロダクトマネジメントを最近は生業としていますが、プロジェクトマネジメントについても必要となることが多くあります。 最近、周囲でもプロジェクトマネジメントが必要な機会を見聞きすることがあり、需要はあるのではないかと思い、私が学んできた知識や経験を書き記してみます。 仕事の終わらせ方は2つしかない プロダクトマネジメントとの違い プロジェクトマネジメントの３種の神器 プロジェクトマネージャーの仕事は不確実性を潰していくこと チームマネジメントについて 「運用でカバー」は最終手段 まとめ 仕事の終わらせ方は2つしかない 新人研修で、仕事の終わらせ方は2つしかないという話を教えてもらいました。その2つは「成果で終わらせるか」、「期限で終わらせるか」です。 （こちらの企業の研修だったと思います http://www.onevision.jp） 言い換えると、あらかじめ定めた成果物が完成した時、ある
MVP（Minimum Viable Product）の意味を理解する。そして、なぜ私はEarliest Testable / Usable / Lovableを好むのか。 | ANKR DESIGN | デザインリサーチ・プロトタイピング・サービスデザイン
数年前、私はこんな絵を書いて、アジャイル開発やリーン開発のついての様々なプレゼンで用いた。 そこから、この絵は急速に広まっていった！記事、プレゼン、さらには本（Jeff Pattonの”User Story Mapping”という素晴らしい読み物なのだが）にまで至る所で姿を見せた。多くの人がこの絵は反復型開発、リーンスタートアップ、MVP(minimum viable product)の本質をよく捉えていると伝えてくれた。しかし、元の文脈から切り離して物事を捉える際にはごく自然なことであるのだが、この絵を誤解している人がいる。簡素化しすぎだと非難する人もいる。（正しい指摘である） この絵はあくまで比喩である。実際の車の開発の話ではなく、車を比喩とした一般的なプロダクトの開発の話なのである。 とにかく、これらのバズからこの考えの背景を話す時だと判断したのだ。 １つ目の例：not like
炎上プロジェクトでスキルを会得する前にお前は死ぬ - GoTheDistance
最短でイッセンマンITエンジニアを目指すなら大炎上プロジェクトがオススメ！！経験浅でも採用の可能性が上がるし、週最大7日間1日15時間以上、プロに揉まれながらスキルを磨けるので面倒な家での積み上げは不要！やり遂げた際の経験値はヤバいし、活躍によってはPMが次のPJに引っ張ってくれるよ！— 代表取締役 岩元仁＠株式会社ロックシステム (@iwa3nen) 2021年8月28日 経験の浅いエンジニアが1千万の年収を得る最短ルートが、炎上案件に飛び込んですげぇ修行して界王拳をマスターしろなのか... 社員にそれを言えるのがすごいな。(いわもと様から社員向けではないとコメントを頂いたので、打ち消します) 炎上プロジェクトで心を病んだ人を多かれ少なかれ見てきて、人づてに色んな哀しみを聞いている身としては、危険としか言いようがない。 僕が若い頃にやった、月稼働400時間が2ヶ月続いたプロジェクトは炎上
ロードマップに機能を書くべからず｜小城久美子 / ozyozyo
機能を書くならバックログにまず機能だけが書かれたロードマップから見ていきましょう。時系列に沿って、どんな機能を追加するのか並んでいます。 残念ながら、多くの場合、機能開発が遅延したり、差し込み案件が発生したりして、以下のようになってしまいます。 こうなると、もうこのロードマップは信頼できません。過去の実装がここまで遅延していると、次に取り掛かる機能がいつリリースされるのか分からず、どれの優先度がもっとも高いのかも判断するのが難しくなってしまいます。 こういった「機能」に近いものは、縦長のプロダクトバックログの形式で並べ、ユーザーストーリーに分解して見積もったものを上から順番に実施していくほうがスッキリします。 では、ロードマップがなぜ必要なのかプロダクトバックログはとても良いものですが、プロダクトの中期的・長期的な未来を構想するには少し見づらくなります。特に、会社の中で中期的・長期的な方針
プロダクトマネージャーに必要な資質って何ですか？ 元グーグルのPM対談 | HRナビ by リクルート
プロダクトマネージャー（PM）ってどんな仕事？ プロジェクトマネージャーと何が違って、普段どんなことを考えながら仕事してるの？——日本でも徐々に認知度が高まってきた「プロダクトマネージャー」にフォーカスし、そんな疑問に答える「Japan Product Manager Conference 2016」が10月24日、25日の2日間にわたって都内で開催された。内外のさまざまな企業で活躍しているPMが壇上に立ち、自らの試行錯誤や経験、時には失敗を踏まえ、PMという仕事の難しさと醍醐味を紹介した。 そのセッションの一つ「グローバル企業におけるプロダクトマネージメント」では、ナイアンティックの河合敬一氏と、カンファレンスの実行委員でIncrementsでQiitaのPMを務める及川卓也氏が登場。「僕がPMとしてグーグルに入ったときの面接を担当したのが及川さん」（河合氏）という関係にある二人が、会場
新入社員に教え込んでいる13の具体的な仕事術を紹介するよ | Outward Matrix
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
「彼女欲しい」という欲求はプロジェクトとして考えると破綻している: 不倒城
「嫁欲しい」「彼女欲しい」というのは、具体的な成果物設定がないままゴールだけを規定しているという、プロジェクトマネジメントとしては失敗プロジェクトのモデルケースみたいな欲求なので、「○○さんを彼女にしたい」みたいな対象物を伴った適切なゴールラインの設定をした方がいいと思います。 ということで、タイトルと最初の三行で言いたいことは全部言ったので、以下は補足。文中「彼女」というのは全て「彼氏」にも読み替え可能だとは思いますが、正直、あまり真面目に受け取ることはお勧めしません。 一般的に言って、プロジェクト構築の際には、最低限以下のような項目を設定しておくことが必要になると思います。 1.プロジェクトの目的設定 2.プロジェクト達成の為のアウトライン設定 3.ステージごとの成果物設定 4.ステージごとの課題・リスク想定 5.ステージごとのスケジュール設定 6.予算想定 7.リソース・体制設定 細
WEBディレクターなら知っておきたい。プロジェクトを上手に進めるために必要な知識。 | 株式会社LIG(リグ)｜DX支援・システム開発・Web制作
WEBディレクターの定義は曖昧です。プロジェクトの舵取り役として、コンセプトから仕様検討、デザイン、設計、プロジェクトマネジメント、マーケティングなど広範囲な業務に携わります。広範囲な業務だからこそ曖昧になりそうな職種ですが、デザイナー、エンジニア、マーケター等、チームから信頼されるために必要な知識をまとめてみました。 WEBサービスの知識 WEBの世界は日進月歩で変化していきます。RSSやソーシャルフィルターなど、自分なりに最新の情報をキャッチできる環境を整える事が大事です。クライアントからの信頼を得るためにも、最新のWEB事情やイケてるデザインをパパっと提案の中に組み込めるといいと思います。情報は大きな武器になるので、アンテナは常に立てておくことをオススメします。 Webディレクターならチェックしたい、ニュースサイト15選 大まかな設計の知識、インフラの知識 データベースの構成やサーバ
チームでのプロジェクトを成功させる秘訣34項目「コラボレーション・パターン」
これまでにない全く新しいものを生み出す時や未知なる領域の問題を解決しようとする時、複数の人でのコラボレーションが重要になりますが、「コラボレーション・パターン」はそうやって複数の人間が一つのことに取り組む際に、アイデアを積極的に出し合い、メンバーが互いを高めあいながら、個人では考えられなかったような結果を出すことができるようパタン・ランゲージの考え方に基づいて作られた34項目。対立や分裂で破滅的な結果が起こることもある集団での作業を、ポジティブな結果に昇華させます。 コラボレーション・パターン ― 創造的コラボレーションのためのパターン・ランゲージ http://collabpatterns.sfc.keio.ac.jp/index.html コラボレーション・パターンは全部で34項目あるのですが、パターンは大きくわけて「未来への使命感」「方法のイノベーション」「伝説を作る」の3つのまとま
JS 大規模プロジェクトの管理手法 – ロードオブナイツの実例紹介
どうもこんにちは。 Aiming で東京開発グループのゼネラルマネージャをやっている小林です。 8月に mobage と Yahoo! モバゲー で ロードオブナイツ というシミュレーション RPG をリリースさせて頂きました。 そして、先週、 Yahoo! モバゲー版の PC ブラウザ専用デザインをリリースさせて頂きました。 今回リリースしたものは元々 Unity で作られていた iOS アプリ版 Lord of Knights を HTML5 で書きなおしたものです。 （今は Android 版 もあります） HTML のポチポチゲーをネイティブに移植したというのはよく聞く話ですね。 ですが、逆にリッチなネイティブアプリを HTML5 に移植し、かつスマフォブラウザと PC ブラウザで同じものを動かすなんてのは前例が見当たりませんでした。 技術的ハードルが高かったことに加えて期日がタイ
PM力であなたも組織も強くなる
数カ月にわたり、お送りして参りましたこの連載、今回でいよいよ最後となります。最終回では、これまでの内容を皆様の実務に活かすために「まずどこから始めるべきか？」についてお伝えしたいと思います。 とりあえず“心配事”を書きだす プロジェクトマネジメントとはリスクと戦う武器です。まずは戦う相手をハッキリさせなければ始まりません。 とりあえず、皆さんがこれから仕事を進める上での心配事、「モヤモヤしていること」「不安に思っていること」「このままでは危ないと思っていること」を洗い出してみましょう。 「うーん、あまりやったことない仕事だからよくわからん！」とか「ふーむ、もしかしたら人手が足らなくなるかも？」とか「いやー、気難しいお客様だからいろいろ怒られるかも・・・」とか、考えれば様々な心配事、つまりリスクを見つけることができると思います。 洗い出しが終わったら、それぞれの心配事について対応策を考えてみ
5分で分かる、「スクラム」の基本まとめ
5分で分かる、「スクラム」の基本まとめ：開発チームを改善するためのスクラムTips（8）（1/2 ページ） 「スクラム」は、アジャイル開発の手法群の中でも、「チームとしての仕事の進め方」に特化したフレームワークだ。スクラムの知識を応用して、開発チームの日常をちょっとリファクタリングしてみよう。 これまで、アジャイル時代のチーム・マネジメント手法として主流になっている「スクラム」の手法を紹介してきました。今回は総集編として「スクラムの基本」をコンパクトにまとめます。 そもそもスクラムとは スクラムは、一言でいえば「チームで仕事の進めるための枠組み（フレームワーク）」です。 もともとはソフトウェア開発プロジェクトを成功させる仕組みですが、技術的な要素は取り除かれ、多くのチーム作業に共通して適用できる要素だけが残りました。そのため、ソフトウェア開発以外のチームにも適用できるのが特徴です。 ●バッ
ソフトウェア開発プロジェクトをとりまく６つの誤解〜プログラミングを経験しないとわからないこと | Social Change!
続きを書きました → 伝えなければ伝わらないという当たり前の話 ソフトウェア開発に関する相談を受ける中で、どうもソフトウェアというものの特性について誤解をされているな、という思いを持つことがあります。 そうした場合、聞いてみるとプログラミングの経験が無かったり、殆どプログラミングには携わったことがないという方が多いです。 ソフトウェアを開発しようとするならば、ソフトウェアという特性をよく知った上で、プロジェクトは運営した方が良いし、うまくいくはずです。そしてソフトウェアならではの特徴を知るのに、プログラミングの経験はとても重要です。 この記事では、プログラミング経験の無い方が陥ってしまいがちな、ソフトウェア開発にまつわる誤解について考えてみました。 Harry Potter is Ready for Divination / weekbeforenext 誤解：既にあるソフトウェアを流用し
プロジェクトのキックオフ会議（その２） - 経営・業務・ICT活用の支援活動記録
顧客獲得などの効果的な仕組み化（業務プロセス再構築）をご支援するコンサルタントの活動記録や役立つ考え方を記録しています。 もう直ぐ、あるプロジェクトのキックオフ会議が実施されます。 ちなみに、システム関連がメインではなく、「業務プロセス見直し」（業務改善）がテーマです。 私は、極力、キックオフ会議には、組織ＴＯＰ（経営層など）に参加していただきます。 理由は、組織ＴＯＰから、 ・本プロジェクトが組織にとってたいへん重要であること ・本プロジェクトの成果に大きな関心と期待をもっていること などを、直接、キックオフ会議で伝えていただくことで、メンバーのモチベーションを高めていただくためです。 少し話しは変わるのですが、各フェーズの区切の会議でも、組織ＴＯＰに参加していただきます。 また普段から、「どうなっている？」とメンバーへ質問していただくことも良いですね。 このように、組織ＴＯＰには、プロ
プロジェクトのキックオフ会議 - 経営・業務・ICT活用の支援活動記録
顧客獲得などの効果的な仕組み化（業務プロセス再構築）をご支援するコンサルタントの活動記録や役立つ考え方を記録しています。 最近、お客様の基幹システム再構築プロジェクトのキックオフ会議が開催されました。 この案件は、今まで、 ①事業戦略策定会議の運営と戦略企画書（一次案）とりまとめの支援、 ②情報化構想の策定支援、 ③情報システムの調達支援、 をさせていただいた上で、 今後は要件定義フェーズのアドバイザーとして参加することになったものです。 私は、情報システム構築プロジェクトのキックオフ会議では、次の事項が議題設定され、プロジェクト計画書として事前配布されている必要があると考えています。 １．プロジェクトの目的 何の課題を実現しようとするシステムの構築か？ ２．プロジェクトの範囲 ・成果物（要件定義書、仕様書、プログラム、操作説明書など） ・システム化の範囲 ・作業内容および役割分担 ３．プ
アジャイル手法によって生産性が上がりプロジェクトは成功するか？（いいえ） - 勘と経験と読経
ソフトウェア開発におけるアジャイル手法の適用が話題になっている。生産性が格段に向上した事例や、従来手法に比べて成功確率が上がったというレポートも出ている。では、あなたの（わたしの）プロジェクトにも導入すべき？ その判断はちょっと待ったほうがいい。 アジャイル手法とウォーターフォール型開発の比較とバランスについて論じた書籍『アジャイルと規律』では、アジャイル手法と既存手法の比較資料について下記のように評している。 人は失敗より成功を報告する傾向にある。 先駆的プロジェクトは、新しい手法をいち早く取り入れる、かなり有能な人によって実施されている。 先駆的プロジェクトにはホーソン効果が働いており、注目を浴びている間は非常に素晴らしい成果を上げることができる。 これらのプロジェクトは過去の特に効率が悪かったプロジェクトと比較されている。 アジャイルと規律 ～ソフトウエア開発を成功させる２つの鍵のバ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
coach4pm.com
TechCrunch
任天堂の宮本茂氏「引退」を語る