プロダクトのグロースのためのチームを立ち上げてプロセス改善をしている話

Scrum Fest Osaka2020の登壇内容です
https://confengine.com/scrum-fest-osaka-2020/proposal/14041

Transcript

1. プロダクトのグロースのためのチームを立ち 上げてプロセス改善をしている話 小西 裕真@i-plug.inc
2. 自己紹介 小西 裕真 (Yuma Konishi) 1993/11/02 i-plug.inc グロースチームマネージャー 元々はWebエンジニアで 最近はチームマネジメントと企画。 ギルドワークス中村さんに コーチで来ていただきアジャイル開発に 出会ってハマる。
3. 自己紹介 Offerboxという就活の逆求人プラットフォームの開発をしています。
4. このセッションで伝えたいこと 正しいものを作る大切さとそのための方法論 間違ったものを一生懸命作るのは無駄でしかないので 作るものの正しさにもっと目を向けた方が良い。 正しいものを 間違ったものを 正しく作る 理想 間違った方向に全力疾走 正しく作れない 方向は正しいが進み方が悪い まずはどちらかの改善を QCD Value
5. 目次 - 開発プロセス - 元々どんな開発プロセスで - どんな問題があったので - 何を意図して - どう変えたのか - 実践しての学び - 良かったことは何か - 新たな課題は何か - それにどう取り組んでいるか - 改善を始めるために
6. 開発プロセス(元々のもの) ENGEN EER 何かしらの アイデア 他部署 経営層 企画/仕様検討 企画/仕様説明 リファイン メント プランニング 実装 どこからともなく有効性の検証されていない 企画、仕様が要望として投げられてくる 作り方だけアジャイル。 結果の検証とその後の意思決定が行われることはほ ぼない。 いわゆる良くない社内受託状態。 課題の質も悪く、リリース数の割にはプロダクトの改善にほとんど役立っていない。
7. 開発プロセス(元々のもの) 作る価値があるかよくわからないもの作らされる 納期が指定されていることもしばしば リリース後それが価値を生んでいたのか誰もわからない 不満が溜まってモチベが下がる 何よりプロダクトの指標が大して改善していない
8. 作る価値があるかよくわからないもの作らされる 納期が指定されていることもしばしば リリース後それが価値を生んでいたのか誰もわからない 不満が溜まってモチベが下がる 何よりプロダクトの指標が対して改善していない 開発プロセス(元々のもの) このままではいけないということ で数字の改善にコミットする専門 チームを作ることに
9. 開発プロセス(チーム構成) PO ・ドメイン知識が豊富 ・データ分析できる グロースチーム ・小西(SM兼エンジニア) ・エンジニア1人 ・マーケター1人 デザイナーチーム デザイナー3人
10. 期待値の高い仮説を高速で検証しながら実装していく 開発プロセス(改善の方向性) 課題仮説 Customer Problem Fit Problem Solution Fit プロトタイプ MVP/MVF ユーザー理解 解決策検討 検証方法検討 本実装
11. 開発プロセス(リリース前) 仮説構築 データ 分析 PO DESIGN ENGINE ER サービスの改善点の目星をつけ 解決策の方向性を検討する。 仮説が本当にユーザーにとって課題なのか、 解決策が受け入れられそうなものなのかを ユーザーに触れながら検証する。 企画案 共有 ユーザー テスト 計画 プロト 実装 テスト 実施 テスト 結果の 解釈 本実装 仕様策定 本実装 結果の モニタリ ング 価値がありそうならば実装してリ リースしてその結果を計測して次 の改善の参考にする。 それぞれの専門性を活かしつつ、課題 /解決策の妥当性を確認しながら 段階的にリリース/価値提供に向かって動いていく。
12. 開発プロセス(リリース後) PO DESIGN ENGINE ER 機能の新規追加、改善、継 続、廃止の判断をする 結果のモニタリング に戻る 結果の モニタ リング 機能に手を入れる場合は再度テスト計画を立てて 効果を検証する リリースしたら終わりではなく、結果をモニタリングして 意思決定をするサイクルを繰り返す。 SICS 判断 企画検討 テスト 計画 テスト 実装
13. 実践してみての学び(良かったこと) 結論、良いことづくめ - 想定と違う反応が多くあり思い込みで進めることの怖さがわかる - 質の低い案件=無駄という認識が生まれる - 実験や学びの複利効果が生まれる - 他の職種の人との協業は楽しい、勉強になる
14. 質量共に上流工程に求められるものが大きすぎる - 質の高い課題を作り続けることは大変 - イシュー度が低いと生み出せる価値が少ない - 量が少ないとエンジニアの手が浮いてしまう - 企画/データ分析業務のPOへの属人化が極端 実践してみての学び(課題に感じたこと) イシュー度低 イシュー度高 解の質高 犬の道 理想 解の質低 問題だらけ 解決できない重要な課題
15. - 質の高い課題を作り続けることは大変 - 小西も企画に参画 - 年間計画を作成して 1年を通して改善したい論点を事前準備 - 他部署を巻き込んだプロジェクト進行 - 企画/データ分析業務のPOへの属人化が極端 - 小西も企画に参画 - データサイエンティストの採用で問題発見、意思決定部分の強化。 実践してみての学び(最近チャレンジしていること)
16. 計測習慣をつけて振り返りと改善していくに尽きる 改善を始めるために 企画 実装 リリース 振り返り 目的の明確化 確認観点の 準備 成否の基準の 準備 データ取得の 仕組み整備 情報の取得 結果の解釈 結果の改善の 検討 早期発見できた かの検討
17. 参考文献 改善を始めるために
18. おわりに 「正しいもの」を作るのは楽しい。 納得感を持って案件を進められるし、同じ目標に向けてみんなで一体になって進んでい けるし結果が出るととてもやりがいがある。 ユーザーも作り手も会社も嬉しいまさに三方良し。 色んな現場の話を知りたいので良かったら 個別でも声かけてください。 twitterやdiscordでコメントいただけたら絡みに行きます(-ω-)/