8.4 プラットフォームエンジニアリングと開発者体験

概要と動機

プラットフォームエンジニアリングとは、他のエンジニアがソフトウェアを構築し、出荷し、運用するために使う内部プロダクト、つまり内部開発者プラットフォーム(IDP)を、築いて運営する規律です。各チームがパイプライン、インフラストラクチャ、ツールをゼロから自前で組み立てる代わりに、専任のプラットフォームチームが、よくサポートされた「ゴールデンパス」に沿って、選り抜きのセルフサービスの機能を提供します。ゴールデンパスとは、妥当な既定が組み込まれた、意見のあるサポートされた経路です。開発者体験(DevEx)は、密接に関連する関心事で、組織でエンジニアであることがどう感じられるかです。開発者がどれだけ容易かつ素早くアイデアから稼働するソフトウェアに至れるか、そして行く手にどれだけの摩擦があるか。

大きなチームにとって、これが重要なのは、認知負荷と摩擦がきれいにはスケールしないからです。チームが多いと、各エンジニアがやりくりしなければならないツール、システム、決定の数は増え続けます。やがて、時間の大きな割合が、価値を届けることではなく、インフラストラクチャの配管と調整に費やされます。プラットフォームがなければ、すべてのチームが、プロビジョニング、デプロイ、オブザーバビリティ、コンプライアンスのような同じ問題を、一貫せずに繰り返し解きます。良いプラットフォームは、この共有の複雑さを吸収します。するとチームは、セキュリティ、信頼性、コストの組織の標準を引き継ぎながら、自分のドメインに集中できます。

企業と政府にとっての関連性は高いです。これらの組織は規模と厳格なガバナンスを併せ持つからです。プラットフォームは、コンプライアンス、セキュリティ、監査の要件を、チームが既定で従う舗装された道として、一度だけ符号化する自然な場所です。それは、すべてのチームが自力で方針を正しく解釈して実装すると期待するよりよいことです。ガバナンスを摩擦の源から、標準のワークフローの目に見えない性質に変え、それはまさに、大きな規制対象の組織が統制を失わずに速く動くために必要なものです。

主要原則

プラットフォームを、ユーザー、ロードマップ、そして採用を強制するのではなく勝ち取る使命を持つプロダクトとして扱います。
ゴールデンパスを提供します。正しいやり方を容易なやり方にする、意見のある、よくサポートされた経路。
能力をセルフサービスにし、チームがチケットと人間の引き継ぎを待たなくてよいようにします。
ゲートを建てるのではなく、道を舗装します。正当な仕事を妨げずに導くガードレールを組み込みます。
アプリケーション開発者の認知負荷を、容赦なく減らします。
開発者体験と生産性を、バランスのとれた多次元のシグナルで測定します。
ゴールデンパスは任意に保ちつつ、チームが選ぶほど優れたものにします。

推奨事項

プラットフォームをプロダクトとして築く

最も重要な唯一の転換は、プラットフォームを、上から課される義務の標準ではなく、内部の顧客に仕えるプロダクトとして扱うことです。実際には、調査とフィードバックを通じて開発者のニーズを理解し、ロードマップを保ち、採用と満足度を測定し、体験に責任を負うことを意味します。チームが使うことを強いられるが彼らを遅くするプラットフォームは、恨まれて迂回されます。チームを本当に速くするプラットフォームは、評判で広がります。品質を通じて勝ち取られた採用が、プラットフォームの成功の最も真実な尺度です。

ゴールデンパスと舗装された道を提供する

一般的な道筋のためにゴールデンパスを定義します。新しいサービスの作成、デプロイ、データベースの追加、オブザーバビリティの配線、コンプライアンス要件の充足。ゴールデンパスは、妥当な既定が組み込まれた、サポートされた、意見のある、端から端までの経路です。これらの道に沿って、セキュリティスキャン、ポリシーのチェック、ベストプラクティスというガードレールを埋め込み、道に従うチームが自動的に準拠して安全になるようにします。目標は単純です。何かをする最も容易なやり方が、正しく、安全で、準拠したやり方でもあること。本当に特異なニーズを持つチームが逸れられるよう、道は任意に保ちます。しかし、ほとんどのチームが決して逸れたくならないほど、道を魅力的にします。

本物のセルフサービスのインフラストラクチャを届ける

インフラストラクチャと能力を、ポータル、コマンドラインツール、API、テンプレート化されたリポジトリといったセルフサービスのインターフェースで公開し、チケットを出して待つ引き継ぎをなくします。開発者は、準拠した環境をプロビジョニングし、テンプレートから新しいサービスを立ち上げ、データベースを数分で要求できるべきで、他のチームに依頼を出して数日待つ必要はありません。セルフサービスは、プラットフォームをボトルネックから加速装置に変えるものです。そしてそれは、根底のガードレールがセルフサービスを安全にするからこそ機能します。

開発者ポータル、サービスカタログ、スコアカードを提供する

開発者ポータルは、単一の窓を与えます。すべてのサービスの、所有者、ドキュメント、依存関係、ヘルスを備えたカタログ。サービスカタログは、所有とアーキテクチャを発見可能にします。誰もシステム全体を頭に保てない規模では、計り知れない価値があります。スコアカードは、各サービスを、テストカバレッジ、セキュリティの姿勢、オンコールの備え、ドキュメントのような標準に対して測定し、チームに、自分がどこにいて何を改善すべきかの明確で客観的な像を与えます。合わせて、これらのツールは、エンジニアが情報を探すのに費やす時間を削り、説明責任を明確にします。

バランスのとれた枠組みで開発者体験を測定する

単一の数字の生産性指標に抵抗してください。それらは容易にゲーム化され、誤解を招きます。SPACE(満足とウェルビーイング、パフォーマンス、活動、コミュニケーションとコラボレーション、効率とフロー)のような多次元の枠組みを使い、開発者体験の本物の質感を捉えます。調査からの知覚データを、ツールからのシステムデータと組み合わせます。リードタイムやデプロイ頻度のようなデリバリー指標を、開発者の感情と並べて追跡します。狙いは、個人を順位づけることではなく、摩擦を理解して取り除くことです。監視のように感じられる測定は、プラットフォームが依存する信頼を腐食させます。

認知負荷の削減を第一級の目標にする

認知負荷、つまり開発者が仕事をするために費やさなければならない精神的労力の総量は、プラットフォームが減らすために存在する、隠れた税です。アプリケーション開発者が習得しなければならないツール、概念、コンテキストの切り替えの数を最小化します。チームが価値の低い決定をより少なくするよう、妥当な既定を提供します。各チームが、境界のある理解可能なシステムの一部を所有するよう、所有を構造化します。プラットフォームのどの機能を評価するときも、一つの問いを立ててください。それを使うチームの負荷を減らすか、増やすか。

トレードオフ: 長所と短所

選択	長所	短所	最適な場合
プロダクトとしてのプラットフォーム(オプトイン)	採用を勝ち取る。有用に保たれる	完全な範囲に達するのが遅い	ほとんどの組織
義務づけられたプラットフォーム	速い標準化	恨み。回避策	強いガバナンスのニーズがある場合のみ
ポータル/プラットフォームを買う	価値に至るのが速い	合わせ込みが少ない。ライセンス費用	先行きを求めるチーム
自社で築く	ちょうどのニーズに合う	高い構築と保守のコスト	大きく特色ある組織
硬直したゴールデンパスのみ	最大の一貫性	正当な端のケースを妨げる	非常に均一なワークロード
逃げ道のある柔軟な道	一貫性と自律のバランス	管理すべきいくらかの乖離	多様なチームのニーズ

中核の緊張は、標準化対自律です。標準化が少なすぎると、すべてのチームが車輪を一貫せず再発明します。多すぎると、本当にニーズが異なるチームを窒息させます。プロダクトとしてのプラットフォームの哲学は、標準化を義務ではなく魅力的にすることで、これを解きます。第二の本物のトレードオフは、築くか買うかです。自社のプラットフォームを築くことは、ちょうどのニーズに合いますが、相当な継続的コストを伴います。既存のツールの採用は価値を速めますが、いくらかのカスタマイズを代償にします。

チームで議論すべき問い

プラットフォームが、もう一つ学ぶべきツールを加えるのではなく、認知負荷を減らしていると、どうやって知りますか。 認知負荷とは、エンジニアが仕事をするために費やす精神的労力の総量で、概念とコンテキストの切り替えを加えるプラットフォームは、見事に見えても事態を悪化させうるのです。すべての機能に一つのテストを採用してください。それを使うチームの負荷を減らすか、増やすか。規模では、これは決定的です。プラットフォームは数百人のエンジニアの前に座り、混乱させる抽象化は毎日そのすべてに課税するからです。証拠を持ち込んでください。変更を出荷するために開発者が触れるツールとポータルの数、新入社員の最初のデプロイまでの時間、人々がどこでつまずくかについての定性的なフィードバック。プラットフォームがツールチェーンを縮めるのではなく育てるなら、あなたが築いたのは舗装された道ではなく、税です。
スコアカードはどんな標準を徹底し、点数の悪いサービスには実際に何が起こりますか。 スコアカードは、各サービスを、テストカバレッジ、セキュリティの姿勢、オンコールの備え、ドキュメントのような期待に対して測定し、赤い点数が何の結果ももたらさないなら、その価値は崩れます。スコアカードが純粋に助言的か、レビューに反映されるか、特定の能力をゲートするかを決め、誰が標準を所有するかを決めてください。規制対象の組織では、スコアカードは監督機関にコンプライアンスの姿勢への継続的な可視性を与え、手作業の報告に取って代わるので、あなたの設定する基準は重要です。標準の草案と、それに対して採点された本物のサービスのサンプルを持ち込み、チームが正当に反発しそうな所を議論してください。誰も行動しないスコアカードはダッシュボードで、明確な期待に結びついたスコアカードは行動を変えます。
プラットフォームを、ロードマップ、ユーザー調査、採用指標を備えた本物のプロダクトとして運営していますか。それとも義務としてですか。 この章の中心的な賭けは、標準化は強制されるのではなく魅力的であるべきで、それは内部のエンジニアを、勝ち取らなければならない顧客として扱う場合にだけ成り立つ、ということです。誰がプラットフォームのプロダクトマネージャーを務めるか、開発者のニーズをどう集めるか、どの採用と満足度の数字が成功を定義するかを決めてください。大きな組織では、義務は誘惑的です。速く標準化するからですが、ツールが人々を遅くするとき、回避策と恨みを育てます。現在の自発的な採用率、満足度のシグナル、チームが今日報告する上位の摩擦点を持ち込んでください。義務が解けた瞬間にチームがプラットフォームを捨てるなら、あなたはプロダクトを築いたのではなく、方針を築いたのです。
チームがゴールデンパスの端に達したとき、逃げ道は何で、道を広げるか線を守るかを誰が決めますか。 ゴールデンパスは、妥当な既定を持つ、サポートされた、意見のある経路で、その価値はほとんどのチームがそこにとどまることから来ますが、出口のない道は、本当に特異な仕事をプラットフォームから完全に押し出すゲートに変わります。チームがどう逸脱を要求するか、誰がレビューするか、一回限りの例外と、道そのものが変わるべきというシグナルをどう区別するかを、事前に合意してください。大きな組織では、これが、多様性を吸収するプラットフォームと、チームが妨げられたと感じた瞬間に影のツールへと断片化するプラットフォームの違いです。道を外れたチームの現在の数、彼らが挙げた理由、例外の承認にかかる時間を持ち込んでください。企業と政府の設定では、各逃げ道を、それが迂回する統制に結びつけ、舗装された道からの逸脱が、静かにセキュリティや認定の基準線からの逸脱にならないようにしてください。
プラットフォームを自社で築きますか、買いますか。そしてどちらの道の継続的なコストも誠実に値付けしましたか。 プラットフォームはそれ自体がライフサイクルを持つプロダクトで、築くか買うかの選択は、何年もあなたのコスト構造を決めます。自社のポータルはちょうどのニーズに合いますが、それを保守する資金のあるチームを要求し、買ったプラットフォームは、ライセンスと決して完全ではない適合を代償に、価値により速く到達します。どの能力が築くに足る差別化要因で、どれが買うべきコモディティかを決め、ベンダーが成熟するにつれてその線を見直してください。大きなチームにとって、賭け金はてこです。間違った築く決定は、プロダクトが扱えたはずの配管に、乏しい上級エンジニアを沈め、間違った買う決定は、数百人の開発者を他者のロードマップに閉じ込めます。各選択肢について、保守、アップグレード、出口のコストを含む現実的な総コストの見積もりを持ち込んでください。企業と政府の調達では、認定とデータの可搬性の条件を加え、上に築いたサービスカタログとスコアカードを放棄せずに離れられる契約を好んでください。
プラットフォームチームは、仕える開発者に対してどう資金を出され規模を決められ、予算が逼迫したとき、それはどうなりますか。 プラットフォームはてこで元を取ります。小さなチームが、はるかに大きなアプリケーション開発者の集団の生産性を倍増させますが、その同じ枠組みが、財務が削減を探すとき、利益が一つのプロダクトラインに帰属せず拡散しているため、容易な標的にします。資金のモデル、プラットフォームエンジニアと彼らが支える開発者の比率、信仰ではなく証拠でその投資をどう擁護するかを決めてください。大きな組織では、資金不足のプラットフォームは、ないよりも悪いです。チームはそれに依存し、それは朽ち、摩擦が依存を伴って戻ってきます。プラットフォームの人員、採用と満足度の傾向、組織全体で取り戻された開発者の時間の見積もりを持ち込んでください。政府と規制対象の企業では、プラットフォームを、コンプライアンスが一度符号化される場所として枠づけてください。それを削ることはお金を節約せず、いまや手作業でそれを行わなければならないすべてのチームに、監査とセキュリティの仕事を再び散らすからです。

セクター別の視点

スタートアップ。 少数のエンジニアと余裕のない資金では、プラットフォームチームを立ち上げないでください。新しいサービスがクローンして1時間で動かせる、ゴールデンパスのテンプレートリポジトリを一つ築いてください。CI、コンテナのビルド、リンティング、ヘルスチェックを事前に配線し、誰かが義務づけるからではなく、明らかに時間を節約するから広がるにまかせます。買えるコモディティの能力はすべて買い、ツールチェーンを小さく保ち、守るべきものとして、範囲ではなく認知負荷を扱います。

小規模事業者。 専任のプラットフォームの専門家はおらず予算も厳しいので、内部開発者プラットフォームを自分で築くのではなく、マネージドなプラットフォームや意見のあるクラウドの提供に頼ってください。決定を買うか築くかとして枠づけ、既定は買うです。買ったポータルとそのテンプレートは、保守するチームなしに、ジェネラリストのエンジニアにゴールデンパスを与えます。ベンダーの変更が、あなたが動かす少数のサービスを取り残さないよう、セルフサービスで離れやすいツールを選びます。

大企業。 規模と多くのチームが、ポートフォリオの一貫性を賞品にします。資金のあるプラットフォームチーム、ガードレールを備えたゴールデンパス、セルフサービスのプロビジョニング、数百のサービスにわたって所有と品質を可視にするサービスカタログとスコアカード。プラットフォームを、回避策を育てる義務ではなく、自発的な採用を勝ち取るプロダクトとして運営し、ガバナンスが既定で付いてくるよう、セキュリティとコンプライアンスを舗装された道として一度符号化します。バランスのとれた枠組みで開発者体験を測定し、取り戻された開発者の時間でプラットフォームの資金を擁護します。

政府。 調達規則、透明性、公的な説明責任がプラットフォームを形づくります。義務づけられたセキュリティ統制と認定の要件を、ゴールデンパスに沿ったガードレールとして符号化し、セルフサービスのポータルでプロビジョニングするチームが、すでに統制の基準線を満たす環境を引き継ぐようにすれば、数か月の手作業の認定が、ほぼ自動化されたステップに変わります。スコアカードを使って、監督機関にコンプライアンスの姿勢への継続的で監査可能な可視性を与え、調達では、築いたカタログと舗装された道が一つの供給者に縛られないよう、データの可搬性とオープンなインターフェースを要求します。

事例

スタートアップ。 12人のスタートアップにはプラットフォームチームがないので、一人の上級エンジニアが数回の金曜日を使って、CI、Dockerfile、リンティング、ヘルスチェックが事前に配線された、単一の「新しいサービス」のテンプレートリポジトリを築きます。どのエンジニアもそれをクローンして1時間以内にステージングでサービスを動かせ、古いプロジェクトから設定をコピーして隙間を推測する必要がありません。テンプレートがゴールデンパスで、明らかに全員の時間を節約するので、誰も言われなくても、チーム全体がそれを採用します。

大企業。 大手の保険会社は、内部開発者ポータルを出荷するプラットフォームチームを作ります。それは、すべてのサービスを、その所有者、ドキュメント、ヘルスのスコアカードとともにカタログ化します。新しいサービスは、CI/CD、セキュリティスキャン、オブザーバビリティ、コンプライアンスのチェックが事前に配線されたゴールデンパスのテンプレートから作られます。データベースと環境は、ポータルを通じてセルフサービスでプロビジョニングされます。新しいエンジニアのオンボーディング時間は数週間から数日に下がり、すべてのサービスが同じ舗装された道に従うので、監査の証拠は自動的に生成されます。プラットフォームの採用は自発的で、それを使うチームが目に見えて速く出荷するので広がります。

政府。 数十のデジタルサービスを動かす連邦機関は、共有のプラットフォームを立ち上げます。義務づけられたセキュリティ統制と認定の要件を、ゴールデンパスに沿ったガードレールとして符号化します。セルフサービスのポータルでインフラストラクチャをプロビジョニングするチームは、すでに統制の基準線を満たす環境を引き継ぎます。それは、数か月かかる手作業の認定の作業を、ほぼ自動化されたものに変えます。スコアカードが各サービスのコンプライアンスの姿勢を追跡し、手作業の報告なしに監督機関に継続的な可視性を与え、乏しい専門の職員を繰り返しのレビューから解放します。

ビジネスケース: 動機、ROI、TCO

プラットフォームエンジニアリングのROIは、取り戻された開発者の時間と得られた一貫性から来ます。エンジニアがインフラストラクチャと格闘し情報を探すのに費やす時間が減れば、彼らの高価な時間のより多くがプロダクトの価値を届けることに向かいます。より速いオンボーディング、より少ない重複した解決、自動化されたコンプライアンスはすべて、測定可能な容量とリスクの低減に変わります。プラットフォームは多くのチームに仕えるので、その改善はすべて、組織全体にてこが効きます。

TCOでは、採用のコストは本物の継続的な投資です。資金のあるプラットフォームチーム、(築くか買うかの)ツール、継続的な改善でプラットフォームをプロダクトとして運営する規律。採用しないコストは拡散していますが大きいです。すべてのチームが同じインフラストラクチャの税を繰り返し払うこと、一貫しないセキュリティとコンプライアンス、遅いオンボーディング、苦役で燃え尽きる上級エンジニア。リーダーシップには、論拠はてこの観点で述べるのが最善です。適度でよく運営されたプラットフォームチームは、はるかに大きなアプリケーション開発者の集団の生産性を倍増させ、すべてのチームが正しくやることに頼るのではなく、ガバナンスを一度符号化します。

アンチパターンと落とし穴

提供されるのではなく課されるプラットフォーム。 開発者が嫌うプラットフォームを義務づけることは、回避策と恨みを育てること。
象牙の塔のプラットフォームチーム。 本物の開発者のニーズを理解せずに築くと、誰も望まないツールを生むこと。
舗装された道ではなくゲート。 正当な仕事を妨げるガードレールは、チームにプラットフォームを完全に迂回させること。
単一の生産性指標。 生産性を一つのゲーム化できる数字に還元することは、行動を歪め、信頼を侵食すること。
監視としての測定。 個人を順位づけるのに使われる開発者体験の指標は、プラットフォームが必要とする心理的安全性を破壊すること。
逃げ道のないゴールデンパス。 本物の端のケースに合わせて曲がれない硬直した道は、障害物になること。
資金不足のプラットフォーム。 プラットフォームを副業として扱うことは、それを飢えさせ、貧しい体験を保証すること。

成熟度モデル

レベル1: 開始。 プラットフォームは存在しません。各チームが自分のツールとインフラストラクチャを反応的に組み立て、チケット駆動の引き継ぎ、重複した解決、高い認知負荷が重くのしかかります。すべてのチームが、プロビジョニング、デプロイ、コンプライアンスを自力で、一貫せずに解きます。

レベル2: 発展。 共有のツール、テンプレート、スターターリポジトリがいくつか現れますが、しばしば熱心なエンジニアが作ったもので、断片的で部分的に手作業です。いくつかのチームはゴールデンパスを採用し、他は無視し、セルフサービスは限られ、開発者体験は測定されないので、プラットフォームの価値は逸話に頼ります。

レベル3: 標準化。 プラットフォームチームが、文書化されたゴールデンパス、セルフサービスのプロビジョニング、サービスカタログを備えた開発者ポータル、スコアカードを、組織全体に適用して運営します。セキュリティ、方針、コンプライアンスのガードレールが舗装された道に埋め込まれているので、標準のワークフローが準拠したものであり、同じ慣習が、グループごとに変わるのではなくチーム間で成り立ちます。

レベル4: 管理。 プラットフォームが、ベースラインに対するデータで測定され制御されます。採用、満足度、最初のデプロイまでの時間、リードタイム、デプロイ頻度が、SPACEのようなバランスのとれた枠組みと、調査とシステムのシグナルの組み合わせで追跡され、スコアカードの結果がレビューに反映され、認知負荷、オンボーディング時間、取り戻された開発者の時間が目標に対して監視されます。能力に投資するか退役させるかの決定は、擁護ではなく証拠に基づきます。

レベル5: オーケストレーション。 プラットフォームは、高い自発的な採用を持つ成熟したプロダクトで、開発者のフィードバックと指標から継続的に改善され、組織全体でセキュリティ、コンプライアンス、デリバリーの計画と統合されています。ゴールデンパスはニーズが移るにつれて適応し、ガバナンスは標準のワークフローの目に見えない性質であり、プラットフォームチームは、技術と組織が進化するにつれて、能力を日常的に退役させ、置き換え、範囲を見直します。

議論のためのアイデア

義務づけずにプラットフォームの採用を勝ち取るにはどうし、義務が正当化されるのは、あるとすればいつですか。
どのゴールデンパスが、あなたのチームに最初に最も価値を届けますか。
監視のように感じさせずに、開発者体験をどう測定しますか。
特異なチームがプラットフォームから完全に押し出されないよう、逃げ道はどこに存在すべきですか。
仕える開発者に対して、プラットフォームチームの正しい規模と資金のモデルは何ですか。
開発者ポータルとツールについて、何を自社で築き、何を買うかをどう決めますか。

要点

プラットフォームを、チームを本当に速くすることで採用を勝ち取るプロダクトとして運営します。
正しく、安全で、準拠したやり方を容易なやり方にする、ゴールデンパスと舗装された道を提供します。
チームがチケットと引き継ぎを待つのをやめるよう、本物のセルフサービスを届けます。
所有、アーキテクチャ、品質を可視にするために、ポータル、カタログ、スコアカードを使います。
開発者体験は、SPACEのようなバランスのとれた枠組みで測定し、ゲーム化できる単一の数字では決してしません。
認知負荷の削減を、プラットフォームの中心的な目的として扱います。

参考文献とさらなる読み物

Matthew Skelton and Manuel Pais, Team Topologies.
Nicole Forsgren, Margaret-Anne Storey, Chandra Maddila, et al., “The SPACE of Developer Productivity” (paper).
Nicole Forsgren, Jez Humble, and Gene Kim, Accelerate.
Gregor Hohpe, The Software Architect Elevator.
Camille Fournier, The Manager’s Path.
Cloud Native Computing Foundation, platform engineering white paper.