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
51k
開発速度が速い #とは(LayerX社内資料)/ How fast is the development speed
LayerX社内の定例でつかった資料です。
LayerX
PRO
February 21, 2022
Tweet
Share
More Decks by LayerX
See All by LayerX
可観測性は開発環境から、開発環境にもオブザーバビリティ導入のススメ
layerx
PRO
4
2.2k
コンパウンド組織のCRE #cre_meetup
layerx
PRO
1
290
AI時代の経営、Bet AI Vision #BetAIDay
layerx
PRO
6
3.4k
バクラクによるコーポレート業務の自動運転 #BetAIDay
layerx
PRO
1
1.4k
金融サービスにおける高速な価値提供とAIの役割 #BetAIDay
layerx
PRO
3
1.1k
LLMをツールからプラットフォームへ〜Ai Workforceの戦略〜 #BetAIDay
layerx
PRO
1
2.1k
Bet "Bet AI" - Accelerating Our AI Journey #BetAIDay
layerx
PRO
5
2.6k
人に寄り添うAIエージェントとアーキテクチャ #BetAIDay
layerx
PRO
10
3.2k
生成AI時代におけるAI・機械学習技術を用いたプロダクト開発の深化と進化 #BetAIDay
layerx
PRO
1
18k
Other Decks in Technology
See All in Technology
251029 JAWS-UG AI/ML 退屈なことはQDevにやらせよう
otakensh
0
110
Zero Trust DNS でより安全なインターネット アクセス
murachiakira
0
120
OPENLOGI Company Profile for engineer
hr01
1
46k
JSConf JPのwebsiteをGatsbyからNext.jsに移行した話 - Next.jsの多言語静的サイトと課題
leko
2
200
SREのキャリアから経営に近づく - Enterprise Risk Managementを基に -
shonansurvivors
1
490
AWSが好きすぎて、41歳でエンジニアになり、AAIを経由してAWSパートナー企業に入った話
yama3133
2
200
dbtとAIエージェントを組み合わせて見えたデータ調査の新しい形
10xinc
7
1.5k
20251024_TROCCO/COMETAアップデート紹介といくつかデモもやります!_#p_UG 東京:データ活用が進む組織の作り方
soysoysoyb
0
140
IBC 2025 動画技術関連レポート / IBC 2025 Report
cyberagentdevelopers
PRO
2
220
デザインとエンジニアリングの架け橋を目指す OPTiMのデザインシステム「nucleus」の軌跡と広げ方
optim
0
120
オブザーバビリティが育むシステム理解と好奇心
maruloop
3
1.7k
RemoteFunctionを使ったコロケーション
mkazutaka
1
160
Featured
See All Featured
YesSQL, Process and Tooling at Scale
rocio
173
15k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
48
9.7k
Agile that works and the tools we love
rasmusluckow
331
21k
Making Projects Easy
brettharned
120
6.4k
The Art of Programming - Codeland 2020
erikaheidi
56
14k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
55
3k
Leading Effective Engineering Teams in the AI Era
addyosmani
7
670
VelocityConf: Rendering Performance Case Studies
addyosmani
333
24k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
140
34k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
36
6.1k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
127
54k
Rebuilding a faster, lazier Slack
samanthasiow
84
9.2k
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後に、品質へ重⼼を移していく