ライセンス買うのものなあ。フリーで使い込んでみよう。入門」勉強会に参加してきました。渋谷界隈でネットサービスを行っている4社から参加者が集まりました。各社ネットサービスを展開していますが、お互いにビジネス領域が被らないためざっくばらんに話ができそうです。企業毎に組織体制や文化が異なり、プロダクトマネージャーの仕事・役割もそれぞれ違うよねということをあらためて感じました。取り組みや課題などをお互いに情報交換することで、いろいろ学びがありそうです。部門経験者の方も何名かいて、ぐっと親近感がわきました。今回は幹事役をしてくれた方が資料を用意してくださっていてそれを使いながらファシリテーションしてくれました。話題からある方のところでは、ユーザーに影響のある施策についてはコンセプトシートを書くとおっしゃっていました。他の方はリーンキャンバスを作るようにしているとのこと。自分のチームではプロダクトバックログ上にストーリーを書いて済ませることも多いのですが、少し大きいサイズのものはこういったものを書いた方が良いなと今回感じました。いう役職・肩書のある会社はというお題については、ほとんどの方がないということでした。それからユーザーストーリーマッピングを1日かけたという話をしてくれた方は「エンジニアも一緒に参加することで、作る側の納得感が出て良かった」とおっしゃってました。今回は1章から3章がトピックだったので以下個人的なメモ。第1部は「ソフトウェア製品の開発に関わる人たち」。人・プロセス・製品という3領域の中の「人」。その役割と責任について。製品開発の鍵を握る担当者とその役割まずは役割の説明。プロダクトマネージャーのやることとして以下を挙げています。プロダクトマネージャーの主な任務としては2つある。製品の市場性を評価することと、開発すべき製品を定義することである。プロダクトマーケティングも兼務になっていることが多々あるがまったく別の技能が必要なので、兼務は非常に難しいとしています。この点は第2章で詳しく取り上げられています。プロダクトマーケティングが分離されていると助かります。プロダクトマネージャーは5〜10人のエンジニアに対して1人必要とのこと。スクラムチームの人数ともだいたい同じ規模感。プロダクトマネジメントとプロダクトマーケティング「プロダクトマネジメントとプロダクトマーケティングをそれぞれしっかり」「製品の最終責任者を明確に」「プロダクトマネジメントは専任で」プロダクトマネージャーの役割とプロダクトマーケティングの役割をきちんと区別するのが大切。プロダクトマネジメントとプロジェクトマネジメントここではさらにプロダクトマネジメントとプロジェクトマネジメントを区別しましょうという話。(金)プロジェクトでみんなをバスに乗せるために書いておく項目リストみんなをバスに乗せるためにプロジェクトのプランニングで明確にして共有した方が良いドキュメント形式って、方法論やプロジェクトの段階によっていろいろな名前のものがありますが、基本的に項目はどれも似たような感じです。項目名を整理して決めておくと楽なのでちょっと書き出してみました。コンセプトシート比較的軽量にまとめる時。(Why)プロダクトプランプロダクトプランニング(エンビジョニング)のアウトプットとして。エピックレベル(数カ月程度の大きさ)。メンバ概要レベルのプロダクトバックログプロダクトロードマップポートフォリオバックログアイテムポートフォリオプランニングで、プロダクトプランを評価した結果のもの。エピックレベル(数カ月程度の大きさ)。遅延コスト(ビジネス価値・時間価値・リスク軽減/チャンスと利用)WSJFプロダクトバックログアイテムスクラムで1スプリントで完成できるサイズのアイテム。プロダクトバックログアイテム名ユーザーストーリー(誰・概要と目標・背景と目的)満足条件(あれば成果物を含む)サイズレビュー方法タスクチケットちょっとしたタスク。他には以下のような形式もあります。(水)複雑な領域に合わせたプロジェクトマネジメントをするあるプロジェクトのプレイングマネージャーが抜けることになってから、プロジェクトがうまく進まなくなってきた。プレイングマネージャーがメインでやってしまっている間は良かったけれど、そうでなくなった今も週1回30分のミーティングのスタイルのままでスローダウンしてしまったように思える。クネビンフレームワークで言うところの「複雑な領域」のプロジェクトだから、もっと密接にチームメンバが連携して「検査と適応」をしていかないと、進まないし成果も出ないよね。開発プロジェクトではないけれどスクラムがいいんじゃないかなと思っているので取り入れてみるつもり。事業の部長をしています。日記(兼パーソナルナレッジベース)です。※内容は個人的見解であり所属組織とは関係ありません。