内製プラットフォームは何を削減したのか

「プラットフォームエンジニアリング」というラベルは2022年以降、DevOps の後継として急速に広まった。中身が何を指すかについて業界内の合意はない。流行を追って DevOps チームを改名しただけの組織と、実際に運用モデルを変えた組織とで、成果に差が出始めている。差を生んでいる構造を三点に分けて見る。

内部プロダクトとして設計するということ

Skelton と Pais の『Team Topologies』は、プラットフォームチームを開発者体験を製品として設計するチームと定義した。重要なのは「製品として」の部分にある。プラットフォームは開発チームが選択的に使うプロダクトであって、強制されるインフラではない。推論基盤のような特殊ワークロードを抱える組織でも前提は変わらない。

この転換が理解されないと、プラットフォームチームは「開発チームに使い方を教える」役割に落ちる。教育コストは高く、しかも開発チームが増えるほど線形に膨らむ。製品として設計されたプラットフォームは、教育なしで採用されることを目標に置く。

違いは指標に出る。オンボーディング時間、初回デプロイまでの日数、サポートチケット数。これらを測っていないプラットフォームチームは、自分たちが正しい方向に進んでいるかを判断する材料を持たない。逆に言えば、測り始めた時点で議論の質は変わる。

認知的負荷は測れる

『Team Topologies』が持ち込んだ認知的負荷という概念は、プラットフォームの価値評価に使える。開発チームが自分たちのサービスを本番に届けるために理解しなければならない事柄の総量、と定義すれば、良いプラットフォームはこの総量を減らす。悪いプラットフォームは抽象化のレイヤーを増やすだけで総量を減らさない。増やす場合すらある。

測定はアンケートで足りる。本番デプロイのために理解する必要があるツールの数、トラブル時に相談すべき相手の数、独立してリリースできると感じるか。この種の質問セットは多くの組織ですでに運用されている。四半期ごとに実行してプラットフォーム変更との相関を取っている組織となると、数は少ない。配送性能の指標と組み合わせれば、プラットフォームの効果は定量化できる。

敵対関係は設計から予測できる

プラットフォームチームと開発チームが対立する構図には、再現性のある前提条件がある。プラットフォーム利用が強制であること、プラットフォームチームの評価指標に利用率が含まれること、開発チームの目標にプラットフォーム移行が課されること。この三つが揃うと、ほぼ確実に敵対関係へ発展する。

揃った先で何が起きるかも決まっている。プラットフォームチームは「なぜ使われないか」を開発チームの怠慢に帰属させ、開発チームは「なぜ使いたくないか」を製品品質の問題として説明する。どちらの主張も部分的に正しく、そして噛み合わない。

予防するには、プラットフォームチームの評価指標を利用率から利用者の代替時間削減へ置き換える必要がある。組織の評価文化に踏み込む話なので、技術的な議論だけでは実装できない。ここで詰まる組織は多い。

ラベルを変えるだけなら混乱が増える

プラットフォームエンジニアリングは DevOps のリブランドにすぎない、という懐疑論は業界内で根強い。公開されているプラットフォームチームの職務内容と5年前の DevOps チームの職務内容を比べると、共通項目が多いのは事実である。

それでもラベルの変更が組織行動を変える場合はある。プラットフォームを製品として定義することで、内部プロダクトマネジャーの配置、ロードマップ管理、利用者フィードバックのサイクルといった、DevOps 時代には稀だった運用が正当化される。DevOps でも可能だったが実装されない組織が多かった。ラベルが実装を後押しするなら、リブランドにも価値はある。

導入判断は組織の準備度合いから逆算するのが現実的だろう。内部向け製品管理の経験、認知的負荷を測る文化、評価指標を変える権限。どれかひとつでも欠けた状態で名称変更だけ実施すると、失敗確率が上がる。技術戦略というより組織戦略の問題で、CTO や VP of Engineering が単独で決められる範囲を超えていることが多い。