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.9k
激動の一年を通じて見えてきた「技術でリードする」ということ
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
340
CLI ツールを Go ライブラリ として再実装する理由 / Why reimplement a CLI tool as a Go library
ktr_0731
3
1.3k
Monorepo における Go テストの差分実行 / Running Differential Go Tests in a Monorepo
ktr_0731
1
290
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
220
Fuzzy finder as a Go library
ktr_0731
3
6.1k
つよくてニューゲーム / 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
PythonとLLMで挑む、 4コマ漫画の構造化データ化
esuji5
1
130
LLMアプリケーション開発におけるセキュリティリスクと対策 / LLM Application Security
flatt_security
7
1.8k
Modern_Data_Stack最新動向クイズ_買収_AI_激動の2025年_.pdf
sagara
0
200
[2025-09-30] Databricks Genie を利用した分析基盤とデータモデリングの IVRy の現在地
wxyzzz
0
460
Exadata Database Service on Dedicated Infrastructure(ExaDB-D) UI スクリーン・キャプチャ集
oracle4engineer
PRO
2
5.4k
研究開発部メンバーの働き⽅ / Sansan R&D Profile
sansan33
PRO
3
20k
Flaky Testへの現実解をGoのプロポーザルから考える | Go Conference 2025
upamune
1
400
Pythonによる契約プログラミング入門 / PyCon JP 2025
7pairs
5
2.5k
生成AIとM5Stack / M5 Japan Tour 2025 Autumn 東京
you
PRO
0
190
後進育成のしくじり〜任せるスキルとリーダーシップの両立〜
matsu0228
6
2.2k
自作LLM Native GORM Pluginで実現する AI Agentバックテスト基盤構築
po3rin
2
240
M5製品で作るポン置きセルラー対応カメラ
sayacom
0
120
Featured
See All Featured
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
162
15k
Documentation Writing (for coders)
carmenintech
75
5k
Optimising Largest Contentful Paint
csswizardry
37
3.4k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
52
5.6k
Side Projects
sachag
455
43k
Bash Introduction
62gerente
615
210k
Thoughts on Productivity
jonyablonski
70
4.9k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
36
2.5k
Building Flexible Design Systems
yeseniaperezcruz
329
39k
Producing Creativity
orderedlist
PRO
347
40k
How STYLIGHT went responsive
nonsquared
100
5.8k
Art, The Web, and Tiny UX
lynnandtonic
303
21k
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