プラットフォームエンジニアリングとは? | CircleCI
から引用。
「プラットフォームエンジニアリングとは？
プラットフォームエンジニアリング(Platform Engineering)とは、最近生まれたエンジニアリング手法です。モダンなソフトウェアデリバリーが抱える複雑さと不確実性を減らし、開発者の生産性を向上させることに重点を置いています。DevOps を大規模に実施する場合、開発の都合とビジネス上の優先順位をすり合わせたり、アプリケーションライフサイクル全体にわたって複雑に入り組んだツールやインフラストラクチャを手間なく管理可能にしたりといった、大きな課題が発生します。しかし、プラットフォームエンジニアリングを導入することでこれらの課題に対処できます。
プラットフォームエンジニアリングでは、プラットフォームチームがインフラストラクチャの管理を自動化し、一元管理されたテクノロジープラットフォームから信頼の置けるツールやワークフローを開発者がセルフサービスで利用できるようにします。このように開発チームの認知負荷を低減させることで、クラウドネイティブなソフトウェアデリバリーに大きな進化がもたらされます。
プラットフォームエンジニアリングの価値
プラットフォームエンジニアリングがソフトウェア組織にもたらすメリットは、運用の複雑さが軽減されることと、開発プロセスの摩擦が解消されることです。これまでは、開発した人が運用すべきという考え方があり、大規模な分散アプリケーションをクラウドに構築する場合に混乱やムダが生じていました。プラットフォームエンジニアリングは、この状況を変える堅実な考え方です。
プラットフォームチームの役割には、大きく分けて以下の 4 つの領域があります。
- 内部開発者プラットフォームの構築
- 重要なデリバリープロセスの標準化とセキュリティ確保
- 社内のサービスレベル アグリーメントの設定と順守
- チームのパフォーマンスメトリクスの監視
以下では、上述のプラットフォームエンジニアリングの各分野の詳細と、それらが開発プロセスにもたらす価値について見ていきます。
内部開発者プラットフォーム (IDP)
プラットフォームチームの最も重要な仕事の 1 つは、内部開発者プラットフォーム (IDP) を構築して、保守することです。IDP とは、組織全体でソフトウェアプロダクトの開発とデリバリーをスピーディに行うためのツール、サービス、自動化ワークフローを 1 つのプラットフォームにまとめたものです。IDP では、アプリケーションの構成やインフラストラクチャの管理の手間をサービスレイヤーで抽象化します。
重要なポイントは、IDP があることで、アプリケーションをすばやくスムーズに構築、テスト、デプロイ、監視するためのリソースを開発者がセルフサービス形式で利用できるようになることです。つまり、運用チームにインフラストラクチャをプロビジョニングしたり、チケットを解決したりしてもらう必要なく、クラウド環境のスピンアップ、テストやデプロイを自動化する CI/CD パイプラインのトリガー、ロールバックの実装、ログとビルドアーティファクトへのアクセスなどを、1 つの API や GUI から簡単に行えるのです。
プロセスの標準化と認知負荷の軽減のための “舗装道路”
プラットフォームエンジニアリングでは、一般的な DevOps のプロセスとワークフローを管理、標準化、拡張するための統合システムを用意します。つまり、リソースのカタログを吟味、整理することで、開発の手間を減らしスピードを高める “舗装道路” を構築するのです。この “道路” には、必要なときに好みのツールを使える自律性を開発者に与える効果もあります。
何百人、何千人もの開発者を擁する大組織では、自律性を与えすぎると、ツールの無秩序な増大、知識のサイロ化、コストの急騰、燃え尽きといった弊害が発生する可能性があります。”舗装道路” は、そのような弊害を発生させることなく開発チームが抱える運用の負荷を減らすことができる、実績ある確実な手法です。さらに、セキュリティ、コンプライアンス、予算管理の強化にもつなげることができます。
社内のサービスレベル アグリーメント (SLA) の設定と順守
プラットフォームチームにとって、IDP は商品であり、開発者は顧客です。IDP の導入を広げるために、サービスレベル アグリーメントで IDP の信頼性とパフォーマンスに対して高い期待値を設定し、チームが負う責任を明確にします。
IDP を安定かつセキュアに保つことは、プラットフォームエンジニアの重要な仕事です。内部システムに障害が発生すると、”舗装道路” に従わない開発者が増えるだけでなく、外部顧客に価値を提供するフローに中断が起きるおそれもあります。そのため、プラットフォームチームは、開発者の生産性と組織の顧客の満足度を維持するために、IDP の正常性とパフォーマンスを能動的に監視します。
重要なパフォーマンスメトリクスの監視
プラットフォームチームは、ボトルネックの解消や開発者のニーズに応じたプラットフォームのカスタマイズのために、スループット、ワークフローの実行時間、インシデントの復旧時間などの重要なエンジニアリングパフォーマンスメトリクスを追跡します。そして、たとえば復旧時間が基準値を超えるようになった場合には、パイプラインへの自動テストの追加や、IDP に用意している監視機能やアラート機能の改善などの対策を試します。
また、開発者の生産性やパフォーマンスに関連するデータを追跡することで、IDP が組織の開発パターンやビジネス目標に適切に対応しているかどうかも確認できます。
プラットフォームチームは必要？
多数のチームで複雑なエンジニアリングが必要とされる大規模な分散プロジェクトを進めている場合や、部門横断型のチームを編成してアプリケーションの開発、運用、インフラストラクチャを監督している場合には、おそらく何らかの形で暫定的なプラットフォームエンジニアリングを行っていることでしょう。そのような場合には、プラットフォームチームの編成を検討することをお勧めします。
プラットフォームチームの編成をお勧めする状況は他にもあります。組織に成熟した製品がある、将来に対する明確なビジョンがある、業務の規模を拡張する準備ができている、といった状況です。
また、エンジニアリングチームがクラウド統合とインフラストラクチャ運用に取り組んでいる場合も、プラットフォームチームが必要な可能性があります。検討するうえで重要となる前提条件は、各チームメンバーの役割と責任を明確に理解したうえで、エンジニアリングチームのワークフローが詳しく定義されていることです。エンジニアリングチームのサイズやプロダクトの成熟度は、必ずしも重要ではありません。規模の拡大に伴って、いずれプラットフォームチームが必要になるからです。
一方、組織規模が小さく、少人数の開発者でモノリシックアプリケーションを開発している場合は、プラットフォームチームを編成しても大きなメリットを得られる可能性は低いと考えられます。まずはプロダクトマーケットフィットの達成に注力し、反復タスクを自動化して、開発者がイノベーションに集中できる体制を整えましょう。アプリケーションを個別のサービスに分け、複数のエンジニアリングチームが異なるバリューストリームでデリバリーする段階に達したら、プラットフォームチームを編成すると、スピードと安定性の最適なバランスを実現するのに役立ちます。
CI/CD を使ったプラットフォームエンジニアリング
どのようなプラットフォームチームでも備えておくべきツールとして、堅牢な継続的インテグレーション & 継続的デリバリー (CI/CD) パイプラインが挙げられます。CI/CD パイプラインは自動化エンジンを備えており、テンプレート化されたワークフローをトリガーして開発環境、QA 環境、ステージング環境、本番環境でコードのビルド、テスト、デプロイを行うことができます。より概念的に言えば、成熟した CI/CD パイプラインとは、開発においてビジネス上の優先事項のコード化、適用、測定を行うコントロールプレーンの役割を果たすものです。
CircleCI には、プラットフォームチームが重要な開発タスクを自動化したり、効率化したりするうえで役立つ機能が数多く用意されています。たとえば、CircleCI Orb は移植性に優れた再利用可能な構成コードのスニペットです。Orb を使用すると、人気のツールやサービスをワークフローに簡単に統合したり、一般的なプロセスを複数のプロジェクトで共有したりできます。また、設定ファイルのポリシー管理機能では、グローバルなルールを設定することで、組織のすべてのパイプラインに同じ規則とセキュリティポリシーを適用できます。
Insights ダッシュボードでは、パフォーマンスを視覚的に確かめられます。これを活用して、改善が必要な領域をすばやく特定し、効率が最大になるようにパイプラインを最適化できます。表示される情報には、実行時間が長く頻繁に失敗するワークフローの時系列データ、リソース使用率、クレジット使用量などがあります。それらの情報から、パイプラインで開発者が求めるスピードや今日の企業が必要とするコスト効率を実現できているかどうかを把握できます。
CI/CD には、開発者の作業効率を高め、開発プロセスを改善する力があります。プラットフォームエンジニアリングツールの中核を担い、セルフサービス機能や再利用性など、プラットフォームエンジニアリング手法の重要な要素を形にできます。
まとめ
プラットフォームエンジニアリングは、品質、セキュリティ、効率のいずれも犠牲にすることなく、ソフトウェアデリバリープロセスをスケールアップできる強力なツールです。リソースのプロビジョニングと管理が簡素化および自動化されるので、開発者は今までよりも短時間で、より多くの価値を顧客に届けることができるようになります。
組織としては、プラットフォームチームを編成することで DevOps のメリットを享受し、高めることができます。その結果として、開発者のアジリティが強化され、組織の信頼性、可視性、自信も高まります。組織のパフォーマンス向上のためにプラットフォームエンジニアリングを導入すべき状況にあるなら、ぜひ CircleCI に無料でユーザー登録して、業界トップクラスの継続的インテグレーションサービスが反復サイクルの高速化とデリバリー成果の強化にもたらす効果を実感してください。
」
https://x-tech.pasona.co.jp/media/detail.html?p=9594#
から引用。
「
プラットフォームエンジニアリングとはなにか？
そもそもプラットフォームエンジニアリングとは、どのような意味を持つ用語なのでしょうか。ここでは2つの観点から概要を解説しますので、イメージをつかんでください。
開発者がアプリケーション開発環境を自律的に作成できる
プラットフォームエンジニアリングは、開発者がクラウド環境において、アプリケーションの開発環境を自ら作成できる仕組みを提供します。セルフサービスで使えるツールや環境の自動化は、代表的な項目です。
インフラに関する多種多様な知識を、開発者が覚える必要はありません。またシステムの運用部門やインフラ部門による環境構築を待つ必要もありません。開発者自身が簡単に開発環境を構築できるため、適時適切なタイミングでソフトウェアを提供できることは大きなメリットです。
専門のチームが作られ、ツールが提供される場合もある
プラットフォームエンジニアリングを実現する目的で専門のプラットフォームチームを設け、開発チームを助ける場合があります。プラットフォームチームは内部開発者プラットフォーム（IDP）をつくり、アプリケーションの開発者に対してツールを提供します。
これにより多くの開発者はインフラを気にせず、アプリケーションの開発に集中できるわけです。数十人規模のプロジェクトでも、プラットフォームチームやIDPは役立ちます。目立たない役割であるものの、迅速なシステムの提供には重要です。
プラットフォームエンジニアリングが求められる3つの背景
<picture> </picture>クリックして拡大
プラットフォームエンジニアリングが求められるようになった背景は、3つあります。いずれも現代の開発現場における重要な項目が関連しています。時代にこたえる手法であることを確認してください。
クラウドサービスの普及
かつての環境構築は高価なハードウェアを用意しなければならず、作業も大変でした。ハードウェアの設置はもちろん、メモリなど部品を取り付けることは、インフラエンジニアのおもな作業です。専門性が高い業務であるため、インフラ業務はインフラエンジニアに任せるケースもよくありました。
クラウドサービスの普及は、この状況を変えました。インフラエンジニアでない方でも画面で必要な設定を行ない、開発に必要なサーバーをセルフサービスで用意できます。また高価なハードウェアを用意しなくても、必要な期間だけ使えば良いため価格も抑えられます。多くの開発者が環境づくりに携われるようになったことは、おもな背景の一つです。
スピーディーな開発が求められている
情報化が進んだ結果、多くの業務を迅速に進められるようになり、より速く情報を提供できるようになりました。社会全体のスピード化により、変化に対して迅速な対応が求められます。システム開発においても、より短い期間で充実した機能を提供する必要があるわけです。
開発環境の構築を専門のエンジニアに任せず、簡便化した方法で自ら行なうことは、開発期間の短縮につながります。このことも、プラットフォームエンジニアリングが求められる背景に挙げられます。
ITエンジニアの不足
慢性的なITエンジニアの不足も、プラットフォームエンジニアリングが求められる背景の一つです。人が足りないからといって、システムに求められる品質は下がりません。むしろIT技術の進化にともない、求められる品質は上がっています。
皆さまのなかには、「人が足りないならば、優秀なエンジニアを多く採用しよう」と考える方もいるかもしれません。しかし優秀なエンジニアやフルスタックエンジニアは特に不足しており、各社で取り合いとなっているため、思うように人を採れない企業も多いことでしょう。
開発エンジニアに比重を置いた採用をするならば、できるだけ開発業務に専念できる仕組みづくりが必要です。インフラの手間を軽減する仕組みが求められるでしょう。
DevOpsやSREとの相違点
よく使われる開発の手法には、DevOpsやSREなどが挙げられます。プラットフォームエンジニアリングとの相違点に加えて、どのような課題を解決しているのかについて確認していきましょう。
DevOpsよりも開発者の役割を軽減できる
DevOpsとプラットフォームエンジニアリングは、効率的な開発により生産性を上げる点が共通しています。一方で開発者への負担は異なります。DevOpsでは、環境構築にかかる負担が開発者にのしかかるためです。開発業務を行ないながら、環境構築や運用に関する多種多様な業務をこなさなければなりません。優秀なエンジニアは他のエンジニアの支援を行なわなければならず、パフォーマンス低下の要因となりかねません。
プラットフォームエンジニアリングでは、開発者の負担軽減がコンセプトです。専門のチームやIDPなどの活用により、開発業務に集中して取り組める環境を提供できます。
SREとは着眼点が異なる
SRE（サイト信頼性エンジニアリング）とプラットフォームエンジニアリングは、着眼点が異なります。SREの目的は、プロダクトやサービスの信頼性を上げることです。品質の向上により開発期間の短縮につながる可能性はありますが、おもな目的ではありません。
一方でプラットフォームエンジニアリングは、効率的な開発を目的としています。環境構築の標準化・簡素化により、品質アップにつながる可能性はあります。しかしおもな目的は開発者の負担を軽くして、開発業務にリソースを集中させることです。
プラットフォームエンジニアリングを活用する4つのメリット
<picture> </picture>クリックして拡大
プラットフォームエンジニアリングの活用により、さまざまなメリットが得られます。おもな4つの項目について、どのようなメリットがあるか確認していきましょう。
開発期間を短縮でき生産性も向上する
開発期間を短縮でき生産性も向上できることは、おもなメリットの一つです。IDPの活用により、開発環境の構築においてプラットフォームに強いエンジニアの手を煩わせる必要がありません。待ち時間がなくなることで開発期間を短くできるとともに、優秀なエンジニアへの集中を防ぎ開発業務に専念させることで生産性が上がります。
また開発業務の多くで、自動化技術が採用されるでしょう。標準化される業務も増え、短期間でのリリースが可能となります。本番環境への移行が楽になることは、代表的なメリットの一つです。
保守開発も迅速に実施し顧客に提供できる
どれだけシステムを完璧に作ったとしても、環境の変化に対応するなどの理由で修正が入ることは避けられません。このような保守開発のフェーズにおいても、プラットフォームエンジニアリングならば迅速に実施し、顧客に提供できます。開発者は数回のクリックにより、現在の環境に適したシステムを作成できるためです。環境作成の手間が減り、少ない作業で短期間での対応が可能となることは大きなメリットといえるでしょう。
経験の少ないエンジニアでも開発現場で活躍できる
プラットフォームエンジニアリングでは、さまざまな自動化技術が活用されています。開発環境や開発業務の遂行における業務の多くが自動化されます。覚えるべき項目が減るため、スキルによる差は縮まることでしょう。
このため経験の少ないエンジニアであっても即戦力になりやすく、開発現場での活躍がしやすくなります。しかるべき品質のソフトウェアを作りやすくなることも、メリットといえるでしょう。
優秀なエンジニアをレベルの高い業務に集中配置できる
優秀なエンジニアをレベルの高い業務に集中配置できることも、見逃せないメリットに挙げられます。そもそも慢性的な採用難のなか、優秀なエンジニアの確保や育成は簡単ではありません。エンジニアの負担を軽くする工夫が必要ですが、DevOpsでは開発以外のさまざまな業務に時間を割かれがちとなり、逆に優秀なエンジニアほど忙しくなる事態を招きかねません。
プラットフォームエンジニアリングならば、開発以外の負担を軽減する仕組みが整えられています。高いレベルのエンジニアがさまざまな業務に忙殺されることを防ぎ、難しい業務を集中して任せられるため、人材の有効活用も行なえるでしょう。
顧客にフィットするシステムを迅速に開発できる方法
プラットフォームエンジニアリングは、顧客にフィットするシステムを迅速に開発できる方法です。この方法は新規開発だけでなく、保守開発にも有効です。ツールの活用により、限られた人材を開発業務に集中させることが可能となります。適時適切なソフトウェアの提供につながり、より良いビジネスにつながることでしょう。
これは近年よく聞かれる「フルスタックエンジニア」と逆行する動きのように見えますが、エンジニアのキャリアパスが多様化する現れともいえるでしょう。一般の開発エンジニアがインフラを意識しなくて良い時代となれば、開発スキルをより一層磨き続ける必要に迫られそうです。」
だとよ。
