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

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

5 A.

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

7 今日のお話し

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

11 Kaizenでの日々の開発

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

25 ここまでのまとめ

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

Slide 32

Slide 32 text

32 小さく作る

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

34 Microservices?

Slide 35

Slide 35 text

35 Microservices?

Slide 36

Slide 36 text

36 小さく作るということ

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

51 まとめ

Slide 52

Slide 52 text

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