Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
プロダクトのグロースのためのチームを立ち上げてプロセス改善をしている話
Search
Yuma Konishi
June 27, 2020
Business
0
310
プロダクトのグロースのためのチームを立ち上げてプロセス改善をしている話
Scrum Fest Osaka2020の登壇内容です
https://confengine.com/scrum-fest-osaka-2020/proposal/14041
Yuma Konishi
June 27, 2020
Tweet
Share
More Decks by Yuma Konishi
See All by Yuma Konishi
イベント運営から学ぶコミュニティ活動の始め方、続け方
ymk1102
0
16
メンバーを飛躍させるマネジメント戦略
ymk1102
0
48
意思から始めるプロダクトマネジメント
ymk1102
0
66
Other Decks in Business
See All in Business
20250220_生成AIで実現する業務改革とは?活用事例とデモでご紹介!
suzakiyoshito
0
230
n=1の経験が紡ぐエンジニアリングマネジメントの可能性 / The Possibilities of Engineering Management from n=1 Experiences
iwashi86
21
7.2k
エメラダ Vision to Values
emerada2016
0
180
ホラクラシー組織の比較
hashiyaman
0
290
VISASQ: ABOUT DEV TEAM
eikohashiba
3
24k
IRIAM Culture Deck
iriam
4
100k
CENTRAGE CO., LTD. 会社説明資料
tsuji2021
0
260
エンジニア→PM進化論
natty_natty254
2
220
株式会社shizai - Recruit Deck
shizai
3
57k
株式会社ビズリーチ 会社概要資料 / Corporate Deck
bizreach_inc
2
28k
GMOフィナンシャルHD 会社紹介資料
gmofh_hr_team
0
44k
POとSMの人財発掘と育成への挑戦
amapyon
0
110
Featured
See All Featured
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
227
22k
The Power of CSS Pseudo Elements
geoffreycrofte
75
5.5k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
32
2.2k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Reflections from 52 weeks, 52 projects
jeffersonlam
348
20k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
7
650
Speed Design
sergeychernyshev
27
810
GitHub's CSS Performance
jonrohan
1030
460k
Writing Fast Ruby
sferik
628
61k
Thoughts on Productivity
jonyablonski
69
4.5k
Site-Speed That Sticks
csswizardry
4
410
Transcript
プロダクトのグロースのためのチームを立ち 上げてプロセス改善をしている話 小西 裕真@i-plug.inc
自己紹介 小西 裕真 (Yuma Konishi) 1993/11/02 i-plug.inc グロースチームマネージャー 元々はWebエンジニアで 最近はチームマネジメントと企画。
ギルドワークス中村さんに コーチで来ていただきアジャイル開発に 出会ってハマる。
自己紹介 Offerboxという就活の逆求人プラットフォームの開発をしています。
このセッションで伝えたいこと 正しいものを作る大切さとそのための方法論 間違ったものを一生懸命作るのは無駄でしかないので 作るものの正しさにもっと目を向けた方が良い。 正しいものを 間違ったものを 正しく作る 理想 間違った方向に全力疾走 正しく作れない
方向は正しいが進み方が悪い まずはどちらかの改善を QCD Value
目次 - 開発プロセス - 元々どんな開発プロセスで - どんな問題があったので - 何を意図して -
どう変えたのか - 実践しての学び - 良かったことは何か - 新たな課題は何か - それにどう取り組んでいるか - 改善を始めるために
開発プロセス(元々のもの) ENGEN EER 何かしらの アイデア 他部署 経営層 企画/仕様検討 企画/仕様説明 リファイン
メント プランニング 実装 どこからともなく有効性の検証されていない 企画、仕様が要望として投げられてくる 作り方だけアジャイル。 結果の検証とその後の意思決定が行われることはほ ぼない。 いわゆる良くない社内受託状態。 課題の質も悪く、リリース数の割にはプロダクトの改善にほとんど役立っていない。
開発プロセス(元々のもの) 作る価値があるかよくわからないもの作らされる 納期が指定されていることもしばしば リリース後それが価値を生んでいたのか誰もわからない 不満が溜まってモチベが下がる 何よりプロダクトの指標が大して改善していない
作る価値があるかよくわからないもの作らされる 納期が指定されていることもしばしば リリース後それが価値を生んでいたのか誰もわからない 不満が溜まってモチベが下がる 何よりプロダクトの指標が対して改善していない 開発プロセス(元々のもの) このままではいけないということ で数字の改善にコミットする専門 チームを作ることに
開発プロセス(チーム構成) PO ・ドメイン知識が豊富 ・データ分析できる グロースチーム ・小西(SM兼エンジニア) ・エンジニア1人 ・マーケター1人 デザイナーチーム デザイナー3人
期待値の高い仮説を高速で検証しながら実装していく 開発プロセス(改善の方向性) 課題仮説 Customer Problem Fit Problem Solution Fit プロトタイプ
MVP/MVF ユーザー理解 解決策検討 検証方法検討 本実装
開発プロセス(リリース前) 仮説構築 データ 分析 PO DESIGN ENGINE ER サービスの改善点の目星をつけ 解決策の方向性を検討する。
仮説が本当にユーザーにとって課題なのか、 解決策が受け入れられそうなものなのかを ユーザーに触れながら検証する。 企画案 共有 ユーザー テスト 計画 プロト 実装 テスト 実施 テスト 結果の 解釈 本実装 仕様策定 本実装 結果の モニタリ ング 価値がありそうならば実装してリ リースしてその結果を計測して次 の改善の参考にする。 それぞれの専門性を活かしつつ、課題 /解決策の妥当性を確認しながら 段階的にリリース/価値提供に向かって動いていく。
開発プロセス(リリース後) PO DESIGN ENGINE ER 機能の新規追加、改善、継 続、廃止の判断をする 結果のモニタリング に戻る 結果の
モニタ リング 機能に手を入れる場合は再度テスト計画を立てて 効果を検証する リリースしたら終わりではなく、結果をモニタリングして 意思決定をするサイクルを繰り返す。 SICS 判断 企画検討 テスト 計画 テスト 実装
実践してみての学び(良かったこと) 結論、良いことづくめ - 想定と違う反応が多くあり思い込みで進めることの怖さがわかる - 質の低い案件=無駄という認識が生まれる - 実験や学びの複利効果が生まれる - 他の職種の人との協業は楽しい、勉強になる
質量共に上流工程に求められるものが大きすぎる - 質の高い課題を作り続けることは大変 - イシュー度が低いと生み出せる価値が少ない - 量が少ないとエンジニアの手が浮いてしまう - 企画/データ分析業務のPOへの属人化が極端 実践してみての学び(課題に感じたこと)
イシュー度低 イシュー度高 解の質高 犬の道 理想 解の質低 問題だらけ 解決できない重要な課題
- 質の高い課題を作り続けることは大変 - 小西も企画に参画 - 年間計画を作成して 1年を通して改善したい論点を事前準備 - 他部署を巻き込んだプロジェクト進行 -
企画/データ分析業務のPOへの属人化が極端 - 小西も企画に参画 - データサイエンティストの採用で問題発見、意思決定部分の強化。 実践してみての学び(最近チャレンジしていること)
計測習慣をつけて振り返りと改善していくに尽きる 改善を始めるために 企画 実装 リリース 振り返り 目的の明確化 確認観点の 準備 成否の基準の
準備 データ取得の 仕組み整備 情報の取得 結果の解釈 結果の改善の 検討 早期発見できた かの検討
参考文献 改善を始めるために
おわりに 「正しいもの」を作るのは楽しい。 納得感を持って案件を進められるし、同じ目標に向けてみんなで一体になって進んでい けるし結果が出るととてもやりがいがある。 ユーザーも作り手も会社も嬉しいまさに三方良し。 色んな現場の話を知りたいので良かったら 個別でも声かけてください。 twitterやdiscordでコメントいただけたら絡みに行きます(-ω-)/