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
3.7k
Ruby makes everything
ryopeko
0
100
CircleCI を使って自動(ほぼ)でセキュリティアップデート / circleci meetup
ryopeko
4
530
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
30代からでも遅くない! 内製開発の世界に飛び込み、最前線で戦うLLMアプリ開発エンジニアになろう
minorun365
PRO
6
600
いつも初心者向けの記事に助けられているので得意分野では初心者向けの記事を書きます
toru_kubota
2
320
LangfuseでAIエージェントの 可観測性を高めよう!/Enhancing AI Agent Observability with Langfuse!
jnymyk
1
230
品質文化を支える小さいクロスファンクショナルなチーム / Cross-functional teams fostering quality culture
toma_sm
0
110
CBになったのでEKSのこともっと知ってもらいたい!
daitak
1
160
ここはMCPの夜明けまえ
nwiizo
16
6.7k
Porting PicoRuby to Another Microcontroller: ESP32
yuuu
4
410
サーバレス、コンテナ、データベース特化型機能をご紹介。CloudWatch をもっと使いこなそう!
o11yfes2023
0
170
AWSの新機能検証をやる時こそ、Amazon Qでプロンプトエンジニアリングを駆使しよう
duelist2020jp
1
220
Стильный код: натуральный поиск редких атрибутов по картинке. Юлия Антохина, Data Scientist, Lamoda Tech
lamodatech
0
720
クラウド開発環境Cloud Workstationsの紹介
yunosukey
0
170
ブラウザのレガシー・独自機能を愛でる-Firefoxの脆弱性4選- / Browser Crash Club #1
masatokinugawa
1
470
Featured
See All Featured
Practical Orchestrator
shlominoach
186
11k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
331
21k
Become a Pro
speakerdeck
PRO
27
5.3k
Facilitating Awesome Meetings
lara
54
6.3k
The Cost Of JavaScript in 2023
addyosmani
49
7.7k
Documentation Writing (for coders)
carmenintech
69
4.7k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
34
2.2k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
31
1.1k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
Bash Introduction
62gerente
611
210k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
29
1.6k
Statistics for Hackers
jakevdp
798
220k
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 まとめ • 大きく作って間違えないことはかなり難しい • 間違えてなくても事業、顧客、ユーザーの成長により求められ るものは変化する • 小さく作って間違えても大丈夫なようにする •
失敗しやすく、気付きを最速で得られるようにする