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

一人でちいさくはじめる Platform Engineering 株式会社MIXI 井上 翔太 ©MIXI

自己紹介 名前：しょっさん X（旧: Twitter）/ mixi2：@syossan27 所属：株式会社 MIXI 活動： ● SRE Kaigi 実行委員長 ● SRE Magazine 編集長 ● ゆるSRE勉強会 共同運営 ● 一般社団法人 SREコネクト 代表理事 ● クラウドネイティブ会議 Co-chair ● 縁側テックトーク MC ©MIXI

今回お伝えしたいこと ©MIXI

今回お伝えしたいこと ● がんばりすぎない ● 必要なことにフォーカスする ©MIXI

最初に疑問 ©MIXI

なんでSREsがPlatform Engineeringを やるの？ ©MIXI

Platform EngineeringとSREの"交差点" "始まり"は違うが重なるところがある Platform Engineering ： 「ストリームアラインドチーム 」の方向から 「プロダクション 」へ向かっている SRE： 「プロダクション 」の方向から ※ 「ストリームアラインドチーム 」へ向かっている 各々がグラデーションを持ってタスクをこなす中で、たとえば「トイル」という 点においても重なりを持つ。 ※参考: Kusama Kazuto (2025年) 「あなたの興味は信頼性？それとも生産性？ SREとしてのキャリアに悩むみなさまに伝えたい選択肢」 ©MIXI

Platform EngineeringとSREの"交差点" Platform Engineering ：「開発者の認知負荷を上げる運用上のトイル」を 改善しようとする ex. 環境作成、デプロイ設定 、権限付与対応など SRE： 「間接的に信頼性を脅かすトイル」を改善しようとする ex. 定期データ更新作業、手作業によるデプロイ 、キャパシティの変更 ©MIXI

Platform EngineeringとSREの"交差点" Platform Engineering ：「開発者の認知負荷を上げる運用上のトイル」を 改善しようとする ex. 環境作成、デプロイ設定 、権限付与対応など SRE： 「間接的に信頼性を脅かすトイル」を改善しようとする ex. 定期データ更新作業、手作業によるデプロイ 、キャパシティの変更 Platform EngineeringとSREは目的こそ異なるが、領域としては大きな重なりがある。 そのため、組織状況によってはひとつのチームが両方を実践することは十二分にあり得る。 ©MIXI

私のケース ©MIXI

SREがスタート プロジェクト全体に跨って、アプリケーション実装を担当 インフラ・トイル最適化・負荷計測基盤の構築・インシデント管理 など、SRE的な動きをすることが増える いつの間にかストリームアラインドチームの認知負荷軽減を考え、 Platform Engineering的な動きも増える ©MIXI

SREがスタート プロジェクト全体に跨って、アプリケーション実装を担当 いつの間にか インフラ・トイル最適化・負荷計測基盤の構築・インシデント管理 など、SRE的な動きをすることが増える やっていた いつの間にかストリームアラインドチームの認知負荷軽減を考え、 Platform Engineering的な動きも増える ©MIXI

SREがスタート 意識していなかったが、SRE/Platform Engineeringを実は行っていたパターンの一例になりま す。意外と知らず知らずにやっているパターンは多いのでは？ 大事なことは"本質を見失わない "こと。 もちろんベストプラクティスは存在するが、あくまでも用意された型であり、必ずしも プラットフォームを作らなければならないというわけでもない。 Platform Engineeringを 成功させるコツは プラットフォームのことなんて忘れること ※ ※引用: Kusama Kazuto (2025年) 「今日からはじめるプラットフォームエンジニアリング」 ©MIXI

何をしたか？ ©MIXI

Platform Engineeringの観点から活動を振り返り 開発ワークフローの改善 ゴールデンパスの整備 ● CI/CDパイプラインの整備 ● プレビュー・開発環境の整備 ● リリースプロセスの自動化 ● 依存関係の管理 ● スクラムプロセスの自動化 セルフサービスの実現 ● QAチーム向け支援ツールの開発 ● 開発環境の可視化・利用管理 ©MIXI

"Platform Engineering"の観点から活動を振り返り ゴールデンパスの整備 ● CI/CDパイプラインの整備 ● リリースプロセスの自動化 状況 思考 必要最低限の基盤が整っており、とりあえず「リリース に間に合わせた」といった状態 「ストリームアラインドチームが"価値"を提供するまで の間で迷わないように道を舗装すること」を考えていた ©MIXI

"Platform Engineering"の観点から活動を振り返り 開発ワークフローの改善 ● プレビュー・開発環境の整備 ● 依存関係の管理 ● スクラムプロセスの自動化 状況 思考 開発をより良くする環境づくりがされていない状況 新しく始めたスクラムもイベントに時間がかかったり・・・ ストリームアラインドチームが雑事に時間を割かないように 集中するための環境づくりをしたい！ ©MIXI

"Platform Engineering"の観点から活動を振り返り セルフサービスの実現 ● QAチーム向け支援ツールの開発 ● 開発環境の可視化・利用管理 状況 思考 特にケアされていない状況 ストリームアラインドチーム・イネイブリングチームで作業が 完結する環境を作りたかった ©MIXI

Platform Engineeringを 知ってどう変わったか？ ©MIXI

Platform Engineeringへの挑戦 「意識せずにPlatform Engineering的な動きをしていた」というだけでは、 たまたま触れた"点"の課題解決 に過ぎません。 Platform Engineeringについて、考え方を学び、本質を捉えたうえで "面"の課題解決 へ行動を変容させていく必要があります。 なんとなくやっていた状態 本質に則した課題解決へ ©MIXI

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

• https://www.sbbit.jp/article/cont1/48848

Platform Engineeringの実践 ● Terraformを利用したIaCの導入 ● AIによる権限管理のセルフサービス化 ● ゴールデンパスの改善 ○ Workload Identityの導入 ○ E2Eテストの導入 ○ テストカバレッジの整備 ○ 静的解析ツールの導入 実践の一部だが、ストリームアラインドチームが直面していたペインポイント を最適化することにフォーカスし、実践した。 認知負荷は、ファシリテーションモードでも対応。 ©MIXI

ひとりで始める心がけ ©MIXI

小規模チームだからこそ 一人で進めていけたのは「チームの大きさ」と「協力体制」 一人でPlatform Engineeringを進めていけたのはストリームアラインド チームの大きさが５〜６人で、つらみの共有が円滑にできた ストリームアラインドチームが非常に協力的で、仕組みの導入に理解 を示してくれた SREと同じく、Platform Engineeringを円滑に進めるには "対話" ©MIXI

そうは言っても・・・ 勿論、現実として出来なかったことや失敗したことなどが多くあります。 リソースの限界 どうしても一人でやる場合、バックログは大量にストックされ優先順位付けをすること が必須となります。 そのため、「理想としてはやりたいが、急務ではない 」ものはどうしても優先度が下 げられ、もどかしい気持ちになることが多々ありました。 "迷い"を解決する場が近くにない 周りにアイデアや設計の壁打ち相手がおらず、自分の視点だけで判断しなければならな い難しさに厳しさを感じました。 「これをやらなくてよいのか？」「他にもよりスマートな解があるのでは？」など迷い つつも、他の方の発信を参考に進めていました。 ©MIXI

AIの福音 最近は、これらの問題に対してAIがサポートしてくれています。 リソースの拡張 AIを並列実行させることで、限界はあれど大きくリソースを拡張させることができるよ うになりました。広木大地さんが「すべてのエンジニアは、AIをメンバーに持つEMに なる」と仰っていましたが、まさしく一人でやるといった概念がAIによって希薄化して きています。 ※ 良き相談相手 AIは24時間いつでも・どれだけでも壁打ち相手となってくれます。 もちろん、全てを鵜呑みには出来ない部分はありますが、ある程度材料を持ち寄って壁 打ちをすると非常に示唆に富んだ回答をくれることが多いです。 引用：「エンジニアリングマネージャーのロードマップ」https://hirokidaichi.github.io/presentation/emconf.html#68 ©MIXI

がんばりすぎない AIのサポートによって、ひとりで出来ることは大きく広がりました。 しかし、出来ることが広がったからといって、すべてをやろうとするのもいけま せん。 AIに振り回されないように、以下を心がけるのが良いでしょう。 ● やらないことを決める ● 目の前にあるペインに立ち向かう ● 完璧なクオリティを求めない ● 他チームに頼れるところは頼る 「出来ること 」と「やるべきこと 」は別物です。 AIの全能感に惑わされず、「 選択と集中 」がより必要になります。 ©MIXI

まとめ ©MIXI

実践してみた気付き Platform Engineeringは大規模チームや 大規模組織だけのものではない ©MIXI

実践してみた気付き Platform Engineeringは大規模チームや 大規模組織だけのものではない ストリームアラインドチームとの対話をもとに第一歩を踏んでみる。 追い求めるのは「あるべき姿」ではなく、 「開発者体験・生産性向上と認知負荷の軽減 」 ©MIXI

一人でもちいさくPlatform Engineeringはじめてみましょう！ ご清聴ありがとうございました ©MIXI