Upgrade to Pro — share decks privately, control downloads, hide ads and more …

ソフトバンク流!プラットフォームエンジニアリング実現へのアプローチ

Sponsored · SiteGround - Reliable hosting with speed, security, and support you can count on.

 ソフトバンク流!プラットフォームエンジニアリング実現へのアプローチ

本セッションでは、ソフトバンク社内でインフラ運用を劇的に効率化したリアルな事例を紹介します。
 「ソフトバンク流」のポイントは、Kubernetesを単なるリソース管理基盤ではなく、運用の抽象化レイヤーとして捉えることです。
この考え方により、周辺リソースのパッケージ化やYAMLによる一括管理を進め、インフラチームを日々の煩雑な運用から解放することが出来ました。結果として、開発スピードと品質の両立を実現しました。

以下のイベントで公演した資料です
Platform Engineering - SoftBank Tech Night #18
https://techplay.jp/event/992449

Avatar for SoftBank Tech Night

SoftBank Tech Night

March 18, 2026
Tweet

More Decks by SoftBank Tech Night

Other Decks in Technology

Transcript

  1. © SoftBank Corp. All Rights Reserved. ソフトバンク株式会社 佐藤 良太 ソフトバンク流!

    Platform Engineering 2026/3/17 SoftBank Tech Night #18 プラットフォームエンジニアリング実現へのアプローチ
  2. © SoftBank Corp. All Rights Reserved. 佐藤 良太 Ryota Sato

    自己紹介 1 所属 ソフトバンク株式会社 / AIプラットフォーム開発本部 役割 DevOpsエンジニア / プリセールス 経歴 2015年:新卒でSIer入社 ・アプリ開発(Java / Python) ・SRE(AWS / Azure / Alibaba Cloud) 2023年:ソフトバンク中途入社 ・開発者のセルフサービス化を実現するアプリケーション開発基盤 『CNAP』の開発 ・プラットフォームエンジニアリングの実践に向けた顧客提案 マイブーム Stylish なパワポ作成
  3. © SoftBank Corp. All Rights Reserved. アイスブレイク 2 ① これから検討したい

    ② 検討中だが進め方に悩んでいる ③ 導入しているが課題がある ④ 導入が進み、改善を続けている アンケート プラットフォームエンジニアリングの導入状況は?
  4. © SoftBank Corp. All Rights Reserved. ✓ ソフトバンクの実践アプローチを事例として紹介 ✓ PFE

    実現に向けた具体的なヒントを持ち帰っていただく 本日のゴール 3 ① これから検討したい ② 検討中だが進め方に悩んでいる ③ 導入しているが課題がある ターゲット 本日のゴール
  5. © SoftBank Corp. All Rights Reserved. アジェンダ 4 1. 共通基盤とは何か?

    2. ソフトバンク流!共通基盤の要求へのアプローチ 3. ソフトバンクでの具体的な実践事例 4. ソフトバンクでの取り組み紹介
  6. © SoftBank Corp. All Rights Reserved. 共通基盤とは何か? 共通基盤は、プラットフォームエンジニアリングの中核を担う土台である。 開発スピードと品質を両立するために、開発者体験を裏側で支える。 6

    プラットフォームエンジニアリングの構成要素 Internal Developer Platform (内部開発者プラットフォーム) 開発者ポータル 共通基盤 • 入口(インターフェース) • カタログ • 申請 / 実行導線 • ドキュメンテーション • 構成テンプレート • セルフサービス • 標準化された実行環境 • セキュリティ / ガバナンス • 自動化 / GitOps 開発者 プラットフォームチーム 利用 提供
  7. © SoftBank Corp. All Rights Reserved. 共通基盤とは何か? 共通基盤は、プラットフォームエンジニアリングの中核を担う土台である。 開発スピードと品質を両立するために、開発者体験を裏側で支える。 7

    プラットフォームエンジニアリングの構成要素 Internal Developer Platform (内部開発者プラットフォーム) 開発者ポータル 共通基盤 • 入口(インターフェース) • カタログ • 申請 / 実行導線 • ドキュメンテーション • 構成テンプレート • セルフサービス • 標準化された実行環境 • セキュリティ / ガバナンス • 自動化 / GitOps 開発者 プラットフォームチー ム 利用 提供 今回のスコープ
  8. © SoftBank Corp. All Rights Reserved. なぜ、共通基盤が必要なのか? 開発スピードと品質を両立するには、 個別最適ではなく、複雑さを吸収する共通基盤が必要になる。 8

    認知負荷・運用負荷の増大 個別最適の積み上がり 技術や選択肢の増加 共通基盤が必要 ⚫ クラウド、Kubernetes、各マ ネージドサービスなど 利用できる技術は増え続けて いる ⚫ 開発チームが選べる自由度は 高まっている ⚫ チームごとに構成や運用がばら つく ⚫ 同じような仕組みを都度作り 込むことになる ⚫ ノウハウが分散し、再利用しづ らい ⚫ 開発者は基盤の複雑さまで意 識せざるを得ない ⚫ 運用側は個別対応が増え続 ける ⚫ 開発スピードと品質の両立が 困難に ⚫ 複雑さを吸収する ⚫ 標準化する ⚫ 安全かつ速く使える形で提供 する ⚫ 開発者体験と運用効率を両 立する 自由度が高いだけでは、開発は速くならない。 複雑さを各チームに背負わせず、共通基盤で吸収することが重要。
  9. © SoftBank Corp. All Rights Reserved. ソフトバンクが直面した課題 開発者と運用者の双方に負荷が偏り、全体最適が難しかった。 9 開発者にも運用者にも負荷が偏る状態では、

    継続的に速く、安全に価値を届けることは難しい。 開発者視点での課題 ⚫環境準備に時間がかかる ⚫チームごとに構成や使い方が異なり、 学習コストが高い ⚫基盤の複雑さまで意識しないと、 開発を進めづらい ⚫安全な進め方が標準化されておらず、 都度判断が必要になる 運用者視点での課題 ⚫個別案件ごとの対応が増え続ける ⚫標準化されていないため、 再利用や横展開がしづらい ⚫セキュリティやガバナンスが 後追いになりやすい ⚫運用負荷が高く、 本来注力すべき改善活動に時間を割きづらい
  10. © SoftBank Corp. All Rights Reserved. 課題への解決方針 いきなりツールを選ぶのではなく、まず要件とユーザ体験を定義した。 11 要件とユーザ体験を定義したうえで、実装アプローチを決めた。

    ① 課題認識 ⚫認知負荷を下げたい ⚫環境準備を速くしたい ⚫個別対応を減らしたい ⚫安全性と標準化を両立したい ② 要件・ユーザ体験を 定義 ③ 実装アプローチ を決定 ⚫共通基盤に求める要件 ⚫実現したいユーザ体験 ⚫要件と体験を実現する方法を 検討
  11. © SoftBank Corp. All Rights Reserved. 共通基盤に求めた要件 12 これらの要件を満たすことを前提に、共通基盤の設計を進めた。 セルフサービス

    で利用出来ること 標準化 できること セキュリティ / ガバナンス を組み込めること 再現性のある運用 ができること 認知負荷 を下げられること 開発者が必要な環境や 機能を迅速に利用開始 できる 構成や運用のばらつきを 抑え、再利用しやすくする 安全なやり方を、最初か ら仕組みに組み込む 構成変更や運用が属人 化せず、継続的に扱える 利用者が基盤の複雑さを 意識しすぎずに使える 共通基盤には、セルフサービスと標準化を両立できることを求めた。
  12. © SoftBank Corp. All Rights Reserved. 実現したかったユーザ体験 13 要件を満たすだけでなく、利用者にとっての利便性と体験向上を重視。 目指したのは、開発者が迷わず、安全に、素早く利用できる共通基盤。

    迷わず始められる すぐ使える 複雑さを意識しすぎな い 安全なやり方 に乗れる 継続的に使える 何をどう使えば良いかわか りやすい 必要な環境や機能を迅 速に利用開始できる 基盤の詳細を知らなくても 使える セキュリティやガバナンスが 最初から組み込まれている 運用まで見据えて再利用 しやすい
  13. © SoftBank Corp. All Rights Reserved. ソフトバンク流 3つのアプローチ 14 単一の技術で全部を解くのではなく、

    複数のアプローチを組み合わせて、要件と体験を実現する。 5つの要件を満たし、5つの目指すユーザ体験を実現するために、 3つの実現アプローチを定めた。 アプローチ① Kubernetesを 中核に据える 支える要件 • 標準化 • 再現性のある運用 • 認知負荷の低減 支える体験 • 複雑さを意識しすぎない • 継続的に使える アプローチ② 周辺リソースも含めて パッケージ化 支える要件 • セルフサービス • 標準化 支える体験 • すぐ使える • 迷わず始められる アプローチ③ 構成を宣言的に 一元管理する 支える要件 • 再現性のある運用 • セキュリティ / ガバナンス 支える体験 • 安全なやり方に乗れる • 継続的に使える
  14. © SoftBank Corp. All Rights Reserved. アプローチ① Kubernetesを中核に据える 16 Kubernetesを中核に据えることで、標準化・抽象化を

    アプリ開発者とインフラチーム双方に価値ある形で提供しやすくなった。 共通基盤で複雑さを吸収し、利用者にはシンプルな体験を提供する。 その中核として、Kubernetesを採用した。 Kubernetesは、単なるコンピューティングリソースではなく、 インフラチームとアプリ開発者の双方にとって、運用の複雑さを解消す る抽象化レイヤーとして機能する。 アプリ開発者のメリット ⚫インフラのコードをアプリのコードと同一のGitリポジ トリで管理可能 ⚫インフラをセルフサービスで準備可能 ⚫基盤の複雑さを意識しすぎず、開発に集中しや すい インフラチームのメリット ⚫顧客のインフラ構成をIaCで管理可能 ⚫共通のセキュリティポリシーを適用可能 ⚫標準化・再利用・横展開を進めやすい
  15. © SoftBank Corp. All Rights Reserved. アプローチ② 周辺リソースも含めてパッケージ化 17 周辺リソースを

    yaml ファイルで一括管理するにあたり、 『Helm』※1 『Flux』※2 『Kustomise』※3 を組み合わせた GitOps 環境を提供 ✓ 複雑なフォルダ構成の把握 ✓ 構成情報の把握 発生した課題 解決策 パッケージ化して提供 ✓ 様々なインフラ構成パターンをIaC化 ✓ さらに、これらをパッケージ化(抽象化) ✓ 必要な周辺リソースも含めて、まとめて デプロイ可能に ※1 Helm:Kubernetes のマニフェスト(yamlファイル)をテンプレート化し、再利用可能な形にするツール ※2 Flux:Kubernetes向けの GitOps ツール ※3 Kustomize:kustomizationファイルを使ってKubernetesのオブジェクトを変更するためのツール
  16. © SoftBank Corp. All Rights Reserved. アプローチ② 周辺リソースも含めてパッケージ化 18 ※サンプル

    BASIC-DEPLOYMENTパッケージ:外部公開アプリケーション用の workload パッケージ apiVersion: managed.msp.sbopsv/v1alpha1 kind: Application metadata: name: nginx namespace: staging spec: chart: name: basic-deployment version: 0.7.x settings: image: repository: nignx pullPolicy: Always tag: "latest" service: domain: www.example.com ports: - name: nginx containerPort: 80 servicePort: 80 実際に投入する設定ファイル例(最小構成) GIP DNS node External DNS Kubernetes アプリ実行環境 LB node node Cert Manager ・・・ RDB Secret Manager Prometheus 自動的に関連リソースを構築 + 実行環境にアプリをデプロイ 複雑な構成を、再利用可能なパッケージとして提供
  17. © SoftBank Corp. All Rights Reserved. アプローチ③ 構成を宣言的に一元管理 19 Gitを正とした一元管理により、構成の統制・継続維持・クラウド差分の吸収を実現した。

    管理負荷の大幅削減に貢献。 ① GitOps による統合管理(Single Source of Truth) ② Gitを正とした「あるべき状態」の自動維持(構成ドリフト防止) ③ マルチクラウド間の構成管理差分を共通基盤側で吸収 push アプリ開発者 インフラ管理者 顧客インフラ構 成ファイル ①統合管理 ② 同期・維持 ③ 差分吸収
  18. © SoftBank Corp. All Rights Reserved. 事例紹介 | 活用による効果 20

    アジリティ向上によるアプリ開発・運用への効果と インフラ運用の長期的なコスト削減効果が特に大きい 定性評価 定量評価 ✓ アジリティ向上 ✓ 開発者体験の向上 ✓ 運用負荷の低減 要件定義と目標設定 アーキテクチャ設計 セキュリティ要件の定義 スケーラビリティと高可用性設計 ツールのインストール ツール実行環境の設定 リポジトリの作成 リポジトリのCD設定 プロジェクトの初期設定 CIパイプラインの設定 アプリコードの開発 ドキュメンテーション インフラ設計 インフラテンプレート作成 インフラコード開発 リソース監視とアラート設定 ドキュメンテーション アプリコードの変更 インフラコードの変更 変更のレビューと承認 クレデンシャル管理 アプリ UT/IT/E2E アプリケーションビルド アーティファクトビルド アプリのリリース ドキュメント管理 コスト管理と最適化 アプリのリリース K8sサービスのリリース クラウドサービスノリリース k8sセキュリティパッチ適用 OSSセキュリティパッチ適用 バージョン管理 150万 ⇒ 48万 180万 ⇒ 180万 436万 ⇒ 279万 5年で5040万 ⇒ 3186万 5年で1億4160万 ⇒ 3000万 CICD基盤初期開発 アプリ初期開発 インフラ初期開発 アプリ運用 インフラ運用 フェーズ 共通基盤 利用前後の コスト※ 作業内容 ※ 弊社デリバリー実績を基に試算。中程度のアプリケーションおよび複数のPaaSを含む Kubernetes 環境を想定。
  19. © SoftBank Corp. All Rights Reserved. MSPプラットフォームプランの紹介 22 『プラットフォームエンジニア リング』の要件を網羅した

    サービス ② 伴走支援 ① プラット フォーム ② 伴走支援 ② 伴走支援 ① プラット フォーム ※参考: Platform Engineering の 6原則 CNCF Platforms White Paper:https://tag-app-delivery.cncf.io/whitepapers/platforms/
  20. © SoftBank Corp. All Rights Reserved. MSPプラットフォームプランの紹介 23 共通基盤(CNAP)と伴走支援でクラウドネイティブ時代の内製化を支援 ①

    共通基盤 ② 伴走支援 セルフサービスで簡単に、 ローコードでインフラ環境を管理できる Kubernetesベースのプラットフォーム 熟練エンジニアが、 本番利用開始と事業部門への展開を 伴走しながら強力にサポート CNAP