キーポイント
- 成功するプラットフォームチームは、組織全体の目標に合致し、組織内でのチームの役割を積極的に定義し、エンジニアを鼓舞するミッションステートメントを持っている
- ユーザーリサーチを実施し、フィードバックを募り、ステークホルダーから社内の賛同を得ることで、プラットフォームチームは、開発者のペインポイントや組織全体で共有する課題を全体的に理解できる
- 成功するプラットフォームチームは、車輪の再発明をしない
- 社内開発者向けポータルは、開発者が基礎となる社内開発者向けプラットフォームにアクセスするために使用できる、サービスカタログ機能を備えたUIを提供する。これに対して、社内開発者プラットフォームは、労力と反復作業を排除し、設計によって標準化を推進するのだ
コミュニティとツールは急速に発展しており、プラットフォームエンジニアリングが今後も盛りあがリ続けることは明らかである。一方で新しいトレンドにありがちな未解決の疑問がまだ多く残っている。Humanitecは、「プラットフォームエンジニアリングの現状」の初版レポートを発表した。ここではプラットフォームエンジニアリングの重要なトレンドとともに、このレポートから学んだ重要な事柄を紹介していく。
プラットフォームエンジニアリングは、ソフトウェアエンジニアリングにおける最大のトレンドの1つである。史上初のプラットフォームエンジニアリングのカンファレンスであるPlatformCon2022は6,000人以上の参加者を集め、地域のミートアップグループの会員数は数千人に達している。このトレンドが今後も続くことは明らかである。
ソフトウェアエンジニアリングのトレンドと同様に、コミュニティ内外の人々が好奇心を抱く未解決の問題が数多く存在するのは当然だ。State of Platform Engineering Reportは、このような疑問に答え、プラットフォームエンジニアリングの現状について情報を提供し、コミュニティのさまざまな集まりから重要なリソースをまとめようとするものである。
そこで早速だがプラットフォーム・エンジニアリングについて知っておくべき重要なことを紹介したい。
なぜプラットフォームエンジニアリングがホットなトレンドになっているのか？
この10年間で複雑なマイクロサービス・アーキテクチャ、Kubernetesなどのテクノロジー、インフラストラクチャ・アズ・コード（IaC）などのアプローチは業界標準となった。単純な作業でさえ、開発者は自らが使用するツールチェーンをエンドツーエンドで理解する必要があり、認知負荷が大幅に増加し、シャドーオペレーションのような組織の非効率性を生み出している。
認知負荷とは"ワーキングメモリで使用されるメンタル的な労力の総量"のことである。心理学者のJohn Sweller氏は、1980年代後半に認知負荷理論を定式化しようとした。この理論では、"学習課題によってワーキングメモリの容量が超過した場合、学習が妨げられる "と主張している。
2019年、Manuel Pais氏とMatthew Skelton氏は、認知負荷がDevOpsを実施しようとするときのよくある弊害であると特定した。この発見は専任のプロダクトチームが抽象化レイヤーやプラットフォームを構築して基礎技術の複雑さから開発者を解放し、認知負荷を軽減する彼らのTeam Topologiesの創設を後押しした。
Team Topologiesは、いくつかのDevOpsセットアップで発生する、特定の繰り返し発生するアンチパターンに対処するために設計された。私たちが"シャドーオプス"と呼ぶアンチパターンでは、Humanitecの2021年DevOpsベンチマーク調査でも確認されたように、エンジニアリング組織がもはや専任のオペレーション専門家は必要ないと判断し（あるいは数を減らし）そのタスクを開発者にシフトしている。多くの場合、経験の浅い開発者はシニアバックエンドエンジニアに支援を求める。その結果もっとも優秀で重要なリソースを誤って割り当ててしまいチームの生産性を低下させてしまうのである。
Inspired by Daniel Bryant at PlatformCon 2022
その結果として、いくつかの企業や組織は良いアプローチを発見することを余儀なくされた。そのような企業はプラットフォームエンジニアリングチームを設立し、内部開発者プラットフォーム（IDP）を構築した。IDPとは開発者の認知負荷を軽減するために複数の技術とツールを組み合わせたものであり、基盤となる技術のコンテキストを抽象化することなく、開発者の認知負荷を軽減するための技術やツールの組み合わせたものである。Netflixは複数のサービスやソフトウェアを管理し、どのツールが存在するかを把握し、ツール間でコンテキストを切り替えるという開発者の課題を解決するためにプラットフォームを活用した。 Nordstromは"セルフサービスのノーススター"となるためのプラットフォームを構築した。同社のプラットフォームはプロビジョニングプロセスのボトルネックを解消し、本番環境へのログインを不要にした。このような変化により組織は迅速に行動できるようになった。Zalandoは、自社プラットフォームを活用して、デベロッパーエクスペリエンスを統一し、デフォルトでコンプライアンスを促進し、長期的に会社の運営方法を改善したのである。
これらは成功したプラットフォームに関する取り組みのほんの一例に過ぎない。Puppetの2020年と2021年のState of DevOps ReportやHumanitecの2021年のDevOps Benchmarking Reportなどの調査では、IDPを運用しているチームのDORAメトリクスにおいて高度なDevOps進化とパフォーマンスの傾向が示されている。
ではプラットフォーム・エンジニアリングとは一体何なのだろうか？
プラットフォーム・エンジニアリングの共通の定義に合意・納得するのは難しいが、重要な課題でもある。私は先日次のように定義した。
クラウドネイティブ時代のソフトウェアエンジニアリング組織において、セルフサービス機能を実現するツールチェーンやワークフローを設計・構築する学問である。プラットフォームエンジニアは、アプリケーションのライフサイクル全体の運用に必要なものを網羅する"内部開発者向けプラットフォーム"と呼ばれる統合プロダクトを提供することが多い。
内部開発者向けプラットフォームは専門チームによって構築されている。チーム・トポロジーではこのチームがどのような存在であるか、またはどのような存在ではないのかについて説明している。プラットフォームチームはSREのかわりでも、開発チケットを処理する影のチームでもない。また個々の課題やプロダクションの信頼性に焦点を当てるべきでもない。そのかわりに開発者をプラットフォームの顧客として扱うプロダクトマインドセットで取りまわすものなのだ。
プラットフォームエンジニアリングの原則とベストプラクティス
プラットフォームチームがプロダクトの構築を開始する前に、そのプロセスを導く明確なミッションステートメントを定義する必要がある。これは組織全体の目標に適合し、組織内でのプラットフォームチームの役割を積極的にするものだ。またエンジニアを鼓舞するものでなければならない。Hashicorpのプラットフォームエンジニアリング・インフラストラクチャーのディレクターであるMichael Galloway氏は、これをうまく要約している。
"感情的であり、刺激的であるべきだ。...またシンプルでありながら、意味をもつものであるべきなのだ"
まず目標を定義することから始めよう。例えば、認知負荷をかけずに開発者のセルフサービスを実現する、開発者にインフラストラクチャ中心の技術を学ばせることなく運用のチケット数を減らす、などである。この後おそらく次のようなものに行き着くはずだ。 「私たちの使命はワークフローを標準化してデベロッパーエクスペリエンスを向上させ、イノベーションサイクルを加速させ、市場投入までにエンジニアリング組織が消費する時間を短縮することだ」。これは説明的ではあるが、刺激的ではない。ミッションステートメントを洗練させ、うまくバランスを取るようにしよう。例えば 「私たちの使命は、開発者がすぐにイノベーションを起こせるような、開発者に好かれるプラットフォームの構築である」。
プラットフォームを構築する最良の方法は、プロダクトアプローチに従うことである。ユーザーリサーチやユーザーからのフィードバック、ステークホルダーからの賛同を得ることでプラットフォームチームは、開発者の悩みや組織全体で共有されている課題を総合的に理解できるのである。そして開発者が必要とする機能を特定し、それらのソリューションを網羅するゴールデンパスを構築可能なのである。しかしプラットフォームの旅はそこで終わりではない。成功するプラットフォームチームは開発者とのコミュニケーションをオープンにし、エンジニアリングKPIを測定して、開発者がプラットフォームを採用しているか、プラットフォームが開発者の人生を快適なものにしているかを確認するのだ。
Lambros Charissis氏は、Wiseのプラットフォームエンジニアリングチームが、課題の特定とパフォーマンス測定のために実質的なKPIを定義した方法を紹介した。彼らはKPIツリーを使って生産性やリードタイム、デプロイ頻度、開発者の幸福度、安定性、効率性、リスクといったKPIを明確にしたとのことである。
また、市場シェア（開発者が実際にプラットフォームを使用しているか、それとも技術やツールに直接アクセスすることを好むか）、使用による時間短縮、チーム間の関係改善（開発者と運用など）などのプラットフォーム導入KPIを監視する必要がある。定期的にアンケートを実施し、プラットフォームが開発者のエクスペリエンスを向上させたかどうかを把握する。
プラットフォームチームと彼らが提供するゴールデンパスは、このような複雑なセットアップをまとめる接着剤となるものだ。しかし通常、顧客向けの機能を出荷しないため、多くの組織はコストセンターと誤って捉えている。プラットフォームチームは社内プラットフォームプロジェクトを長続きさせるために、関連するステークホルダー・グループからの社内賛同を得るよう努力する必要があるのだ。
最後に、おそらくもっとも重要なことだが、成功するプラットフォームチームは車輪の再発明をしない。時にはソリューションをゼロから構築する場合もあるが、多くの企業は、具体的で効果的なソリューションのためにリソースを割いている現状だ。ツールはさまざまな問題に対応するために日に日に増えている。プラットフォームチームは可能な限り既製品のソリューションを利用することで、時間を節約し、より大きな価値を生み出すことが可能なのである。
プラットフォーム・ツーリング・ランドスケープ
プラットフォームエンジニアリングは、Internal Developer Platformをアーキテクトすることだ。Kaspar von Grünberg氏は、Internal Developer Platformとは"プラットフォームエンジニアリングチームが最も良いソリューションを構築するために活用する、すべての技術やツールの総体"だと説明する。
その方法は数多くあり、万能なソリューションは存在しない。
プラットフォーム・エンジニアリングの現状レポートでは、プラットフォーム・ツールの状況を分解し、すべての選択肢をより理解することを試みている。
プラットフォームを構築する方法は数多くあり、一部のベンダーが約束しているにもかかわらず、万能なソリューションは存在しない。ベンダーによっては、PaaSのような体験を提供するものもあり（Herokuなど）、小規模なスタートアップ企業、特にPOCやMVPを素早く作成したい企業には有効かもしれない。
しかし、大企業や、ブラウンフィールドのセットアップをサポートする必要があり、グリーンフィールドを始めることができない中堅エンジニアリング組織では、ほとんどの場合、このようなPaaSは役立たない。
だがプラットフォームエンジニアリングの専門家は、一般に、プロダクトとしてのアプローチを推奨している。つまり、常にゼロから始める必要はないのだ。プラットフォーム・ツールは、オープンソースもあればプロプライエタリなものもあり、数多く存在する。可能であれば、時間とコストを節約するために、あらかじめ構築されたソリューションを購入し、カスタマイズを検討してほしい。そうすることで、プラットフォーム・チームは、カスタマイズが必要な機能に時間とリソースを割くことが可能になる。
プラットフォームエンジニアリングの現状レポートでは、プラットフォームツールの状況を分解し、すべての選択肢をより理解できるように試みている。
ガートナーは、レポート"A Software Engineering Leader's Guide to Improving Developer Experience"内において、プラットフォームエンジニアリングの指針となる3つの重要な考え方を示している。
-
開発者エクスペリエンスを向上させるには、社内の開発者プラットフォームを構築し、認知的負荷、開発者の労力、反復的な手作業を軽減する
-
プラットフォームは、特定のツールセットやアプローチを強制するのではなく、開発者がソフトウェアを容易に構築・提供できるようにするものであり、基盤となるコアサービスの有用で差別化された機能を抽象化するものではない
-
プラットフォーム・エンジニアリング・チームは、プラットフォームを（開発者が使用する）プロダクトとして扱い、セルフサービス方式で消費されるように設計する
内部開発者向けプラットフォームと内部開発者向けポータルの違いを明確にすることも重要だ。ガートナーのレポートもこのテーマを扱っており、著者は次のように書いている。
"社内開発者向けポータルは、開発者が社内開発者向けプラットフォームの機能を発見し、アクセスするためのインターフェースとして機能する"
内部開発者ポータルは、開発者が基礎となる内部開発者プラットフォームにアクセスするために使用可能だ。サービスカタログ機能を備えたUIを提供できる。これに対して、内部開発者プラットフォームは、労力と反復作業を取り除くものである。
開発者ポータルを構築しても、デベロッパーエクスペリエンスに悪影響を及ぼしている根本的な構成やワークフローの問題は解決しない。そのため、Internal Developer Platformと開発者ポータルの組み合わせが理想的である。
コミュニティとキャリア
プラットフォーム・エンジニアリング・コミュニティは、2021年にオースティンとベルリンの少数のミートアップ・グループから始まった。現在では、世界中の19のミートアップグループで1万人を超えるアクティブなプラットフォームエンジニアを誇っている。このコミュニティの勢いは、組織がプラットフォームエンジニアリングにもっと真剣に取り組むべきというサインだ。
プラットフォーム・エンジニアリングは、有望なキャリアパスでもある。多くの企業が、社内開発者向けプラットフォームの構築は、自社の収益に付加価値をもたらすと認識しているのだ。そのため、内部開発者プラットフォームの構築に携わる人は、DevOpsに携わる人よりも平均して高い収入を得られる可能性がある。
このような変化にもかかわらず、プラットフォーム・エンジニアやHead of Platformといった職種は、まだ一般的なものではない。現状レポートによると、組織のプラットフォームを構築している回答者の多くは、シニア・ソフトウェア・エンジニア、ITアーキテクト、プリンシパル・エンジニア、シニアDevOpsエンジニアといった肩書きだった。このように、業界はプラットフォーム・エンジニアリングを受け入れ始めているが、プラットフォームの役割を適切に定義するにはまだ苦労している。
プラットフォームエンジニアのキャリアを考えている人は、どの技術を習得する必要があるのか、コミュニティによく質問する。今回の調査では、半数以上の回答者がDocker、Kubernetes、IaC、CI/CDにもっとも注力していると回答した。データベース、ストレージ、ネットワーク技術もリストアップされたが、回答者の4分の1以下だった。
柔軟な勤務形態に関しては、プラットフォーム・エンジニアリングが先行している。米国の調査回答者の80％以上がフルリモートで仕事をしている現状だ。ヨーロッパの回答者は、フルリモートとハイブリッドがよりバランスよく配置されている。全体として、100％オフィスでの勤務は過去のものとなっているのだ。
次はどうなる？
プラットフォーム・エンジニアリングは、ここ数年で大きく進歩し、今後もその勢いは衰えないだろう。ツールやコミュニティは日々成長しており、そのことを始めたり、キャリアを積んだりするのに役立つリソースには事欠かない。