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
開発速度が速い #とは(LayerX社内資料)/ How fast is the devel...
Search
LayerX
PRO
February 21, 2022
Technology
31
50k
開発速度が速い #とは(LayerX社内資料)/ How fast is the development speed
LayerX社内の定例でつかった資料です。
LayerX
PRO
February 21, 2022
Tweet
Share
More Decks by LayerX
See All by LayerX
AI時代の経営、Bet AI Vision #BetAIDay
layerx
PRO
5
3.2k
バクラクによるコーポレート業務の自動運転 #BetAIDay
layerx
PRO
1
1.3k
金融サービスにおける高速な価値提供とAIの役割 #BetAIDay
layerx
PRO
2
1.1k
LLMをツールからプラットフォームへ〜Ai Workforceの戦略〜 #BetAIDay
layerx
PRO
1
1.7k
Bet "Bet AI" - Accelerating Our AI Journey #BetAIDay
layerx
PRO
5
2.5k
人に寄り添うAIエージェントとアーキテクチャ #BetAIDay
layerx
PRO
10
3k
生成AI時代におけるAI・機械学習技術を用いたプロダクト開発の深化と進化 #BetAIDay
layerx
PRO
1
1.8k
AIエージェントが変える開発組織のEnabling #開発生産性con_findy
layerx
PRO
3
29k
LayerX Ai Workforce Division Deck
layerx
PRO
2
43k
Other Decks in Technology
See All in Technology
analysis パッケージの仕組みの上でMulti linter with configを実現する / Go Conference 2025
k1low
1
250
コンテキストエンジニアリングとは? 考え方と応用方法
findy_eventslides
4
860
「Verify with Wallet API」を アプリに導入するために
hinakko
1
190
タスクって今どうなってるの?3.14の新機能 asyncio ps と pstree でasyncioのデバッグを (PyCon JP 2025)
jrfk
1
200
Green Tea Garbage Collector の今
zchee
PRO
2
370
自作LLM Native GORM Pluginで実現する AI Agentバックテスト基盤構築
po3rin
2
220
Azure SynapseからAzure Databricksへ 移行してわかった新時代のコスト問題!?
databricksjapan
0
110
LLMアプリケーション開発におけるセキュリティリスクと対策 / LLM Application Security
flatt_security
7
1.7k
全てGoで作るP2P対戦ゲーム入門
ponyo877
3
1.3k
GC25 Recap+: Advancing Go Garbage Collection with Green Tea
logica0419
1
320
定期的な価値提供だけじゃない、スクラムが導くチームの共創化 / 20251004 Naoki Takahashi
shift_evolve
PRO
3
190
成長自己責任時代のあるきかた/How to navigate the era of personal responsibility for growth
kwappa
3
190
Featured
See All Featured
jQuery: Nuts, Bolts and Bling
dougneiner
64
7.9k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.5k
Build The Right Thing And Hit Your Dates
maggiecrowley
37
2.9k
How To Stay Up To Date on Web Technology
chriscoyier
791
250k
Unsuck your backbone
ammeep
671
58k
Scaling GitHub
holman
463
140k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
52
5.6k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
229
22k
Side Projects
sachag
455
43k
Art, The Web, and Tiny UX
lynnandtonic
303
21k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.5k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
358
30k
Transcript
Confidential © 2022 LayerX Inc. 1 社内資料 『開発速度が速い #とは』 2022/02/21
@mosa_siru
Confidential © 2022 LayerX Inc. 2 LayerXは 開発速度が速いと⾔われることがあります (⼿前味噌ですが…)
Confidential © 2022 LayerX Inc. 3 そう⾔っていただける理由は︖
Confidential © 2022 LayerX Inc. 4 「優秀なエンジニアがいるから」 ☓
Confidential © 2022 LayerX Inc. 5 そもそも開発速度って何︖
Confidential © 2022 LayerX Inc. 6 機能の開発 (アウトプット)が速いこと ☓
Confidential © 2022 LayerX Inc. 7 顧客への価値提供 (アウトカム)が速いこと ◦
Confidential © 2022 LayerX Inc. 8 アウトカムを最⼤化するために 重要なこと3つ
Confidential © 2022 LayerX Inc. 9 使われないものを作らない
Confidential © 2022 LayerX Inc. 10 使われないものを作らない ・顧客の価値提供につながらないものは作らない ・バシバシやらないことを決める。 ・作ったものは必ず負債になり、作るほど後の”開発速度"を落とす。
・作るなら、作るに値するものを作る。 ・顧客・ドメインエキスパートの声を聞く(紙芝居, ⾼速でβ版を開発) ・体験にこだわりぬいて作る。 ※⼤きめの新機能は不確実性が⾼いので、作らない罠にはまらないよう注意。ト ライする不確実性を下げるのが⼤事。
Confidential © 2022 LayerX Inc. 11 仕様をシンプルにする
Confidential © 2022 LayerX Inc. 12 仕様をシンプルにする ・複雑なものは伝わらない、使われない ・複雑な仕様は開発が⼤変、負債も巨⼤ ・複雑な仕様は品質が低くなる
複雑な仕様は何かが間違っているという嗅覚 もっと⼯夫して考えれば、それに準じた体験を満たせるはず。 仕様をシンプルにすることは妥協ではない。
Confidential © 2022 LayerX Inc. 13 ⾔われた通り作らない
Confidential © 2022 LayerX Inc. 14 ⾔われた通り作らない ・顧客の本当のお気持ち、真のペインを解決するものを作る ・例「バクラク申請の申請⽇時で、古い順にソートしたい」 =>
なぜ︖ =>よくよく深ぼると、承認者への催促機能が本当にほしいものだった ・そもそも、その業務フロー・使い⽅はあるべき姿か︖ ・複数の要望を抽象化して満たせるものを作る ・カスタマイズをしない ・使われるものを、シンプルに作る(重要なので2回)
Confidential © 2022 LayerX Inc. 15 そのためには・・・
Confidential © 2022 LayerX Inc. 16 皆様がいただいている要望が宝です。 いつもありがとうございますmm
Confidential © 2022 LayerX Inc. 17 これからも 「お客様はなぜその機能がほしいのか︖」 その本当のお気持ちを教えて下さいmm
Confidential © 2022 LayerX Inc. 18 おまけ、”機能開発速度” について ・”機能開発速度”が速いと、早く失敗できる、早く修正できる ・短期と⻑期の”機能開発速度”は、しばしばトレードオフがある
・その中でも守るものを決める ・例︓DB設計/APIインターフェース/命名/セキュリティにこだわる ・フェーズによって重⼼を変える ・例︓⽴ち上げからちゃんとしすぎない ・例︓PMF後に、品質へ重⼼を移していく