正しく失敗しながら進むプロダクト開発/railsdm2018

Transcript

1. 1 正しく失敗しながら進む プロダクト開発 Rails Developer Meetup 2018 Day 2 関口亮一(@ryopeko)
2. 2 関口亮一 (@ryopeko) 株式会社 Kaizen Platform Application Engineer パーフェクトRuby共著者
3. 3 Q. Kaizen Platform って何やってる会社ですか？
4. 4 Q. Kaizen Platform って何やってる会社ですか？ • A/Bテストの会社？ • なんかリクルート出身の人が起業した会社？ • rebuild.fmでたまに出てたけど名前ぐらいしか知らない
5. 5 A.
6. 6 A. Kaizen Platform って何やってる会社ですか？ • Webの改善活動に関わる様々なことを提供する会社 • Kaizen に日々蓄えられているWeb改善の知識経験技術人 材を駆使して顧客の改善活動をサポートする会社 • そのためのツールとして様々なサービスを SaaS として提供し ている会社 • A/Bテストはその一部
7. 7 今日のお話し
8. 8 この2年ぐらいの間に起きたものづくりの プロセスの変化のお話し
9. 9
10. 10 様々な変化があったが 今回は開発に寄ったお話しをします
11. 11 Kaizenでの日々の開発
12. 12 Kaizenでの日々の開発 • 以下のロールの人たちがチームを組んで仕事をする ◦ Backend Engineer ◦ Frontend Engineer ◦ UI/UX Designer ◦ Analyst ◦ QA Team ◦ Product Manager
13. 13 Kaizenでの日々の開発 • 規模や内容によって役割を兼務することもある • チームで組んだり1人で完結させたり様々 • 作るものの規模によって2週間 ~ 2ヶ月など • 仕事場はオフィスと各所からのリモート
14. 14 Kaizenでの日々の開発 • 四半期に1度全社合宿とProductチーム合宿 • 次の四半期、半期、1年、その先について議論し認識を合わせ る • ロードマップ、プロダクト理解、業務の振り返り棚卸し • etc...
15. 15 以前は大きなロードマップの中で仕事をしていた
16. 16 以前までのプロダクト開発 • CEOやPMが優れたアイディアを披露 • そうして見定めたものをみんなで作っていく • 合宿などで議論しつつロードマップを作る
17. 17 以前までのプロダクト開発 • これほんといるの？ちゃんと使われるの？ • キャッチアップし続けるのが大変
18. 18 以前までのプロダクト開発 • 作るものが大きい故の不確実性 • 作ったものが刺さらなかった時のリスク増 • 一気に作るのでフィードバックを受けても反映されにくい
19. 19 そうしつつも事業は成長していく
20. 20 進むと見えてくるたくさんのこと
21. 21 進むと見えてくるたくさんのこと • 足元の課題の顕在化 • 複雑化する業務プロセス、プロダクト • 複雑でも変化し続けるので更に複雑に
22. 22 個々に頑張ってしまい知見やノウハウが 横展開されない...
23. 23
24. 24 最恐のツール Google Spreadsheets の乱立　
25. 25 ここまでのまとめ
26. 26 ここまでのまとめ • 会社、事業が順調に成長してきた • 先を見越して大きく作って大きく出す • 業務やプロダクトの複雑化 • 個々で進む業務効率化 • 知見が横展開されず暗黙知に溢れる
27. 27 プロダクト開発チームはどう対処したか
28. 28 対処方法 • 問題点を整理しあるべき姿を定義する • Kaizen の中で積み上げられてきた知識、仕事の棚卸し • 暗黙知からベストプラクティスへの型化 • 型化したものをよりスケールする形でツール化する
29. 29
30. 30 巨大なモノリシックなアプリケーションに構築
31. 31
32. 32 小さく作る
33. 33 小さく作る • 小さく作ってすぐに出す • フィードバックを受けて改善する • 試しやすく捨てやすく統合しやすくしてスピードを上げる • コンテキストを明確にしてシステムの中で迷子にならないようにする
34. 34 Microservices?
35. 35 Microservices?
36. 36 小さく作るということ
37. 37 小さく作るということ • スピードを出すために組織、役割を分割すること • チームの生産性を維持したまま事業のcapabilityを上げることを狙う • 事業、組織、役割の理解分解再構築の結果としての小さなサービス ※ちょうど ajito.fm #20 でも似たようなことが言われていた https://ajito.fm/20/
38. 38 プロダクト開発のパターン分類
39. 39 プロダクト開発のパターン分類 • 小さく作りつつも事業全体として統率を取るために • 分類によっては必要なもの不要なものがある • 全部のものづくりをひとつのパターンに当てはめても無駄なこと をしてスピードや安心、信頼性を損ねてしまう
40. 40 プロダクト開発のパターン分類
41. 41 プロダクト開発のパターン分類 • MVP ◦ 先々ローンチしたい機能/UXのProof Of Conceptをとることを目的とする • α ◦ 基本的には社内での利用 • β ◦ 一部の顧客に対して closed なもの、public なものを含む • GA ◦ 全ての顧客に対して公開されていて高いSLOを担保する
42. 42 その結果リリースの頻度とスピードが上がった
43. 43
44. 44 フィードバックの受け方
45. 45 フィードバックの受け方 • 開発するものの具体像を決める前に対処したい問題を見極め る • 見極めた上でどうあるべきかのドラフトを作る • 開発するものの主ユーザーに↑と対処したい問題をセットで見 せることで方向性を一致させる • 開発を進める
46. 46 フィードバックの受け方 • ある程度動くものになってから触ってもらう • その段階で見えてくるもの = 開発前に提示したものとのギャッ プ をプロダクトにフィードバックする • 時にはデータを持って問題、対処、フィードバックをリードする
47. 47 これらのサイクルに携わる人
48. 48 フィードバックサイクルに携わる人 • UI/UX Designer • Product Manager • Engineer • Analyst • ユーザー(顧客、社内の様々なロールの人)
49. 49 フィードバックの重要性
50. 50 フィードバックの重要性 • 間違い、失敗、認識違いを最速で認知、対処するため • 期待値の維持 • 間違ったものを作っていないという安心感 • 巻き込み、一体感
51. 51 まとめ
52. 52 まとめ • 大きく作って間違えないことはかなり難しい • 間違えてなくても事業、顧客、ユーザーの成長により求められ るものは変化する • 小さく作って間違えても大丈夫なようにする • 失敗しやすく、気付きを最速で得られるようにする