エンジニアはどこまで越境するべきか＿Take

Product Engineering TalksにてTakenariさんが登壇した資料です。
https://upsider.connpass.com/event/401501/

Transcript

1. エンジニアはどこまで越境するべきか Product Engineer として「上流」に踏み込んで見えた境界線 © 2026 UPSIDER.inc
2. Presenter Profile 山本 剛成 Takenari Yamamoto) 株式会社UPSIDER Software Engineer 株式会社UPSIDERでバックエンドエンジニアとして、法人カードをはじめとするプロダクトの開発に従事。 バックエンド開発を中心に、プロダクトの企画・設計から開発、運用まで幅広く携わる。プロダクト開発を通じ て、技術と事業の両面から価値を届けるためのエンジニアリングを実践する傍ら、エンジニアの専門性とプ ロダクトへの貢献を両立する開発のあり方を日々模索している。 © 2026 UPSIDER.inc
3. 挑戦者を支える世界的な 金融プラットフォームを創る UPSIDERはカード会社から、総合金融機関へ © 2026 UPSIDER.inc
4. Our Services © 2026 UPSIDER.inc
5. Product Engineer の役割 Topic 1 Product Engineer の役割 © 2026 UPSIDER.inc
6. Product Engineer の役割 Product Engineer の責務 技術の力を最大限に活かして、ユーザーの課題を解決し、最速でビジネス成果（アウトカム）を出すこと © 2026 UPSIDER.inc
7. Product Engineer の役割 なぜ越境したのか 業務・技術・運用がつながっている 役割を分断すると… • お金に関わる複雑な業務 • 意思決定の鈍化 • 一つの変更が複数領域に波及 • 認識齟齬と手戻りの増加 • 多くのステークホルダー • 全体最適の喪失 問題を解くために必要だったので越境した © 2026 UPSIDER.inc
8. 越境した先で、何が起きたのか Topic 2 越境した先で、何が起きたのか © 2026 UPSIDER.inc
9. 越境した先で、何が起きたのか 越境によって何が良くなったか • PdM／プロダクト設計 ◦ 「何を、どこまで作るか」を考える → 技術制約を仕様決定の段階で扱い、PdMとの往復を減らせた • 業務要件整理／仕様への翻訳 ◦ 「その仕様が業務として成立するか」を確認する → 業務とシステムの制約を同じテーブルに載せ、実装前に認識を揃えられた • プロジェクトリード ◦ 技術設計だけでなく、スコープ、優先順位、リソース配分、依存関係、ステークホルダー調整まで見ている → 技術リスクを、プロジェクト全体の判断材料として扱えた
10. 越境した先で、何が起きたのか 越境しすぎることによる弊害 • 自分がボトルネックになる ◦ 判断・確認・連絡が集中し、確認待ちや連絡漏れが増える • エンジニアリングに集中できなくなる ◦ 会議や調整に時間を取られ、設計・実装・技術的検討が浅くなる • 責任を抱えすぎて疲弊する ◦ 要件整理や調整を引き取る一方で、エンジニアリングの責務も抱え続ける
11. エンジニアは、どこまで越境すべきか Topic 3 エンジニアは、どこまで越境すべきか © 2026 UPSIDER.inc
12. エンジニアは、どこまで越境すべきか 「越境するか・しないか」ではなく「どこで止めるか」
13. エンジニアは、どこまで越境すべきか 越境と抱え込みの境界線 • 良い越境 • 抱え込み ◦ 判断できる状態をチームに残す ◦ 判断と実務を個人に残す ◦ 背景・制約・判断基準を共有する ◦ 背景や判断基準が個人に集中する ◦ 次からは適切な人が判断できる ◦ 自分がいないと意思決定が止まる 越境の成果は、「自分ができること」ではなく「チームができるようになったこと」
14. エンジニアは、どこまで越境すべきか 自分が決めるのではなく、適切な人が決められる状態をつくる
15. エンジニアは、どこまで越境すべきか 問題には越境する。役割までは奪わない。
16. Recruit We are hiring！ UPSIDERでは一緒に働く仲間を募集しています © 2026 UPSIDER.inc