テクニカルプロジェクトマネージャーとSREが協働して構築する信頼性 / reliability-tpm-sre-collaboration

Transcript

1. テクニカルプロジェクトマネージャーと SREが協働して構築する信頼性 SRE NEXT 2026 / 2026/07/10 Joe / @joe_yuzupi
2. Joe (Yuzuru Ohira) © LayerX Inc. About Me 株式会社 LayerX Ai Workforce 事業部 Platform Enablement グループマネージャー 生まれたばかりの長男の育児に奮闘中 趣味: ゴルフ シングルになりたい。 。 。 2
3. © LayerX Inc. 3
4. 今日話すこと © LayerX Inc. Agenda SRE に「SRE 以外の力」が必要な理由 TPM × SRE という協働モデル TPM と SRE の協働実践 まとめ 4
5. 今日の内容について ※ ちなみに、社内では TPM を「TechPM」と呼ぶこともあります © LayerX Inc. 今日の内容について このプロポーザルを提出したとき、私は一人のテクニカルプロジェクトマネージャー (TPM)として SRE の取り組みに関わっていました その後、現在は TPM と SRE の双方のマネージャーをしています TPM という役割がいなくとも応用できる内容になっています 5
6. SREに「SRE以外の力」が必要な理由
7. SREだけでは解決できない課題 © LayerX Inc. SREに「SRE以外の力」が必要な理由 SRE活動のためのリソース確保ができない 差し込みの対応が増えてしまう 信頼性の優先度が機能開発に負けがちになる 障害が起きるまで、その価値が見えにくい SRE チームだけの努力では、ソフトウェア全体の品質は変わらない 7
8. SREだけで回すには課題が多かった © LayerX Inc. SREに「SRE以外の力」が必要な理由 環境: シングルテナントで提供しており、お客様ごとに環境が存在している 運用: 監視・障害対応が積み上がり、SRE の負荷が増えやすい 優先度: 共通化・自動化したい改善が、個別案件や機能開発に埋もれやすい 体制・組織: SRE は少人数から増員してきたが、SREだけで全てを回すには限界があった 開発プロジェクトが並行して走り、横断的な調整が多発していた AI による局所的な自動化は進むが、全体の運用課題を解くにはまだつながりきって いない 8
9. TPM という役割
10. TPM は技術理解を武器にプロジェクトを前に進める役割 © LayerX Inc. TPM × SRE の協働モデル 技術を理解しつつ、推進・組織調整を担う エンジニアリングマネージャーとは異なり、ピープルマネジメントではなく「前進」に 責任を持つ 技術理解をもとに、関係者をつなぎ実現可能な進め方に落とす 参考: Ai Workforce における TPM の役割 10
11. TPM は、技術的な不確実性を「進められる計画」に変換する 観点 PMにも共通すること TPMに特に求めること プロジェクト推 進 進捗・期限・リソースを整える 技術的な依存関係も踏まえて進め方を設計する 技術理解 専門家と連携して意思決定を支え る 技術的な論点を理解し、実現可能な計画に落と す チーム連携 関係者間の認識をそろえる 技術チームと同じ目線で課題を前に進める SRE との協働 プロジェクトの前進を支える 信頼性課題を開発で扱えるプロジェクトにする © LayerX Inc. TPM × SRE の協働モデル 11
12. TPM が情報の中心になり、進め方を揃える TPM を置く狙いは、各担当者が自分の役割に集中できる状態をつくること © LayerX Inc. SREがTPMの実務に与える影響 12 事業・顧客 要求・優先度・制約を伝える 開発チーム 実装計画・リリース判断に落とす TPM 論点・優先度・関係者・ 進め方を集約する SRE 信頼性・運用・計測の観点を持ち込む セキュリティ / QA リスク・検証・品質観点を加える
13. 信頼性はデリバリー品質を左右する 私の入社時は、SRE が1名で奮闘していた。参考: SRE、はじめました - 事業部1人目SRE、Day1から現在ま での過ごし方 © LayerX Inc. SREがTPMの実務に与える影響 デリバリーでは、機能面・セキュリティ面など多くの観点を扱う その中でも信頼性は、届けた後の品質を左右する重要なファクター だからこそ、SRE のプラクティスを開発の進め方に取り込む必要がある SRE が信頼性向上に向き合えるように、TPM が周辺の調整を巻き取る 13
14. 実践① オブザーバビリティ環境整備
15. まずはオブザーバビリティから 信頼性を作っていく中で、オブザーバビリティは最 重要。 まずはプロダクションの状態を見えるようにする整 備から開始した。 © LayerX Inc. 実践① オブザーバビリティ環境整備 → 出典: Site Reliability Engineering (Google) - Dickerson's Hierarchy of Service Reliability 可観測性は開発環境から、開発環境にもオブザーバビリティ導入のススメ 15
16. 具体的に整備したこと 計測の設計・共通ライブラリは TPM、各環境への展開とダッシュボードは SRE。 TPM: 設計・基礎実装 → SRE: 展開・ダッシュボード → 見える化された状態 © LayerX Inc. 実践① オブザーバビリティ環境整備 ログ・メトリク ス・トレースの計 測設計 計測用の共通ライ ブラリを実装 各テナント環境へ の展開 共通ダッシュボー ド・監視を構築 SRE だけでなく SWE・FDE も確認 できる 一次調査を開発チ ームが自走できる 16
17. 開発チームが自走して調査できる状態に近づいた © LayerX Inc. 実践① オブザーバビリティ環境整備 SRE だけでなく、SWE や FDE も Datadog を活用している 障害対応や調査時に、ログ・メトリクス・トレースを同じ場所で確認する プロダクションで起きている事象を、開発チーム自身が追える状態になっている 調査支援の仕組みも整備され、開発レベルの調査は SRE なしでも進められる状態に なってきている 17
18. 実践② トイル削減
19. トイル削減は信頼性改善に向き合う余力を作る © LayerX Inc. 実践② トイル削減 手作業・繰り返し作業が増えるほど、SRE はプロアクティブな改善に時間を使いにくく なる 例: 毎回の手動再実行やリリース後確認が積み上がり、根本改善が後回しになる トイルを減らすことで、チーム全体のデリバリー速度と品質を上げる まずは「どの作業に時間を使っているのか」を可視化し、改善の入口を作る 19
20. 出てきたものを分類する 重要度 高 重要度 低 緊急度 高 最優先で対応 本番影響のある障害対応 手順化して抑制 毎回の手動再実行 緊急度 低 計画的に削減 リリース後の手動確認 やめる・移譲する 属人化した定型調査 優先度付けで、今向き合うべき信頼性課題とトイルを分けて扱う。 © LayerX Inc. 実践② トイル削減 20
21. トイルになりうる箇所 重要度 高 重要度 低 緊急度 高 最優先で対応 本番影響のある障害対応 手順化して抑制 毎回の手動再実行 緊急度 低 計画的に削減 リリース後の手動確認 やめる・移譲する 属人化した定型調査 まずはトイルになりうる作業を切り分け、SRE が「重要度高・緊急度高」の信頼性課題に向き合える状態を 作る © LayerX Inc. 実践② トイル削減 21
22. TPMの特性を活かして、プロジェクト化 定量効果は計測中。現時点では、優先度整理と関係者調整を TPM が担うことで、SRE が信頼性課題に向き合いやすくなっている。 © LayerX Inc. 実践② トイル削減 トイル削減は、SRE だけで完結する活動ではない TPM が優先度・関係者・進め方を整理し、運用課題をプロジェクトとして扱える形にす る SRE が信頼性そのものに向き合えるように、周辺の調整やロードマップ化を支える 22
23. 実践③ 開発段階へのSRE浸透
24. SRE のプラクティスを開発チームに広げる © LayerX Inc. 実践③ 開発段階へのSRE浸透 SRE チームだけが信頼性を担うモデルはスケールしない 開発者自身がサービスの運用に当事者意識を持つ SRE チームは「プラクティスを広める」役割にシフト TPM がその浸透プロセスを設計・推進する 24
25. デリバリー計画に信頼性観点を入れる © LayerX Inc. 実践③ 開発段階へのSRE浸透 TPM がプロジェクトに入り、信頼性観点をデリバリーの計画に取り込む リリース前に運用・監視・障害時対応の確認ポイントを明確にする SRE が見るべき論点を、設計レビューやリリース判定の中に組み込む 25
26. TPM がデリバリー前にリスクを潰す © LayerX Inc. 実践③ 開発段階へのSRE浸透 要件整理 技術的な要件を関係者とすり合わせ る 顧客・事業側の要求を、開発チームが扱える 技術論点に落とし込む。 計画化 信頼性観点を組み込む インフラ・セキュリティ・運用の確認ポイン トを、デリバリー計画に入れる。 推進 関係者と前に進める 技術判断は専門家に委ねつつ、関係者調整や 進め方を整理して滞留を減らす。 上記の取り組みを通じて、デリバリー可能な状態を作る 現状、リリース予定どおりにデリバリーできる運用が回っている SRE と協力し、リリース前にリスクを抑えてデリバリーできている 26
27. 実践④ パフォーマンス把握・改善
28. 事業の成長で見えてきた課題 © LayerX Inc. 実践④ パフォーマンス把握・改善 コーディングエージェントの普及により、機能が従来より数倍速いペースでプロダクト に組み込まれている 潜在的なパフォーマンス問題を、事前に把握しづらい 現在どれくらいの処理量に耐えられるのかが見えていない パフォーマンスを把握し、改善につなげる土台が必要になった 28
29. TPM でプロジェクト化 調査する SLI 候補、既存のログ・メトリクス、ユ ーザー影響を整理し、論点を見える状 態にする。 → アクションに落とす SRE が改善に移せるように、計測追 加・性能検証・運用ルールなどのタス クへ分解する。 → 改善・情報資産にする 他のプロジェクトでも同じ前提で進め られるように、判断基準や進め方を再 利用可能にする。 TPM が調査と整理を担うことで、SRE は実際の改善アクションに向き合いやすくなる © LayerX Inc. 実践④ パフォーマンス把握・改善 29
30. 情報資産にすると、次の判断が速くなる 判断基準が残る SLI 候補、測り方、運用ルールの前提を残す ことで、同じ議論を毎回やり直さなくてよく なる。 横展開できる 別の開発プロジェクトでも、以前の情報を使 って検証・計測・改善の計画を立てやすくな る。 改善に移しやすい SRE が判断材料を探す時間を減らし、実際の 検証・計測・改善アクションに向き合いやす くなる。 情報資産にすることで、次のプロジェクトの立ち上がりと判断を速くする © LayerX Inc. 実践④ パフォーマンス把握・改善 30
31. 知りたいことの例 入力規模 ユーザーが大量のファイルやデータを扱うとき、どこから処理時間や失 敗率が悪化するのか。 待ち時間 ユーザーが結果を待てる時間はどれくらいで、どの操作で体験が悪くな るのか。 同時実行 複数ユーザーや複数ジョブが同時に動いたとき、どこが詰まりやすいの か。 出力品質 入力条件や処理量が変わると、どのタイミングで成果物の品質が落ち始 めるのか。 TPM が問いを整理し、SRE が検証・計測・改善に移せる形にする © LayerX Inc. 実践④ パフォーマンス把握・改善 31
32. まとめ
33. うまくいったこと 最初に目線を合わせ、小さく始めたことで信頼を積み上げられた。 © LayerX Inc. 振り返り 見える化オブザーバビリティ環境整備 余力を作るトイル削減 開発へ広げるSRE プラクティスの浸透 判断軸を作るパフォーマンス把握・改善 33
34. 学びとこれからの課題 学び これからの課題 © LayerX Inc. 振り返り 入社して 1 年ほど TPM のあり方を模 索してきたが、うまくワークさせるこ とで、デリバリー速度と品質が上がる 手応えを得た SRE がより商用環境の信頼性に向き合 える状態にする TPM が実践していることを、開発の 当たり前にしていく 34
35. TPM × SRE で信頼性を組織の力にする © LayerX Inc. まとめ SRE の実践には技術力だけでなく、組織を動かす力が必要 TPM が技術理解をもとに、信頼性の取り組みを前に進める 見える化・余力づくり・開発への浸透・性能把握で信頼性を組織文化にする SRE エンジニアが技術に集中できる環境を、TPM が作る 35
36. TPM がいなくても始められること © LayerX Inc. まとめ 今回は「技術と組織をつなぎ、前に進める人」の役割を紹介しました TPM などの専任ロールがいなくても、この取り組み自体は可能 まずは1つ、 「技術課題を組織のアクションに変える」実践から 36
37. エンジニア採用しています！ © LayerX Inc. We're hiring! Open Door 選考に関係なく 気軽にお話ししませんか？ Engineering Hiring Deck 37
38. 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
39. Thank you!