プロダクトマネージャーとエンジニアで行う改善サイクル 3つのp
Post on 11-Apr-2017
200 Views
Preview:
TRANSCRIPT
プロダクトマネージャーとエンジニアで行う改善サイクル 3 つの P
Sansan 株式会社 尾部 絵里子
introduction
私と私たちのこと
Sansan
ミッションビジネスの出会いを資産に変え
働き方を革新する
Career
前職： HR Tech カスタム営業Sansan 3 年前：サポートマネジメント半年前：プロダクト部へ
Parsonal
伊丹市出身元ベーシストAmazon でインディーズ時代の CD 売ってます
私は Sansan の APM です
Favorite ： acidjazz.motown ..live house: 神戸 Starclub福島 2ndline 、心斎橋 Drop ..
プロダクトマネージャーって何するの？「プロダクトマネージャーの主な任務は二つある。
製品の市場性を評価することと、開発すべき製品を定義することである」
ほかには… ✓目的、ビジョンを示す ✓課題を特定する ✓費用対効果を見極める ✓優先順位を決める ✓市場投下タイミングを決める など
↑me
Bayashy↓
mao↓
My Team @ Tokyo office
Osaka
↑fromKorea
My Team @ Tokyo office
Team の担当
↑admin localize
EN
CH
Sansan
本編
Product Manager + Engineer + Designerでおこなう
改善サイクル 3つのP
そもそもなぜ改善が必要なのか？最小の労力で最大の価値を生み出すため1日も早く世の中に価値を提供するため
改善サイクル ３つの P
Process
Person
Product
プロダクトの改善サイクル
Process
Person
Product
MVP
実用最小の製品Minimum Viable Product
MVP とは構築 - 計測 - 学習のループを回せるレベルの製品で、最小限の労力と時間で開発できるもののこと
✓ リリースする頃には ニーズが変わっている…✓ 仮説がハズれていた…
✓ 小さく出して Feedback を 反映しつつ次の開発できる＝不要な機能をつくらない✓ 早く市場に投下できる＝早くユーザに価値が届き Happy 早く稼ぐチャンスが来て Happy
小さく出して早く改善する
ex. 変化の可能性 ✓ 市場（ Technology の進化、ユーザのニーズ） ✓ 自社（戦略、注力ターゲット、価格）
△
◎$
✦✦
♥
$✦
✦
♥
$✦
✦
♥
$
✓ リリースする頃には ニーズが変わっている…✓ 仮説がハズれていた…
✓ 小さく出して Feedback を 反映しつつ次の開発できる＝不要な機能をつくらない✓ 早く市場に投下できる＝早くユーザに価値が届き Happy 早く稼ぐチャンスが来て Happy
小さく出して早く改善する
ex. 変化の可能性 ✓ 市場（ Technology の進化、ユーザのニーズ） ✓ 自社（戦略、注力ターゲット、価格）
△
◎$✦
✦
♥
$✦
✦
♥
$
$✦
✦
♥
最小の機能にしながらもユーザにとって“最も高い価値”を考え抜くのがPM の役目！
プロセス改善のサイクル
Process
Person
Product
一般的なプロセス企画立案 リリース設計 開発→ → →
✓ 課題特定✓ 市場調査 ✓ 要件定義✓ スコープ✓ 仕様検討✓ レビュー
✓ 開発✓ テスト
プロセス改善するタイミング
✓ 3 回の見積もりタイミング✓ 2 回の PJ 振返りタイミング
” 3 回の見積もりタイミング ”企画立案 リリース設計 開発→ → →
here↓
here↓
here↓
仕様具体化前✓ 実装する機能の決定✓ 代替案の検討開発前roadmap 作成中✓ 市場投下時期検討✓ 最善の開発効率
目的と方法When
✓ ロードマップ作成時
✓ 仕様を具体化する前
✓ 開発を始める前
Why✓ 市場投下タイミングと 効率的な開発手順を コントロールするため✓ 機能の費用対効果を 最大化を目的とし、 代替案を考えるため✓？？？？？
How✓PM がざっくり見積もり 開発が 10分でレビュー する✓PM が要件とラフを書き 開発 1名が 1 時間で 工数を Pt で見積る✓ ？？？？？ Ask Engineers
”2 回の PJ 振返りタイミング”企画立案 リリース設計 開発→ → →
here↓
here↓
開発前 リリース後
企画立案 設計→
NEXT PJ
手法：バリューストリームマッピング
企画設計〜リリースまでのPM 、デザイナー、エンジニアが持つ全てのタスクを付箋で見える化し、タスクの要否やプロセスの改善を行う。
企画立案 リリース設計 開発→ → →
✕
気づき例：絶妙な開発連携タイミング企画立案 リリース設計 開発→ → →
◎Best↓
✓ 最小化された MVP を元に 実現可能性を検討できる✓手戻りする振り幅が小さい✓技術的アイデアを導入できる
△早い↓
△遅い↓
ヒトの改善
Process
Person
Product
ヒト改善✓ 組織✓ 認識✓ マインド
組織を改善する
✓ 捨てる
Before ✓ 振返りと相談に毎週 2 時間…✓ 一部のメンバーだけ話す…✓ 他のメンバーは聞くだけ…
After✓ 20分に削減✓ 相談は関係者だけに減らす
捨てた例：ミーティングの改善
120min
20min
Before ✓ 振返りと相談に毎週 2 時間…✓ 一部のメンバーだけ話す…✓ 他のメンバーは聞くだけ…
After✓ 20分に削減✓ 相談は関係者だけに減らす
捨てた例：ミーティングの改善
120min
20min
生産性向上
空いた時間を開発時間にor改善施策の検討など全員で議論するサイクル
ツール： Realtime board東京と大阪をつなぐバーチャルホワイトボード
今やこれ無しではやっていけない必須ツール。付箋を貼るので無口なヒトも発言できる。付箋だから自由に動かせて、プロセス改善や優先度の並び替えとか、グルーピングとか、投票が楽ちん。何よりリモートの操作でもサクサク動く。
認識を改善する
✓ 目線✓ 知識
目線を合わせる
目的・背景・ビジョン・方針を示す✓ 迷わない✓沢山の方法から選択するスピードが上がる
A ：とにかく早く、英語版の切り替え機能がほしい！とにかく急いで作って！
B ：将来、 3言語目、 4言語目と、対応言語を広げていくのでその想定で作って！
例：画面の英語版に表示切り替え機能を作る
A ：とにかく早く、英語版の切り替え機能がほしい！とにかく急いで作って！
B ：将来、 3言語目、 4言語目と、対応言語を広げていくのでその想定で作って！
例：画面の英語版に表示切り替え機能を作る
選べる HOW が豊富WHY と WHATの共通認識度が高いと迷わない
知識を改善する同じものを学び共通言語化できると✓ 説明が要らない✓ 能力の底上げができる✓ チームの文化ができる
ランチ勉強会例：『エッセンシャルスクラム』✓ プラクティスを導入できる
✓ メンバー間の認識を合わせられる
『エッセンシャルスクラム』「どうやるか」だけでなく「なぜやるか」が書かれているので腹落ちしやすいです。勉強会までに章ごとに読んできて、当日はチームの課題と解決に有効な方法をピックアップしたり議論を交わしています。
マインドを改善する改善マインドを持つことで✓ 常に改善できるポイントを探す✓ 常に改善を継続できる
改善サイクル ３つの P
Process
Person
Product
top related