Platform Engineeringの考え方と背景
Platform Engineeringとは、主にソフトウェア開発において、開発者が効率的にコードを作成・テスト・デプロイできるセルフサービス型基盤の構築・運用に焦点を当てた取り組みである。2022年のガートナーによるハイプ・サイクルに登場し注目を集め、2023年および2024年には戦略的テクノロジーのトップ・トレンドにも登場している。
Platform Engineeringは戦略的テクノロジーにおいて特に重要なトレンドと位置付けられている
四七（しな）氏はPlatform Engineeringが注目される背景として、クラウド技術の発展に伴い、アプリケーション開発者の負担が増大していることを挙げる。ただアプリケーションをデプロイするだけでも、設定ファイルをはじめとするさまざまな箇所に手を加える必要があり、「昔に比べてエンジニアのやるべきことが激増している」というのだ。
このような状況を踏まえ、海外では大手クラウド業者によるガイドライン整備が進んでいる。例えばMicrosoftやGoogle、AWSなどでは、それぞれがPlatform Engineeringについてのガイドラインを提示している。これらは「最終的に自社のエコシステムへ取り込むためのもの」だというが、「それでもなお、各社のPlatform Engineeringの考え方を比較してみると面白いだろう」と四七氏は話す。
日本の動向はどうだろうか。四七氏によれば、主に大手企業において適用・実践が進んでいる状況にあるという。例えばSONYや任天堂、メルカリなどでは、Platform Engineeringに対するそれぞれの指針が公表されている。とりわけメルカリは「単なる仕組みだけ、技術だけでなく、いわゆるチームトポロジー（※）も含めてPlatform Engineeringを実践しようとしている点で、他社より一歩進んでいるように感じる」と高く評価する。
※ チームトポロジー：ソフトウェア開発および運用チームの構成とその相互作用を最適化するためのフレームワーク
ここで四七氏は、Platform Engineeringが普及するために欠かせない要素へと話題を移した。
一般に、ソフトウェア開発の規模が拡大するにつれて「共通化」が進むのは自然の流れだ。しかしながら「次世代」「共通」「プラットフォーム」「基盤」といったネーミングで始動した多くの取り組みについて、「うまくいった試しがない」というイメージを持つ人は少なくない。なぜこれらは失敗に終わりがちなのだろうか。
四七氏は、主に3つの原因があると説明する。1つ目は、なぜプラットフォームを作るのかが曖昧なケースだ。とくに、目的についての共通認識がないまま「クラウドネイティブ」や「DevOps」「DX」などの“流行り言葉”に乗っかると、プロジェクトは確実に崩壊する。
2つ目は、技術自体が目的になってしまうケースだ。プロジェクトにおいては、発言権のあるキーパーソンが「これがベストなソリューションだ」と熱量で押し切ってしまうことがある。しかしこうした進め方では、キーパーソンが興味を失ったり、離脱したりするやいなやプロジェクトが頓挫してしまう。
3つ目は、開発自体が目的になるケースである。せっかくプロジェクトが発足しても、予算や期限のリミットに達すれば開発は終了、その後の運用や改善は顧みない──というやり方では、どれだけ良いプラットフォームが生まれても持続できなくなってしまう。結果として、開発自体が無駄に終わってしまうわけだ。
これらを避けるためには、「プラットフォームの利用者、つまりアプリ開発者の困りごとに向き合うしかない」と四七氏は語る。
「開発者を『顧客』と捉え、プラットフォームという『プロダクト』を提供するというPlatform as a Productの考え方が大切だ。期限のある『プロジェクト』ではなく、永続的・継続的にやっていく『プロダクト』として扱うことによって、アプリ開発者の課題と向き合い、認知負荷を軽減し、生産性を高める改善が継続できる」
四七氏はこう強調し、石川氏による「Platform Engineeringの実践に欠かせないアプリ開発者の課題」へとバトンをつないだ。
