プラットフォーム・エンジニアリングとDevOps

プラットフォーム・エンジニアリングと DevOps はいずれも、アジャイルソフトウェア開発の手法を使用する IT プラクティスであり、リリースまでにかかる時間を短縮し、開発の際の障壁を削減します。ただし、実行されるタイミングや対処する問題はそれぞれ異なります。その違いを理解すると、自社の目的に沿ったアプローチを選択するのに役立ちます。DevOps はソフトウェア開発へのアプローチで、組織が開発と IT 運用の機能を組み合わせて反復的なワークフローにするために使用します。一方プラットフォーム・エンジニアリングは、そうしたワークフローをサポートする社内プラットフォームとツールを作成することを指します。 

DevOps は 2 つの領域 (開発と運用) を、ツールとプロセスを使用して統合し、従来は組織内でそれぞれ分離していたチームを一つにします。DevOps ではアジャイルの原則を使用します。これはセルフマネージド型のチームとすばやい反復作業に基づくソフトウェア開発手法です。この手法を実行するにはチーム間の協力、部門横断型の業務、信頼と団結の構築が欠かせないため、DevOps は通常、単なるプロセスの変更ではなく、組織的な変化を必要とする手法であると考えられています。つまり DevOps を実現するには組織文化を変える必要があります。

DevOps とアジャイルの考え方は従来のウォーターフォール型ソフトウェア開発手法に対する批判から生まれました。特に、ウォーターフォール型開発はイノベーションを遅らせ、組織的な障壁やボトルネックを生じさせるとされました。ウォーターフォール型のシステムでは、コードがアプリケーションに統合される前に、コード要件の機能性、効率性、標準化、ドキュメント化がテストされます。こうした点を事前にテストしようとすると、プロセスキューが長くなり、プロジェクトのスコープや時間、予算を守ることが難しくなります。プロジェクトが不明確で流動的な場合は特にその傾向が強くなります

一方 DevOps では、自動化と循環型のプロセスを使用することで、開発チームはソフトウェアを開発から本番稼動へすばやく移行させ、さらに本番環境にあるソフトウェアを継続的に改善できます。DevOps は専門知識の共有を通じたチーム間の緊密なコミュニケーションとコラボレーションを必要とします。この取り組みがあるからこそ、製品の改善点の反復的な統合や開発が可能になります。これは従来のように、長いリリース間隔に合わせて事前に開発を行うのとは異なります。DevOps を導入した組織は、時間をかけて体系的にソフトウェアを改善できるため、チームは変化に適応しながら、従来の開発モデルでは避けられることが多かった方法で新しいアプローチを試すことができます。

プラットフォーム・エンジニアリングは、標準化されたツール、サービス、ワークフローを提供することで DevOps の取り組みを拡大し、開発チームがソフトウェア・ソリューションをより効率的に開発できるようにします。プラットフォーム・エンジニアリングは比較的新しい言葉です。社内のサービスとリソースを組織化して、開発チームがそうした基盤的要素を直接管理することなくソリューションを構築できるようにする手法を指します。プラットフォーム・エンジニアは開発チームに必要なさまざまなツール、サービス、ドキュメントをまとめて管理し、IT 組織のメンバーがすべてを実行しなくても、「Golden Path」と呼ばれる自動化プロセスを使用してより効率的に業務を完了できるようにします。プラットフォーム・エンジニアリングは、DevOps の導入が拡大するに従って成長してきました。プラットフォーム・エンジニアリングは DevOps のワークフローをサポートし、エンタープライズ組織での拡張を支援する基盤コンポーネントを提供しているためです。

Abby Bangser 氏は DevOpsDays London で、DevOps でのプラットフォーム・エンジニアリングの役割を、料理の比喩を使って説明しています。私たちがソフトウェア (食事) を「料理」するとき、ツール (フライパン) や材料 (パセリ) が必要になるとそれをリクエストできますが、正確に必要なものが手に入るとは限りません。プロビジョニングの担当者が必要な材料を提供できない場合や、リクエストしたものを手に入れられない場合があるためです。DevOps モデルでは、リクエストを申請したりプロビジョニングに依存したりすることから生じる不満は避けられますが、必要な材料やツールを自分で作成する必要があります。Bangser 氏の料理の比喩に従えば、フライパンを自分で金属から作ったり、パセリを種から育てたりしなくてはならず、いずれも困難で非効率的です。

このセルフサービスモデルでは、開発チームは日々の作業に必要なさまざまなテクノロジーを使いこなす必要があります。複数のツールセットを使うのは面倒で、効率性は失われ、チームメンバーの認知負荷による脳の疲労も増します。また、オンボーディングの課題も生じます。新規採用者は大量のツールやシステムを学ばなくてはならないため、新メンバーをチームに効率的に組み込むことができず、チームの上級メンバーが本来の仕事から外れてサポートに回る必要が生じることで生産性が落ちます。プラットフォーム・エンジニアリングはこうした負担を減らし、DevOps のワークフローをサポートすることを目標としています。それにより IT 組織はイノベーションに取り組み、プラットフォーム・エンジニアは IT 組織のためにベストプラクティスとセルフサービスのエクスペリエンスを一元化できます。

プラットフォーム・エンジニアリングの舞台裏動画の再生時間：2:31

プラットフォーム・エンジニアリングの詳細はこちら

プラットフォーム・エンジニアリングは DevOps チームがすべてをセルフサービスで行う必要をなくすことで、DevOps の拡張を支援します。プラットフォーム・エンジニアリングが一連の標準化されたツール、知識、サービス、プロセスの確立を支援し、組織全体の開発チームがそれを利用できます。調整されたプラットフォームを使用して開発チームがソリューションのコンポーネントをビルド、デプロイ、サポートする一方、プラットフォームチームはプラットフォームのコンポーネントをビルド、デプロイ、所有、サポートします。これにより、どちらのチームも自分たちの担当業務に集中し、より早く成果を出すことができます。プラットフォームチームが XaaS (サービスとしての X) を提供することで、DevOps チームがすべてをその場で作成する必要がなくなります。

しかし、プラットフォームチームが開発チームのためにコンポーネントを提供するのであれば、プラットフォーム・エンジニアリングは、DevOps が当初、軽減しようとした問題や社内の依存関係を生じさせる可能性があると思われるかもしれません。アプリケーションチームが、自分たちに必要なツールの提供をプラットフォームチームに頼っている場合、それがプロセスのボトルネックとはならないのでしょうか。

理論的にその可能性はありますが、一方でプラットフォームチームは冗長性と重複作業を削減できます。これらは大きな組織では時間の無駄になります。複数の開発チームが同じ機能を持つプラットフォームをそれぞれ独自に作成する代わりに、1 つのセルフサービス・プラットフォームを使用できるようになれば、既存の開発チームが現在のプロジェクトの担当を外れたとしても、長期的にプラットフォームの一貫性を保つことができます。また、プラットフォームチームは開発チームを顧客ととらえているため、自分たちがターゲットユーザーのニーズに応えられなければ、そうした社内顧客たちが別のインフラストラクチャや開発メカニズムを使用するようになると理解しており、これが迅速に成果を出すためのモチベーションになります。ベストプラクティスと確立されたソリューションがプラットフォームに提供されることで、両チームは知識を効果的に共有できます。

プラットフォーム・エンジニアリングは、SRE (サイト信頼性エンジニアリング) を知っている人にはなじみ深い言葉かもしれません。SRE は Google が業界に導入した言葉で、従来はシステム管理者が行っていた手作業に代わり、オートメーションで製品を実行するシステムを指します。SRE は基盤となるインフラストラクチャを管理し、SRE チームはプロセスと自動化を開発してインフラストラクチャの完全性と可用性を確保します。SRE の実行者とプラットフォーム・エンジニアの目標は同じですが、SRE がソフトウェアのパフォーマンス、信頼性、スケーリングを重視しているのに対し、プラットフォーム・エンジニアリングは開発者の効率や使い勝手の向上を目的としたシステムに重点を置きます。

Red Hat の SRE へのアプローチについてさらに詳しく

チームは通常、プラットフォーム・エンジニアリングを使用して、セルフサービスポータルで独自の社内開発プラットフォーム (IDP)、ツール、サービス、ドキュメントを作成します。プラットフォーム・エンジニアはユーザーのニーズとベストプラクティスに応じて IDP を設計および提供し、ユーザーへのリサーチやテストを通じてプロセスを反復します。開発チームがそのターゲットユーザーであることから、プラットフォーム・エンジニアは開発者がセルフサービスで作業でき、開発者チームの認知負荷を軽減する IDP を提供できます。

ソフトウェア開発サイクルで継続的インテグレーションと継続的デリバリー (CI/CD) の確立を目指している組織は DevOps の取り組みを導入する必要があります。CI/CD はコードのテストとビルドを自動化することで、バグやコードの不具合による影響を最小限にします。ソフトウェア開発と更新のサイクルが継続的に統合されているためです。ソフトウェア開発ライフサイクル全体で CI/CD パイプラインの統合と自動化を行うことで、組織は高品質なプラットフォームの構築とアプリケーションの迅速な提供に必要な可視性を得ることができます。

Red Hat® の製品とサービスは連携して開発者の生産性をサポートし、企業がチームの生産性を高めるのに必要な柔軟性を提供できます。これによりセルフサービスを推進し、オンボーディングを効率化し、チーム全体で反復的作業を削減できます。

Red Hat Developer Hub は企業の社内開発者向けポータルであり、Cloud Native Computing Foundation (CNCF) のプロジェクトである Backstage を基盤としています。Red Hat Developer Hub は組織が選択したテクノロジーを集約し、セルフサービスとオンボーディングを促進し、生産性を向上させるのに役立ちます。Red Hat Developer Hub を利用することで、組織は内部開発者向けプラットフォームを使用して開発プロセスの要素を統合し、ワークフローを最適化し、社内コラボレーションを強化できます。

Red Hat Developer Hub に加え、Red Hat OpenShift® では、オンプレミス、クラウド、エッジなどのデプロイ場所を問わず、クラウドネイティブ、レガシー、モダナイズされたアプリケーションなどのさまざまなアプリケーションで信頼できるツールを使用できます。