Tweet
Tweet

Slide 1

Slide 1 text

Why Platform Engineering? マルチプロダクト・少人数 SRE の壁を越える挑戦 Road to SRE NEXT@福岡 Yuki Yoshiiwa

Slide 2

Slide 2 text

📛 吉岩祐貴 (@mananyuki) 💻 Platform Engineer @ Nulab Inc. 📚 趣味・関心 ● SRE / Platform Engineering ● Kubernetes ● いぬ🐕 / さかな🐟 ● ポケモン ● アイドル 2

Slide 3

Slide 3 text

3 ヌーラボについて ● 創業21周年 ● NULL + LAB = NULAB ○ 無の状態から有を創り出す「研究所」のような会社 ● 福岡を拠点に世界へ広がるヌーラボオフィス ○ リモートワーク / コアレスフレックス / 多様な労働スタイルに理解のある職場 ○ General Meeting (社員総会) で集結することも

Slide 4

Slide 4 text

No content

Slide 5

Slide 5 text

5 私たちの挑戦: Why & How 🎨 本日のテーマ: ● Why: なぜ Platform Engineering が必要だったのか？ ● How: SREs と Platform Engineer はどう連携しているのか？ 📝 アジェンダ: ● なぜ Platform Engineering が必要か ● SREs との連携実践 ● まとめ

Slide 6

Slide 6 text

なぜ Platform Engineering が必要か

Slide 7

Slide 7 text

7 ヌーラボの開発組織 ● サービス開発部 ○ プロダクトの価値創造を担当 ○ プロダクトの機能で分割された少人数 の開発チームの集合 ● Reliability Engineering 部 ○ 信頼性を軸にして顧客体験と開発者体 験の継続的な向上を担当 ○ プロダクトごとの SRE チーム (少人数 ・分散) ○ 横断的な Platform Engineering チーム ○ 顧客接点の CRE チーム

Slide 8

Slide 8 text

SREs が直⾯した構造的課題

Slide 9

Slide 9 text

9 SREs の理想と現実 ✨ あるべき SREs の姿: ● 安定稼働・信頼性向上への主体的貢献 ● SLO ベース運用、自動化によるトイル削減 ● 開発チームとの連携 (設計レビュー、プラクティス啓蒙) 🚧 ヌーラボ SREs の現実: ● 運用負荷・認知負荷に忙殺 ● プロダクト間のサイロ化 (ノウハウ・ツール非共通化) ● 信頼性への集中困難 (割り込み多発) ● 開発チームとの連携不足

Slide 10

Slide 10 text

10 理想と現実のギャップがもたらす「痛み」 ⏱ MTTR の悪化: 調査の非効率化、初動の遅れ 😥 モチベーション低下: 本来業務への集中困難、疲弊感 🌀 改善活動の停滞: 日々の運用に追われ、将来への投資が困難 📉 全体最適の欠如: プロダクト・チーム間のサイロ化による非効率

Slide 11

Slide 11 text

11 阻害要因①: ⾼すぎる「認知負荷」の壁 🥵 まとめ: 広範囲知識 × ツール乱立 × 情報分断 → SREs の認知限界 🔍 具体的な状況/要因: ● 少人数体制 vs 広範な技術スタック (プロダクト知識 + 横断技術) ● ツール/手順の多様化・複雑化 (監視、CI/CD など) ● 情報アクセス困難 (チーム間のサイロ化、ドキュメント不足/分散) 🚧 SREs への影響: ● 過度なコンテキストスイッチ ● 高い学習コスト ● 本来業務への集中困難、疲弊

Slide 12

Slide 12 text

12 阻害要因②: 進まない「標準化‧共通化」の壁 🌀 まとめ: 個別最適化の蔓延 → 標準・共通化の欠如 🔍 具体的な状況/要因: ● マルチプロダクト・少人数 SRE 体制 → 各チームが個別最適を優先 ● 全社的な共通基盤・ガイドラインの不在・形骸化 🚧 SREs (と組織) への影響: ● 重複実装・設定・管理コストの増大 (監視、CI/CD、インフラ…) ● 運用方法・技術選択のばらつき拡大 ● 全体最適の阻害、非効率

Slide 13

Slide 13 text

13 阻害要因③: 曖昧な「役割‧責任」の壁 ⏳ まとめ: SREs の役割不明確 → "何でも屋" 化 🔍 具体的な状況/要因: ● SREs に期待される役割・責任範囲が不明確 ● 信頼性の向上以外のタスクの恒常的な発生 (ガバナンス対応、セキュリティ 対応、開発支援など) 🚧 SREs への影響: ● 本来注力すべき SRE 活動 (SLO 改善、自動化、パフォーマンス改善等) の時 間不足 ● モチベーション低下、疲弊

Slide 14

Slide 14 text

14 結論: 個別最適の限界と「横断的解決」の必要性 ここまで見てきた壁は… ● 個々の SRE チームの努力や能力の問題ではない ● 構造的・組織的な課題である 💡 結論: ● 個別最適・局所的な改善には限界がある ● 全体最適化と SREs の負荷軽減のためには、 ● → チームやプロダクトを横断する仕組みが必要不可欠

Slide 15

Slide 15 text

Platform Engineering という解決策

Slide 16

Slide 16 text

16 横断的解決へのアプローチ検討 🤔 SREs の構造的課題に対し、複数の解決アプローチを検討 ● 例：SRE チームの大幅増強、全社横断での標準化プロジェクト、etc. 🎯 ヌーラボの状況と目指す姿を考慮 ● 背景: Platform Engineering に詳しいメンバーがいる ● 目指す姿: SREs の負荷軽減と開発者体験の向上 💡 仮説: 専任チームによる「共通基盤提供」と「標準化推進」が最も効果的かつ 持続可能と判断 ● SREs が本来の業務（信頼性向上）に集中できる環境を目指す

Slide 17

Slide 17 text

17 仮説: Platform Engineering による解決 💡 ヌーラボでの仮説: ● 背景: Platform Engineering に詳しいメンバーがいる ● 仮説: Platform Engineering の考え方 (共通基盤、標準化など) を実践する専 任チームを置けば、構造的課題 (サイロ、認知負荷など) を効果的に解決でき るのでは？ 🔍 選択: この仮説に基づき、Platform Engineering チームを設立し、Internal Developer Platform (IDP) の構築に着手 🎯 IDP の狙い: Platform for Platforms、「ゴールデンパス」の提供 (標準化・ 自動化) 、セルフサービス、開発者体験の向上、Fast Flow の実現

Slide 18

Slide 18 text

私たちの Platform Engineering アプローチ

Slide 19

Slide 19 text

19 基本⽅針 📦 "Platform as a Product": ● ユーザー (SREs / 開発者) のニーズとフィードバックで改善・進化 ● TVP (Thinnest Viable Platform) から小さく始める 🔍 Platform Engineering チームの必要性: ● サイロを越えた全体最適・標準化は、日々の運用に追われる SREs の兼務で は困難

Slide 20

Slide 20 text

20 チームトポロジーの適⽤ 🤝 Team Topologies の適用: ● Platform チーム: 共通基盤 (IDP) を提供・標準化 ● Enabling チーム: SREs / 開発者の活用支援・スキル向上 ● → 意図的に両方の役割 (ツール提供 + 活用支援) を担い、SREs と協働

Slide 21

Slide 21 text

SREs との連携実践

Slide 22

Slide 22 text

22 Platform Engineers と SREs の協働プロセス 👥 役割: ● Platform Engineering チーム: IDP 提供/改善 ● SRE チーム: 活用/フィードバック 🤝 協働プロセス: ヒアリング → 提供 → 活用 → フィードバック 💬 コミュニケーション: Slack、定期 Sync MTG などで密に連携

Slide 23

Slide 23 text

実践例: オブザーバビリティツール標準化

Slide 24

Slide 24 text

24 対象とした壁/課題 🧠 認知負荷の壁: 複数ツールの学習・運用コスト増大 ● Prometheus、Grafana、Amazon CloudWatch、Zipkin などが併存 ● SREs / 開発者の学習コスト、複数ツールの UI / クエリ習得負担 🚧 サイロ化の壁: 情報分断による調査非効率化 ● システム全体の健全性を一元的に把握困難 📉 MTTR の悪化: インシデント解決の遅延 ● 初動の遅れ (どのツールを見るべきか迷う) ● 調査の非効率 (複数ツール間での突き合わせ)

Slide 25

Slide 25 text

25 透明性の⾼い選定プロセス 📝 ADR (Architecture Decision Record) の活用: ● 重要なアーキテクチャ決定の背景・理由・議論プロセスを記録・共有 ● 関係者の合意形成促進、後日の参照容易性、知識共有を目的 📈 評価プロセスの段階的実施: 1. トライアル対象ツールの選定: 客観的評価軸 (機能、コスト、操作性、将来性 等) で比較検討し、Datadog を含む複数候補を選定 2. 多角的なフィードバック収集: 実践的シナリオで詳細トライアル。SREs / 開 発者から定量的・定性的評価を収集 3. 最終決定と組織的合意: 総合評価と最終決定会議を経て Datadog を選定

Slide 26

Slide 26 text

26 Platform Engineering チームの取り組み 🔧 Platform チームとして: ● Datadog 導入・共通基盤の提供 ● SREs / 開発者との継続的な対話 (要件定義、トライアル主導) 🤝 Enabling チームとして: ● 活用支援 (ガイドライン作成、ハンズオン、Q&A 対応) ● Datadog チャンピオンとしての情報提供、ドキュメント整備 🔄 フィードバックに基づく継続的改善: ● 利用状況のヒアリング、要望の収集と反映

Slide 27

Slide 27 text

27 効果と期待 🔭 監視情報の一元化: ● 調査効率向上 ● テレメトリーデータのサイロの破壊 ● → MTTR 短縮が期待できる 🧘 認知負荷・運用負荷の軽減: 学習コスト削減、SREs / 開発者の負担軽減 🔄 DevOps 文化の醸成: 開発と運用の共通理解促進 🔍 データドリブンな意思決定支援

Slide 28

Slide 28 text

実践例: Documentation as a Platform

Slide 29

Slide 29 text

29 対象とした壁/課題 🧠 認知負荷の壁: ● 情報が見つからない、古い、信頼できない ● 必要な情報へのアクセスに時間がかかる ● チーム間での情報共有不足 🚧 サイロ化の壁: ● 暗黙知の蔓延、知識の属人化 ● プロダクト・チーム横断でのノウハウ共有困難 ● オンボーディング時の学習コスト増大

Slide 30

Slide 30 text

30 Platform Engineering チームの取り組み 📁 IDP リポジトリ (internal-developer-platform): ● ガイドライン、ADR、技術情報、Tips などを一箇所に体系的に集約 ● Markdown ベースでバージョン管理、誰もが貢献可能 ● 検索しやすいディレクトリ構造とタグ付けルール 📈 品質と一貫性の担保: ● スタイルガイドの策定と適用: メモリーバンクに基づく執筆ルール ● Lint ツールの導入 (Textlint, Vale): 表記揺れや誤りを機械的にチェック ● レビュープロセスの実施: 新規ドキュメントや大幅な変更にはレビューを実 施

Slide 31

Slide 31 text

31 Platform Engineering チームの取り組み 🤖 AI 活用 (Cline を中心とした支援): ● Cline によるドキュメント作成・検索・要約支援が特に効果を発揮 (NotebookLM、Gemini も併用) ● 自然言語での問い合わせによる情報発見の容易化と、ドキュメント作成プロ セスの効率化 📦 "ドキュメントも Platform as a Product" (検証フェーズ): ● Platform Engineering チーム内でフィードバックループを回し、改善点を洗 い出し中 ● 利用状況の分析と定期的な棚卸しをチーム内で試行

Slide 32

Slide 32 text

32 検証段階での効果と期待 🔍 情報アクセス性の向上: 自己解決の促進 (チーム内での実感) ⏱ ドキュメント作成効率の向上: Cline の支援により、作成時間を大幅に短縮 (チーム内実績) 💡 暗黙知の形式知化の促進: 属人化防止への期待 🌱 オンボーディングの効率化と学習コスト削減への期待

Slide 33

Slide 33 text

まとめ

Slide 34

Slide 34 text

34 ここまでの変化と重要な学び 🌱 変化: ● 標準化の進展 (例: オブザーバビリティ) → 情報アクセス性向上 ● サイロ化による弊害改善の兆し 📚 重要な学び: ● "Platform as a Product" 実践は重要だが難しい (継続的な改善・フィード バックループ設計) ● TVP (Thinnest Viable Platform) アプローチは有効 ● 持続可能な解決策の設計・実装の重視 (標準化、再利用性、自律的利用) ● 最も大事なのは → SREs / 開発者との継続的な対話・協働と期待値調整

Slide 35

Slide 35 text

35 今後の挑戦: IDP の進化と効果測定 🦖 IDP の継続的進化: ● ケイパビリティの拡張 (CI/CD 標準化、Platform の構築・運用自動化) ● フィードバックループ強化 📈 効果測定の精緻化: ● DORA Metrics や開発者満足度などを用いた定量的評価 ● → 改善インパクトの可視化 🎯 組織目標への貢献: ● SLO 導入支援や FinOps との連携

Slide 36

Slide 36 text

36 まとめ 📝 課題: マルチプロダクト・少人数体制の中で、サイロ化や認知負荷という大き な壁に直面 💡 解決策: Platform Engineering を採用したが、重要なのは組織として 「Why (なぜやるのか) 」を問い続けること

Slide 37

Slide 37 text

37 まとめ 🔑 成功の鍵: ● プラットフォーム思考: 根本課題の探求と、共通基盤、標準化、セルフサー ビス化といった Platfrom Engineering の考え方 (エッセンス) を取り入れる こと ● 協働: SREs と開発者 (Platform Engineers 含む) が連携し、ユーザーの声を 元に解決策をプロダクトとして育てる意識 ("Platform as a Product") ● 継続的な対話と改善、そして持続可能な仕組みつくり

Slide 38

Slide 38 text

38 絶賛採⽤中です！ 採用サイト: https://careers.nulab.com/ ● ソフトウェアエンジニア（Platform Engineering team） ● ソフトウェアエンジニア（Product SREs for Backlog） 今日の話を深掘りしたい場合: カジュアル面談をどうぞ！ ● 採用サイトのエントリー一覧にアクセス ● 「ヌーラバーの話を聞いてみたい」を選択 ● 応募先へのメッセージに「Road to SRE NEXT@福岡を見た」