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
34
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
LayerX Fintech事業部の開発について
takochuu
0
80
これまでとこれからのサーバーサイド
takochuu
0
49
Dive panic & type
takochuu
0
480
Go Conference 2018 Autumn - 3カ国を支えるAPI基盤の構築
takochuu
1
2.2k
C Channel x Retty x eureka LT
takochuu
0
10
Global Architecture
takochuu
0
560
Other Decks in Programming
See All in Programming
GitHub Actionsのキャッシュと手を挙げることの大切さとそれに必要なこと
satoshi256kbyte
5
380
PLoP 2024: The evolution of the microservice architecture pattern language
cer
PRO
0
1.6k
OpenTelemetryでRailsのパフォーマンス分析を始めてみよう(KoR2024)
ymtdzzz
4
1.5k
『ドメイン駆動設計をはじめよう』のモデリングアプローチ
masuda220
PRO
7
430
hotwire_or_react
harunatsujita
8
4k
Generative AI Use Cases JP (略称:GenU)奮闘記
hideg
0
150
cXML という電子商取引の トランザクションを支える プロトコルと向きあっている話
phigasui
3
2.2k
レガシーな Android アプリのリアーキテクチャ戦略
oidy
1
170
RailsのPull requestsのレビューの時に私が考えていること
yahonda
5
1.7k
GCCのプラグインを作る / I Made a GCC Plugin
shouth
1
150
デプロイを任されたので、教わった通りにデプロイしたら障害になった件 ~俺のやらかしを越えてゆけ~
techouse
52
32k
約9000個の自動テストの 時間を50分->10分に短縮 Flakyテストを1%以下に抑えた話
hatsu38
23
11k
Featured
See All Featured
Teambox: Starting and Learning
jrom
132
8.7k
The Pragmatic Product Professional
lauravandoore
31
6.3k
Building Adaptive Systems
keathley
38
2.2k
Embracing the Ebb and Flow
colly
84
4.4k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
9
680
How STYLIGHT went responsive
nonsquared
95
5.2k
The Invisible Side of Design
smashingmag
297
50k
Building Better People: How to give real-time feedback that sticks.
wjessup
363
19k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
4
290
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
37
1.8k
Build The Right Thing And Hit Your Dates
maggiecrowley
32
2.4k
Music & Morning Musume
bryan
46
6.1k
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つの解決策 - ドメインを理解することによりコミュニケーション・実装の質を上
げる まとめ