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
9
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
23
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
29
Slide 30
Slide 30 text
30
巨大なモノリシックなアプリケーションに構築
Slide 31
Slide 31 text
31
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
43
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
まとめ
● 大きく作って間違えないことはかなり難しい
● 間違えてなくても事業、顧客、ユーザーの成長により求められ
るものは変化する
● 小さく作って間違えても大丈夫なようにする
● 失敗しやすく、気付きを最速で得られるようにする