結論
as a Serviceの形のビジネスモデルが広がったため、それぞれのサービスの利用方法やコストなどエンジニアが意識する部分が増えたから。
ビジネス側もエンジニアリングにかかるコストを認識できる/するようになったから。
Platform Engineeringとは
プラットフォーム・エンジニアリングとは、ソフトウェアの開発とデリバリを目的とした、セルフサービス型の開発者プラットフォームの構築と運用に関する専門分野です。
https://www.gartner.co.jp/ja/articles/what-is-platform-engineering
Platform Engineeringという言葉言葉は、2023年ごろからインターネットの記事やイベントなどでよく聞くようになったと思う。この2023年はOpenAIなどの生成AIが台頭した時期と重なるが、それと同時にPlatform Engineeringやローコードなどのツールも多くの企業が発表した年のようにも思う。
Platform Engineering自体は上記の引用からもわかるように、ソフトウェアの開発とデプロイメントなどの運用面をより簡潔にするものだ。これはインターネット関連の技術が発展するにつれて、新しい概念や技術が開発され、エンジニアが常に学習しなくてはならない状況に常に晒されているからだ。
2024年10月現在、私が調べた限りではPlatform Engineeringを正面に押し出したサービスはあまりない。Spotifyが開発し、現在はCNCFのincubation projectになっているBackstageなど一応Platform Engineeringを体現するサービスとして存在するが、実際に導入して運用しているという話はあまり聞かない。Internal Development Platformを構築するよりも、運用面を少しずつ改善することで、開発環境を簡潔にすることに注力している会社が今の段階では多いと思う。
必要になった背景
Platform Engineeringとペアでよく聞く言葉として認知負荷というキーワードがある。認知負荷は現在のエンジニアの開発環境、言語やツールそしてManaged Service Providerまで、エンジニアにまつわる環境が多岐に渡り、開発者の工数やツールを習熟するまでに習得するまでにかかる工数が年々大きくなっていることを指している言葉である。認知負荷の主な原因はクラウドサービスの台頭とSaaSというビジネス形態の広がりに主な原因があるだろう。
またクラウドを利用するにはコストを意識せざるを得ない。クラウド台頭以前はオンプレによる自社サーバーでのサービス運用が主流ではあったが、クラウドが広がるにつれて、従量課金制によるエンジニアの責任範囲の拡大がある。具体的な調査などがあるわけではないが、これによって外部サービスの調査時間やプロダクションまでの開発期間などはより慎重にならざるを得ない状況になっているのではないだろうか？
これらの要因から、既に社内や部内で決まったやり方（ゴールデンパス）が確立されている場合は、エンジニアがこれを利用することで、エンジニアの調査、開発、デプロイメントなどの負担を下げようというのがPlatform Engineeringが達成したいことである。
クラウドサービスの台頭
AWSを始めとする大手テック企業が、2000年代初頭からクラウドサービスとして多くのサービスを提供するようになってきた。最初はストレージや仮想マシンなどが主な主力サービスとして利用されてきたが、年々サービスを拡大し、それぞれのクラウドベンダーが今や数百にも及ぶサービスを出している。これらはInfrasturecutre as a Serviceに始まり、Platform as a Service, serverless computing、そしてローコードツールなどに及ぶ。エンジニアはそれぞれのベンダーが提供しているサービスを連携させることで、基盤を作り、社内外のサービスを構築するのが常識になっている。またクラウドサービス内での連携に留まらず、後述するManaged Service Providerとの連携も現在では主流になってきている。
SaaS/MSPの広がり
また、大手テック企業のみならず、多くのスタートアップが現在ではSaaS/MSP(Managed Service Provider)として、特定の業界に特化したサービスを展開している。例えば、名刺管理ツールや会計ソフトなどが日本国内では知られているだろう。
SaaS/MSPは一般的に、企業が提供しているUIを使ってサービスを利用することができるが、APIによる連携も可能なサービスが多い。これによってクラウドベンダーとの連携を行うことで、クラウドベンダーのサービスだけではなく、外部のサービス、さらにその別のサービスとどんどんサービスを連携させることによってビジネスフローを一括で管理する流れができている。
コスト管理
現代のエンジニアには単にフロントエンジニア、バックエンドエンジニア、インフラエンジニアなどのエンジニアのポジションに分かれていたとしてもある程度の知識を全ての領域に対して求められていることを意味する。
それと同時にエンジニアは今まで以上にコストを意識せざるを得なくなってしまった。社内マシンのVM上でマシンを動かしていた際は、本番環境で問題を起こさなければ特に問題がなかったとは思うが、従量課金制でコストがかかる上記のサービス形態ではエンジニアはよりサービスの詳細を認識する必要が出てきている。例えば、AWSやGoogle CloudなどではRequest Quota（リクエストの上限値）これを超えると自動でスケールするが、コストも高額になったり、リクエストの送信に制限がかかることがある。コストが増額するのは経費として利益が減り、リクエストの送信ができなければ継続的なビジネスを行うことができなくなる。
以前は技術的なパフォーマンス向上が結果的にコスト削減に結びつくため、日頃のエンジニアリングの活動においてコストを直接意識する場面はなかなかなかったと思う。しかしながら現代では便利なクラウドサービスを利用するためには日々コストを意識して行動しなければならない。
結果として、エンジニアの責任範囲がエンジニアリングの領域だけではなくビジネス領域にも広がり、以前より責任が重くなっていることが遠因としてエンジニアの負荷となっているため、Platform Engineeringが今必要となっているのではないだろうか？
日本における需要
Service Provider
独自にサービスを提供している事業者は、Platform Engineeringの恩恵を強く受けると思う。なぜなら事業者の中で利用する技術を統一し、同じような形でサービスを展開することでエンジニア間での技術的な齟齬も減り、インフラなどの構築に時間を割くことが減る。しかしながら、新しい技術へ乗り換える際にPlatform Engineeringとして利用していたものが機能しなくなる可能性があるため、導入する際は長期的な目線が必要だと思われる。
System Integrator
日本特有のサービス形態なため、どのように適応するのかが不明瞭だが、System Integratorが独自のPlatform Engineeringサービスを構築することで、サービス利用者に即時に基盤構築、サービス開発などが行うは可能だと思う。しかし、System Integratorは部門間で利用している技術が異なるため、会社内で統一のPlatform Engineeringサービスを構築するのは難しいかもしれない。
終わりに
今後のエンジニアに求められることは、エンジニアという職種に関わらず、私が営業活動をしていて思うことはエンジニアと他の職種という枠組みはどんどん薄れていくと思う。ローコードによる開発支援やManaged Serviceによる知識の抽象化など、エンジニアや専門知識がなかった人に対するハードルは年々低くなっていると思う。逆にエンジニアはよりビジネスに近い考えを持つ必要があるかもしれない。コストの部分や技術的な部分だけでなく、コミュニケーションやサービスへのアイデアなどエンドユーザーが何を求めているかなど、よりビジネス的な観点も今後求められていくかもしれない。