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
2024/06/19_CHUO_Tech
Search
takochuu
June 18, 2024
Programming
0
51
2024/06/19_CHUO_Tech
https://chuo-tech.connpass.com/event/319436/
での発表資料です
takochuu
June 18, 2024
Tweet
Share
More Decks by takochuu
See All by takochuu
プロダクトヒストリーカンファレンス2024 - 登壇資料
takochuu
0
26
LayerX Fintech事業部の開発について
takochuu
0
110
これまでとこれからのサーバーサイド
takochuu
0
50
Dive panic & type
takochuu
0
490
Go Conference 2018 Autumn - 3カ国を支えるAPI基盤の構築
takochuu
1
2.3k
C Channel x Retty x eureka LT
takochuu
0
11
Global Architecture
takochuu
0
570
Other Decks in Programming
See All in Programming
さいきょうのレイヤードアーキテクチャについて考えてみた
yahiru
3
750
Java Webフレームワークの現状 / java web framework at burikaigi
kishida
9
2.2k
法律の脱レガシーに学ぶフロントエンド刷新
oguemon
5
740
Rubyで始める関数型ドメインモデリング
shogo_tksk
0
110
Rails アプリ地図考 Flush Cut
makicamel
1
120
昭和の職場からアジャイルの世界へ
kumagoro95
1
380
SwiftUIで単方向アーキテクチャを導入して得られた成果
takuyaosawa
0
270
データの整合性を保つ非同期処理アーキテクチャパターン / Async Architecture Patterns
mokuo
47
17k
Conform を推す - Advocating for Conform
mizoguchicoji
3
690
Ruby on cygwin 2025-02
fd0
0
140
CDK開発におけるコーディング規約の運用
yamanashi_ren01
2
120
データベースのオペレーターであるCloudNativePGがStatefulSetを使わない理由に迫る
nnaka2992
0
150
Featured
See All Featured
Building a Modern Day E-commerce SEO Strategy
aleyda
38
7.1k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
9
440
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
160
15k
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.3k
The Pragmatic Product Professional
lauravandoore
32
6.4k
Statistics for Hackers
jakevdp
797
220k
GitHub's CSS Performance
jonrohan
1030
460k
Reflections from 52 weeks, 52 projects
jeffersonlam
348
20k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
6
550
[RailsConf 2023] Rails as a piece of cake
palkan
53
5.2k
A better future with KSS
kneath
238
17k
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
Transcript
© LayerX Inc. Fintech事業部流・爆速開発 Kentaro Takahashi, 2024/06/19
自己紹介
© LayerX Inc. 3 Fintech事業部 VPoE Fintech事業部にて、ALTERNA(個人向け投資サービス)と ODX(Operation DX)チームのマネジメントを担当 趣味は酒と保護猫を飼うこと
以前はPairs(エウレカ) / DeNAなどに在籍 自己紹介 Kentaro Takahashi
事業紹介
5 © LayerX Inc. 「すべての経済活動を、デジタル化する。」をミッションに掲げ、 法人支出管理サービス「バクラク」や企業内業務のデジタル化を支援するサービスを提供しています。 事業紹介 バクラク事業 企業活動のインフラとなる法人支出 管理(BSM)SaaSを開発・提供
Fintech事業 ソフトウェアを駆使したアセットマネジメ ント・証券事業を合弁会社にて展開 AI・LLM事業 文書処理を中心とした、LLMの活用による プロセスのリデザイン
© LayerX Inc.
© LayerX Inc.
© LayerX Inc.
開発生産性 ≠ プロダクトの生産性
© LayerX Inc. 10 Four Keys • デプロイ頻度 • 変更のリードタイム
• 変更障害率 • サービス復元時間 開発生産性 ≠ プロダクトの生産性
© LayerX Inc. 11 開発生産性 ≠ プロダクトの生産性
© LayerX Inc. 12 開発生産性 ≠ プロダクトの生産性 2年で4000個のP-Rなので生産性は悪くなさそうだけど...
© LayerX Inc. 13 大事なことは、ちゃんと「成果」が 狙った通りに出ていること 開発生産性 ≠ プロダクトの生産性 =
使われないものを作らない
プロダクト開発の生産性をあげるために
© LayerX Inc. 15 成果 = 打率(施策の成功確率) × 打数(デリバリーのスピード) プロダクト開発の生産性をあげるために
© LayerX Inc. 16 成果 = 打率(施策の成功確率) × 打数(デリバリーのスピード) プロダクト開発の生産性をあげるために
© LayerX Inc. 17 = ドメインの理解 × 最速での価値検証 打数(デリバリーのスピード) プロダクト開発の生産性をあげるために -
マーケティングメールは「特定電子メール法」という法律でオプトインが義務づけられている - 金融商品取引法によって、投資家から預かった資金は明確に分別して管理すること - このような制約を理解しておくことでコミュニケーションのスピードが上がる - 制約を正しく理解できていないと、コミュニケーションが複雑になりスピードが下がる
© LayerX Inc. 18 = ドメインの理解 × 最速での価値検証 打数(デリバリーのスピード) プロダクト開発の生産性をあげるために
© LayerX Inc. 19 = ドメインの理解 × 最速での価値検証 打数(デリバリーのスピード) プロダクト開発の生産性をあげるために 「よーし、エピックレベルの企画を作るぞ!」
「企画の目的Aはこれで、目的Bはこれ」 「Aに対してのストーリーはこの4つで、Bはこの3つ」 「これをこうして...」
© LayerX Inc. 20 = ドメインの理解 × 最速での価値検証 打数(デリバリーのスピード) プロダクト開発の生産性をあげるために 「よーし、エピックレベルの企画を作るぞ!」
「企画の目的Aはこれで、目的Bはこれ」 「Aに対してのストーリーはこの4つで、Bはこの3つ」 「これをこうして...」 ✗
© LayerX Inc. 21 施策の開発は、1つの目的に対して1つの解決策が基本 → 1つの施策で複数の課題を解決しようとすると、論点がブレがち そのために、やらないことをしっかり決めることも重要 プロダクト開発の生産性をあげるために
© LayerX Inc. 22 = ドメインの理解 × 最速での価値検証 打数(デリバリーのスピード) プロダクト開発の生産性をあげるために 「よーし、エピックレベルの企画を作るぞ!」
「企画の目的Aはこれ、Aに対してのストーリーはこの4つ」 「この機能もあればユーザーが喜びそう!」 「使い勝手を考えたら、こういう風に作りたい」
© LayerX Inc. 23 = ドメインの理解 × 最速での価値検証 打数(デリバリーのスピード) プロダクト開発の生産性をあげるために 「よーし、エピックレベルの企画を作るぞ!」
「企画の目的Aはこれ、Aに対してのストーリーはこの4つ」 「この機能もあればユーザーが喜びそう!」 「使い勝手を考えたら、こういう風に作りたい」 ✗
© LayerX Inc. 24 それっぽい思い込みで開発せず、仕様をシンプルに保つ また、仕様検討時に「どうしたらこの機能が成功か」を定義する → 成功指標が定義できないと「使われているがそのプロダクトに とって意味があるのかわからない」機能になりがち プロダクト開発の生産性をあげるために
まとめ
© LayerX Inc. 26 - それっぽい思い込みで開発せず、仕様をシンプルに保つ - 施策の成功指標を定義する - 施策の開発は、1つの目的に対して1つの解決策
- やらないことを決める - ドメインを理解することによりコミュニケーション・実装の質を上 げる まとめ
おわりに
© LayerX Inc. 28 まとめ https://note.layerx.co.jp/n/nd989c05bf9b1
© LayerX Inc. 29 - それっぽい思い込みで開発せず、仕様をシンプルに保つ - 施策の開発は、1つの目的に対して1つの解決策 - ドメインを理解することによりコミュニケーション・実装の質を上
げる まとめ