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

はじめに

この記事は、最近話題のプラットフォームエンジニアリング (PFE) について、5分くらいで雰囲気を掴めるよう執筆しました。新卒研修でPFEについて少しサーベイをしたので、その内容をシェアいたします。

「プラットフォームエンジニアリング？なにそれ美味しいの？」という方のご参考になればと思います。

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

PFEとはずばり、

IT技術の進化により加速している「ビジネス変化への対応速度を高める」ため、
「開発者体験を高める」ことにより開発の効率を向上させる取り組み

のことです。

PFEに類似した単語として「Agile」「Cloud Native」「DevOps」「SRE」など、多くの言葉が定義されています。
DX推進が求められている中でこれらの単語への注目度は年々増加していると感じますが、PFEとの違いは何なのでしょうか？

実は、「このやり方は〇〇だ」、「PFEでやるのはこれだ」のように分類することはあまり意味がないです。重要なのは、誕生の背景を押さえ、何を目的としているか、という点になります。

誕生の背景

Agile
より良いソフトウェアを作るための方法を探った人たちが、各々考えたやり方に共通する価値と原則を定め、それらに基づいた開発を促す取り組みが始まった

DevOps
運用品質を高め安全に素早くビジネス価値を生み出すために必要な文化の醸成やツールの利用を促す取り組みが始まった

Cloud Native
クラウド技術を用いて開発・運用のパフォーマンスを向上させる方法を模索し普及する取り組みが始まった

SRE
システムの安全性や可用性、スケーラビリティの確保のため、作業の自動化やモニタリングが促す取り組みが始まった

---

そしてPFEにおいては、ビジネス変化への対応速度を高めるため「開発者体験を高めて開発の効率を向上させる」という点がポイントになります。

そもそも「開発者体験」って何？

例えば、こんな悩みはありませんか？

• 開発準備に時間が取られなかなか開発ができない
• 毎回マニュアルで行わなければならない作業が多く時間が取られる
• 開発開始からリリースまでの期間が長い

このような悩みは、開発者へのストレスになるのはもちろんですが、ユーザーへの価値速度を低下させるという悪影響も及ぼします。

技術はどんどん多様に複雑になっており、開発者が情報や知識をキャッチアップする労力は増加傾向にあります。
このような現代においては、開発者がより素早く開発していくためのプラットフォームを構築していくことで、開発者の負担が下がるとともに専門領域での活躍がしやすくなると考えられます。
技術が複雑化していることなども起因して、開発者への負荷が大きくなっていることによりPFEへの注目度が上昇してきたわけですね。

さて、ここからは開発者体験の高め方や開発効率が上がったかをどのように判断するかについて説明します。

PFEの導入による効能を測る方法

PFEを導入するうえで「開発効率が上がったのか？」という点を評価することは非常に重要です。
もちろん、はじめから完璧なプラットフォームを用意し、開発者に提供することは難しいです。PFEの活動においても、やりかたや中身を検査しながら適宜適応していくことで、PFEが最適化され「開発者体験の最大化」を見込めます。

PFEの導入による効果測定方法として考えうる指標を3つ紹介します。

1．プロジェクトの「立ち上げ→開発開始→リリース」における各リードタイム

1つ目は「時間指標」です。PFEでは、開発者が素早く開発を開始し、素早くリリースすることで、ユーザーへの価値提供を早くするという側面があります。
開発がPFEによるアプローチでの有無で、どの程度リードタイムが縮小できたか、計測することは重要であると考えられます。

2．PFEに伴い増加・減少する費用や稼働などのコスト

2つ目は「コスト指標」です。PFEによりリードタイムを縮小できたとしても、PFEの維持に伴うコストが増加してしまいすぎるとマイナスになってしまいます。
特に導入初期は注意が必要です。PFEは導入してすぐに効果を発揮するわけではなく、少しずつ組織や開発者に最適化されていき、最終的に効能を得られる取り組みです。スモールスタートで、少しずつ範囲を拡大させるとともに、どの程度の人財リソースを分配し、人的・費用的コストがかかっているのかをモニタリングすることは重要であると考えられます。

3．開発するうえでの開発者のストレスや満足度

最後は「エンゲージメント指標」です。PFEの目的の1つは開発者体験を上げることです。
PFEの導入により、開発者が課題への解決がしやすくなったか、開発者が課題を解決することでやりがいを感じることができているか、という点は重要です。
特に、PFEを導入するとブラックボックス化する要素が増える可能性が高く、それが原因で開発者に余分な作業を行わなければならない、という事態も発生しかねませんので注意が必要です。

Golden Pathを見つけないとPFEはできませぬ！

PFEを進めていくなかで必要不可欠なのが「Golden Path」です。Golden Pathとは、目的に応じて使用できる、迅速なプロジェクト開発を実現するための「コードと機能のテンプレート構成」のことです。

例えば、Java Spring Bootの例場合だと以下のようになります：

1. スタートガイド
2. スケルトン ソースコード  
3. 依存関係の管理
4. CI / CD パイプライン テンプレート
5. クラウド IaC 用テンプレート
6. Kubernetes YAML ファイル
7. ポリシー ガードレール (IAM)
8. ロギングとモニタリング計測
9. リファレンス ドキュメント

Golden Pathには、スタートガイドやスケルトンソースコード、CI/CDパイプラインテンプレートなどが含まれます。これらを用意することで、開発開始までのコストを削減できます。

開発者は目的に適したGolden Pathを選択し、開発を進めていきます。すなわち、各Golden Pathは目的や用途が明確になっていなければいけません。

ではここから、Golden Pathを作るうえで従うべき5原則を見ていきましょう。

Golden Pathの原則

1．ターゲッティングする

Golden Pathを作るうえで最も大切なのは、対象者を明確にするとともに、特定のタスクを簡略化するなどの目的を明らかにすることです。開発者が開発を進める中で感じうる「これが面倒だな」「ここができればすぐに開発に入れるのに…」など、開発者が出会う「お気持ち」を汲み取り、ニーズを洗い出します。このニーズにマッチするよう、Golden Pathを構成する必要があります。
ターゲッティングがうまくできていない場合、誰にも使用されないGolden Pathが生まれてしまうので注意が必要です。

2．明確な単一のパスを示す

Golden Pathは各々1つの明確なパスになっている必要があります。すなわち、複数のGolden Pathが存在するとき、それらは各々疎結合でなければいけません。
タスクを完了するためのベストプラクティスを事前に定め、ツールやサービスの構成に伴う複雑な作業による負担が軽減されるよう標準化することで、チーム内のすべての開発者がタスクを完了できる状態にすることが大切です。

3．柔軟性を持たせる

先に述べたように、Golden Pathは独立しており、ターゲットごとに作成されています。しかし、この目的が大きすぎる場合、使用できるシチュエーションが限られてしまうでしょう。必要に応じて複数のGolden Pathを組み合わせられるよう、大きさを適切に調節することが大切です。
そして、組み合わせをできるようにするためには、そのGoldenPathに何が含まれているか見えるようにする「透明性」が必要になります。

4．透明性を持たせる

Golden Pathを使用する際に、そのGolden Pathの中身が見えるようにすることは非常に重要です。そのGolden Pathはどのように使用できるのか、含まれる内容は何か、使い方はどうすればいいかなどの情報を見えるようにする必要があります。これが見えないと、開発者は「これ、本当に使っていいのか？」「これを使うせいで、変なバグが出ないか？」などの疑念を抱き、調査することになると思います。そうなると、開発者の負担は減らず、開発者体験も上がらないという事象が発生しうることがわかるでしょう。情報の透明性は非常に重要です。

5．セルフサービスにする

Golden Pathは、目的を達成するために必要なものが揃っている必要があります。すなわち、目的達成のために別途開発者が自身で調べ、用意しなければならない状況は避けるべきです。
開発者がツールやサービスをリクエストした際にプロビジョニングするための自動化された方法を提供することにより、外部の介入なしにタスクを完了できるようにする必要があります。
開発者が求める機能を提供する様々なプラットフォームを可能な限り自由な組み合わせで提供し、インフラストラクチャー間での移植性と使いやすさを構成できるようにする必要があります。

---

これらの5原則に則り、ゴールデンパスを作ることが大切です。

そして、開発者にゴールデンパスを提供するために必要なのがデベロッパーポータルです。

開発者とプラットフォームをつなぐデベロッパーポータル

Golden Pathを作り、プラットフォームを用意したとしても、それをどのように提供するのかという点が重要になります。そのために必要なのが「デベロッパーポータル」です。

引用：https://www.gartner.com/en/articles/what-is-platform-engineering　

今回はデベロッパーポータルについては詳細を触れませんが、代表的なデベロッパーポータルである「Backstage」 に基づき、基本的な機能を紹介します。

1. Catalog：Pull Request一覧やCIの実行結果などが確認できる機能
2. Template：Git Repository上に用意されているテンプレートをもとに新しいリポジトリを作成（またはMerge Requestを作成）できる機能
3. TechDocs：リポジトリに格納されているドキュメントを閲覧できる機能

こういった機能を提供するデベロッパーポータルにより、開発者とプラットフォームをつなぐことができるわけです。

おわりに

今回は、プラットフォームエンジニア (PFE) とは何か、雰囲気をわかっていただく目的でこの記事を作成しました。

皆さまの理解への助けとなれば幸いです。

---

参考リンク

• What is Platform Engineering
• Laying the foundation for a career in platform engineering
• Light the way ahead: Platform Engineering, Golden Paths, and the power of self-service
• How We Use Golden Paths to Solve Fragmentation in Our Software Ecosystem
• Backstage.io