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

Transcript

1. 1
   正しく失敗しながら進む
   プロダクト開発
   Rails Developer Meetup 2018 Day 2
   関口亮一(@ryopeko)
   

   View Slide

2. 2
   関口亮一 (@ryopeko)
   株式会社 Kaizen Platform
   Application Engineer
   パーフェクトRuby共著者
   

   View Slide

3. 3
   Q.
   Kaizen Platform って何やってる会社ですか？
   

   View Slide

4. 4
   Q. Kaizen Platform って何やってる会社ですか？
   ● A/Bテストの会社？
   ● なんかリクルート出身の人が起業した会社？
   ● rebuild.fmでたまに出てたけど名前ぐらいしか知らない
   

   View Slide

5. 5
   A.
   

   View Slide

6. 6
   A. Kaizen Platform って何やってる会社ですか？
   ● Webの改善活動に関わる様々なことを提供する会社
   ● Kaizen に日々蓄えられているWeb改善の知識経験技術人
   材を駆使して顧客の改善活動をサポートする会社
   ● そのためのツールとして様々なサービスを SaaS として提供し
   ている会社
   ● A/Bテストはその一部
   

   View Slide

7. 7
   今日のお話し
   

   View Slide

8. 8
   この2年ぐらいの間に起きたものづくりの
   プロセスの変化のお話し
   

   View Slide

9. View Slide

10. 10
    様々な変化があったが
    今回は開発に寄ったお話しをします
    

    View Slide

11. 11
    Kaizenでの日々の開発
    

    View Slide

12. 12
    Kaizenでの日々の開発
    ● 以下のロールの人たちがチームを組んで仕事をする
    ○ Backend Engineer
    ○ Frontend Engineer
    ○ UI/UX Designer
    ○ Analyst
    ○ QA Team
    ○ Product Manager
    

    View Slide

13. 13
    Kaizenでの日々の開発
    ● 規模や内容によって役割を兼務することもある
    ● チームで組んだり1人で完結させたり様々
    ● 作るものの規模によって2週間 ~ 2ヶ月など
    ● 仕事場はオフィスと各所からのリモート
    

    View Slide

14. 14
    Kaizenでの日々の開発
    ● 四半期に1度全社合宿とProductチーム合宿
    ● 次の四半期、半期、1年、その先について議論し認識を合わせ
    る
    ● ロードマップ、プロダクト理解、業務の振り返り棚卸し
    ● etc...
    

    View Slide

15. 15
    以前は大きなロードマップの中で仕事をしていた
    

    View Slide

16. 16
    以前までのプロダクト開発
    ● CEOやPMが優れたアイディアを披露
    ● そうして見定めたものをみんなで作っていく
    ● 合宿などで議論しつつロードマップを作る
    

    View Slide

17. 17
    以前までのプロダクト開発
    ● これほんといるの？ちゃんと使われるの？
    ● キャッチアップし続けるのが大変
    

    View Slide

18. 18
    以前までのプロダクト開発
    ● 作るものが大きい故の不確実性
    ● 作ったものが刺さらなかった時のリスク増
    ● 一気に作るのでフィードバックを受けても反映されにくい
    

    View Slide

19. 19
    そうしつつも事業は成長していく
    

    View Slide

20. 20
    進むと見えてくるたくさんのこと
    

    View Slide

21. 21
    進むと見えてくるたくさんのこと
    ● 足元の課題の顕在化
    ● 複雑化する業務プロセス、プロダクト
    ● 複雑でも変化し続けるので更に複雑に
    

    View Slide

22. 22
    個々に頑張ってしまい知見やノウハウが
    横展開されない...
    

    View Slide

23. View Slide

24. 24
    最恐のツール Google Spreadsheets の乱立　
    

    View Slide

25. 25
    ここまでのまとめ
    

    View Slide

26. 26
    ここまでのまとめ
    ● 会社、事業が順調に成長してきた
    ● 先を見越して大きく作って大きく出す
    ● 業務やプロダクトの複雑化
    ● 個々で進む業務効率化
    ● 知見が横展開されず暗黙知に溢れる
    

    View Slide

27. 27
    プロダクト開発チームはどう対処したか
    

    View Slide

28. 28
    対処方法
    ● 問題点を整理しあるべき姿を定義する
    ● Kaizen の中で積み上げられてきた知識、仕事の棚卸し
    ● 暗黙知からベストプラクティスへの型化
    ● 型化したものをよりスケールする形でツール化する
    

    View Slide

29. View Slide

30. 30
    巨大なモノリシックなアプリケーションに構築
    

    View Slide

31. View Slide

32. 32
    小さく作る
    

    View Slide

33. 33
    小さく作る
    ● 小さく作ってすぐに出す
    ● フィードバックを受けて改善する
    ● 試しやすく捨てやすく統合しやすくしてスピードを上げる
    ● コンテキストを明確にしてシステムの中で迷子にならないようにする
    

    View Slide

34. 34
    Microservices?
    

    View Slide

35. 35
    Microservices?
    

    View Slide

36. 36
    小さく作るということ
    

    View Slide

37. 37
    小さく作るということ
    ● スピードを出すために組織、役割を分割すること
    ● チームの生産性を維持したまま事業のcapabilityを上げることを狙う
    ● 事業、組織、役割の理解分解再構築の結果としての小さなサービス
    ※ちょうど ajito.fm #20 でも似たようなことが言われていた
    https://ajito.fm/20/
    

    View Slide

38. 38
    プロダクト開発のパターン分類
    

    View Slide

39. 39
    プロダクト開発のパターン分類
    ● 小さく作りつつも事業全体として統率を取るために
    ● 分類によっては必要なもの不要なものがある
    ● 全部のものづくりをひとつのパターンに当てはめても無駄なこと
    をしてスピードや安心、信頼性を損ねてしまう
    

    View Slide

40. 40
    プロダクト開発のパターン分類
    

    View Slide

41. 41
    プロダクト開発のパターン分類
    ● MVP
    ○ 先々ローンチしたい機能/UXのProof Of Conceptをとることを目的とする
    ● α
    ○ 基本的には社内での利用
    ● β
    ○ 一部の顧客に対して closed なもの、public なものを含む
    ● GA
    ○ 全ての顧客に対して公開されていて高いSLOを担保する
    

    View Slide

42. 42
    その結果リリースの頻度とスピードが上がった
    

    View Slide

43. View Slide

44. 44
    フィードバックの受け方
    

    View Slide

45. 45
    フィードバックの受け方
    ● 開発するものの具体像を決める前に対処したい問題を見極め
    る
    ● 見極めた上でどうあるべきかのドラフトを作る
    ● 開発するものの主ユーザーに↑と対処したい問題をセットで見
    せることで方向性を一致させる
    ● 開発を進める
    

    View Slide

46. 46
    フィードバックの受け方
    ● ある程度動くものになってから触ってもらう
    ● その段階で見えてくるもの = 開発前に提示したものとのギャッ
    プ をプロダクトにフィードバックする
    ● 時にはデータを持って問題、対処、フィードバックをリードする
    

    View Slide

47. 47
    これらのサイクルに携わる人
    

    View Slide

48. 48
    フィードバックサイクルに携わる人
    ● UI/UX Designer
    ● Product Manager
    ● Engineer
    ● Analyst
    ● ユーザー(顧客、社内の様々なロールの人)
    

    View Slide

49. 49
    フィードバックの重要性
    

    View Slide

50. 50
    フィードバックの重要性
    ● 間違い、失敗、認識違いを最速で認知、対処するため
    ● 期待値の維持
    ● 間違ったものを作っていないという安心感
    ● 巻き込み、一体感
    

    View Slide

51. 51
    まとめ
    

    View Slide

52. 52
    まとめ
    ● 大きく作って間違えないことはかなり難しい
    ● 間違えてなくても事業、顧客、ユーザーの成長により求められ
    るものは変化する
    ● 小さく作って間違えても大丈夫なようにする
    ● 失敗しやすく、気付きを最速で得られるようにする
    

    View Slide