ProductZine Day&オンラインセミナーは、プロダクト開発にフォーカスし、最新情報をお届けしているWebメディア「ProductZine(プロダクトジン)」が主催する読者向けイベントです。現場の最前線で活躍されているゲストの方をお招きし、日々のプロダクト開発のヒントとなるような内容を、講演とディスカッションを通してお伝えしていきます。
最近は仕事をするとき必ずNotionを触っていますので、仕事をする=Notionを使う、と言っても過言ではありません。Notionの素晴らしい点は、私のように複数社で顧問をしていても、必要な業務によってカスタマイズができることです。 日々Notionを使う中で「プロダクトマネージャーが圧倒的に仕事しやすくなるテンプレートを作りたい!」と思ったのが始まりです。そんな中いろいろ探してみたところ、Notionのテンプレート自体はすでに色々なものがありますが、現実問題としてToo much(情報が多すぎる)ものもあれば、逆に情報が足りないものもあり最適解がありませんでした。 そこで、プロのプロダクトマネージャーとしてこれを使っておけば間違いない!というものをキュレーションして整理しました。そのテンプレートの使い方を解説します。 ※テンプレートはページ下部からご利用になれます プロダクトマネージャー
プロダクトマネージャーという仕事はビジネス・デザイン・エンジニアすべてのスキルが求められる総合格闘技のような仕事です。その分、やることも多く忙しくなりがち。 しかし、再現性の高いプロセスというのは仕事が変わってもそのまま活用できます。その代表例がフレームワークです。 今回は世の中に数あるフレームワークのうち、プロダクトマネージャー・事業開発者が絶対知っておいた方が良いと判断したものを厳選してみました。 プロダクトマネージャー向けフレームワーク4選1. Product Prioritization Frameworkhttps://www.product-frameworks.com/Gusto-Product-Prioritization.htmlこちらはもうプロダクトマネージャーであれば無意識に考えていてほしいくらいシンプル、かつ大事なフレームワークです。 expected:期待値の大き
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに ソフトウェアプロジェクトには不思議な性質があります。現状のスケジュールに課題を感じて、短くするために人員を投下しても、なかなか思い通りに短くならない。それどころか悪化してしまうことがあります。場合によってはプロジェクト自体が破綻して失敗してしまうことすらあります。 今回は、このようなソフトウェアプロジェクトに潜む直感に反する性質を数理的なモデルを介して理解していく試みです。ある種の思考実験としてお楽しみください。 宣伝 Qiitaさんとコラボ企画でアドベントカレンダーをつくりました。 DXをめちゃくちゃ改善した話を募集していま
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試験(プロジ
ガントチャートとは ガントチャート(Gantt chart)とは、プロジェクト管理や生産管理でのスケジュール管理に用いられる表の一種です。作業計画を視覚的に表現するために用いられます。 横軸に時間、縦軸にメンバーや作業内容を配置することで、チームのタスクや進捗が、ひと目で把握できるのが特徴です。 Google スプレッドシートの「テンプレート」や「アドオン」を使えば、ガントチャートを無料で簡単に作成できます。 また、Google Workspaceでは2022年11月より、Google スプレッドシートで「タイムラインビュー」と呼ばれるガントチャート機能が利用できるようになっています。 Google スプレッドシートのテンプレートでガントチャートを作る方法 Google スプレッドシートには、ガントチャートのテンプレートが用意されています。ガントチャートの作成画面までの手順は2ステップです
浅見 裕 yutaka azami @azamixx821 仕事が殺到する人は「デザインがすごい」「文章がうまい」みたいな、点のスキルではなく、「なんやかんや最終的にはなんとか形にする」という泥臭いスタンスがあるかどうか。 2020-05-18 07:59:36 DeepSky @SXDYYLfLgzttqv2 自分も、大した事もないくせに、何やかんや喚きまくって、呆れられながらも、結局最後はそれなりの作品を完成させる。そんなツクラーでありたい。 完成さえさせれば、たまに物好きが「とりあえずやってみようか」と来てくれる可能性はある( ^-^)/(T-T ) twitter.com/azamixx821/sta… 2020-05-18 21:21:33
「プロジェクトマネジメント」というと、エンジニアが作業工程を管理するものだと思いがちですが、むしろ非エンジニアこそ徹底すべきものだと思います。 社内、及びチームに向けて参考になる資料を探したのですが、どうもネット上に転がっているものはエンジニア向けの難しいものばかりだったので、自分でまとめてみました。 その名も「料理で例えるプロジェクトマネジメント」 社内で使用したスライドも使って、簡単に説明していきます。 プロマネは誰がやるのか 主にマネージャークラス、責任者クラスの人が該当するように思えますが、実際のところそうでもありません。 例えば弊社の直近の事例をあげると、「魚の臭いに効くハンドソープを作ってよ」と言われた際に、任された人は何をどういう手順で行っていくかといったところですね。 これはマネジメント経験がない人でもいきなり任せられる可能性があるので、まぁぶっちゃけいうと全員知っておいて
こんにちは、poipoiです。 私はテクニカルディレクターという職種柄、プロジェクトマネージャーを兼任することが多々あります。 これは自身で開発を行ったことがない方がテクニカルに関わるスケジュールについて勘所を働かせることが難しいことや、開発という行為自体が不確定要素のオンパレードであるため単純な日割りベースでのスケジュール立てが難しいことなど、開発に知見のある立場の人間がプロジェクト進行を務める必要があるためです。 そこで、私が普段プロジェクト進行をするうえで行なっている 「テクニカルディレクター目線で考えるプロジェクトマネージメント」 の TIPS のようなものを少しずつ紹介していこうと思っています。 初回は「合流地点を意識してプロジェクトを進行する」ということについて。 プロジェクトは依存関係でできている私はプロジェクトマネージメントを担当しスケジュールを組む際に、各タスクの「依存関
はじめに : Who I amこんにちは、建設×ITのスタートアップ「シェルフィー株式会社」でプロダクトマネージャーをしているShoko(@shokosuzuki1991)です。本日noteデビューしました!👏 先日参加した『建設職人甲子園』というイベントで、東京タワー建設時のエピソードが紹介されてたのきっかけに、『東京タワーができるまで』を調べれば調べるほど、すごすぎる!ヤバすぎる!となったので、今回はそのあたりをPM的な切り口でまとめてみました。 (※なるべく事実に忠実に書いてますが、一部わかりやすくする表現を優先しているところもあります。予めご容赦ください🙏) 1.構想の大胆さがヤバい 東京タワーが完成したのは1958年です。当時は爆発的なテレビの普及が予想される中で「このまま各局独自の電波塔が増えると、東京中が電波塔だらけになって景観が悪化する」という問題を抱えていました。 そ
ディレクターにかぎらず、メインプランナーといった管理側の人間のタスクは、軽めにしなければらない。 昔、昔、小規模なゲームのディレクターをしていた時に、プランナー的な仕事もしていて、まあ地獄をみたことがある。 そういった経験も踏まえて、プロジェクト管理をする側の人間は、タスクを軽めにしなければならない理由を書く。 理由1:予定外のことに対処する必要がある 理由2:プロジェクトメンバーが声をかけづらい 理由3:体調を壊されると困る まとめ 理由1:予定外のことに対処する必要がある プロジェクトに、想定外のことはつきものである。 プロジェクト管理者はそれに対して迅速に対応しなければならない。 プロジェクトの最も上流にいるプロジェクト管理者が、事態の収集のために各種事項に対して決定しなければ、プロジェクトメンバーはそれらの事態に対処しきれなくなる。 もし、プロジェクト管理者が他のタスクを抱えいたら
用語集とは、開発で使われている用語をまとめたドキュメントのことを指す。 個人的には割と重要なドキュメントだと思うが、結構な多くの開発現場で作成されていない。 今回は、用語集のメリットを書きたい。 用語集の要素 メリット1:バグが減る メリット2:チーム内の認識を合わせることができる。 メリット3:途中でアサインされたスタッフの仕事をスムーズにする まとめ 用語集の要素 用語集は、主に用語とその用語の定義や、その用語に関する特記事項が記載さている。 記載される用語は、ゲーム内で使用されるものである場合が多い。 開発チームだけが使う用語も記載れることがある。 メリット1:バグが減る いわゆるテキストバグの防止になる。 ゲーム内に登場するテキストを確認できるので、誤った表記や使い方を防止できる。 また、テキストバグがあがってきた場合にも、用語集を元に正確な表記をすぐに書くにすることで、すぐにバグ
ゲームの開発中には、たくさんの予期せぬ問題が発生するものである。 策定した仕様が他の仕様と矛盾していたり、突如、新たな仕様を策定する必要が出てきたり、致命的なバグが発生したりといったことである。 そして、それらの問題を解決するにあたり、様々なタスクが発生する。 そのタスクの担当を決める際に、その問題に「気づいた人がやる」という実に日本的な悪しき習慣にもとづいているプロジェクトが未だにある。 今回は、「気づいた人がやる」という方針がいかに害悪があるかを考えていく。 スポンサードリンク 害悪①:気づいている人に仕事が集中する 害悪②:得意な人が対応できない 害悪③:やらかしている人間が成長しない 害悪④:「気づく人」はいなくなる まとめ 害悪①:気づいている人に仕事が集中する 問題に気づいた人ばかりがどんどん新たな仕事を抱えることになり、気づかない人に仕事がまわらなくなる。 気づく人にタスクが
ギルドワークスの市谷さんと中村さんに仮説キャンバスを作るワークショップをしていただきました。DocBaseをリリースして1年過ぎて、何となくモヤモヤしているところをスッキリしたいというのと、社内全員でサービス事業を見直してみる良い機会になるのではと思い、お願いしました。 ギルドワークス https://guildworks.jp/ 仮説キャンバス 仮説キャンバスとは事業を整理し、検証するためのツールです。ギルドワークスが様々な企業と一緒に仮説検証を繰り返す中でリーンキャンバスを参考に作ってきたものだそうです。 ワークショップ 緊張気味の弊社スタッフをギルドワークスの中村さん(写真右から2番目)がうまくいい雰囲気に持っていきます。個人的に中村さんの問いかける進め方がとても勉強になりました。今度絶対真似します。 まずは課題から 顕在課題から考え始めるとやりやすいとのことです。もちろんこれまで何
ユーザエクスペリエンスマップってなんぞや、どういう時に使えばいいのなどまとめてみました。実際に作る方法は別のスライドにまとめました(http://www.slideshare.net/vistawalk/ss-17410597)
こんにちは、@h0saです。 いきなりですが、業務でUXに関わっている皆さんは下のような図を何と呼んでいますか? 引用:Customer Journey Map as a Tool in Continuous Improvement 1. カスタマージャーニーマップ (Customer Journey Map) 2. エクスペリエンスマップ (Experience Map) 3. UXマップ (UX Map) 4. … 上記のどれかに当てはまったでしょうか。もしかしたら、特に意識せずにその場に合わせて1,2,3のどれでも使っている人もいるかもしれません。 Googleでそれぞれ検索してみると、以下のようなヒット数になりました(2015年5月13日現在)。 “カスタマージャーニーマップ” – 10,700件 “エクスペリエンスマップ” – 867件 “UXマップ” – 4,240件 “Cus
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く