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.9k
正しく失敗しながら進むプロダクト開発/railsdm2018
Ryoichi SEKIGUCHI
March 25, 2018
Tweet
Share
More Decks by Ryoichi SEKIGUCHI
See All by Ryoichi SEKIGUCHI
functionalなアプローチで動的要素を排除する
ryopeko
1
1.6k
Ruby makes everything
ryopeko
0
96
CircleCI を使って自動(ほぼ)でセキュリティアップデート / circleci meetup
ryopeko
4
520
Kaizen Platform でやっている Kaizen Week というイベントについて / kaize week tokyurubykaigi 10
ryopeko
2
1.1k
mysql casual talks vol7
ryopeko
0
2.4k
rubyhiroba
ryopeko
6
1.3k
devsumi2014-dena-bootcamp2014
ryopeko
40
64k
jtrk02
ryopeko
0
5.6k
DeNA Bootcamp 2013
ryopeko
15
7.5k
Other Decks in Technology
See All in Technology
The Future of SEO: The Impact of AI on Search
badams
0
190
エンジニアのためのドキュメント力基礎講座〜構造化思考から始めよう〜(2025/02/15jbug広島#15発表資料)
yasuoyasuo
16
6.6k
人はなぜISUCONに夢中になるのか
kakehashi
PRO
6
1.6k
明日からできる!技術的負債の返済を加速するための実践ガイド~『ホットペッパービューティー』の事例をもとに~
recruitengineers
PRO
3
390
Nekko Cloud、 これまでとこれから ~学生サークルが作る、 小さなクラウド
logica0419
2
960
次世代KYC活動報告 / 20250219-BizDay17-KYC-nextgen
oidfj
0
250
現場の種を事業の芽にする - エンジニア主導のイノベーションを事業戦略に装着する方法 -
kzkmaeda
2
2k
転生CISOサバイバル・ガイド / CISO Career Transition Survival Guide
kanny
3
970
個人開発から公式機能へ: PlaywrightとRailsをつなげた3年の軌跡
yusukeiwaki
11
3k
滅・サービスクラス🔥 / Destruction Service Class
sinsoku
6
1.6k
2.5Dモデルのすべて
yu4u
2
840
RECRUIT TECH CONFERENCE 2025 プレイベント【高橋】
recruitengineers
PRO
0
150
Featured
See All Featured
GitHub's CSS Performance
jonrohan
1030
460k
Product Roadmaps are Hard
iamctodd
PRO
50
11k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
A better future with KSS
kneath
238
17k
The Straight Up "How To Draw Better" Workshop
denniskardys
232
140k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
366
25k
Java REST API Framework Comparison - PWX 2021
mraible
28
8.4k
Scaling GitHub
holman
459
140k
Typedesign – Prime Four
hannesfritz
40
2.5k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
33
2.1k
The Language of Interfaces
destraynor
156
24k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
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 まとめ • 大きく作って間違えないことはかなり難しい • 間違えてなくても事業、顧客、ユーザーの成長により求められ るものは変化する • 小さく作って間違えても大丈夫なようにする •
失敗しやすく、気付きを最速で得られるようにする