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.6k
正しく失敗しながら進むプロダクト開発/railsdm2018
Ryoichi SEKIGUCHI
March 25, 2018
Tweet
Share
More Decks by Ryoichi SEKIGUCHI
See All by Ryoichi SEKIGUCHI
Ruby makes everything
ryopeko
0
79
CircleCI を使って自動(ほぼ)でセキュリティアップデート / circleci meetup
ryopeko
4
450
Kaizen Platform でやっている Kaizen Week というイベントについて / kaize week tokyurubykaigi 10
ryopeko
2
1k
mysql casual talks vol7
ryopeko
0
2.2k
rubyhiroba
ryopeko
6
1.2k
devsumi2014-dena-bootcamp2014
ryopeko
39
63k
jtrk02
ryopeko
0
5.4k
DeNA Bootcamp 2013
ryopeko
15
7.3k
自分の道具を知る
ryopeko
10
2.1k
Other Decks in Technology
See All in Technology
サーバーレスAPI(API Gateway+Lambda)とNext.jsで 個人ブログを作ろう!
shuntaka
PRO
0
560
コンテナ・K8s研修 - 後半 Kubernetes 基礎&ハンズオン【MIXI 24新卒技術研修】
mixi_engineers
PRO
1
120
可視化プラットフォームGrafanaの基本と活用方法の全て
hamadakoji
0
230
JBUG岡山 #6 WordCamp男木島の チームビルディング
takeshifurusato
0
150
開発生産性をむしろ向上させる セキュリティパートナーの作り方 / Dev Productivity Con 2024
flatt_security
0
360
【基調講演】変える、今ここから ― IoTとAIで紡ぐ未来
soracom
PRO
0
310
成長期に歩みを止めないための創業期の開発文化形成
mayah
6
420
Docker互換のセキュアなコンテナ実行環境「Podman」超入門
devops_vtj
6
3.2k
サービス開発を前に進めるために 新米リードエンジニアが 取り組んだこと / Steps Taken by a Novice Lead Engineer to Advance Service Development
nologyance
0
180
CEL(Common Expression Language)で書いた条件にマッチしたIAM Policyを見つける / iam-policy-finder
fujiwara3
0
710
GoとアクターモデルでES+CQRSを実践! / proto_actor_es_cqrs
ytake
1
150
地理情報とAPIのトレンド
nagix
0
160
Featured
See All Featured
Writing Fast Ruby
sferik
623
60k
A Tale of Four Properties
chriscoyier
155
22k
5 minutes of I Can Smell Your CMS
philhawksworth
200
19k
Clear Off the Table
cherdarchuk
89
320k
Building Applications with DynamoDB
mza
89
5.8k
What’s in a name? Adding method to the madness
productmarketing
PRO
21
2.9k
Become a Pro
speakerdeck
PRO
15
4.8k
Faster Mobile Websites
deanohume
303
30k
Keith and Marios Guide to Fast Websites
keithpitt
408
22k
Scaling GitHub
holman
458
140k
A Philosophy of Restraint
colly
200
16k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
35
6.3k
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 まとめ • 大きく作って間違えないことはかなり難しい • 間違えてなくても事業、顧客、ユーザーの成長により求められ るものは変化する • 小さく作って間違えても大丈夫なようにする •
失敗しやすく、気付きを最速で得られるようにする