$30 off During Our Annual Pro Sale. View Details »
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
チームの境界をブチ抜いていけ
Search
tokai235
October 08, 2025
Programming
0
310
チームの境界をブチ抜いていけ
2025/10/8 の TSUDOI by giftee Tech #1 で話した内容です。
tokai235
October 08, 2025
Tweet
Share
More Decks by tokai235
See All by tokai235
俺たちは雰囲気で scope をやっているけどもうちょっとなんとかならんのか?
tokai235
0
1k
Other Decks in Programming
See All in Programming
Level up your Gemini CLI - D&D Style!
palladius
1
170
connect-python: convenient protobuf RPC for Python
anuraaga
0
360
TypeScriptで設計する 堅牢さとUXを両立した非同期ワークフローの実現
moeka__c
6
2.9k
AIコーディングエージェント(Manus)
kondai24
0
120
令和最新版Android Studioで化石デバイス向けアプリを作る
arkw
0
140
レイトレZ世代に捧ぐ、今からレイトレを始めるための小径
ichi_raven
0
490
C-Shared Buildで突破するAI Agent バックテストの壁
po3rin
0
210
Microservices Platforms: When Team Topologies Meets Microservices Patterns
cer
PRO
1
920
TypeScript 5.9 で使えるようになった import defer でパフォーマンス最適化を実現する
bicstone
1
1k
FluorTracer / RayTracingCamp11
kugimasa
0
190
開発に寄りそう自動テストの実現
goyoki
1
420
堅牢なフロントエンドテスト基盤を構築するために行った取り組み
shogo4131
6
1.9k
Featured
See All Featured
Scaling GitHub
holman
464
140k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.5k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
3.2k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
36
6.2k
VelocityConf: Rendering Performance Case Studies
addyosmani
333
24k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
Designing for Performance
lara
610
69k
Leading Effective Engineering Teams in the AI Era
addyosmani
8
1.2k
4 Signs Your Business is Dying
shpigford
186
22k
Testing 201, or: Great Expectations
jmmastey
46
7.8k
Automating Front-end Workflow
addyosmani
1371
200k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
132
19k
Transcript
チームの境界をブチ抜いていけ TSUDOI by giftee Tech #1 2025-10-08 tokai235
自己紹介 • toki(@tokai235)です • 現実世界ではギフティで働いています • 京都在住です これを作ってます
チームを越えた開発 すること、ありませんか? (社内の話です)
チームを越えた開発 • 基盤チームと機能開発チームとか • フロントエンドチームとバックエンドチームとか • プロダクトAとプロダクトBとか
たいへん
むずい
なんもわからん
わかる
なんとかうまく やっていけんか? とはいえ...
今日の話: チームを越えた開発をするときに 大事だと思っていること
Tips1: 「私はあなたの敵ではあり ません」と伝える
Tips1: 「私はあなたの敵ではありません」と伝える • 忘れがちなんだけどめちゃくちゃ大事 • まんま言葉に出してもいい • チームが違うと社内でも「敵」のように見えてしまうことがある ◦ 短期的、直接的なミッションが違うので
◦ 忙しいときほどこうなっていく(ツライ) • でも最終的に目指したいところは同じはず ◦ これを思い出す ※以前どなたかが言っていたことの受け売 りなんですが、出典を見つけられず...
Tips2: オーナーを立てる
Tips2: オーナーを立てる • それぞれのチームに担当がいるだけだと不十分 ◦ お見合いになっちゃう • 2つのチームを1つのプロジェクトでまとめ、そのオーナーを立てる ◦ 1つの大きなチームと見立てる
• オーナーの目的はただ一つ ◦ プロジェクトを終わらせること
Tips3: 目に見える形で合意する
Tips3: 目に見える形で合意する • なぜ? ◦ チームにはプロジェクト以外にも仕事がある ▪ プロジェクト ≠ プロダクト
◦ チームが違うと見えてない情報も多い • 境界や全体像をいつでも見られるようにする • 例えばマイルストーン、API スキーマなど
まとめ • 「私はあなたの敵ではありません」と伝えよう ◦ チームが違うとミッションが違うので忘れがちだけど大事 • オーナーを立てよう ◦ オーナーの目的はただ一つ、「プロジェクトを終わらせること」 •
目に見える形で合意しよう ◦ 境界や全体像をいつでも見られるようにする
ブチ抜いて いきましょう💪
他にもTips • 定例 MTG 入れる • はみ出す心意気を持つ ◦ プロダクトの責務 ≠
チームの責務 • 飲みに行く • 最悪やり直す気持ちを持つ • 少人数で議論 ⇒ みんなに共有のサイクル • 飲みに行く