Red Hat Summit概要
プラットフォーム・エンジニアリングは、生産性、アプリケーションのサイクルタイム、市場投入スピードの向上に重点を置くソフトウェア開発の分野の 1 つです。
プラットフォーム・エンジニアリングは、労働文化と生産性を改善し、収益にプラスの影響を与えるための多専門的アプローチと捉えるべきものです。ビジネスの観点から見ると、プラットフォーム・エンジニアリングのプログラムは、アプリケーションの市場投入を効率化し、運用を最適化し、アプリケーションの開発、デプロイ、管理、保守の効率を向上させます。文化的な観点から見ると、プラットフォーム・エンジニアリングは、開発者が自身の仕事の中で最も重要な部分に集中するために必要なツールとサポートを提供することで、チーム間のコラボレーションを向上させ、認知的負荷を軽減することを目的としています。
プラットフォーム・エンジニアリングの包括的な目標は、開発チームに影響を与える問題点を特定し、内部開発者向けプラットフォーム (IDP) を介して共通の再利用可能なツールと機能を提供することでそれらの問題を軽減することです。
プラットフォーム・エンジニアリングとは
プラットフォーム・エンジニアリングは特定の職務内容である場合もありますが、個人のグループがチームのイニシアチブとして取り組む分野や手法である場合もあります。
プラットフォーム・エンジニアリングの役割は、一貫性と効率性を促進するという点で組織にとって有益です。チーム間の連携をより効率的にすることで、チーム間のより良いコラボレーションを促進し、新しいチームメンバーの学習を容易にします。
根本的には、プラットフォーム・エンジニアリングの目的は、開発者の生産性を妨げ、アプリケーション・ライフサイクルにおいてボトルネックを生み出す可能性がある管理タスクに必要とされる時間を削減することです。これを実現するために、プラットフォーム・エンジニアとプラットフォーム・エンジニアリング・チームはインフラストラクチャの管理と、開発者のニーズに対応できるように設計されたワークフロー (「Golden Path」とも呼ばれる) を通じて開発者を導く一連のツールの作成を担います。
開発チームが異なれば (同じ企業内であっても) ニーズも異なり、同じ開発者プラットフォームは 2 つとありません。プラットフォーム・エンジニアはこれを理解し、ソフトウェア開発者を支援するセルフサービス機能と自動化されたインフラストラクチャを通じて、組織固有のニーズに合わせてカスタマイズされたツールとプロセスのセットを厳選します。この適応性により、開発者は画一的なソリューションに縛られることなく、プロジェクト要件に最適なツールを使って作業することができます。同時に、これによって開発者が新たなスキルセットを習得して余分な作業を行う必要性が減り、最も得意とする作業である「コード」に集中できるようになります。
また、プラットフォーム・エンジニアリング・チームは堅牢なガバナンスフレームワークを導入し、すべての環境にわたってリソース、セキュリティ、コンプライアンスの制御性を維持できるようにします。これにはパフォーマンスを監視し、コストを追跡し、潜在的なリスクや脆弱性を特定するためのより実践的な方法が提供されるという追加のメリットもあります。
プラットフォーム・エンジニアリングの舞台裏動画の再生時間：2:31
Red Hat のリソース
プラットフォーム・エンジニアリングが生まれた背景
プラットフォームエンジニアリングは、テクノロジー分野における新たな議論に反応するかたちで登場しました。それは、「インフラストラクチャは、ハイブリッド環境やマルチクラウド環境の場合は特に、開発者が心配すべきものではない」という議論です。
従来、開発者の仕事は、必要な作業に適したツールを見つけるか、そのツールをゼロから構築するかのどちらかでした。以前のような、テクノロジーの基本的な反復作業はそのような仕事に対応していましたが、エンタープライズレベルの組織で働く現在の開発者は、ビジネスが成長するにつれて、ユーザーのサポートと効果的なスケーリングがより複雑で断片化していることを認識しています。
新しいツールが毎日リリースされ、把握しておくべき新しい機能が常にあり、仕事に適したツールの評価と選択には時間がかかります。こうした時間は新しいツールに関するスキルの習得、新しいテクノロジーの調査、インフラストラクチャおよびアプリケーションサービスのリクエスト、最新のセキュリティ脅威の理解に費やされ、多くの精神的エネルギーとリソースを浪費し、販売されている製品の改善やビジネス上の優先事項の達成に充てる時間が奪われてしまいます。
内部開発者向けプラットフォームとは
プラットフォーム・エンジニアリングの領域では、開発者が顧客の場合、内部開発者向けプラットフォーム (IDP) は製品です。
IDP はプラットフォーム・エンジニアリング・チームによって設定され、開発者がアプリケーションのライフサイクル全体を通じてコードを作成、デプロイ、保守するために必要な、標準化された一連の内部セルフサービスツールとテクノロジーで構成されます。IDP に統合されたツールチェーンは、開発者向けのよりポジティブで生産的なワークフローを実現し、セキュリティやスケーラビリティなどの要素に重点を置き、最終的に組織はより多くの顧客価値を生み出すことができます。
効果的な IDP を作成することで、開発者エクスペリエンスにおける摩擦を能動的に探し、その摩擦を除去または緩和できるツールやテクノロジーを厳選することができます。最小限のアプローチから始めて、開発チームにとって有益であることがわかっているツールのみを組み込み、途中でフィードバックを求めながら、開発チームのニーズに合わせて機能を段階的に拡張し、進化させることができます。
プラットフォーム・エンジニアリングと DevOps
DevOps と同様、プラットフォーム・エンジニアリングも、自動化とコラボレーションの強化によって開発者と運用担当者の連携を高めるという共通の目標を共有しています。2 つの手法の関係を考えるとき、プラットフォーム・エンジニアリングは、組織全体で DevOps を拡張するという課題に対処するための重要かつ補完的な要素であると考えることができます。
従来、DevOps 手法では開発者が自分でソフトウェアを探し、学習し、デプロイし、管理することを奨励しているため、プロダクションのソフトウェアについて開発者がより多くの知見を得ることができ、制御性が向上します。しかし、これは必ずしも収益にメリットをもたらすとは限らず、開発者の管理オーバーヘッドが追加され、認知的負荷が増加します。
あるチームは、機能を提供することに関心があっても、スキルセットを持たないかもしれません。スキルセットを持っていても、それを構築することに関心がないかもしれません。スキルや関心を持っていても、そのアイデアを実行するのは安全ではなかったり費用対効果が良くなかったりするかもしれません。こうしたことはすべて、組織の拡大と成長に伴ってさらに複雑になります。
DevOps と継続的デリバリーの導入により、パイプラインとツールチェーンが長くなっており、さらに、「シフトレフト」(アプリケーションの作成および保守時にワークフローの各段階のセキュリティ保護についてエンドツーエンドで理解すること) というプレッシャーが加わったことにより、開発者は自身が構築しているアプリケーションに関連する複雑さを細部までより詳細に理解する責任を負うようになりました。
この自律性は「自由にできる」という感覚を開発者に与えますが、最終的には個人にも組織にも役に立たない、開発者を消耗させる責任感や認知的負荷をもたらす可能性もあります。
戦略としてのプラットフォーム・エンジニアリングは DevOps に基づいて構築されますが、それは、共感とユーザージャーニーをより重視することと、アプリケーション提供の自動化やコラボレーションとコミュニケーションの改善、エラーの削減、セキュリティとコンプライアンスの強化、効率の向上、そして、最も重要なことに、最も重視するべき開発者の強みに改めて焦点を当てる、といったことを実行するためのより良い方法を見つけることで実現します。
プラットフォーム・エンジニアとサイト信頼性エンジニア (SRE)
プラットフォーム・エンジニアリングとサイト信頼性エンジニアリングはいずれも、システムの作成と保守に関するものです。2 つの概念の違いは、それぞれの手法の焦点にあります。SRE は IT 運用チームに焦点を当て、ソフトウェアをツールとして使用してシステムの管理、問題解決、および運用タスクの自動化を行えるよう支援します。
プラットフォーム・エンジニアは開発チームに焦点を当て、システムの管理、問題解決、および開発タスクの自動化のためのプラットフォームの作成を支援します。
Red Hat 公式ブログ
Red Hat のお客様、パートナー、およびコミュニティのエコシステムに関する最新の情報を入手しましょう。
