プラットフォームエンジニアリングとは?なぜ今、必要なのか。

2025年6月6日掲載

キービジュアル

みなさんこんにちは。ソフトバンクで DevOpsエンジニアをやっている増井です。

みなさんはプラットフォームエンジニアリングという言葉をご存知でしょうか?私が所属している開発チームではCloud Native Application Platform(以降、CNAP)というサービスを開発しています。

CNAPは「高度な自動化を備えた共通プラットフォーム」を提供し、プラットフォームエンジニアリングの実現をサポートする製品です。

今後、何回かに分けてCNAPを紹介したいのですが、本記事では、CNAPの根幹を支える概念であるプラットフォームエンジニアリングについて説明していきます。

目次

プラットフォームエンジニアリングとは?

プラットフォームエンジニアリングは、ソフトウェア開発および運用における効率化と標準化を目指した新しいアプローチです。この手法は、開発者自らリソースを簡単に確保し、アプリケーションを迅速にデプロイし、運用を一元管理できるプラットフォームを提供します。これにより、開発スピードが向上し、運用効率も高まります。

また、プラットフォームエンジニアリングはプラットフォームエンジニアリングチームとしての活動を含めての概念でもあります。

なぜ今、注目されているのか?

急速にデジタルトランスフォーメーション(DX)を進める企業にとって、効率的でスケーラブルなITインフラが不可欠です。そのためにContainerやCI/CD、それらを利活用したクラウドネイティブといった概念が生まれました。

しかしクラウドネイティブには高い専門性を要します。

その難しさから、クラウドファーストやクラウドネイティブのプロジェクトでは、少なからず問題を抱えたり、失敗してしまうケースが存在します。

これらを解決に近づけるプラットフォームエンジニアリングは、Gartnerの「Top 10 Strategic Technology Trends for 2024」に選ばれていることから、近年注目を集めていることがわかります。

企業がこのアプローチを導入することで、リソースの最適化と運用の簡素化を達成し、競争力を大幅に向上させることが可能です。

SRE・DevOpsとの違い

プラットフォームエンジニアリングは、SRE(Site Reliability Engineering)やDevOpsといった他のアプローチとは異なり、開発者向けに標準化されたプラットフォームを提供する点に焦点を当てています。

下図で説明している通り、個々の役割は異なります。

項目DevOpsSRE
プラットフォームエンジニアリング

目的

開発スピードと信頼性の向上

システムの安定稼働と信頼性の向上

開発者の認知負荷軽減と生産性向上

手段

自動化、CI/CD、コミュニケーション

モニタリング、自動復旧、インシデント管理

標準化されたツール、自動化、セルフサービス化、伴走支援

解決できる課題とは?

プラットフォームエンジニアリングが解決できることに「認知負荷の軽減」が挙げられます。認知負荷という単語に馴染みがあまりないと思いますので、少し説明します。

認知負荷とは

認知負荷とは、開発者がアプリケーション開発以外に必要な環境やツールを理解し、対応するために負担する思考の量のことを指します。高い認知負荷は開発者の生産性を低下させ、エラーの増加やプロジェクトの遅延を引き起こす可能性があります。

昨今ではソフトウェアの進歩が著しく、非常に便利な反面、ツールなどを使うための習得時間や知識が必要となります。

開発に集中したいのに「Kubernetesとはなにか」「CI/CDでの継続的な検証やデプロイをする」「Containerを使って開発環境の標準化」などの「認知負荷」が発生し、キャッチアップする工数が必要になります。

プラットフォームエンジニアリングはこのような「認知負荷」を軽減することが可能です。

プラットフォームエンジニアリングができること

この章ではプラットフォームエンジニアリングができることを、かいつまんで紹介します。

  1. ツールやインフラストラクチャの標準化
    Container(Kubernetes)、CI/CDパイプライン、様々なクラウドベンダーのリソースなどを利用者に意識させないように標準化、セルフサービス化していることです。セルフサービス化されているので、普段では色々と調べないと作れないようなContainer環境、複雑な設定のクラウド環境を簡単に構築できるようになります。これにより、開発者は自分で作りたい環境を作りたい時に作れるようになり、開発に集中できるようになります。
  2. 自動化による繰り返し作業の削減
    プラットフォームエンジニアリングは、インフラストラクチャや開発パイプラインの自動化にも重点を置きます。自動化により、手動で行っていた繰り返しの作業や設定作業を削減し、開発者の負担やミスの誘発を軽減します。
    • CI/CDパイプラインの自動化により、テストとデプロイが自動で行われる(だれでもデプロイができる)
    • インフラストラクチャをコード(IaC)として管理し、新しい環境をスピーディかつ一貫して展開できる

プラットフォームエンジニアリングを実現するには

プラットフォームエンジニアリング成功のポイントは下記と言われています。
※参考: CNCF Platforms White Paper

これらを満たすとよりよいプラットフォームエンジニアリングとなります。すべて重要ですが、冒頭でも述べた通りプラットフォームエンジニアリングチームとしての活動を含めての概念です。

チームとして作った・整備した物を提供し顧客(利用者)からフィードバックを収集し、改善するサイクルが不可欠です。

「すごく使いにくくても我慢してください」と言われたら困りますよね?顧客のニーズに合った機能を提供して、使用してもらう信頼を得ていく必要があります。

これらの概念からより良いものを作り、開発者に更に良い体験を提供することが大事です。

実現後のイメージ

プラットフォームエンジニアリングを実現した際のイメージは下図になります。

1枚目はプラットフォームエンジニアリングを導入しない開発。
画像のように開発者が開発するにあたって学ばなければならないことが多いです。

2枚目がプラットフォームエンジニアリングを導入した開発。
プラットフォームエンジニアリングのチームが開発チームに欲しい環境などを提供することで、開発に集中できます。

ソフトバンクでもプラットフォームエンジニアリングに注目しており、この概念を意識した開発をしています。

私が所属している開発チームでは、CNAPを開発しています。

CNAPはまさに今まで話していた「認知負荷」に対するサービスで、Kubernetesを利用した製品となります。Kubernetes自体が「認知負荷」の高い技術ですが、利用者はあまり意識せずに使うことができます。

これにより「完成されたDevOps環境」を手に入れられ、「常に最新の機能」を利用することができます。

詳しい内容については、今後アップされる記事に詳しく記載しますので楽しみにしていてください。

次回記事について

本記事は3部構成の1部目の記事で、プラットフォームエンジニアリングとはなにか?なにができるのか?実現するには?という内容について記載いたしました。

2部目の記事では、ソフトバンク発の開発者がセルフサービスで利用できることを可能にする基盤である「CNAP」を支える、KubernetesやIaC(HelmやTerraform)の話など、技術面での話をさせていただきます。

3部目の記事では、CNAPを導入するメリットや導入事例からの導入のヒントなど「CNAP」について掘り下げた記事をアップしますので、そちらも楽しみにしていただけたらと思います。

それでは次回の記事をお楽しみに。

関連サービス

MSPサービスのフレームワークを活用し、お客さまのDX実現につながる環境づくりをトータルサポートします。

CNAPは標準化されたアプリケーション実行環境を手軽に利用できるサービスです。リリースプロセスを自動化し、開発者自身がセルフサービスで実行環境を準備できるようになります。

MSP(Managed Service Provider)サービスは、お客さまのパブリッククラウドの導入から運用までをトータルでご提供するマネージドサービスです。

おすすめの記事

条件に該当するページがございません