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
47k
開発速度が速い #とは(LayerX社内資料)/ How fast is the development speed
LayerX社内の定例でつかった資料です。
LayerX
PRO
February 21, 2022
Tweet
Share
More Decks by LayerX
See All by LayerX
LayerX における mastra の活用と課題
layerx
PRO
8
2.5k
現場で動くAIワークフロー 〜チューニングを効率化する工夫〜
layerx
PRO
1
960
LLM as プロダクト開発のパワードスーツ
layerx
PRO
2
460
AIエージェント時代の可能性と実践 #AIエージェント_findy
layerx
PRO
37
16k
企業も候補者も納得する採用プロセスとは? 〜LayerXの実践事例〜
layerx
PRO
6
6.1k
エンタープライズ向け生成AIプロダクトにおけるAIエージェントの取り組み
layerx
PRO
1
550
LayerX 3事業部合同 エンジニア向け採用説明会資料(2025年1月版)
layerx
PRO
1
1.4k
LayerX AI・LLM Division Deck
layerx
PRO
1
30k
LayerX DesignersDeck
layerx
PRO
2
8.1k
Other Decks in Technology
See All in Technology
Why every SwiftUI developer should care about the Environment - iOSKonf25
peterfriese
0
160
Coding Agentに値札を付けろ
watany
3
590
株式会社Awarefy(アウェアファイ)会社説明資料 / Awarefy-Company-Deck
awarefy
3
17k
問 1:以下のコンパイラを証明せよ(予告編) #kernelvm / Kernel VM Study Kansai 11th
ytaka23
3
640
正解のない未知(インボイス制度対応)をフルサイクル開発で乗り越える方法 / How to overcome the unknown invoice system with full cycle development
carta_engineering
0
170
Design for Failure - リージョンとAZについて
yuki_ink
0
130
Next.jsと状態管理のプラクティス
uhyo
6
2.4k
経済メディア編集部の実務に小さく刺さるAI / small-ai-with-editorial
nkzn
2
510
ITベンダーから見る内製化支援の本質/in-house-dev
slsops
1
170
地に足の付いた現実的な技術選定から魔力のある体験を得る『AIレシート読み取り機能』のケーススタディ / From Grounded Tech Choices to Magical UX: A Case Study of AI Receipt Scanning
moznion
5
1.9k
ゆるくはじめるSLI・SLO
yatoum
1
120
KubeCon + CloudNativeCon Europe 2025 Recap: The GPUs on the Bus Go 'Round and 'Round / Kubernetes Meetup Tokyo #70
pfn
PRO
0
130
Featured
See All Featured
The Pragmatic Product Professional
lauravandoore
33
6.6k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
233
17k
Testing 201, or: Great Expectations
jmmastey
42
7.5k
Art, The Web, and Tiny UX
lynnandtonic
298
20k
Building Better People: How to give real-time feedback that sticks.
wjessup
368
19k
Thoughts on Productivity
jonyablonski
69
4.6k
Gamification - CAS2011
davidbonilla
81
5.3k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
10
810
Fontdeck: Realign not Redesign
paulrobertlloyd
84
5.5k
How STYLIGHT went responsive
nonsquared
100
5.5k
Intergalactic Javascript Robots from Outer Space
tanoku
271
27k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
16k
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後に、品質へ重⼼を移していく