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
10k
激動の一年を通じて見えてきた「技術でリードする」ということ
ktr
May 15, 2025
Tweet
Share
More Decks by ktr
See All by ktr
詳解 MCP Go SDK / MCP Go SDK
ktr_0731
3
590
あまり知られていない MCP 仕様たち / MCP specifications that aren’t widely known
ktr_0731
0
500
CLI ツールを Go ライブラリ として再実装する理由 / Why reimplement a CLI tool as a Go library
ktr_0731
3
1.5k
Monorepo における Go テストの差分実行 / Running Differential Go Tests in a Monorepo
ktr_0731
1
410
Designing libraries in Go way
ktr_0731
7
1.6k
Go Modules and Proxy Walkthrough
ktr_0731
8
27k
ソフトウェアの複雑さに立ち向かう技術 / Tackling software complexity
ktr_0731
0
240
Fuzzy finder as a Go library
ktr_0731
3
6.2k
つよくてニューゲーム / NewGame++
ktr_0731
0
1.1k
Other Decks in Technology
See All in Technology
FastMCP OAuth Proxy with Cognito
hironobuiga
3
180
LINEヤフーにおけるAIOpsの現在地
lycorptech_jp
PRO
5
2.2k
形式手法特論:SMT ソルバで解く認可ポリシの静的解析 #kernelvm / Kernel VM Study Tsukuba No3
ytaka23
1
770
ADK + Gemini Enterprise で 外部 API 連携エージェント作るなら OAuth の仕組みを理解しておこう
kaz1437
0
180
TUNA Camp 2026 京都Stage ヒューリスティックアルゴリズム入門
terryu16
0
110
スピンアウト講座04_ルーティン処理
overflowinc
0
1.1k
Laravelで学ぶOAuthとOpenID Connectの基礎と実装
kyoshidaxx
4
1.8k
AIエージェント×GitHubで実現するQAナレッジの資産化と業務活用 / QA Knowledge as Assets with AI Agents & GitHub
tknw_hitsuji
0
210
「通るまでRe-run」から卒業!落ちないテストを書く勘所
asumikam
2
480
Blue/Green Deployment を用いた PostgreSQL のメジャーバージョンアップ
kkato1
0
120
Phase06_ClaudeCode実践
overflowinc
0
1.8k
「コントロールの三分法」で考える「コト」への向き合い方 / phperkaigi2026
blue_goheimochi
0
140
Featured
See All Featured
Redefining SEO in the New Era of Traffic Generation
szymonslowik
1
250
Measuring Dark Social's Impact On Conversion and Attribution
stephenakadiri
1
160
sira's awesome portfolio website redesign presentation
elsirapls
0
200
jQuery: Nuts, Bolts and Bling
dougneiner
65
8.4k
Marketing Yourself as an Engineer | Alaka | Gurzu
gurzu
0
160
Heart Work Chapter 1 - Part 1
lfama
PRO
5
35k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
360
30k
Context Engineering - Making Every Token Count
addyosmani
9
770
How to Align SEO within the Product Triangle To Get Buy-In & Support - #RIMC
aleyda
1
1.5k
What Being in a Rock Band Can Teach Us About Real World SEO
427marketing
0
200
The B2B funnel & how to create a winning content strategy
katarinadahlin
PRO
1
310
GraphQLの誤解/rethinking-graphql
sonatard
75
11k
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