Why Platform Engineering? - マルチプロダクト・少人数 SRE の壁を越える挑戦 -

ヌーラボはマルチプロダクト戦略をとっており、プロダクトごとに SRE チームが存在しますが、その人数規模はプロダクトにより異なります。結果、チーム間のサイロ化による認知負荷増大や非効率化が進み、SREs は疲弊していました。この阻害要因に向き合うため、Platform Engineering チームを設立し、開発プラットフォーム構築に着手しました。「なぜ SREs の価値発揮が難しいのか？」を問い、SREs の課題解消をチームの「Why」としました。本セッションでは、Platform Engineering チームが共通基盤を提供・改善しつつ、SRE チームが必要な知識やスキルを習得できるよう支援する、その協働プロセスを共有します。私たちの挑戦と学びが、皆様の組織での SRE / Platform Engineering 連携のヒントになれば幸いです。

Transcript

1. Why Platform Engineering? マルチプロダクト・少人数 SRE の壁を越える挑戦 Road to SRE NEXT@福岡 Yuki Yoshiiwa
2. 📛 吉岩祐貴 (@mananyuki) 💻 Platform Engineer @ Nulab Inc. 📚 趣味・関心 • SRE / Platform Engineering • Kubernetes • いぬ🐕 / さかな🐟 • ポケモン • アイドル 2
3. 3 ヌーラボについて • 創業21周年 • NULL + LAB = NULAB ◦ 無の状態から有を創り出す「研究所」のような会社 • 福岡を拠点に世界へ広がるヌーラボオフィス ◦ リモートワーク / コアレスフレックス / 多様な労働スタイルに理解のある職場 ◦ General Meeting (社員総会) で集結することも
5. 5 私たちの挑戦: Why & How 🎨 本日のテーマ: • Why: なぜ Platform Engineering が必要だったのか？ • How: SREs と Platform Engineer はどう連携しているのか？ 📝 アジェンダ: • なぜ Platform Engineering が必要か • SREs との連携実践 • まとめ
6. なぜ Platform Engineering が必要か
7. 7 ヌーラボの開発組織 • サービス開発部 ◦ プロダクトの価値創造を担当 ◦ プロダクトの機能で分割された少人数 の開発チームの集合 • Reliability Engineering 部 ◦ 信頼性を軸にして顧客体験と開発者体 験の継続的な向上を担当 ◦ プロダクトごとの SRE チーム (少人数 ・分散) ◦ 横断的な Platform Engineering チーム ◦ 顧客接点の CRE チーム
8. SREs が直⾯した構造的課題
9. 9 SREs の理想と現実 ✨ あるべき SREs の姿: • 安定稼働・信頼性向上への主体的貢献 • SLO ベース運用、自動化によるトイル削減 • 開発チームとの連携 (設計レビュー、プラクティス啓蒙) 🚧 ヌーラボ SREs の現実: • 運用負荷・認知負荷に忙殺 • プロダクト間のサイロ化 (ノウハウ・ツール非共通化) • 信頼性への集中困難 (割り込み多発) • 開発チームとの連携不足
10. 10 理想と現実のギャップがもたらす「痛み」 ⏱ MTTR の悪化: 調査の非効率化、初動の遅れ 😥 モチベーション低下: 本来業務への集中困難、疲弊感 🌀 改善活動の停滞: 日々の運用に追われ、将来への投資が困難 📉 全体最適の欠如: プロダクト・チーム間のサイロ化による非効率
11. 11 阻害要因①: ⾼すぎる「認知負荷」の壁 🥵 まとめ: 広範囲知識 × ツール乱立 × 情報分断 → SREs の認知限界 🔍 具体的な状況/要因: • 少人数体制 vs 広範な技術スタック (プロダクト知識 + 横断技術) • ツール/手順の多様化・複雑化 (監視、CI/CD など) • 情報アクセス困難 (チーム間のサイロ化、ドキュメント不足/分散) 🚧 SREs への影響: • 過度なコンテキストスイッチ • 高い学習コスト • 本来業務への集中困難、疲弊
12. 12 阻害要因②: 進まない「標準化‧共通化」の壁 🌀 まとめ: 個別最適化の蔓延 → 標準・共通化の欠如 🔍 具体的な状況/要因: • マルチプロダクト・少人数 SRE 体制 → 各チームが個別最適を優先 • 全社的な共通基盤・ガイドラインの不在・形骸化 🚧 SREs (と組織) への影響: • 重複実装・設定・管理コストの増大 (監視、CI/CD、インフラ…) • 運用方法・技術選択のばらつき拡大 • 全体最適の阻害、非効率
13. 13 阻害要因③: 曖昧な「役割‧責任」の壁 ⏳ まとめ: SREs の役割不明確 → "何でも屋" 化 🔍 具体的な状況/要因: • SREs に期待される役割・責任範囲が不明確 • 信頼性の向上以外のタスクの恒常的な発生 (ガバナンス対応、セキュリティ 対応、開発支援など) 🚧 SREs への影響: • 本来注力すべき SRE 活動 (SLO 改善、自動化、パフォーマンス改善等) の時 間不足 • モチベーション低下、疲弊
14. 14 結論: 個別最適の限界と「横断的解決」の必要性 ここまで見てきた壁は… • 個々の SRE チームの努力や能力の問題ではない • 構造的・組織的な課題である 💡 結論: • 個別最適・局所的な改善には限界がある • 全体最適化と SREs の負荷軽減のためには、 • → チームやプロダクトを横断する仕組みが必要不可欠
15. Platform Engineering という解決策
16. 16 横断的解決へのアプローチ検討 🤔 SREs の構造的課題に対し、複数の解決アプローチを検討 • 例：SRE チームの大幅増強、全社横断での標準化プロジェクト、etc. 🎯 ヌーラボの状況と目指す姿を考慮 • 背景: Platform Engineering に詳しいメンバーがいる • 目指す姿: SREs の負荷軽減と開発者体験の向上 💡 仮説: 専任チームによる「共通基盤提供」と「標準化推進」が最も効果的かつ 持続可能と判断 • SREs が本来の業務（信頼性向上）に集中できる環境を目指す
17. 17 仮説: Platform Engineering による解決 💡 ヌーラボでの仮説: • 背景: Platform Engineering に詳しいメンバーがいる • 仮説: Platform Engineering の考え方 (共通基盤、標準化など) を実践する専 任チームを置けば、構造的課題 (サイロ、認知負荷など) を効果的に解決でき るのでは？ 🔍 選択: この仮説に基づき、Platform Engineering チームを設立し、Internal Developer Platform (IDP) の構築に着手 🎯 IDP の狙い: Platform for Platforms、「ゴールデンパス」の提供 (標準化・ 自動化)、セルフサービス、開発者体験の向上、Fast Flow の実現
18. 私たちの Platform Engineering アプローチ
19. 19 基本⽅針 📦 "Platform as a Product": • ユーザー (SREs / 開発者) のニーズとフィードバックで改善・進化 • TVP (Thinnest Viable Platform) から小さく始める 🔍 Platform Engineering チームの必要性: • サイロを越えた全体最適・標準化は、日々の運用に追われる SREs の兼務で は困難
20. 20 チームトポロジーの適⽤ 🤝 Team Topologies の適用: • Platform チーム: 共通基盤 (IDP) を提供・標準化 • Enabling チーム: SREs / 開発者の活用支援・スキル向上 • → 意図的に両方の役割 (ツール提供 + 活用支援) を担い、SREs と協働
21. SREs との連携実践
22. 22 Platform Engineers と SREs の協働プロセス 👥 役割: • Platform Engineering チーム: IDP 提供/改善 • SRE チーム: 活用/フィードバック 🤝 協働プロセス: ヒアリング → 提供 → 活用 → フィードバック 💬 コミュニケーション: Slack、定期 Sync MTG などで密に連携
23. 実践例: オブザーバビリティツール標準化
24. 24 対象とした壁/課題 🧠 認知負荷の壁: 複数ツールの学習・運用コスト増大 • Prometheus、Grafana、Amazon CloudWatch、Zipkin などが併存 • SREs / 開発者の学習コスト、複数ツールの UI / クエリ習得負担 🚧 サイロ化の壁: 情報分断による調査非効率化 • システム全体の健全性を一元的に把握困難 📉 MTTR の悪化: インシデント解決の遅延 • 初動の遅れ (どのツールを見るべきか迷う) • 調査の非効率 (複数ツール間での突き合わせ)
25. 25 透明性の⾼い選定プロセス 📝 ADR (Architecture Decision Record) の活用: • 重要なアーキテクチャ決定の背景・理由・議論プロセスを記録・共有 • 関係者の合意形成促進、後日の参照容易性、知識共有を目的 📈 評価プロセスの段階的実施: 1. トライアル対象ツールの選定: 客観的評価軸 (機能、コスト、操作性、将来性 等) で比較検討し、Datadog を含む複数候補を選定 2. 多角的なフィードバック収集: 実践的シナリオで詳細トライアル。SREs / 開 発者から定量的・定性的評価を収集 3. 最終決定と組織的合意: 総合評価と最終決定会議を経て Datadog を選定
26. 26 Platform Engineering チームの取り組み 🔧 Platform チームとして: • Datadog 導入・共通基盤の提供 • SREs / 開発者との継続的な対話 (要件定義、トライアル主導) 🤝 Enabling チームとして: • 活用支援 (ガイドライン作成、ハンズオン、Q&A 対応) • Datadog チャンピオンとしての情報提供、ドキュメント整備 🔄 フィードバックに基づく継続的改善: • 利用状況のヒアリング、要望の収集と反映
27. 27 効果と期待 🔭 監視情報の一元化: • 調査効率向上 • テレメトリーデータのサイロの破壊 • → MTTR 短縮が期待できる 🧘 認知負荷・運用負荷の軽減: 学習コスト削減、SREs / 開発者の負担軽減 🔄 DevOps 文化の醸成: 開発と運用の共通理解促進 🔍 データドリブンな意思決定支援
28. 実践例: Documentation as a Platform
29. 29 対象とした壁/課題 🧠 認知負荷の壁: • 情報が見つからない、古い、信頼できない • 必要な情報へのアクセスに時間がかかる • チーム間での情報共有不足 🚧 サイロ化の壁: • 暗黙知の蔓延、知識の属人化 • プロダクト・チーム横断でのノウハウ共有困難 • オンボーディング時の学習コスト増大
30. 30 Platform Engineering チームの取り組み 📁 IDP リポジトリ (internal-developer-platform): • ガイドライン、ADR、技術情報、Tips などを一箇所に体系的に集約 • Markdown ベースでバージョン管理、誰もが貢献可能 • 検索しやすいディレクトリ構造とタグ付けルール 📈 品質と一貫性の担保: • スタイルガイドの策定と適用: メモリーバンクに基づく執筆ルール • Lint ツールの導入 (Textlint, Vale): 表記揺れや誤りを機械的にチェック • レビュープロセスの実施: 新規ドキュメントや大幅な変更にはレビューを実 施
31. 31 Platform Engineering チームの取り組み 🤖 AI 活用 (Cline を中心とした支援): • Cline によるドキュメント作成・検索・要約支援が特に効果を発揮 (NotebookLM、Gemini も併用) • 自然言語での問い合わせによる情報発見の容易化と、ドキュメント作成プロ セスの効率化 📦 "ドキュメントも Platform as a Product" (検証フェーズ): • Platform Engineering チーム内でフィードバックループを回し、改善点を洗 い出し中 • 利用状況の分析と定期的な棚卸しをチーム内で試行
32. 32 検証段階での効果と期待 🔍 情報アクセス性の向上: 自己解決の促進 (チーム内での実感) ⏱ ドキュメント作成効率の向上: Cline の支援により、作成時間を大幅に短縮 (チーム内実績) 💡 暗黙知の形式知化の促進: 属人化防止への期待 🌱 オンボーディングの効率化と学習コスト削減への期待
33. まとめ
34. 34 ここまでの変化と重要な学び 🌱 変化: • 標準化の進展 (例: オブザーバビリティ) → 情報アクセス性向上 • サイロ化による弊害改善の兆し 📚 重要な学び: • "Platform as a Product" 実践は重要だが難しい (継続的な改善・フィード バックループ設計) • TVP (Thinnest Viable Platform) アプローチは有効 • 持続可能な解決策の設計・実装の重視 (標準化、再利用性、自律的利用) • 最も大事なのは → SREs / 開発者との継続的な対話・協働と期待値調整
35. 35 今後の挑戦: IDP の進化と効果測定 🦖 IDP の継続的進化: • ケイパビリティの拡張 (CI/CD 標準化、Platform の構築・運用自動化) • フィードバックループ強化 📈 効果測定の精緻化: • DORA Metrics や開発者満足度などを用いた定量的評価 • → 改善インパクトの可視化 🎯 組織目標への貢献: • SLO 導入支援や FinOps との連携
36. 36 まとめ 📝 課題: マルチプロダクト・少人数体制の中で、サイロ化や認知負荷という大き な壁に直面 💡 解決策: Platform Engineering を採用したが、重要なのは組織として 「Why (なぜやるのか)」を問い続けること
37. 37 まとめ 🔑 成功の鍵: • プラットフォーム思考: 根本課題の探求と、共通基盤、標準化、セルフサー ビス化といった Platfrom Engineering の考え方 (エッセンス) を取り入れる こと • 協働: SREs と開発者 (Platform Engineers 含む) が連携し、ユーザーの声を 元に解決策をプロダクトとして育てる意識 ("Platform as a Product") • 継続的な対話と改善、そして持続可能な仕組みつくり
38. 38 絶賛採⽤中です！ 採用サイト: https://careers.nulab.com/ • ソフトウェアエンジニア（Platform Engineering team） • ソフトウェアエンジニア（Product SREs for Backlog） 今日の話を深掘りしたい場合はカジュアル面談をどうぞ！ • 採用サイトのエントリー一覧にアクセス • 「ヌーラバーの話を聞いてみたい」を選択 • 応募先へのメッセージに「Road to SRE NEXT@福岡を見た」