DASA Platform Engineering の認定資格をもらったので Platform Engineering が何かを改めてまとめてみた

はじめに

先日、DASAの認定資格研修である「DASA Platform Engineering 研修」を受講しました。

実は、プラットフォームエンジニアリング (PFE) について、新卒入社時に研修の一環でサーベイしたことがありました。

その時の記事はこちらです：

5分でわかる！プラットフォームエンジニアリング

この調査をしていた経緯もあり、「Hisaさんも受けてみない？」と声をかけていただいて、この認定研修を受講させていただきました。受講者が国内にはほぼいない状態で、クリエーションラインから日本語版のトレーニングを提供したため、国内で数番目にこの認定資格を取ることができました。

今回は、このような貴重な学習をさせていただいたので、その研修で学んだ内容の一部を皆さんにも共有したいと思います。

なお、上記の記事で記した内容については理解している前提で本記事を執筆しています。まだご覧になっていない方は、先に読んでいただく方が本記事の内容をより理解できると思います。

そもそもプラットフォームとは？

プラットフォームとは、このようなコンテキストの相違点が少ない共通で利用できるセルフサービスの基盤のことです。

例えば、空港では複数の航空会社が保安検査場やボーディングブリッジといった共通基盤を利用していますね。これらの基盤を利用する業務は、手続き上のコンテキストの相違が少ないのが特徴です。

このような、コンテキストの相違点が少ない「API、ツール、サービス、知識、サポート」などのソリューションを提供するプロダクトがプラットフォームです。

そして、プラットフォームとして提供されるプロダクトはセルフサービスであることが重要です。セルフサービスとは、開発者が他部門の助けを借りずに迅速かつ簡単にリソースを利用できるようにする仕組みや考え方を指します。ユーザーとなる開発者がセルフサービスとして利用できることで、自律的な利用が可能となる一方、実際に開発者が使いやすいと思うプロダクトとして提供していく必要があるところが、PFEの難しいところです。

ただ、ガートナーの予測では、ソフトウェアエンジニアリング組織におけるプラットフォームチームの設立割合は、2022年の45%から2026年までに80%に増加するとされています。プラットフォームの重要性は今後も高まり、なくてはならないものになるかもしれません。

そんなわけで、大切になってくるのがプラットフォームエンジニアリングです。

プラットフォームエンジニアリング（PFE）とは？

PFEは、適切な内部開発者プラットフォーム（IDP）を提供し、調整などのオーバーヘッドを減らすことで、デリバリー速度と開発者体験を向上させる活動を指します。IDPは、開発者がアプリケーションのビルド、テスト、デプロイ、運用をより自律的に行えるよう支援する社内向けプラットフォームで、デベロッパーポータル、CI/CDパイプライン、IaC基盤、Observabilityツール、セキュリティポリシーなどで構成されます。開発者体験とは、開発者が直感的で使いやすいUI/UXや整備された「ツール、ドキュメント、信頼性の高い基盤」を通じて、ストレスなく効率的・生産的に働き、迅速に価値を届けられる環境や状態のことです。

PFEという単語の定義は様々あり、ほとんどの定義で上記の内容が当てはまります。今回受講した認定研修を提供しているDASAは、PFEを以下のように定義しています：

プラットフォームエンジニアリングは、DevOpsの原則に基づいて構築されたプラクティスであり、安全で統制されたフレームワークの中で、開発者体験とセルフサービスを改善し、各チームのセキュリティ、コンプライアンス、コスト、ビジネス価値実現までのリードタイムを改善を目指すという、プロダクト思考のマインドセットをサポートするツールとシステムの集合体です。

DASAの定義なので、PFEをDevOpsのプラクティスの1つとして定義されていますね。開発者・開発チームが共通で利用できる、コンテキストの影響が大きくない部分の中心的なハブとしてプラットフォームを提供し、さまざまなツールなどを提供することで、手動ワークフローとリリースの「Glue（接着剤）」となるよう自動化と合理化を行い、デリバリの効率・信頼性を高めることを目指すという趣旨が述べられています。

ここから、DASAの定義をベースに、PFEの利点や役割について紹介します。

PFEの役割

プラットフォームエンジニアは、開発チームと密接にコラボレーションすることが大切です。IDPを通じて、開発者がより速く、効率的に開発できるように支援するために、開発者が使いやすさを後押しする「Advocate (アドボケート) 」としての役割を担う状態を作り出し、開発者体験の継続的な改善を目指します。

具体的な役割は以下の通りです:

• ゴールデンパスのキュレーション・デザイン:
  開発者のための効率的で実績のあるワークフローを構築するため、ツールチェーン、ワークフロー、ドキュメント、開発者体験、ポータルなどを統合します。
• ガードレールの設定:
  開発者が効率性、セキュリティ、スケーラビリティのベストプラクティスに沿って作業できるように、安全で統制されたフレームワークを提供します。
• ステークホルダーの調整:
  ビジネス、コンプライアンス、セキュリティ、開発者のニーズのバランスを取り、標準化されたワークフローやツールチェーン、ベストプラクティスを通じて連携を図ります。
• アーキテクチャの高速化とサポート:
  IDPプロダクトを通じてベストプラクティスの採用を加速し、アプリケーションがプロダクション環境に耐えられるように構築されることを保証し、スケーラビリティ、可用性、デプロイメント、ディザスタリカバリー、オブザーバビリティを強化します。

PFEの利点

PFEは組織に多大な利益をもたらします。目的としている開発者体験の向上はもちろんですが、ビジネス上の収益への貢献や組織の成長にもつながります。ここから、各項目について記述していきます。

開発者体験の向上

• 複雑さの抽象化（カプセル化）:
  複雑なインフラやクラウドの概念をシンプルなインターフェースに簡素化し、開発者が基盤となるインフラの複雑さではなく、アプリケーション開発に集中できるようにします。
• 新規開発者の立ち上がり速度を加速:
  標準化されたツールとベストプラクティスを抽象化したサービスとして提供し、開発者が深い理解なしで利用できるようにすることで、新しい開発者が迅速に生産性を高めることができます。
• 認知負荷・コンテキストスイッチの削減:
  異なるアーキテクチャ、ワークフロー、ツールを単一のプラットフォームに統合することで、コンテキストスイッチを最小限に抑え、開発者の生産性を向上させます。
• 定量的評価の容易性向上:
  重要業績評価指標（KPI）のテレメトリー提供を標準化・自動化し、スキーマや用語の不一致を避け、パフォーマンス測定の統一フレームワークを提供します。
• 「You build it, you run it, you own it」の実現:
  開発者が自信を持ってアプリケーションを構築し実行できるようにし、開発からプロダクションまで支援する状態を実現します。

ビジネス上の収益への貢献

• 新規プロジェクトの立ち上げを加速:
  新たなプロジェクトを開始する際の環境構築などを効率化し、開発者のプラクティスをビジネスの優先順位に合わせることで、組織全体の効率性と収益性を最大化します。
• SLAの向上:
  SLAに対して考慮されたIDPの提供により、より堅牢で競争力のあるサービスレベルアグリーメント（SLA）の提供が可能になり、競争優位性を高めます。
• 新機能やプロダクトのデリバリー速度向上:
  アイデアの迅速な検証を実現するための基盤を提供することで、ビジネスの成功を加速させ、市場投入までの時間を短縮します。
• ガバナンス・トレーサビリティの実現コストを削減:
  自動化とベストプラクティスを組み込んだプラットフォームを提供することで、運用コストを削減しリソース利用を最適化します。
• ビジネスへの効果が薄い業務の削減:
  ビジネスに直結しにくい部分をセルフサービスで利用できる基盤として提供することにより、開発者の業務をビジネスの優先事項に合わせ、組織の効率性と収益性を最大化します。

標準化する際の注意点

コンテクストの少ない部分を共通のプラットフォームとして提供するということは、そのプラットフォームにより代替される業務については組織内で標準化されることと近しい意味を持ちます。

標準化を進めることで、開発、テスト、プロダクションの一貫性が確保され、設定に関する問題が減少し、デプロイメントの信頼性が向上するため、開発者の負荷が軽減されます。

ただし、過度に厳格または恣意的に強制された標準は、チームの創造性や柔軟性を阻害し、イノベーションを妨げる可能性があるため注意が必要です。標準は現場のニーズや開発者のワークフローに基づき、合意と相互理解のもとに策定されるべきです。柔軟性を持たせることで、ガイドラインとして機能しつつも、自立性を維持した開発を可能とします。

標準化する際には、以下の要素も重要となります: 

• コンテナ化しどのような環境でも同じように実行できるようにすること
• IaCの動的構成管理（DCM）によるプロビジョニングと管理の自動化
• 構成設定情報のバージョン管理
• 開発環境・ステージング環境・本番環境などでの同一性
• ワークフローの自動化による開発サイクルの速度向上
• プロアクティブモニタリングに基づく異常検知と自己修復・フェイルオーバーの自動化
• 単一障害点（SPOF）の排除
• サービス中断を伴わない計画的なメンテナンス

PFEの原則

PFEは、DevOpsでも提唱される以下の4原則に基づいた活動を行います：

• フェーズ分割・反復デリバリーによる継続的改善
• 自動化とEaS（Everything as Code）によるスケーラブルで柔軟な設計
• ユーザーとのコラボレーションとサイロの排除
• リードタイム短縮につながる新技術への抵抗削減

PFEでは、プロダクト思考を重視し、ビジネスのビジョンと戦略を明確に理解したうえで、開発者に価値が提供されている状態が大切です。開発者は発見と学習を繰り返しながら適応を繰り返し、ビジネスの実現を目指す姿勢が重要です。ツールを作ること自体を目的とすると、提供されるIDPが逆にオーバーヘッドになったり、ビジネスからズレたものとなりかねません。

つまり、コンテクストに配慮したプラットフォームの設計が必要であり、共通点を認知し、その拡大を認める中でもしっかりとニーズを把握しながら継続的・反復的に改善していく必要があります。

この原則に基づいてPFEを進め、適切にIDPを提供することにより、DevOps導入の過程で陥りがちな以下のようなアンチパターンを解決に導くことができます：

• DevOpsサイロ化:
  チーム間での連携不足により、知識共有が分断され全体的な生産性が低下しますが、PFEは部門横断的な調整役となり、共通のプラクティスと透明性をもたらします。デベロッパーアドボケイトが連絡役となり、異なるチーム間のコミュニケーションと理解を促進します。
• ハンドオフによる責任転嫁:
  DevとOpsの明確な分離により問題解決における責任の所在が曖昧になりますが、PFEは開発ライフサイクル全体を見通し、責任の一体化を促進します。IDP内でツールを統合し、ワークフローを自動化することで、チーム間で作業がシームレスに流れるようになります。
• 肩書きだけのDevOps:
  名ばかりの役割では本質的な変化は起きませんが、PFEでは実践的な支援とツール整備、教育を通じた実効的な変革が必要です。責任共有モデルと明確な役割分担により、全員が全体像における自分の役割を理解できます。

PFEは、プラットフォームエンジニアリングを「プロジェクト」ではなく「プロダクト」として捉えることで、これらのアンチパターンに対処します。プラットフォームエンジニアリングチームは、内部開発プラットフォームプロダクトの成功に責任を持ち、採用、開発者の負担軽減、開発者の生産性向上に貢献します。

開発者体験の構築

開発者体験は、開発者がソフトウェア開発におけるプロセスやプラットフォーム、ツールを操作する際の全体的な経験を指します。開発者体験の向上は、よりスムーズな開発ワークフローを促進し、プロセスの摩擦を減らし、ソフトウェアデリバリーの効率とスピードを向上させます。結果として、より高品質なソフトウェア、納品時間の短縮、業績と顧客満足度の向上といったビジネス成果に繋がります。開発者体験が高まることで、やる気と結束力のあるチーム環境を育み、従業員の幸福度や生産性を向上されます。

このことから分かる通り、PFEでは単にIDPを作ればいいという話ではありません。作成されるIDPは、実態の開発者・開発チームのニーズに沿ったものである必要があり、それは時の流れとともに変化するものでもあります。つまり、プラットフォームを組織に浸透させるためにはユーザーとなる開発者・開発チームのニーズをしっかりと把握したうえで、提供するIDPを常に進化させる必要があります。

このようにして構築されたIDPは、以下のような開発者体験の向上を生み出します

• 開発環境の基盤としての品質・信頼性:
  セキュリティとコンプライアンスに優れた開発環境の提供、スケーラビリティとパフォーマンスの担保をします。
• 開発効率を支える自動化とツール整備:
  CI/CD、IDEなどの自動化とツールの統合、開発者体験を強化する各種ツールの導入、必要なツールへのアクセス性を高めます。
• スムーズな立ち上げと運用支援:
  効率的なオンボーディングプロセス（素早いセットアップ、対話型チュートリアル、メンターシップ制度、バディの任命など）、包括的なドキュメンテーション、継続的な学習を促進します。

開発者体験の計測には、プロダクトメトリクス、サポートチケットの解決率、オンボーディングの完了率、開発者の定着率などが用いられます。また、セキュリティとコンプライアンス面では、脆弱性管理、アクセスコントロール、セキュリティトレーニング、セキュアコーディング、データ保護対策などが重要視されます。

このような項目で開発者体験を計測しながら、開発者とも密にコラボレートしてIDPを作っていくことによって、ビジネスの強化につながるプラットフォームが完成していくのです。

おわりに

今回の研修では、上記で述べたようなPFEの基本原則はもちろん、上記の基本原則を実現していくためのさまざまなノウハウについて学びました。例えば、チームトポロジーをベースにしたPFEの構築や、PFEを実現する上でのハードスキル・ソフトスキルなどについて詳細に解説してもらいました。これらの内容により、具体的なPFEでの取り組みについて解像度が高まったと感じました。

同時に、PFEが単なる技術的な取り組みではなく、組織全体の文化変革を促し、開発者の生産性を飛躍的に向上させるための戦略的なアプローチであることがよく分かりました。つまり、PFEを実現する上でのHowはたくさんあれど、導入の目的と文化の醸成をどのようにしていくか、という点がすごく大切なのだと感じました。

この研修では、このようなPFEの考え方はもちろん、実現するために必要な技術的スキル、プロダクトマネジメントスキル、ソフトスキルやコラボレーションの方法についても紹介してくれます。興味がある方はぜひ受講してみてください。

私自身も、学んだ知識を活かし、今後の業務に貢献していきたいと思います。