Platform EngineeringはこれまでのSREやインフラチームと何が違うのか？

第2回　Platform Engineerの役割と、SRE、インフラエンジニアとのアプローチの違い

　近年急速に注目を浴びている「Platform Engineering」。本連載ではPlatform Engineeringとは何か、そのメリットについて解説します。第2回では、これまでのプラットフォームと何が異なるのか、および、インフラエンジニアやSRE（Site Reliability Engineer）などとの違いを解説します。

Platform Engineeringはプラットフォーム作りを成功に導く考え方

　Platform Engineeringの文脈でプラットフォームを語る際に、「これまでのプラットフォームと何が違うの？」という疑問を持たれる方は多いんじゃないかなと思います。

　従来の考え方との違いはズバリ、「プラットフォーム作りを成功させる考え方が含まれていること」にあります。そもそもプラットフォームの成功とは何か？ 逆に失敗とは何か。成功させるために必要な考え方とは何かを説明していきます。

　例えば、アプリ開発者がアプリをクラウド上に存在するサーバーにデプロイができないままローカル環境で開発を進めていたとします。いわゆるやりたいことはあるが、CI/CDパイプラインを構築することはアプリ開発者にとって認知負荷が高く、手がつけられていないような状況です。プラットフォームの提供者はそれらの課題を解決するためにCI/CDプラットフォームを提供しました。しかし、蓋を開けてみると提供されたCI/CDプラットフォームはアプリ開発者が不慣れな言語で作られており、アプリ開発者がメンテナンスもできない状態でした。さらに、プラットフォーム提供者側もプラットフォームを提供したきり放置状態になってしまい、結果としてアプリ開発者が自分達でメンテナンスしやすい別のCI/CDプラットフォームに乗り換えてしまいました。

　提供したプラットフォームが使われなくなってしまった背景として、問題点が2つあります。プラットフォーム提供者が、アプリ開発者のニーズを捉えきれていなかったことと、プラットフォームを提供したきりになってしまったことです。

　事前にアプリ開発者の馴染みのある技術をヒアリングして、アプリ開発者が望む形式で提供できていれば、プラットフォームは使用され続けたかもしれません。あるいは、プラットフォーム提供後に継続してメンテナンスを実施したり、アプリ開発者へCI/CDプラットフォームに関するナレッジのシェアを続けていれば、アプリ開発者はCI/CDプラットフォームで使用されている技術にキャッチアップできたかもしれません。アプリ開発者のことを考えず、プラットフォーム提供者側が持ち合わせている技術で作れる範囲のものを提供してしまい、さらには提供後に放置してしまった結果、プラットフォームが利用されずに終わってしまったという例です。

　例から、プラットフォーム開発もtoC向けのプロダクト開発と同様に「誰に」「何を」届けるかにこれまで以上に意識して行く必要があることがわかります。加えてプラットフォームを提供した後も、継続的に顧客が必要としている価値を提供できているかという視点に基づき、プラットフォームを更新・運用して行くことが重要です。

　このように、生まれたが定着せずに使われなくなって姿を消したプラットフォームは数多くあります。そのため、それらの失敗を教訓にしてプラットフォームの利用者が本当に求めているものは何であるかを考えて、利用者に長く使われるプラットフォームを作っていきましょう。

Platform Engineeringにおいて意識するポイント