テクニカルプロジェクトマネージャーとSREが協働して構築する信頼性 / reliability-tpm-sre-collaboration

by yuzujoe

Embed

Start on current slide

Slide 1

Slide 1 text

テクニカルプロジェクトマネージャーと SREが協働して構築する信頼性 SRE NEXT 2026 / 2026/07/10 Joe / @joe_yuzupi

Slide 2

Slide 2 text

Joe (Yuzuru Ohira) © LayerX Inc. About Me 株式会社 LayerX Ai Workforce 事業部 Platform Enablement グループマネージャー生まれたばかりの長男の育児に奮闘中趣味: ゴルフシングルになりたい。。。 2

Slide 3

Slide 3 text

Slide 4

Slide 4 text

今日話すこと © LayerX Inc. Agenda SRE に「SRE 以外の力」が必要な理由 TPM × SRE という協働モデル TPM と SRE の協働実践まとめ 4

Slide 5

Slide 5 text

今日の内容について ※ ちなみに、社内では TPM を「TechPM」と呼ぶこともあります © LayerX Inc. 今日の内容についてこのプロポーザルを提出したとき、私は一人のテクニカルプロジェクトマネージャー (TPM)として SRE の取り組みに関わっていましたその後、現在は TPM と SRE の双方のマネージャーをしています TPM という役割がいなくとも応用できる内容になっています 5

Slide 6

Slide 6 text

SREに「SRE以外の力」が必要な理由

Slide 7

Slide 7 text

SREだけでは解決できない課題 © LayerX Inc. SREに「SRE以外の力」が必要な理由 SRE活動のためのリソース確保ができない差し込みの対応が増えてしまう信頼性の優先度が機能開発に負けがちになる障害が起きるまで、その価値が見えにくい SRE チームだけの努力では、ソフトウェア全体の品質は変わらない 7

Slide 8

Slide 8 text

SREだけで回すには課題が多かった © LayerX Inc. SREに「SRE以外の力」が必要な理由環境: シングルテナントで提供しており、お客様ごとに環境が存在している運用: 監視・障害対応が積み上がり、SRE の負荷が増えやすい優先度: 共通化・自動化したい改善が、個別案件や機能開発に埋もれやすい体制・組織: SRE は少人数から増員してきたが、SREだけで全てを回すには限界があった開発プロジェクトが並行して走り、横断的な調整が多発していた AI による局所的な自動化は進むが、全体の運用課題を解くにはまだつながりきっていない 8

Slide 9

Slide 9 text

TPM という役割

Slide 10

Slide 10 text

TPM は技術理解を武器にプロジェクトを前に進める役割 © LayerX Inc. TPM × SRE の協働モデル技術を理解しつつ、推進・組織調整を担うエンジニアリングマネージャーとは異なり、ピープルマネジメントではなく「前進」に責任を持つ技術理解をもとに、関係者をつなぎ実現可能な進め方に落とす参考: Ai Workforce における TPM の役割 10

Slide 11

Slide 11 text

TPM は、技術的な不確実性を「進められる計画」に変換する観点 PMにも共通すること TPMに特に求めることプロジェクト推進進捗・期限・リソースを整える技術的な依存関係も踏まえて進め方を設計する技術理解専門家と連携して意思決定を支える技術的な論点を理解し、実現可能な計画に落とすチーム連携関係者間の認識をそろえる技術チームと同じ目線で課題を前に進める SRE との協働プロジェクトの前進を支える信頼性課題を開発で扱えるプロジェクトにする © LayerX Inc. TPM × SRE の協働モデル 11

Slide 12

Slide 12 text

TPM が情報の中心になり、進め方を揃える TPM を置く狙いは、各担当者が自分の役割に集中できる状態をつくること © LayerX Inc. SREがTPMの実務に与える影響 12 事業・顧客要求・優先度・制約を伝える開発チーム実装計画・リリース判断に落とす TPM 論点・優先度・関係者・進め方を集約する SRE 信頼性・運用・計測の観点を持ち込むセキュリティ / QA リスク・検証・品質観点を加える

Slide 13

Slide 13 text

信頼性はデリバリー品質を左右する私の入社時は、SRE が1名で奮闘していた。参考: SRE、はじめました - 事業部1人目SRE、Day1から現在までの過ごし方 © LayerX Inc. SREがTPMの実務に与える影響デリバリーでは、機能面・セキュリティ面など多くの観点を扱うその中でも信頼性は、届けた後の品質を左右する重要なファクターだからこそ、SRE のプラクティスを開発の進め方に取り込む必要がある SRE が信頼性向上に向き合えるように、TPM が周辺の調整を巻き取る 13

Slide 14

Slide 14 text

実践① オブザーバビリティ環境整備

Slide 15

Slide 15 text

まずはオブザーバビリティから信頼性を作っていく中で、オブザーバビリティは最重要。まずはプロダクションの状態を見えるようにする整備から開始した。 © LayerX Inc. 実践① オブザーバビリティ環境整備 → 出典: Site Reliability Engineering (Google) - Dickerson's Hierarchy of Service Reliability 可観測性は開発環境から、開発環境にもオブザーバビリティ導入のススメ 15

Slide 16

Slide 16 text

具体的に整備したこと計測の設計・共通ライブラリは TPM、各環境への展開とダッシュボードは SRE。 TPM: 設計・基礎実装 → SRE: 展開・ダッシュボード → 見える化された状態 © LayerX Inc. 実践① オブザーバビリティ環境整備ログ・メトリクス・トレースの計測設計計測用の共通ライブラリを実装各テナント環境への展開共通ダッシュボード・監視を構築 SRE だけでなく SWE・FDE も確認できる一次調査を開発チームが自走できる 16

Slide 17

Slide 17 text

開発チームが自走して調査できる状態に近づいた © LayerX Inc. 実践① オブザーバビリティ環境整備 SRE だけでなく、SWE や FDE も Datadog を活用している障害対応や調査時に、ログ・メトリクス・トレースを同じ場所で確認するプロダクションで起きている事象を、開発チーム自身が追える状態になっている調査支援の仕組みも整備され、開発レベルの調査は SRE なしでも進められる状態になってきている 17

Slide 18

Slide 18 text

実践② トイル削減

Slide 19

Slide 19 text

トイル削減は信頼性改善に向き合う余力を作る © LayerX Inc. 実践② トイル削減手作業・繰り返し作業が増えるほど、SRE はプロアクティブな改善に時間を使いにくくなる例: 毎回の手動再実行やリリース後確認が積み上がり、根本改善が後回しになるトイルを減らすことで、チーム全体のデリバリー速度と品質を上げるまずは「どの作業に時間を使っているのか」を可視化し、改善の入口を作る 19

Slide 20

Slide 20 text

出てきたものを分類する重要度高重要度低緊急度高最優先で対応本番影響のある障害対応手順化して抑制毎回の手動再実行緊急度低計画的に削減リリース後の手動確認やめる・移譲する属人化した定型調査優先度付けで、今向き合うべき信頼性課題とトイルを分けて扱う。 © LayerX Inc. 実践② トイル削減 20

Slide 21

Slide 21 text

トイルになりうる箇所重要度高重要度低緊急度高最優先で対応本番影響のある障害対応手順化して抑制毎回の手動再実行緊急度低計画的に削減リリース後の手動確認やめる・移譲する属人化した定型調査まずはトイルになりうる作業を切り分け、SRE が「重要度高・緊急度高」の信頼性課題に向き合える状態を作る © LayerX Inc. 実践② トイル削減 21

Slide 22

Slide 22 text

TPMの特性を活かして、プロジェクト化定量効果は計測中。現時点では、優先度整理と関係者調整を TPM が担うことで、SRE が信頼性課題に向き合いやすくなっている。 © LayerX Inc. 実践② トイル削減トイル削減は、SRE だけで完結する活動ではない TPM が優先度・関係者・進め方を整理し、運用課題をプロジェクトとして扱える形にする SRE が信頼性そのものに向き合えるように、周辺の調整やロードマップ化を支える 22

Slide 23

Slide 23 text

実践③ 開発段階へのSRE浸透

Slide 24

Slide 24 text

SRE のプラクティスを開発チームに広げる © LayerX Inc. 実践③ 開発段階へのSRE浸透 SRE チームだけが信頼性を担うモデルはスケールしない開発者自身がサービスの運用に当事者意識を持つ SRE チームは「プラクティスを広める」役割にシフト TPM がその浸透プロセスを設計・推進する 24

Slide 25

Slide 25 text

デリバリー計画に信頼性観点を入れる © LayerX Inc. 実践③ 開発段階へのSRE浸透 TPM がプロジェクトに入り、信頼性観点をデリバリーの計画に取り込むリリース前に運用・監視・障害時対応の確認ポイントを明確にする SRE が見るべき論点を、設計レビューやリリース判定の中に組み込む 25

Slide 26

Slide 26 text

TPM がデリバリー前にリスクを潰す © LayerX Inc. 実践③ 開発段階へのSRE浸透要件整理技術的な要件を関係者とすり合わせる顧客・事業側の要求を、開発チームが扱える技術論点に落とし込む。計画化信頼性観点を組み込むインフラ・セキュリティ・運用の確認ポイントを、デリバリー計画に入れる。推進関係者と前に進める技術判断は専門家に委ねつつ、関係者調整や進め方を整理して滞留を減らす。上記の取り組みを通じて、デリバリー可能な状態を作る現状、リリース予定どおりにデリバリーできる運用が回っている SRE と協力し、リリース前にリスクを抑えてデリバリーできている 26

Slide 27

Slide 27 text

実践④ パフォーマンス把握・改善

Slide 28

Slide 28 text

事業の成長で見えてきた課題 © LayerX Inc. 実践④ パフォーマンス把握・改善コーディングエージェントの普及により、機能が従来より数倍速いペースでプロダクトに組み込まれている潜在的なパフォーマンス問題を、事前に把握しづらい現在どれくらいの処理量に耐えられるのかが見えていないパフォーマンスを把握し、改善につなげる土台が必要になった 28

Slide 29

Slide 29 text

TPM でプロジェクト化調査する SLI 候補、既存のログ・メトリクス、ユーザー影響を整理し、論点を見える状態にする。 → アクションに落とす SRE が改善に移せるように、計測追加・性能検証・運用ルールなどのタスクへ分解する。 → 改善・情報資産にする他のプロジェクトでも同じ前提で進められるように、判断基準や進め方を再利用可能にする。 TPM が調査と整理を担うことで、SRE は実際の改善アクションに向き合いやすくなる © LayerX Inc. 実践④ パフォーマンス把握・改善 29

Slide 30

Slide 30 text

情報資産にすると、次の判断が速くなる判断基準が残る SLI 候補、測り方、運用ルールの前提を残すことで、同じ議論を毎回やり直さなくてよくなる。横展開できる別の開発プロジェクトでも、以前の情報を使って検証・計測・改善の計画を立てやすくなる。改善に移しやすい SRE が判断材料を探す時間を減らし、実際の検証・計測・改善アクションに向き合いやすくなる。情報資産にすることで、次のプロジェクトの立ち上がりと判断を速くする © LayerX Inc. 実践④ パフォーマンス把握・改善 30

Slide 31

Slide 31 text

知りたいことの例入力規模ユーザーが大量のファイルやデータを扱うとき、どこから処理時間や失敗率が悪化するのか。待ち時間ユーザーが結果を待てる時間はどれくらいで、どの操作で体験が悪くなるのか。同時実行複数ユーザーや複数ジョブが同時に動いたとき、どこが詰まりやすいのか。出力品質入力条件や処理量が変わると、どのタイミングで成果物の品質が落ち始めるのか。 TPM が問いを整理し、SRE が検証・計測・改善に移せる形にする © LayerX Inc. 実践④ パフォーマンス把握・改善 31

Slide 32

Slide 32 text

まとめ

Slide 33

Slide 33 text

うまくいったこと最初に目線を合わせ、小さく始めたことで信頼を積み上げられた。 © LayerX Inc. 振り返り見える化オブザーバビリティ環境整備余力を作るトイル削減開発へ広げるSRE プラクティスの浸透判断軸を作るパフォーマンス把握・改善 33

Slide 34

Slide 34 text

学びとこれからの課題学びこれからの課題 © LayerX Inc. 振り返り入社して 1 年ほど TPM のあり方を模索してきたが、うまくワークさせることで、デリバリー速度と品質が上がる手応えを得た SRE がより商用環境の信頼性に向き合える状態にする TPM が実践していることを、開発の当たり前にしていく 34

Slide 35

Slide 35 text

TPM × SRE で信頼性を組織の力にする © LayerX Inc. まとめ SRE の実践には技術力だけでなく、組織を動かす力が必要 TPM が技術理解をもとに、信頼性の取り組みを前に進める見える化・余力づくり・開発への浸透・性能把握で信頼性を組織文化にする SRE エンジニアが技術に集中できる環境を、TPM が作る 35

Slide 36

Slide 36 text

TPM がいなくても始められること © LayerX Inc. まとめ今回は「技術と組織をつなぎ、前に進める人」の役割を紹介しました TPM などの専任ロールがいなくても、この取り組み自体は可能まずは1つ、「技術課題を組織のアクションに変える」実践から 36

Slide 37

Slide 37 text

Slide 38

Slide 38 text

LayerX からの登壇はこちらも Track C ・ 7/10 16:55-17:25 AIと共生する開発者プラットフォーム：バクラクのモノレポ×マイクロサービス基盤坂田純 (@sakajunquality) LayerX SRE Track B ・ 7/11 13:00-13:40 しぶいSRE: サーバから見えない障害にどう向き合うか。ラストワンマイルのデバッグ実践星北斗 LayerX 執行役員 CISO 兼バクラク事業 VPoE © LayerX Inc. LayerX からの登壇 https://sre-next.dev/2026/schedule/#slot076 https://sre-next.dev/2026/schedule/#slot097 38

Slide 39

Slide 39 text

Thank you!