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

社内向けの開発基盤に専任チームを置く組織は、この数年で目に見えて増えた。増えたのは事実として観測できる。その基盤が何を削減したのかを数字で示せる組織がどれだけあるかは、別の問題である。

プラットフォームとは何を指すのか

Evan Bottcher は2018年の「What I Talk About When I Talk About Platforms」で、社内プラットフォームを、明確に定義されたセルフサービスの基盤であり、製品チームがそれを使うかどうかを自ら選べるもの、として特徴づけている。この特徴づけには二つの条件が埋め込まれている。セルフサービスであること、そして選択可能であることだ。

選択可能性の条件は、しばしば無視される。利用が義務化された基盤は、利用率という指標では成功に見える。だが義務化は、その基盤が選ばれるだけの価値を持つかという問いを封じてしまう。

認知負荷という設計変数

Skelton と Pais の『Team Topologies』（2019）は、チーム構成を認知負荷の観点から設計する枠組みを提示した。同書におけるプラットフォームチームの役割は、ストリームアラインドチーム（製品を届けるチーム）が扱わなければならない事柄の総量を減らすことにある。

この枠組みが有用なのは、基盤の成否を「機能の多さ」ではなく「製品チームが知らずに済むことの多さ」で測る視点を与えるからだ。機能が増えても、それを使うために学ぶべき概念が増えるなら、認知負荷は減っていない。

1968年に Melvin Conway が述べたとおり、システムの構造は組織の構造を反映する。基盤の設計はチーム境界の設計であり、技術的判断であると同時に組織的判断でもある。

効果をどう測るか

Forsgren、Humble、Kim による『Accelerate』（2018）と、その後の DORA レポート群は、ソフトウェア配送の性能を四つの指標で捉える枠組みを普及させた。

• デプロイ頻度
• 変更のリードタイム
• 変更失敗率
• 復旧までの時間

これらは基盤の効果を測る候補になる。ただし注意すべき点がある。四指標は組織全体の配送性能を測るのであって、基盤の寄与を他の要因から分離しない。同時期に採用が進んだ、あるいは製品の性質が変わった、といった交絡が入る。

反論：短期で測れないものがある

基盤への投資が回収されるまでには時間がかかる、という主張はしばしば擁護に使われる。この主張は、少なくとも部分的には正しい。標準化された配備経路の価値は、事故が起きたとき、あるいは人員が入れ替わったときに顕在化する。平時にはコストにしか見えない。

もっとも、この主張には検証不可能性という問題がついてまわる。「効果は数年後に現れる」は、いま効果が見えないことの説明にも、効果がないことの言い訳にも、同じように使える。区別するには、中間指標を先に宣言しておくしかない。新しいサービスの初回デプロイまでの日数、オンコール担当が参照する手順書の数、といった具体的な量である。

削減されたものを記録する

基盤チームが提示できる最も強い証拠は、以前は各チームが個別に行っていた作業のうち、いま誰も行っていないものの一覧である。監査ログの設定、証明書の更新、依存関係の走査。これらが基盤側に吸収されたなら、供給網の検証のような横断的な要件も、一箇所で満たせるようになる。

逆に、基盤が既存の作業を吸収せず、その上に新しい抽象を積んだだけであれば、認知負荷の総量は増えている。この判定は利用率では行えない。何を測るかの選択が、そのまま何を成功と呼ぶかの選択になっている。