"うちにはまだ早い"は本当？ 小さく始めるPlatform Engineering入門 Friday, May 15, 2026 Haruka Sakihara 

自己紹介 Haruka Sakihara <主な資格・表彰> • 2023 Japan AWS Jr.Champion • 2024-25 Japan AWS All Certifications Engineer • Google Cloud Certification 10資格 • ネットワークスペシャリスト試験(IPA) <所属> • アクセンチュア株式会社 テクノロジー コンサル ティング本部 (2021年新卒入社) • クラウドの部署にいます <趣味> • Go言語が好きです • フィギュアスケートとサンリオも好きです <クラウドネイティブ会議との関わり> • CloudNative Security Conference 2022 • セキュアなTerraformの使い方 • CloudNative Days Winter 2024 • そのCIは本当に役に立ってますか？～高品質なCI プロセスを実現する設計術 

ある日の一幕 こんなことがありました。 チームメンバー 私 大変です！ 何が起こったんや 

工数足りない問題その1 地道なデグレチェック検証を必要とする大量のタスクが突然降って湧いてきて絶望します。 チームメンバー 私 Python3.9の LambdaランタイムがEoLになると たくさんAWSからメールが来てます！ うちはPython Lambdaばっかりなのに 何てことしてくれやがったんだ（絶望） 

工数足りない問題その2 地道なデグレチェック検証を必要とする大量のタスクが突然降って湧いてきて絶望します(2回目)。 チームメンバー 私 某ライブラリに脆弱性が発見されて Dependabotが たくさんPR立ててます！ そのライブラリ使ってるマイクロサービス 10か所以上あるんだが（絶望） 

課題感の確認 • 忘れたころに降って湧いてくる、サービス固有の重たい個別作業 • EoL対応 • ライブラリ脆弱性対応 • リリース準備 • etc… • これら地道な運用・メンテナンス作業が、サービスの数ごとに個別で発生する • しかも1度きりではなく、サービスが生きている限り1年～数年ごとに何度も発生する このような「本質的ではない繰り返し作業」で 対応工数が圧迫され 本来やりたい開発ができなくなる 

そうだ、 Platform Engineeringしよう！ 

"うちにはまだ早い"は本当？ 小さく始めるPlatform Engineering入門 Agenda KubernetesがなくてもできるPlatform Engineering 自分たちだけでもできるPlatform Engineering Platform普及の壁をどう超えるか？ 開発生産性の源泉 1 2 3 4 

1. k8sがなくてもできるPlatformEngineering 「Kubernetesがないとできない」はウソ！ Platform Engineeringと聞くと真っ先に思い浮かべるのはKubernetesです。そうなるとごくごく一 部の大企業や尖った企業の話に聞こえて、「うちには関係ない」となりがちです。 上司 よそはよそ、うちはうちでしょ？ 

1. k8sがなくてもできるPlatformEngineering Kubernetes基盤でPEが効率的な理由 Platform EngineeringでよくKubernetesが出てくる理由は、kube-apiserver経由でクラスタ内のす べてのリソースを維持管理するk8sの設計思想がPEと相性がいいからです。 Kubernetes cluster Control Plane ... Node 1 Node 2 Node N 1. 操作したいリソースタイプに応じて、クラ スタノード内のkubeletがkube-apiserverへ のREST APIリクエストを作成 2. リクエストを受け取ったkube-apiserverが、 認証認可・アドミッションコントロールな どの処理を実施し、問題なければリソース 情報をetcdに永続化 3. kube-schedulerやkube-controller-manager、 kubeletが連携しながらetcdに保存された状 態に応じた実リソースを作成 Kubernetesで リソースが作られるStep サービス1 2 3 リソースの維持・ 管理を一手に担う kube-apiserverで設定値の 画一的な精査・統一が可能 kube-apiserver 1 2 3 request 1 requestをもとにクラスタの リソース状態を管理 2 create 3 

1. k8sがなくてもできるPlatformEngineering Kubernetes基盤上でのリソース統制ソリューション kube-apiserverに来るリクエストを拾って、k8sクラスタ全体にガバナンスを利かせる製品はコミュ ニティ内に数多く存在しています。 kyverno cosign Istio 動作 イメージ ⚫ 署名検証されたコンテナイメージのみPodとして デプロイ可能にする ⚫ 署名検証に失敗した場合はAdmission Policyで作成ブロック ⚫ サービスメッシュを実現するOSS ⚫ Admission Policyでサイドカーを自動注入し、 通信暗号化・認可・トラフィック制御をクラスタ横 断で実現 概要＆ 利点 ⚫ クラスタにデプロイするリソースに対して特定のポリ シーを適用し、非準拠のリソースは作成ブロック ⚫ Admission Controllerを用いることで漏れなく リソースを検知・操作 ソリュー ション kube-apiserver kubelet cosign Policy Controller Allow or Deny Webhook Request Signature Validation OCI Registry kube-apiserver kubelet kyverno policy engine Allow or Deny Webhook Request Policies Check Contents kube-apiserver kubelet Istiod Webhook Request Insert Sidecar Container in manifest Create Istio Sidecar 1 2 1 2 1 2 

1. k8sがなくてもできるPlatformEngineering Kubernetesがなくても作れる画一基盤 「どこか一か所に一律にまとめて来るオペレーションに対して統制を利かせる」という考え方は、 Kubernetes以外のクラウド環境・SaaS環境に対しても適用可能です。 自作AWS CDKコンストラクタ サンプルレポジトリの提供 AWS Config 動作 イメージ 概要 ⚫ Artifact等にEoL対応や各種ポリシー準拠済 みの組織自作モジュールを公開 ⚫ 各サービスはそれをimportして利用 ⚫ CI・CD設定や便利スクリプト・ツールが整ったサ ンプルレポジトリを公開 ⚫ 新サービス作成時はそれをforkして開発開始 ⚫ クラウド上にデプロイされたリソースの設定値が組 織ポリシーに準拠していなかったら自動で検知・ 修正を行わせる 利点 ⚫ 組織自作のCDKをimportすることによって、設 定値の更新・追従が容易 ⚫ CI/CDやテストの形式が統一されることによる認 知不可の軽減 ⚫ 自動化の設定や横展開が容易 ⚫ チーム横断でのガバナンスを利かせることが容易 ⚫ 自動修正まで整備することで組織ポリシーの強 制が可能 AWS Config Compliant Instances AWS CDK Constructor AWS CodeArtifact Stack Import Deploy 組織ポリシーを適用した リソースConstructorを 開発・公開 AWS CodeBuild Clone 同じRepo構成で 同じ自動化を展開 Standard Non-Compliant Instance Check Detect & Auto Modify 同じAWS環境内に 同じポリシーを展開 

1. k8sがなくてもできるPlatformEngineering ここまでのまとめ • Platform Engineeringの本質は「横断的に繰り返す作業を、共通の仕組みで解決する」というス キーム • サービスごとにバラバラに行われる開発作業を、どこか一か所の基盤でまとめて制御するという ことさえできるのであれば、どんな環境・どんな技術スタックであってもPlatform Engineering はできる 

"うちにはまだ早い"は本当？ 小さく始めるPlatform Engineering入門 Agenda KubernetesがなくてもできるPlatform Engineering 自分たちだけでもできるPlatform Engineering Platform普及の壁をどう超えるか？ 開発生産性の源泉 1 2 3 4 

2. 自分たちだけでもできるPlatform Engineering Platform Engineeringの難しさ 一網打尽のPlatform Engineeringをしようとすると、以下のような壁にぶつかります。 プラットフォーム設計の難しさ 1 プラットフォーム浸透の難しさ プラットフォーム利用の難しさ 2 3 全サービスに効く 統一設定を作るのが難しい 作っても使ってもらえない プラットフォームに乗る 難易度が高くて 開発速度向上の足かせになる まあ待て、早まるな Common Platform Common Platform Common Platform 

2.自分たちだけでもできるPlatform Engineering Platform Engineeringの成熟度モデル 組織でPlatformがどれだけ成長し活用されているかのレベルを、CNCFがPlatform Engineeringの成 熟度モデルという形で指標化しています。 Provisional – By Request Operationalized - Centrally tracked Scalable - Centrally enabled Optimizing - Managed services Level 1 Level 2 Level 3 Level 4 •ボランティアベース 人員・工数 利用動機 I/F 開発戦略 フィードバック 取り込み •専任チーム •プロダクト •活発なエコシステム •一貫していない •外部からの動機付け •内発的な動機付け •プロアクティブな参加 •機能ごとの独自ツール •標準ツール •セルフサービスのソリューショ ン •統合されたサービス •リクエストに応じて開発 •中央集権的な追跡 •中央集権的な支援 •マネージドサービス •アドホック •一貫性を持った収集 •洞察の獲得 •定量的かつ定性的 出典: https://tag-app-delivery.cncf.io/whitepapers/platform-eng-maturity-model/ 

2.自分たちだけでもできるPlatform Engineering まずはLevel1を目指す Platformというと「皆が不自由なく使える」というイメージを真っ先に思い浮かべますが、まずは 地道にLevel1から目指すという取り組みが大事です。 Provisional – By Request Operationalized - Centrally tracked Scalable - Centrally enabled Optimizing - Managed services Level 1 Level 2 Level 3 Level 4 •ボランティアベース 人員・工数 利用動機 I/F 開発戦略 フィードバック 取り込み •専任チーム •プロダクト •活発なエコシステム •一貫していない •外部からの動機付け •内発的な動機付け •プロアクティブな参加 •機能ごとの独自ツール •標準ツール •セルフサービスのソリューショ ン •統合されたサービス •リクエストに応じて開発 •中央集権的な追跡 •中央集権的な支援 •マネージドサービス •アドホック •一貫性を持った収集 •洞察の獲得 •定量的かつ定性的 

2.自分たちだけでもできるPlatform Engineering やらないよりやったほうがいい CNCFの原典にはLevel0 = プラットフォームなしという状態は規定されていませんが、そ の”Level0”状態と比べるとLevel1も十分すごいことです。 Provisional – By Request Operationalized - Centrally tracked Scalable - Centrally enabled Optimizing - Managed services Level 2 Level 3 Level 4 •ボランティアベース 人員・工数 利用動機 I/F 開発戦略 フィードバック 取り込み •専任チーム •プロダクト •活発なエコシステム •一貫していない •外部からの動機付け •内発的な動機付け •プロアクティブな参加 •機能ごとの独自ツール •標準ツール •セルフサービスのソリュー ション •統合されたサービス •リクエストに応じて開発 •中央集権的な追跡 •中央集権的な支援 •マネージドサービス •アドホック •一貫性を持った収集 •洞察の獲得 •定量的かつ定性的 Not Started Level 1 •N/A •N/A •それぞれ好き勝手やっ ている •N/A •N/A Level 0 

2.自分たちだけでもできるPlatform Engineering Level0 → Level1への取り組み Level1にステップアップするために必要な取り組みや振る舞いは、実はそう難しいものではありませ ん。気軽な相談やトライアンドエラーが許されるようなチームビルディングがなされていれば、それ が手掛かりになることが多いです。 Level0 それぞれが 好き勝手 Level1 便利な設定を 内部で シェアしよう • 誰が何をやっているのかが わからない • 自分だけがめんどくさくて つらい 1-1. 積極的な自己開示 • DailyStandupや夕会な どで困っていることをチーム で共有 • 「XXXで困っているのは自 分だけではない」という課 題感の共有 1-2. 積極的なナレッジ共有 • こんな便利スクリプト書いて みました！こうすれば問題 解決しました！という日々 の気づきをSlackや Teamsに投稿 • 雑談チャネルの重要さ 1-3. 気軽なコミット • 需要がありそうなら自サー ビスのレポジトリに気軽にア セットをコミットして共有 • Contributerへの心理 的安全性の重要さ 

2.自分たちだけでもできるPlatform Engineering Level0 → Level1への取り組み 「他の人も同じことで困ってないか」「もしかしたら他のみんなにも役立つかもしれない」という意 識をもって、一人一人の開発者がナレッジシェアする風土を作るところがLevel1への道です。 Level1 便利な設定を 内部で シェアしよう 1-1. 積極的な自己開示 • DailyStandupや夕会な どで困っていることをチーム で共有 • 「XXXで困っているのは自 分だけではない」という課 題感の共有 1-2. 積極的なナレッジ共有 • こんな便利スクリプト書いて みました！こうすれば問題 解決しました！という日々 の気づきをSlackや Teamsに投稿 • 雑談チャネルの重要さ 1-3. 気軽なコミット • 需要がありそうなら自サー ビスのレポジトリに気軽に アセットをコミットして共有 • Contributerへの心理的 安全性の重要さ Provisional – By Request Level 1 •ボランティアベース →チームの誰かがやる 人員・工数 利用動機 I/F 開発戦略 フィードバック 取り込み •一貫していない →困ったときにやる •機能ごとの独自ツール →自サービスの中に閉じる •リクエストに応じて開発 →困ったときにやる •アドホック →SlackやPRでワイワイ 

2.自分たちだけでもできるPlatform Engineering Level2への足掛かり Level1のチーム運営が確立化され、シェアされたナレッジの再現性や堅牢さが内部で十分揉まれて 育ってからでないと、それを横展開するLevel2への移行はスムーズには行きません。 Level0 それぞれが 好き勝手 Level1 便利な設定を 内部で シェアしよう • 誰が何をやっているのかが わからない • 自分だけがめんどくさくて つらい 1-1. 積極的な自己開示 • DailyStandupや夕会な どで困っていることをチーム で共有 • 「XXXで困っているのは自 分だけではない」という課 題感の共有 1-2. 積極的なナレッジ共有 • こんな便利スクリプト書いて みました！こうすれば問題 解決しました！という日々 の気づきをSlackや Teamsに投稿 • 雑談チャネルの重要さ 1-3. 気軽なコミット • 需要がありそうなら自サー ビスのレポジトリに気軽にア セットをコミットして共有 • Contributerへの心理 的安全性の重要さ Level2 便利な設定を 展開しよう Clear! NEW! 

"うちにはまだ早い"は本当？ 小さく始めるPlatform Engineering入門 Agenda KubernetesがなくてもできるPlatform Engineering 自分たちだけでもできるPlatform Engineering Platform普及の壁をどう超えるか？ 開発生産性の源泉 1 2 3 4 

3. Platform普及の壁をどう超えるか？ Platform Engineeringの難しさ = Level2の難しさ PEの難しさと聞いて思い浮かべる課題は主にLevel2のものが多いです。これらは自チームの外にプ ロダクトを出し使ってもらう「強制感」が出てくるフェーズ故です。 横展開が始まり「強制されている感」が強くなるフェーズに顕在化 プラットフォーム設計の難しさ 1 プラットフォーム浸透の難しさ プラットフォーム利用の難しさ 2 3 全サービスに効く 統一設定を作るのが難しい 作っても使ってもらえない プラットフォームに乗る 難易度が高くて 開発速度向上の足かせになる Common Platform Common Platform Common Platform (再掲) Platform Engineeringの難しさ 

3. Platform普及の壁をどう超えるか？ 強制されている感からの脱却 = 推奨というスタンス 「取り込んだほうが楽になる」という価値を示しつつ、導入しやすい箇所から小さく始める・導入有 無の判断は各サービスに委ねるという「推奨」のスタンスを取ることで強制感を薄れさせます。 プラットフォーム設計の難しさ 1 プラットフォーム浸透の難しさ プラットフォーム利用の難しさ 2 3 全サービスに効く 統一設定を作るのが難しい ↓ まずはスモールスタート 一部のサービスを対象にする 作っても使ってもらえない ↓ Level1の成果をもとに 「使うかの判断は各チーム」として 心理的安全性を確保 プラットフォームに乗る 難易度が高くて 開発速度向上の足かせになる ↓ ターゲットを絞って段階的に進め 利用実績を積む Common Platform Common Platform Common Platform (再掲) Platform Engineeringの難しさ Pending 

3. Platform普及の壁をどう超えるか？ フィードバック機構の重要さ 推奨してもこぼれている人を拾うためにはフィードバック機構の存在が重要です。フィードバックを 受けられないと、プラットフォームがいつまでたっても「ローカルルール」のままで進化できません。 プラットフォーム設計の難しさ 1 プラットフォーム浸透の難しさ プラットフォーム利用の難しさ 2 3 スモールスタートからこぼれる サービスの発生 使わない判断をした人たちの存在 ターゲットからこぼれる サービスの発生 Common Platform Common Platform Common Platform (再掲) Platform Engineeringの難しさ Pending こぼれたものを拾い上げて反映する双方向FBの仕組みが必要 

3. Platform普及の壁をどう超えるか？ 「強制されている感」が出てしまう例 先ほど挙げた「KubernetesではないPE例」は、サンプル・ポリシー提供者へのフィードバック機構 がなくて反発を生んでいるケースも少なくありません。 自作AWS CDKコンストラクタ サンプルレポジトリの提供 AWS Config 動作 イメージ 悪い例 ⚫ 組織提供のCDKでは利用できないリソースや構 築を組みたいときに問い合わせ先がない ⚫ ブラックボックス化された構造が使いにくいが問い 合わせ先がない ⚫ 標準レポジトリで使われている技術スタックになじ みがないチームへのフォローがない ⚫ 共通CI/CDなどの設定が使いにくいが問い合わ せ先がない ⚫ 一方的に適用されたポリシーによってアーキテク チャの見直しを強いられ手戻りとなる 対策 ⚫ Docの整備や問い合わせ先の明示 ⚫ プラットフォームチームのOfficeHour開催 ⚫ Docの整備や問い合わせ先の明示 ⚫ プラットフォームチームのOfficeHour開催 ⚫ ポリシーの内容の周知 ⚫ Fixを手助けする問い合わせ先の明示 AWS Config Compliant Instances AWS CDK Constructor AWS CodeArtifact Stack Import Deploy 利用可能な リソースや設定値 を一方的に制限 AWS CodeBuild Clone 画一的なRepo構成を 一方的に展開 Standard Non-Compliant Instance Check Detect & Auto Modify 一方的なポリシーを 問答無用に適用 

3. Platform普及の壁をどう超えるか？ Level2要件の再確認 フィードバック取り込みのためのチーム体制が整って回り始めれば、おおよそLevel2相応になった と言えるのではないかと思います。 Provisional – By Request Operationalized - Centrally tracked Scalable - Centrally enabled Optimizing - Managed services Level 2 Level 3 Level 4 •ボランティアベース 人員・工数 利用動機 I/F 開発戦略 フィードバック 取り込み •専任チーム •プロダクト •活発なエコシステム •一貫していない •外部からの動機付け •内発的な動機付け •プロアクティブな参加 •機能ごとの独自ツール •標準ツール •セルフサービスのソリュー ション •統合されたサービス •リクエストに応じて開発 •中央集権的な追跡 •中央集権的な支援 •マネージドサービス •アドホック •一貫性を持った収集 •洞察の獲得 •定量的かつ定性的 Not Started Level 1 •N/A •N/A •それぞれ好き勝手やっ ている •N/A •N/A Level 0 

"うちにはまだ早い"は本当？ 小さく始めるPlatform Engineering入門 Agenda KubernetesがなくてもできるPlatform Engineering 自分たちだけでもできるPlatform Engineering Platform普及の壁をどう超えるか？ 開発生産性の源泉 1 2 3 4 

4.開発生産性の源泉 CloudNativeとSREとPlatform Engineeringの関係 開発生産性はPlatform Engineeringだけではなく、CloudNativeやSREとも連携しながら向上させて いくものです。その関係性を紐解いてみたいと思います。 

4.開発生産性の源泉 CloudNativeとSREとPlatform Engineeringの関係 CNが開発の局所化や冪等性を引き受け、SREが信頼性を担保し、PEが開発体験を向上させる基盤を 提供するという3連携で、素早い顧客価値の提供を可能にしています。 CloudNative 素早い 顧客価値の 提供 SRE Platform Engineering Mission: 開発生産性の底上げ • 開発者が本質的な開発に集 中できるようにする • 基盤・処理の共通化によるメ ンテナンスコストおよび開発コ ストの削減 Mission: クラウドの活用による 顧客価値提供 • 責任境界モデルの具現化 によるアジリティの確保 • スケーラブルな事業展開の 実現 Mission: 信頼性の担保・維持 • サービスのスケールと信頼性を両立 させる • 信頼性を足掛かりにシステムを安全 に進化させる • これを開発サイクルのどこででもやる DevOps CI/CDの提供 マイクロサービスの 疎結合構成 メッシュによる サービス間連携 オブザーバビリティ の提供 トイルの撲滅 コンテナ技術の活用 宣言的APIによる 冪等性の担保 監視・アラート体制 の構築 自動化推進 インフラリソース 推奨設定の提供 開発環境 推奨設定の提供 

4.開発生産性の源泉 CN/SRE/PE 3つの成熟度モデル Platform Engineeringだけではなく、CloudNative/SREにもそれぞれ以下のような成熟度モデルが 定義されています。 Level 1 Level2 Level3 Level4 & 5 CloudNative SRE Platform Engineering Build •CloudNativeな実装を理 解し、開発・ステージ環境 で試している Operate •CloudNativeな実装で 構築したシステムを本番環 境に適用している Scale •組織とシステムのスケール プロセスが定義されている Improve & Optimize •ガバナンスポリシーを適用 •決定をレビュー・再検討す る改善プロセスが存在 The FireFighter •障害対応にリアクティブに 追われて本質的な改善に は手が回らない The Gatekeeper •本番デプロイの承認ロール を担う •ボトルネックになりやすい The Advocate •SREの文化・プラクティスを 組織内に啓発・普及する 役割を担う The Partner & Engineer •開発チームと対等な存在と して設計段階から関与 •組織全体にSREが定着 Provisional •課題が生じるたびにアド ホックに対応 Operationalized •専任のチームによる共通 化の促進 Scalable •プロダクトとして認知され、 利用者からの需要・FBが 内発的に生まれ始める Optimizing •使うのは当たり前でなくて はならない存在に 

4.開発生産性の源泉 CN/SRE/PE 3つの成熟度モデル それぞれのスコープに合わせて表現は異なるものの、大まかレベルごとの目標体制やレベル移行のイ メージは一致しているように感じます。 Level 1 Level2 Level3 Level4 & 5 CloudNative SRE Platform Engineering Build •CloudNativeな実装を理 解し、開発・ステージ環境 で試している Operate •CloudNativeな実装で 構築したシステムを本番環 境に適用している Scale •組織とシステムのスケール プロセスが定義されている Improve & Optimize •ガバナンスポリシーを適用 •決定をレビュー・再検討す る改善プロセスが存在 The FireFighter •障害対応にリアクティブに 追われて本質的な改善に は手が回らない The Gatekeeper •本番デプロイの承認ロール を担う •ボトルネックになりやすい The Advocate •SREの文化・プラクティスを 組織内に啓発・普及する 役割を担う The Partner & Engineer •開発チームと対等な存在と して設計段階から関与 •組織全体にSREが定着 Provisional •課題が生じるたびにアド ホックに対応 Operationalized •専任のチームによる共通 化の促進 Scalable •プロダクトとして認知され、 利用者からの需要・FBが 内発的に生まれ始める Optimizing •使うのは当たり前でなくて はならない存在に それぞれが バラバラに対応 サービス間・ チーム間で 連携が始まる 連携から シナジーが 生まれる サービス・ チームの境界を 意識しない 協業体制へ 共通化のとっかかりや 障害パターン・勘所が 見える化されたら 連携によって 対話やFBが 活性化されたら 時が経って何度も シナジープロセスが 回ると 

4.開発生産性の源泉 CN/SRE/PE 3つの成熟度モデル ３つがばらばらに成長するのではなく、３つ連携して成熟するモデルです。どこかの成熟度Levelを 上げたいのになかなかうまくいかないようなら、もしかしたら他要素がブロッカーかもしれません。 Level 1 Level2 Level3 Level4 & 5 CloudNative SRE Platform Engineering Build •CloudNativeな実装を理 解し、開発・ステージ環境 で試している Operate •CloudNativeな実装で 構築したシステムを本番環 境に適用している Scale •組織とシステムのスケール プロセスが定義されている Improve & Optimize •ガバナンスポリシーを適用 •決定をレビュー・再検討す る改善プロセスが存在 The FireFighter •障害対応にリアクティブに 追われて本質的な改善に は手が回らない The Gatekeeper •本番デプロイの承認ロール を担う •ボトルネックになりやすい The Advocate •SREの文化・プラクティスを 組織内に啓発・普及する 役割を担う The Partner & Engineer •開発チームと対等な存在と して設計段階から関与 •組織全体にSREが定着 Provisional •課題が生じるたびにアド ホックに対応 Operationalized •専任のチームによる共通 化の促進 Scalable •プロダクトとして認知され、 利用者からの需要・FBが 内発的に生まれ始める Optimizing •使うのは当たり前でなくて はならない存在に もしここが動かせなくて 困っているなら…… こちらを先に進めること が手掛かりになるかも？ 

"うちにはまだ早い"は本当？ 小さく始めるPlatform Engineering入門 Agenda KubernetesがなくてもできるPlatform Engineering 自分たちだけでもできるPlatform Engineering Platform普及の壁をどう超えるか？ 開発生産性の源泉 まとめ 1 2 3 4 5 

まとめ • サービスごとにバラバラに行われる開発作業を、どこか一か所の基盤でまとめて制御するという ことさえできるのであれば、どんな環境・どんな技術スタックであってもPlatform Engineeringはできる • やらないよりもまずは最初の第一歩！自チーム内の課題を解決する最適化や便利ツールづくり (Level1)から始めよう • もしLevel2以上に育てる！という意思決定になっても、Level1で下固めができているとスムーズ。 追加で「強制されている感」をなくすためのフィードバック機構が重要 • 顧客に素早く価値を提供するためには、Platform Engineeringによる開発生産性の底上げだけで はなく、クラウドネイティブスキルやSREの実践といった、三者の協力が必要 • もしも皆さんの開発に何か課題があるなら、Platform Engineeringが解決のカギになっているか も？ 

Thank You ご意見、ご質問ありましたらお気軽にご連絡下さい [email protected] Haruka Sakihara(崎原 晴香)