Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
正しく失敗しながら進むプロダクト開発/railsdm2018
Search
Ryoichi SEKIGUCHI
March 25, 2018
Technology
10
5.8k
正しく失敗しながら進むプロダクト開発/railsdm2018
Ryoichi SEKIGUCHI
March 25, 2018
Tweet
Share
More Decks by Ryoichi SEKIGUCHI
See All by Ryoichi SEKIGUCHI
functionalなアプローチで動的要素を排除する
ryopeko
1
190
Ruby makes everything
ryopeko
0
94
CircleCI を使って自動(ほぼ)でセキュリティアップデート / circleci meetup
ryopeko
4
510
Kaizen Platform でやっている Kaizen Week というイベントについて / kaize week tokyurubykaigi 10
ryopeko
2
1.1k
mysql casual talks vol7
ryopeko
0
2.4k
rubyhiroba
ryopeko
6
1.2k
devsumi2014-dena-bootcamp2014
ryopeko
40
63k
jtrk02
ryopeko
0
5.6k
DeNA Bootcamp 2013
ryopeko
15
7.5k
Other Decks in Technology
See All in Technology
iPadOS18でフローティングタブバーを解除してみた
sansantech
PRO
1
100
2025年のARグラスの潮流
kotauchisunsun
0
780
アジャイルチームが変化し続けるための組織文化とマネジメント・アプローチ / Agile management that enables ever-changing teams
kakehashi
3
3.2k
ゼロからわかる!!AWSの構成図を書いてみようワークショップ 問題&解答解説 #デッカイギ #羽田デッカイギおつ
_mossann_t
0
1.4k
【NGK2025S】動物園(PINTO_model_zoo)に遊びに行こう
kazuhitotakahashi
0
170
AWSサービスアップデート 2024/12 Part3
nrinetcom
PRO
0
120
あなたの知らないクラフトビールの世界
miura55
0
100
三菱電機で社内コミュニティを立ち上げた話
kurebayashi
1
340
Azureの開発で辛いところ
re3turn
0
240
Visual StudioとかIDE関連小ネタ話
kosmosebi
1
360
30分でわかる「リスクから学ぶKubernetesコンテナセキュリティ」/30min-k8s-container-sec
mochizuki875
3
430
20250116_JAWS_Osaka
takuyay0ne
2
190
Featured
See All Featured
Dealing with People You Can't Stand - Big Design 2015
cassininazir
365
25k
Done Done
chrislema
182
16k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
3
240
Reflections from 52 weeks, 52 projects
jeffersonlam
348
20k
Git: the NoSQL Database
bkeepers
PRO
427
64k
Testing 201, or: Great Expectations
jmmastey
41
7.2k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
44
7k
jQuery: Nuts, Bolts and Bling
dougneiner
62
7.6k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
8
1.2k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
The MySQL Ecosystem @ GitHub 2015
samlambert
250
12k
Docker and Python
trallard
43
3.2k
Transcript
1 正しく失敗しながら進む プロダクト開発 Rails Developer Meetup 2018 Day 2 関口亮一(@ryopeko)
2 関口亮一 (@ryopeko) 株式会社 Kaizen Platform Application Engineer パーフェクトRuby共著者
3 Q. Kaizen Platform って何やってる会社ですか?
4 Q. Kaizen Platform って何やってる会社ですか? • A/Bテストの会社? • なんかリクルート出身の人が起業した会社? •
rebuild.fmでたまに出てたけど名前ぐらいしか知らない
5 A.
6 A. Kaizen Platform って何やってる会社ですか? • Webの改善活動に関わる様々なことを提供する会社 • Kaizen に日々蓄えられているWeb改善の知識経験技術人
材を駆使して顧客の改善活動をサポートする会社 • そのためのツールとして様々なサービスを SaaS として提供し ている会社 • A/Bテストはその一部
7 今日のお話し
8 この2年ぐらいの間に起きたものづくりの プロセスの変化のお話し
9
10 様々な変化があったが 今回は開発に寄ったお話しをします
11 Kaizenでの日々の開発
12 Kaizenでの日々の開発 • 以下のロールの人たちがチームを組んで仕事をする ◦ Backend Engineer ◦ Frontend Engineer
◦ UI/UX Designer ◦ Analyst ◦ QA Team ◦ Product Manager
13 Kaizenでの日々の開発 • 規模や内容によって役割を兼務することもある • チームで組んだり1人で完結させたり様々 • 作るものの規模によって2週間 ~ 2ヶ月など
• 仕事場はオフィスと各所からのリモート
14 Kaizenでの日々の開発 • 四半期に1度全社合宿とProductチーム合宿 • 次の四半期、半期、1年、その先について議論し認識を合わせ る • ロードマップ、プロダクト理解、業務の振り返り棚卸し •
etc...
15 以前は大きなロードマップの中で仕事をしていた
16 以前までのプロダクト開発 • CEOやPMが優れたアイディアを披露 • そうして見定めたものをみんなで作っていく • 合宿などで議論しつつロードマップを作る
17 以前までのプロダクト開発 • これほんといるの?ちゃんと使われるの? • キャッチアップし続けるのが大変
18 以前までのプロダクト開発 • 作るものが大きい故の不確実性 • 作ったものが刺さらなかった時のリスク増 • 一気に作るのでフィードバックを受けても反映されにくい
19 そうしつつも事業は成長していく
20 進むと見えてくるたくさんのこと
21 進むと見えてくるたくさんのこと • 足元の課題の顕在化 • 複雑化する業務プロセス、プロダクト • 複雑でも変化し続けるので更に複雑に
22 個々に頑張ってしまい知見やノウハウが 横展開されない...
23
24 最恐のツール Google Spreadsheets の乱立
25 ここまでのまとめ
26 ここまでのまとめ • 会社、事業が順調に成長してきた • 先を見越して大きく作って大きく出す • 業務やプロダクトの複雑化 • 個々で進む業務効率化
• 知見が横展開されず暗黙知に溢れる
27 プロダクト開発チームはどう対処したか
28 対処方法 • 問題点を整理しあるべき姿を定義する • Kaizen の中で積み上げられてきた知識、仕事の棚卸し • 暗黙知からベストプラクティスへの型化 •
型化したものをよりスケールする形でツール化する
29
30 巨大なモノリシックなアプリケーションに構築
31
32 小さく作る
33 小さく作る • 小さく作ってすぐに出す • フィードバックを受けて改善する • 試しやすく捨てやすく統合しやすくしてスピードを上げる • コンテキストを明確にしてシステムの中で迷子にならないようにする
34 Microservices?
35 Microservices?
36 小さく作るということ
37 小さく作るということ • スピードを出すために組織、役割を分割すること • チームの生産性を維持したまま事業のcapabilityを上げることを狙う • 事業、組織、役割の理解分解再構築の結果としての小さなサービス ※ちょうど ajito.fm
#20 でも似たようなことが言われていた https://ajito.fm/20/
38 プロダクト開発のパターン分類
39 プロダクト開発のパターン分類 • 小さく作りつつも事業全体として統率を取るために • 分類によっては必要なもの不要なものがある • 全部のものづくりをひとつのパターンに当てはめても無駄なこと をしてスピードや安心、信頼性を損ねてしまう
40 プロダクト開発のパターン分類
41 プロダクト開発のパターン分類 • MVP ◦ 先々ローンチしたい機能/UXのProof Of Conceptをとることを目的とする • α
◦ 基本的には社内での利用 • β ◦ 一部の顧客に対して closed なもの、public なものを含む • GA ◦ 全ての顧客に対して公開されていて高いSLOを担保する
42 その結果リリースの頻度とスピードが上がった
43
44 フィードバックの受け方
45 フィードバックの受け方 • 開発するものの具体像を決める前に対処したい問題を見極め る • 見極めた上でどうあるべきかのドラフトを作る • 開発するものの主ユーザーに↑と対処したい問題をセットで見 せることで方向性を一致させる
• 開発を進める
46 フィードバックの受け方 • ある程度動くものになってから触ってもらう • その段階で見えてくるもの = 開発前に提示したものとのギャッ プ をプロダクトにフィードバックする
• 時にはデータを持って問題、対処、フィードバックをリードする
47 これらのサイクルに携わる人
48 フィードバックサイクルに携わる人 • UI/UX Designer • Product Manager • Engineer
• Analyst • ユーザー(顧客、社内の様々なロールの人)
49 フィードバックの重要性
50 フィードバックの重要性 • 間違い、失敗、認識違いを最速で認知、対処するため • 期待値の維持 • 間違ったものを作っていないという安心感 • 巻き込み、一体感
51 まとめ
52 まとめ • 大きく作って間違えないことはかなり難しい • 間違えてなくても事業、顧客、ユーザーの成長により求められ るものは変化する • 小さく作って間違えても大丈夫なようにする •
失敗しやすく、気付きを最速で得られるようにする