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
6k
正しく失敗しながら進むプロダクト開発/railsdm2018
Ryoichi SEKIGUCHI
March 25, 2018
Tweet
Share
More Decks by Ryoichi SEKIGUCHI
See All by Ryoichi SEKIGUCHI
functionalなアプローチで動的要素を排除する
ryopeko
1
3.9k
Ruby makes everything
ryopeko
0
110
CircleCI を使って自動(ほぼ)でセキュリティアップデート / circleci meetup
ryopeko
4
540
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.7k
DeNA Bootcamp 2013
ryopeko
15
7.5k
Other Decks in Technology
See All in Technology
Devin&Cursor、それぞれの「本質」から導く最適ユースケース戦略
empitsu
8
2.5k
会社員しながら本を書いてきた知見の共有
sat
PRO
3
690
Java 30周年記念! Javaの30年をふりかえる
skrb
1
660
新卒から4年間、20年もののWebサービスと向き合って学んだソフトウェア考古学 - PHPカンファレンス新潟2025 / new graduate 4year software archeology
oguri
2
360
2025advance01
minamizaki
0
130
MCP で繋ぐ Figma とデザインシステム〜LLM を使った UI 実装のリアル〜
kimuson
2
1.3k
S3 Tables を図解でやさしくおさらい~基本から QuickSight 連携まで/s3-tables-illustrated-basics-quicksight
emiki
2
340
大手企業のAIツール導入の壁を越えて:サイバーエージェントのCursor活用戦略
gunta
19
5k
人とAIとの共創を夢見た2か月 #共創AIミートアップ / Co-Creation with Keito-chan
kondoyuko
1
710
Digitization部 紹介資料
sansan33
PRO
1
3.8k
ローカル環境でAIを動かそう!
falken
PRO
1
170
AIに実況させる / AI Streamer
motemen
3
1.4k
Featured
See All Featured
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
45
7.3k
Imperfection Machines: The Place of Print at Facebook
scottboms
267
13k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
34
2.3k
Six Lessons from altMBA
skipperchong
28
3.8k
Building Applications with DynamoDB
mza
95
6.4k
Why Our Code Smells
bkeepers
PRO
336
57k
Fontdeck: Realign not Redesign
paulrobertlloyd
84
5.5k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
48
5.4k
Unsuck your backbone
ammeep
671
58k
Optimising Largest Contentful Paint
csswizardry
37
3.3k
Reflections from 52 weeks, 52 projects
jeffersonlam
349
20k
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 まとめ • 大きく作って間違えないことはかなり難しい • 間違えてなくても事業、顧客、ユーザーの成長により求められ るものは変化する • 小さく作って間違えても大丈夫なようにする •
失敗しやすく、気付きを最速で得られるようにする