一人でちいさくはじめる Platform Engineering

「1人SRE、Platform Engineeringに挑む。」の登壇資料です。
https://tenshoku-draft.connpass.com/event/401492/

Transcript

1. 一人でちいさくはじめる Platform Engineering 株式会社MIXI 井上 翔太 ©MIXI
2. 自己紹介 名前：しょっさん X（旧: Twitter）/ mixi2：@syossan27 所属：株式会社 MIXI 活動： • SRE Kaigi 実行委員長 • SRE Magazine 編集長 • ゆるSRE勉強会 共同運営 • 一般社団法人 SREコネクト 代表理事 • クラウドネイティブ会議 Co-chair • 縁側テックトーク MC ©MIXI
3. 今回お伝えしたいこと ©MIXI
4. 今回お伝えしたいこと • がんばりすぎない • 必要なことにフォーカスする ©MIXI
5. 最初に疑問 ©MIXI
6. なんでSREsがPlatform Engineeringを やるの？ ©MIXI
7. Platform EngineeringとSREの"交差点" "始まり"は違うが重なるところがある Platform Engineering ： 「ストリームアラインドチーム 」の方向から 「プロダクション 」へ向かっている SRE： 「プロダクション 」の方向から ※ 「ストリームアラインドチーム 」へ向かっている 各々がグラデーションを持ってタスクをこなす中で、たとえば「トイル」という 点においても重なりを持つ。 ※参考: Kusama Kazuto (2025年) 「あなたの興味は信頼性？それとも生産性？ SREとしてのキャリアに悩むみなさまに伝えたい選択肢」 ©MIXI
8. Platform EngineeringとSREの"交差点" Platform Engineering ：「開発者の認知負荷を上げる運用上のトイル」を 改善しようとする ex. 環境作成、デプロイ設定 、権限付与対応など SRE： 「間接的に信頼性を脅かすトイル」を改善しようとする ex. 定期データ更新作業、手作業によるデプロイ 、キャパシティの変更 ©MIXI
9. Platform EngineeringとSREの"交差点" Platform Engineering ：「開発者の認知負荷を上げる運用上のトイル」を 改善しようとする ex. 環境作成、デプロイ設定 、権限付与対応など SRE： 「間接的に信頼性を脅かすトイル」を改善しようとする ex. 定期データ更新作業、手作業によるデプロイ 、キャパシティの変更 Platform EngineeringとSREは目的こそ異なるが、領域としては大きな重なりがある。 そのため、組織状況によってはひとつのチームが両方を実践することは十二分にあり得る。 ©MIXI
10. 私のケース ©MIXI
11. SREがスタート プロジェクト全体に跨って、アプリケーション実装を担当 インフラ・トイル最適化・負荷計測基盤の構築・インシデント管理 など、SRE的な動きをすることが増える いつの間にかストリームアラインドチームの認知負荷軽減を考え、 Platform Engineering的な動きも増える ©MIXI
12. SREがスタート プロジェクト全体に跨って、アプリケーション実装を担当 いつの間にか インフラ・トイル最適化・負荷計測基盤の構築・インシデント管理 など、SRE的な動きをすることが増える やっていた いつの間にかストリームアラインドチームの認知負荷軽減を考え、 Platform Engineering的な動きも増える ©MIXI
13. SREがスタート 意識していなかったが、SRE/Platform Engineeringを実は行っていたパターンの一例になりま す。意外と知らず知らずにやっているパターンは多いのでは？ 大事なことは"本質を見失わない "こと。 もちろんベストプラクティスは存在するが、あくまでも用意された型であり、必ずしも プラットフォームを作らなければならないというわけでもない。 Platform Engineeringを 成功させるコツは プラットフォームのことなんて忘れること ※ ※引用: Kusama Kazuto (2025年) 「今日からはじめるプラットフォームエンジニアリング」 ©MIXI
14. 何をしたか？ ©MIXI
15. Platform Engineeringの観点から活動を振り返り 開発ワークフローの改善 ゴールデンパスの整備 • CI/CDパイプラインの整備 • プレビュー・開発環境の整備 • リリースプロセスの自動化 • 依存関係の管理 • スクラムプロセスの自動化 セルフサービスの実現 • QAチーム向け支援ツールの開発 • 開発環境の可視化・利用管理 ©MIXI
16. "Platform Engineering"の観点から活動を振り返り ゴールデンパスの整備 • CI/CDパイプラインの整備 • リリースプロセスの自動化 状況 思考 必要最低限の基盤が整っており、とりあえず「リリース に間に合わせた」といった状態 「ストリームアラインドチームが"価値"を提供するまで の間で迷わないように道を舗装すること」を考えていた ©MIXI
17. "Platform Engineering"の観点から活動を振り返り 開発ワークフローの改善 • プレビュー・開発環境の整備 • 依存関係の管理 • スクラムプロセスの自動化 状況 思考 開発をより良くする環境づくりがされていない状況 新しく始めたスクラムもイベントに時間がかかったり・・・ ストリームアラインドチームが雑事に時間を割かないように 集中するための環境づくりをしたい！ ©MIXI
18. "Platform Engineering"の観点から活動を振り返り セルフサービスの実現 • QAチーム向け支援ツールの開発 • 開発環境の可視化・利用管理 状況 思考 特にケアされていない状況 ストリームアラインドチーム・イネイブリングチームで作業が 完結する環境を作りたかった ©MIXI
19. Platform Engineeringを 知ってどう変わったか？ ©MIXI
20. Platform Engineeringへの挑戦 「意識せずにPlatform Engineering的な動きをしていた」というだけでは、 たまたま触れた"点"の課題解決 に過ぎません。 Platform Engineeringについて、考え方を学び、本質を捉えたうえで "面"の課題解決 へ行動を変容させていく必要があります。 なんとなくやっていた状態 本質に則した課題解決へ ©MIXI
21. Platform Engineeringへの挑戦 "本質を捉える"という言葉が出てきましたが、Platform Engineeringにおける本質 とはなんでしょうか？ ここではGartnerの定義とTeam Topologyより、２つの本質を取り上げます。 ※ 開発者体験と生産性の向上 開発者のペインポイントを特定し、和らげるための施策を執り行う。 究極、きちんとしたプラットフォームが存在しなくとも良い。（ex. 最小のTVPはWiki） 認知負荷の軽減 ストリームアラインドチームが価値提供にフォーカスするために、インフラやセ キュリティなど認知負荷のかかる部分をPlatform Engineeringで軽減する。 ※参考：「SREとは何か？DevOpsと何が違う？ガートナーが解説する運用管理変革の現実解」 https://www.sbbit.jp/article/cont1/48848 「Team Topology」（日本能率協会マネジメントセンター） https://pub.jmam.co.jp/book/b593881.html ©MIXI
22. Platform Engineeringの実践 • Terraformを利用したIaCの導入 • AIによる権限管理のセルフサービス化 • ゴールデンパスの改善 ◦ Workload Identityの導入 ◦ E2Eテストの導入 ◦ テストカバレッジの整備 ◦ 静的解析ツールの導入 実践の一部だが、ストリームアラインドチームが直面していたペインポイント を最適化することにフォーカスし、実践した。 認知負荷は、ファシリテーションモードでも対応。 ©MIXI
23. ひとりで始める心がけ ©MIXI
24. 小規模チームだからこそ 一人で進めていけたのは「チームの大きさ」と「協力体制」 一人でPlatform Engineeringを進めていけたのはストリームアラインド チームの大きさが５〜６人で、つらみの共有が円滑にできた ストリームアラインドチームが非常に協力的で、仕組みの導入に理解 を示してくれた SREと同じく、Platform Engineeringを円滑に進めるには "対話" ©MIXI
25. そうは言っても・・・ 勿論、現実として出来なかったことや失敗したことなどが多くあります。 リソースの限界 どうしても一人でやる場合、バックログは大量にストックされ優先順位付けをすること が必須となります。 そのため、「理想としてはやりたいが、急務ではない 」ものはどうしても優先度が下 げられ、もどかしい気持ちになることが多々ありました。 "迷い"を解決する場が近くにない 周りにアイデアや設計の壁打ち相手がおらず、自分の視点だけで判断しなければならな い難しさに厳しさを感じました。 「これをやらなくてよいのか？」「他にもよりスマートな解があるのでは？」など迷い つつも、他の方の発信を参考に進めていました。 ©MIXI
26. AIの福音 最近は、これらの問題に対してAIがサポートしてくれています。 リソースの拡張 AIを並列実行させることで、限界はあれど大きくリソースを拡張させることができるよ うになりました。広木大地さんが「すべてのエンジニアは、AIをメンバーに持つEMに なる」と仰っていましたが、まさしく一人でやるといった概念がAIによって希薄化して きています。 ※ 良き相談相手 AIは24時間いつでも・どれだけでも壁打ち相手となってくれます。 もちろん、全てを鵜呑みには出来ない部分はありますが、ある程度材料を持ち寄って壁 打ちをすると非常に示唆に富んだ回答をくれることが多いです。 引用：「エンジニアリングマネージャーのロードマップ」https://hirokidaichi.github.io/presentation/emconf.html#68 ©MIXI
27. がんばりすぎない AIのサポートによって、ひとりで出来ることは大きく広がりました。 しかし、出来ることが広がったからといって、すべてをやろうとするのもいけま せん。 AIに振り回されないように、以下を心がけるのが良いでしょう。 • やらないことを決める • 目の前にあるペインに立ち向かう • 完璧なクオリティを求めない • 他チームに頼れるところは頼る 「出来ること 」と「やるべきこと 」は別物です。 AIの全能感に惑わされず、「 選択と集中 」がより必要になります。 ©MIXI
28. まとめ ©MIXI
29. 実践してみた気付き Platform Engineeringは大規模チームや 大規模組織だけのものではない ©MIXI
30. 実践してみた気付き Platform Engineeringは大規模チームや 大規模組織だけのものではない ストリームアラインドチームとの対話をもとに第一歩を踏んでみる。 追い求めるのは「あるべき姿」ではなく、 「開発者体験・生産性向上と認知負荷の軽減 」 ©MIXI
31. 一人でもちいさくPlatform Engineeringはじめてみましょう！ ご清聴ありがとうございました ©MIXI