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