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
9.7k
激動の一年を通じて見えてきた「技術でリードする」ということ
ktr
May 15, 2025
Tweet
Share
More Decks by ktr
See All by ktr
あまり知られていない MCP 仕様たち / MCP specifications that aren’t widely known
ktr_0731
0
220
CLI ツールを Go ライブラリ として再実装する理由 / Why reimplement a CLI tool as a Go library
ktr_0731
3
940
Monorepo における Go テストの差分実行 / Running Differential Go Tests in a Monorepo
ktr_0731
1
200
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
210
Fuzzy finder as a Go library
ktr_0731
3
6k
つよくてニューゲーム / NewGame++
ktr_0731
0
1k
やはり俺の Go アプリケーション設計はまちがっている。 / My Go Application Design Is Wrong, As I Expected
ktr_0731
13
3.7k
Other Decks in Technology
See All in Technology
Perlアプリケーションで トレースを実装するまでの 工夫と苦労話
masayoshi
1
400
alecthomas/kong はいいぞ
fujiwara3
6
1.4k
家族の思い出を形にする 〜 1秒動画の生成を支えるインフラアーキテクチャ
ojima_h
1
130
LLMでAI-OCR、実際どうなの? / llm_ai_ocr_layerx_bet_ai_day_lt
sbrf248
0
430
Oracle Cloud Infrastructure:2025年7月度サービス・アップデート
oracle4engineer
PRO
1
100
20250807_Kiroと私の反省会
riz3f7
0
110
クマ×共生 HACKATHON - 熊対策を『特別な行動」から「生活の一部」に -
pharaohkj
0
290
✨敗北解法コレクション✨〜Expertだった頃に足りなかった知識と技術〜
nanachi
1
310
JAWS AI/ML #30 AI コーディング IDE "Kiro" を触ってみよう
inariku
3
260
AI によるドキュメント処理を加速するためのOCR 結果の永続化と再利用戦略
tomoaki25
0
370
SRE新規立ち上げ! Hubbleインフラのこれまでと展望
katsuya0515
0
150
【2025 Japan AWS Jr. Champions Ignition】点から線、線から面へ〜僕たちが起こすコラボレーション・ムーブメント〜
amixedcolor
1
120
Featured
See All Featured
Building Applications with DynamoDB
mza
95
6.5k
We Have a Design System, Now What?
morganepeng
53
7.7k
Navigating Team Friction
lara
188
15k
Java REST API Framework Comparison - PWX 2021
mraible
32
8.8k
How to train your dragon (web standard)
notwaldorf
96
6.1k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
182
54k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Reflections from 52 weeks, 52 projects
jeffersonlam
351
21k
GitHub's CSS Performance
jonrohan
1031
460k
What's in a price? How to price your products and services
michaelherold
246
12k
The World Runs on Bad Software
bkeepers
PRO
70
11k
Building Flexible Design Systems
yeseniaperezcruz
328
39k
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