ソフトウェア開発者がより多くのビジネス価値創造へ――「プラットフォームエンジニアリング」とは？ | 東京エレクトロンデバイス

システムインテグレーターやオンラインサービス企業をはじめとするIT専業企業はもちろん、金融や流通などのIT業界以外の企業においても、顧客の接点としてのWebサイトやスマートフォンなどの活用、あるいは顧客データや販売データの分析と活用、さらにはビジネスそのものをITによって変革するDX（デジタルトランスフォーメーション）など、ソフトウェアの開発と活用が重要性を増してきています。

そうした中で、ソフトウェア開発体制の充実を図るキーワードの1つとして注目を集めるのが「プラットフォームエンジニアリング」（Platform Engineering）です。

プラットフォームエンジニアリングは2～3年前から注目を集め始めたキーワードです。その背景にはソフトウェア開発者の「認知負荷」の高まりがあると言われています。

認知負荷とは、要するに考えなくてはならない事柄の多さや複雑さであり、認知負荷が高い状態とは考えたり注意を払ったりする物事が多くなってきて、重要なことに集中しにくい状態を言います。

ソフトウェア開発者にとって、この認知負荷の高まりが課題になっているのです。というのも、現在のソフトウェア開発は非常に複雑な環境を構築しなければなりません。

例えばインフラとしてDockerコンテナやKubernetes環境をTerraformによってクラウド上に用意し、アプリケーション開発にはNode.jsやNext.jsをはじめとするフレームワークやライブラリを用い、コードエディタにはVisual Studio Codeをセットして、ソースコード管理にはGitHubを採用し、GitHub ActionsでCI/CD環境も構築した上で、デプロイ後はGrafanaとPrometheusを用いてオブザーバービリティを実現する――。というように、インフラ、コーディング、デプロイ、運用のさまざまな工程においていまや多数のソフトウェアやサービスが関わっています。

さらにDevOpsの普及によって、開発者は運用を含めたアプリケーションのライフサイクル全体まで考慮しなくてはならないことも、こうした多数のソフトウェアやサービスをソフトウェアエンジニアがカバーしなければならない要因の1つとなっています。

しかも、これらソフトウェアの進化スピードは速く、より優れたソフトウェアの登場やメジャーバージョンアップなどについてもウォッチしておく必要があるでしょう。

下図はCloud Native Computing Foundationが公開している「Cloud Native Landscape」と呼ばれる一覧表です。クラウドネイティブの分野だけでも、これほど大量のソフトウェア開発が進められています。

ソフトウェア開発において増え続ける“ソフトウェア開発者の認知負荷”を下げることで、ソフトウェア開発者本来のミッション、すなわちソフトウェア開発を通じてビジネスの価値を向上させるための作業に集中できる環境を用意するのがプラットフォームエンジニアリングの目的です。

しかし、ソフトウェア開発のための共通基盤といった取り組みは過去に何度も多くの企業が取り組んできたことでした。それらとプラットフォームエンジニアリングはどのように違うのでしょうか。

プラットフォームエンジニアリングの定義の一例として「プラットフォームエンジニアリングはセルフサービス機能とインフラストラクチャーオペレーションの自動化により、開発者のエクスペリエンスと生産性を向上させる」という定義があります。

プラットフォームエンジニアリングには厳密な定義があるわけではなく、説明する立場などによりある程度の定義の幅があるのですが、上記の定義にあるような「セルフサービス」であることはどの定義でも概ね一致しています。

セルフサービスで利用されるツールとしては、必要なドキュメントや情報の共有、ソフトウェアやツールをダウンロードしたり設定を行ったりできる「社内向け開発者ポータル」と、開発環境やビルド環境などの必要なインフラを柔軟に構成できる「社内向けクラウドサービス」（XaaS）の2つが重要なものとして挙げられます。

具体的なツールとしては、Spotifyが開発して現在オープンソースとなっている「Backstage」がプラットフォームエンジニアリングのための代表的なツールとして知られています。

過去に行われてきたソフトウェア開発のための共通基盤への取り組みなどは、主に共通化することによるコスト削減や一定の品質のライブラリなどを使い回すことによる品質の安定化など、ソフトウェアエンジニアの認知負荷を下げる目的とは別であったことがほとんどでした。

結果として、それらはソフトウェア開発者にとって開発体験の向上や生産性を高めるものとはならず、それゆえ積極的に使われることもなく、徐々に使われなくなったと考えられています。

一方、プラットフォームエンジニアリングでは提供するツールやサービスの制約を用いた緩やかなガバナンスを実現しつつ、セルフサービスによってソフトウェア開発者自身あるいは開発チームが適切なツールやサービスとコンフィギュレーションを容易に選択・設定できる点、あるいは適切な情報共有が可能になる点など、開発者の体験を良くする仕組みがポイントの1つになっています。

そして、これがソフトウェア開発者や開発チームにとってプラットフォームエンジニアリングによるツールやサービスを積極的に使う大きな理由と考えられているのです。

もちろん、そのためにはソフトウェア開発者のニーズを適切に捉えたツールやサービスから構成される社内ポータルや社内向けクラウドサービスを構築しなければなりません。

それにはプラットフォームエンジニアリングを構築するのためのチームも必要になってきます。ソフトウェア開発者のニーズをくみ取り、社内ガバナンスなどとも適切に組み合わせながら、社内ポータルや社内クラウドサービスの構築を行うチームです。

そうしたチームをつくるには経営層の理解も必要となるでしょう。そう考えると、プラットフォームエンジニアリングは一定数以上のソフトウェア開発者が在籍する企業規模を要求すると言えます。実際、プラットフォームエンジニアリングをすでに実現している国内企業には、任天堂やLINEヤフー、リクルート、バンダイナムコといった大手企業の名前が並んでいます。

では、中小規模の企業ではプラットフォームエンジニアリングに取り組むことはできないのでしょうか。確かに組織ごとの事情に依存するとはいえ、プラットフォームエンジニアリングの考え方やツールは中小規模企業のソフトウェア開発でも有用なものです。

ソフトウェア開発において認知負荷が高まっていることは事実であり、「それぞれの企業規模に合わせてプラットフォームエンジニアリングのサービスやエッセンスを取り入れていく」、まさにこれが現時点での現実的な落としどころなのかもしれません。