プラットフォーム エンジニアリング チームにとって大きな問題は、「構築するのか、それとも購入するのか」ということです。
開発者がより多くのことを行えるよう支援する より短時間で行うことが組織にとっての優先事項となっています。 SaaS の範囲がますます広がり、DevOps の人気が高まるにつれ、企業は開発者の認知的負荷を軽減する必要があることに気づき始めています。開発者は多くの場合、利用可能なすべてのマイクロサービスを認識しなければなりません。
この問題は当初サービス カタログで解決されましたが、このカテゴリはより野心的なもの、つまり開発者がエコシステム内のすべてのマイクロサービスとツールにアクセスできるワンストップ ショップへと変化しました。
内部開発者ポータルと呼ばれるこのカテゴリは、開発者のエクスペリエンス、ひいては効率の向上を目指すソフトウェアを多用する企業で急速に注目を集めています。 によると フォレスターDevOps リーダーの 87% が、開発者の生産性向上が今後 12 か月間での優先事項であることに同意しました。
あたり ガートナー「これらのポータルにより、ソフトウェア エンジニアリングのリーダーは、ソフトウェアの再利用を増やし、開発者のオンボーディング エクスペリエンスを向上させ、ソフトウェアの配信を合理化し、知識の共有を促進する多用途の『アプリ ストア』を作成できます。」
しかし、これらの開発者ポータルは単独で誕生したわけではありません。 それらの出現は、別のトレンド、つまりプラットフォーム エンジニアリングの出現と密接に関係しています。
一言で言えば、プラットフォーム エンジニアリング チームとは、「組織内の他の開発者の開発者エクスペリエンスを向上させる役割を与えられた、通常は大規模な組織内のグループ」であると、Boldstart Ventures のパートナーである Shomik Ghosh 氏は TechCrunch+ に語った。
プラットフォーム エンジニアリング チームは、内部開発者ポータルと同様に、大規模な組織でますます一般的になってきています。 ガートナー 期待しています 2026 年までにソフトウェア エンジニアリング組織の 80% がプラットフォーム チームを持ち、2025 年までにプラットフォーム チームを持つ組織の 75% がエンジニアにセルフサービス開発者ポータルを提供すると予想されています。
内部開発者ポータルがなぜ、どのようにして誕生したのかをより深く理解するために、少し過去に戻ってみましょう。
カタログを超えて
社内開発者ポータルはプラットフォーム エンジニアリング チームにとって重要なツールですが、実際には両方の概念が完全に構想される前に登場しました。 実際、これらは DevOps をきっかけに生まれました。エンジニアは突然、自分が作成したコードをデプロイして運用するというタスクがますます増えていることに気づきました。 しかし実際には、そして運用環境においては、特定のマイクロサービスを誰が所有しているのかが不明瞭であることがよくありました。