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
激動の一年を通じて見えてきた「技術でリードする」ということ
Search
ktr
May 15, 2025
Technology
8
9k
激動の一年を通じて見えてきた「技術でリードする」ということ
ktr
May 15, 2025
Tweet
Share
More Decks by ktr
See All by ktr
Monorepo における Go テストの差分実行 / Running Differential Go Tests in a Monorepo
ktr_0731
1
180
Designing libraries in Go way
ktr_0731
7
1.5k
Go Modules and Proxy Walkthrough
ktr_0731
8
27k
ソフトウェアの複雑さに立ち向かう技術 / Tackling software complexity
ktr_0731
0
200
Fuzzy finder as a Go library
ktr_0731
3
5.9k
つよくてニューゲーム / NewGame++
ktr_0731
0
1k
やはり俺の Go アプリケーション設計はまちがっている。 / My Go Application Design Is Wrong, As I Expected
ktr_0731
13
3.6k
GopherCon2018
ktr_0731
2
1.8k
Evans: more expressive gRPC client
ktr_0731
2
500
Other Decks in Technology
See All in Technology
それでもぼくらは貢献をつづけるのだ(たぶん) @FOSS4GLT会#002
furukawayasuto
1
270
GigaViewerにおけるMackerel APM導入の裏側
7474
0
450
Contract One Dev Group 紹介資料
sansan33
PRO
0
6k
Digitization部 紹介資料
sansan33
PRO
1
3.8k
toittaにOpenTelemetryを導入した話 / Mackerel APM リリースパーティ
cohalz
1
480
AIの電力問題を概観する
rmaruy
1
210
Cloud Run を解剖して コンテナ監視を考える / Breaking Down Cloud Run to Rethink Container Monitoring
aoto
PRO
0
110
S3 Tables を図解でやさしくおさらい~基本から QuickSight 連携まで/s3-tables-illustrated-basics-quicksight
emiki
1
330
Introduction to Bill One Development Engineer
sansan33
PRO
0
240
Scale Security Programs with Scorecarding
ramimac
0
430
継続戦闘能⼒
sansantech
PRO
0
220
MCP Clientを活用するための設計と実装上の工夫
yudai00
1
750
Featured
See All Featured
GraphQLの誤解/rethinking-graphql
sonatard
71
11k
How to Ace a Technical Interview
jacobian
276
23k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
Why You Should Never Use an ORM
jnunemaker
PRO
56
9.4k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
60k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
34
2.3k
The Straight Up "How To Draw Better" Workshop
denniskardys
233
140k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
50k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
52
2.8k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
47
2.8k
Embracing the Ebb and Flow
colly
85
4.7k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
129
19k
Transcript
激動の一年を通じて見えてきた 「技術でリードする」ということ ktr / @ktr_0731 2025年5月15日 Techlead Meetup ─ 技術リーダーシップとは何か
─
自己紹介 ktr / きたろー メルカリ → LayerX(2024/04〜) バクラク事業部 プロダクト開発部 バクラク申請・経費精算チーム
テックリード 最近、都営大江戸線を徒歩で一周しました © LayerX Inc. 2
© LayerX Inc. 3
© LayerX Inc. 4
1年前のチーム状況 同時多発的な変化が自分たちのチームを直撃…! © LayerX Inc. 事業成長の鈍化に伴う方針転換 長年在籍していたメンバーが全員離脱 5
事業成長の鈍化に伴う方針転換 © LayerX Inc. 目標数値を大幅に下回る可能性が浮上 導入障壁となっている未提供機能の早期リリースが急務に 6
長年在籍していたメンバーが全員離脱 © LayerX Inc. 異動や育休で主要メンバーが不在に EM、テックリード、立ち上げメンバー 3 名…! 多くのメンバーがプロダクトに不慣れ 自分を含む2名は4月入社の新人エンジニア
7
どうする???
当時の主な課題 © LayerX Inc. プロダクトやドメイン知識のキャッチアップに苦戦 コードベースが複雑化し、影響範囲の把握が困難 QA期間に入ってから考慮漏れやバグが発覚 コードフリーズ後にたびたびコード修正 9
高速な機能のデリバリーが求められる中で、 自分たちは爆速開発ができない状態
困難を乗り越えるために取った5つの手 © LayerX Inc. ① 技術負債を返済しない ② やる/やらないを明確に決める ③ とにかく高速にフィードバックを得る
④ QAチームと密に連携したテスト計画 ⑤ 最低限の品質ラインを守る 11
① 技術負債を返済しない © LayerX Inc. 方針: 複雑なコードも短期的な開発速度を優先し、意図的に改善しないと決断 長期的には改善が望ましい しかし、最優先は未提供機能の早期リリース 判断軸:
許容する負債: リリース速度に直接影響しない内部的な複雑さ、将来的なリファクタリングで対応可能なもの 許容しない負債: セキュリティリスク、修正コストが指数関数的に増大するもの 学び: 負債は戦略的に管理すれば短期的に味方になる。状況に応じた選択が重要。 12
② やる/やらないを明確に決める © LayerX Inc. 方針:重要機能の実装に集中し、リリース速度を最大化 判断軸/プロセス: 価値と工数の再評価: 定期的に「その機能は本当に今必要か?」 「同じ価値をより少ない工数で提供できない
か?」をチームで問い直す 段階的リリース: 機能フラグや「先行おためし機能」を活用し、価値検証とリスク分散を図る 学び: 「やらないこと」を決める勇気が、チームを窮地から救う。完璧よりまずリリー ス。 13
© LayerX Inc. 14
③ とにかく高速にフィードバックを得る © LayerX Inc. 方針:作り込み後の大規模な手戻りを徹底的に回避する 早い段階で認識齟齬を潰し、軌道修正コストを最小化 具体的な取り組みと効果: 仕様議論: デザインやプロトタイプを用いて、開発前にチーム全員で仕様を確認
夕会での共有: 各フェーズでの成果物を共有し、即座にフィードバックを得る おさわり会: 定期的に時間を設け、開発中の機能をメンバー全員で触る 学び: フィードバックは早ければ早いほど価値が高い。臆せず見せる・相談する文化が 手戻りを減らす。 15
© LayerX Inc. 16
④ QAチームと密に連携したテスト計画 © LayerX Inc. 方針:開発初期からQAチームと協働し、品質懸念を早期に特定・解消する 連携プロセスと工夫: 開発着手前の観点共有: 大きな機能は実装前にQAへ仕様説明し、テスト観点を共同で洗い出す エンジニアによる観点記述と検証:
エンジニアがテスト観点を記述し、QAチームがレビューすることで仕様や観 点の抜け漏れを減らす。また、QAチームでテストする前にエンジニア自身がテストしていく 学び: PJ初期からQAチームと認識を揃えることで品質がぐっと高まる 17
⑤ 最低限の品質ラインを守る © LayerX Inc. 方針:業務停止や重大インシデントに繋がる不具合はなるべく起こさない・すぐに直す お客様とその業務を守るのがもっとも大事なこと 短期的な開発速度と、守るべき品質ラインのバランスを取る 品質ラインの定義と対策: 品質基準の明確化:
「コア業務が遂行不能」 「データ不整合が発生」等を重大インシデントと定義 重点テスト: 特定したコア機能に対し、QAチームと連携して集中的なテストを実施 学び: 「品質は誰かが守るもの」ではなくチーム全員の責務 18
結果どうなった? © LayerX Inc. 開発を計画した機能のうち、83%をリリース コードフリーズ後のバグ修正件数を43%削減 新機能起因のインシデント件数を60%削減 19
開発が早くて バグを生みにくい仕組みができてきている
見えてきた「技術でリードする」とは?
「技術でリードする」ということ 不確実な状況でも技術の道筋を立て、プロダクトを成功へ導く © LayerX Inc. 自分ですべてをやらなくていい。ただし必ず意思決定に関与し、最終的な責任は自分が 持つ。 とにかくなにが起きているのかを知っておく、問題が起きてそうならとりあえず飛び込んでいく 長期的に優れた方法でも短期で生き残れなければ無意味 ときには泥臭く短期成果を追う覚悟も必要
常に現在地を把握し、細かく軌道修正することが鍵 うまくいっていないことに早く気づき、どうリカバリするかをチームで話し合おう 22
チームの現在地 いまは 「より遠い未来」 を見据えるフェーズ © LayerX Inc. 技術負債の返済 最大のインシデント源だった画面をリアーキテクト 続きは
TSKaigi 2025 で! 複雑なフォームを継続的に開発していくための技術選定・設計・実装 by izumin5210 職種の垣根を越える PdM・デザイナーが軽微な修正、エンジニアがヒアリング参加・仕様検討など AI活用で最高のバクラク体験を創る 23
おわりに © LayerX Inc. 「技術でリードする」の形は人の数だけあるはず 懇親会でぜひ皆さんのお話も聞かせてください! 24