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.8k
激動の一年を通じて見えてきた「技術でリードする」ということ
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
300
CLI ツールを Go ライブラリ として再実装する理由 / Why reimplement a CLI tool as a Go library
ktr_0731
3
1.1k
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
Gaze-LLE: Gaze Target Estimation via Large-Scale Learned Encoders
kzykmyzw
0
300
MySQL HeatWave:サービス概要のご紹介
oracle4engineer
PRO
4
1.7k
LLM時代の検索とコンテキストエンジニアリング
shibuiwilliam
2
1.1k
ウォンテッドリーのアラート設計と Datadog 移行での知見
donkomura
0
300
知られざるprops命名の慣習 アクション編
uhyo
9
1.8k
あとはAIに任せて人間は自由に生きる
kentaro
3
1.1k
株式会社ARAV 採用案内
maqui
0
270
Autonomous Database Serverless 技術詳細 / adb-s_technical_detail_jp
oracle4engineer
PRO
18
52k
ABEMAにおける 生成AI活用の現在地 / The Current Status of Generative AI at ABEMA
dekatotoro
0
620
生成AI活用のROI、どう測る? DMM.com 開発責任者から学ぶ「AI効果検証のノウハウ」 / ROI of AI
i35_267
4
150
PFEM Online Feature Flag @ newmo
shinyaishitobi
2
330
広島発!スタートアップ開発の裏側
tsankyo
0
200
Featured
See All Featured
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
234
17k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
4k
Documentation Writing (for coders)
carmenintech
73
5k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
10
1k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
8
470
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
139
34k
For a Future-Friendly Web
brad_frost
179
9.9k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
26k
Being A Developer After 40
akosma
90
590k
A Modern Web Designer's Workflow
chriscoyier
695
190k
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