ソフトウェア開発手法の一つとして、ここ1、2年急速に注目されるようになったアプローチに「プラットフォームエンジニアリング」がある。開発者を「エンドユーザー」（顧客）と位置付け、開発者のための自動化されたプラットフォームを用意することで、生産性を向上し価値創出までの時間の短縮を図る考え方だ。これまでの開発効率化の取り組みと比べどのような特徴があり、今後日本の企業が導入するにはどのような要点を押さえるべきか、識者に聞いた。
（取材・文／五味明子、編集／日高 彰）
 

開発者の負荷軽減で生産性を上げる

　プラットフォームエンジニアリングを最初に提唱したのは調査会社の米Gartner（ガートナー）で、「プラットフォームエンジニアリングとは、先進的なテクノロジーを活用したプラットフォームにより、アプリケーションのより迅速なデリバリーとビジネス価値の創出を可能にする革新的な手法」と定義している。

　具体的には、アプリケーション開発者をエンドユーザーとするプラットフォームチームを編成し、開発者のためのツールとセルフサービス機能を実装した、自動化されたプラットフォームを設計／構築する。開発者のエクスペリエンスを最適化するプラットフォームが提供されれば開発生産性が向上し、ひいてはビジネスにも貢献することになる。既に、いくつかの先進的な企業がプラットフォームエンジニアリングを取り入れたことを明らかにしており、国内でもLINEヤフー（インフラはプライベートクラウド／Kubernetes）、ニンテンドーシステムズ（Amazon Web Services、AWS）、朝日放送グループホールディングス（Google Cloud）などの導入事例が公開されている。

　開発生産性を上げるための手法としては、これまでもアジャイルやDevOps、継続的デリバリーなどさまざまなトレンドが登場してきた。ただ、これらはいずれもプロダクトをエンドユーザーに早く届けることをゴールとしており、必ずしも開発者のエクスペリエンスに特化したものではなかった。これに対して、プラットフォームエンジニアリングの最大の特徴は開発者のエクスペリエンス向上、つまり開発者の課題に適切にアプローチし、彼らが抱える認知負荷を下げることにフォーカスしている点だ。

　ガートナージャパンリサーチ＆アドバイザリ部門の桂島航・バイスプレジデントアナリストは「米国を中心に“Platform Ops”という流れが生まれており、開発者のエクスペリエンス向上を目的としたプラットフォームを用意するための専門チームを置いている企業が増え始めている」と説明する。ガートナーはプラットフォームエンジニアリングに関して、以下のような予測を公表している。
 

▼ 2026年までにインフラストラクチャプラットフォームチームを持つ組織の75％が、開発者エクスペリエンスを向上させ、製品イノベーションを加速するためにセルフサービスの社内開発者プラットフォーム（IDP）を提供する予定であり、23年の40％未満から増加する

▼ 27年までにAIを使用してSDLC（ソフトウェア開発ライフサイクル）の各フェーズを強化するプラットフォームエンジニアリングチームの数は5～40％に増加する


　ここで注目しておきたいのが、プラットフォームエンジニアリングにおける“プラットフォーム”の役割だ。開発者のエクスペリエンス向上に最適なプラットフォームとは具体的に何を指すのか。

　桂島アナリストは「海外ではKubernetesが一般的だが、日本では『Amazon ECS』（AWSのコンテナ管理サービス）や『AWS Fargate』（コンテナ向けサーバーレス環境）を利用するケースも多い」と述べ、前出のニンテンドーシステムズもAmazon ECSを導入している。「プラットフォームも標準化を進めることでガバナンスを効かせるというのがグローバル企業のアプローチで、標準に寄せたほうがエンジニアを集めやすいという側面もある。また、Kubernetesはコスト最適化のノウハウが共有されており、Kubernetes関連のスタートアップも多い。一方でKubernetesのオーバーヘッドを嫌う向きもあり、そうしたユーザーはECS／Fargateを好む傾向にある」（桂島アナリスト）

開発を知る人の配置と環境の整備を

　もっとも、桂島アナリストによれば「日本でも大企業によるKubernetes採用の動きは進んでおり、徐々に増えていくのではないか」と予測する。一方で「開発者エクスペリエンスを最適化するプラットフォーム」のイメージをいまだ描けていない日本企業は少なくない。「KubernetesかECSか」の議論の前に、プラットフォームエンジニアリングの全体像、さらに言えば、開発者エクスペリエンスを向上させることがどんなメリットをもたらすのか、広く知られているとは言い難いのが現状だ。
 
　日本企業がプラットフォームエンジニアリングチームの設置を検討する前に、どんなポイントを押さえておくべきなのか。グローバルで高いシェアをもつKubernetesベースのコンテナ基盤製品「OpenShift」を提供する米Red Hat（レッドハット）日本法人のテクニカルセールス本部クラウドサービススペシャリストソリューションアーキテクト部の北村慎太郎・ソリューションアーキテクトに話を聞いた。

――プラットフォームエンジニアリングチームを構成する場合、どのような人材が担当するべきか。

　プラットフォームエンジニアリングは開発者体験の向上がKPIとなるため、開発者の日常のプロセスを正しく理解し、開発者が抱える不満や課題に適切にアプローチするためのノウハウが必要。したがって開発者／インフラ運用者にかかわらず、開発プロセスを把握している人材が推奨される。プラットフォームチームの構成は組織全体の習熟度によって異なるが、最初はまず一つのスクラムチームに対して2人程度のプラットフォーム運用者をアサインするところから始めるのが理想。そこから開発プロセスの理解や改善点を定義しつつ、自動化とセルフサービス化によって少人数の運用を実現する土壌を形成するとよいだろう。

――プラットフォームエンジニアリングチームが提供するIDPが備えているべき機能としては何が挙げられるか。

　IDPにはさまざまな要素が求められるが、大きく二つの分野がある。一つは開発者体験を向上するためのツール群。もう一つはツール群を活用し、開発者がプラットフォーム上で効率的に開発／運用するためのサポート環境だ。プラットフォームエンジニアリングはクラウドネイティブ開発の潮流に追従するためのプラクティスなので、求められるツール群は必然的にクラウドネイティブ開発に必要なものとなる。

　具体的な機能としては、CI／CD（継続的インテグレーション／デリバリー）、ソースコード管理のGit、オブザーバビリティー、セキュリティーなどに関するツールやサービスが挙げられるが、これらの機能はコンテナと非常に相性がよいため、Kubernetesなどのコンテナオーケストレーターをプラットフォームのベースとして検討することを推奨する（OpenShiftもその一つ）。また、サポート環境に関してはプラットフォームをうまく活用するためのドキュメントや開発テンプレート、プラットフォームの情報を一元的に可視化するポータルなどが挙げられる。ポイントは「いかに開発者の認知負荷を軽減できるか」で、これがプラットフォームエンジニアリング成功のかぎとなる。

クラウドネイティブ時代の差別化要素となるスキルセット

――プラットフォームエンジニアリングは投資対効果を示すのが難しいといわれる。経営層の理解を得るためには何が必要か。

　これまでの共通基盤チームでは、本来発生する業務負荷を自動化や業務効率化でいかに削減できるかを第一に評価されてきたように思う。一方、プラットフォームエンジニアリングは「開発者体験を向上させるための投資」として考える必要がある。したがって、プラットフォームエンジニアリングチームの取り組みの評価点を経営層に正しく示さないといけない。開発者体験が向上すれば、リリーススピードや品質の向上、そして開発者の高い定着率の実現を見込むことができる。

　「開発チームの立ち上げから初回リリースまでの期間の短縮」「バグの発生から修正適用までの時間短縮」などを評価してもらえるよう訴求すると、プラットフォームエンジニアリングの取り組みを理解してもらいやすくなるだろう。コストに関しても「これまでと同じ人数で従来の2倍の数の新機能をリリースできた」など、プラットフォームエンジニアリングで得られる価値と組み合わせて効果を示すことが重要だ。（DevOpsの効果測定に用いられる）「DORAメトリクス」など、開発に関する重要な指標を日々計測しておくと、取り組みの必要性をより明確に伝えられる。

――プラットフォームエンジニアリング推進における“アンチパターン”として注意しておきたいことは。

　大きく二つある。一つは、クラウドネイティブ開発に必要なツールや機能だけを提供することだ。ツールを提供するだけでは、開発者はそれらのツールの利用法の理解に追われ、開発者体験が悪化し、誰も使わないプラットフォームとなりかねない。ツール提供だけでなく開発方法やサンプルとなるコードをあわせて提供することを重視してほしい。二つめは、一度構築したプラットフォームの機能をバージョン1.0で止めてしまうこと。従来のウォーターフォール開発の基盤では、前もって定義された要件を守り、安定した状態を維持しておけば問題なかった。しかしクラウドネイティブ時代になると、市場のニーズの継続的な見直しと機能改善が求められる。

――プラットフォームエンジニアリングを取り入れる企業が増えた場合、ITサービスを提供するパートナーにはどのようなスキルセットが求められるか。

　そもそもクラウドネイティブ開発／運用の世界はいまだに有識者の需要過多な状態だ。したがってパートナー企業にいきなり「プラットフォームエンジニアリング」を要求しても、従来の共通基盤の域を出ないものになったり、アンチパターンに陥る可能性が高い。プラットフォームエンジニアリングを導入する企業は、パートナーとともに試行錯誤しながらプラットフォームを構築する覚悟が必要だといえる。

　逆にパートナーは、顧客のクラウドネイティブ開発／運用を推進する体制が整っていることが大きな強みとなるだろう。社外研修やラーニングプログラムなどを活用してベースとなる技術を磨きつつ、実案件で顧客のプラットフォームを構築し、実践にもとづくノウハウを身につけることを推奨したい。これからのパートナー企業は顧客と同じ目線で開発者の課題に向き合い、改善策をプラットフォームに落とし込むための推進力が必要。契約の主従関係を引きずって顧客からの要望にただ応えるだけでなく、顧客の開発組織全体がよりよい方向に向かうための改善提案を能動的に行えることが、クラウドネイティブ時代のパートナー企業に求められる重要なスキルセットだといえる。


　「プラットフォームエンジニアリングはクラウドネイティブが前提」――まずはこの意識を開発者チーム、プラットフォームチーム、経営層で共有し、開発者の認知負荷を軽減する必要性を理解することが、プラットフォームエンジニアリングの第一歩となる。開発者のエクスペリエンス向上にフォーカスすることが企業全体の価値創出につながるというサイクルを正しく回し、さらに現場での実践を重ねながら、ツール提供にとどまらないプラットフォームエンジニアリングが普及することを望みたい。