これはなに

下記の口頭発表に対する補足記事である。

• 演題: “PfEingのアプローチで働こう”
• イベント名: 【3-shake × enechain】SRE Tech Talk #15
• 日時: 2026年9月4日
• 場所: 株式会社スリーシェイク（東京, 銀座）

この記事では、時間の制約から口頭発表には含められなかった情報を補足として紹介する。

スライド各ページの補足

（タイトル）

本発表で話したのは「PfEingアプローチ」 ではない。 これでは、私が新しい用語を考え出したことになってしまう。

あくまでも「PfEingのアプローチ」だ。

「プラットフォームエンジニアリング」はスライド上では幅を取りすぎるので “PfEing” で統一した。 視覚上は短くなったが、読みは同じなので噛みそうなのは変わらない。

（自己紹介）

サイボウズが提供しているキントーン（kintone, Kintone）というサービスは、単一（というと語弊があるが）のアプリケーションソースコードを国内向け（cybozu.com）・国外向け（kintone.com）二つの基盤で動かすことでエンドユーザーに提供されている。

ちなみに、キントーンのアルファベット表記は、国内向けでは小文字始まりのkintoneなのに対し、海外向けではKintone。

私のチームはkintone.comのプラットフォームを開発・運用しているプラットフォームチームで、社内では通称Yakumoチームと呼ばれている。

10年近い歴史を持つチームなので、記事の中には古くなっているものもあるが、サイボウズのテックブログを “Yakumo” カテゴリで検索すると技術記事がヒットする。

名前の由来をふくむ、Yakumoチーム自体については下の記事にまとまっている。

「やっていること」

本発表はプラットフォームエンジニアリング的な働き方について述べたものだが、別のアプローチの働き方をした経験があるので前職の例と対比した。

DevOpsをチーム名に冠すること自体についてはここには書ききれないので、別の機会に書こうと思う。

「PfEingチームの働き方」

発表には含められなかったが、最近はプラットフォームエンジニアリングに関して、下記のテーマについて考えている:

• PfEingというアプローチそれ自体
• プラットフォームの “optional” という特性と、それが満たされないときに起こること
• 一応の運用が効果計測を目的とした計装と社内の信頼残高との関係
• 責務境界のあるべき姿とストリームアラインドチームの負担増

上記のうち、「PfEingというアプローチ」に関して、LTサイズに切り出せるメッセージが見つかったので本発表を作った。

本スライドに示したのは、本発表が特に影響を受けた下記の記事・書籍である:

• “What I Talk About When I Talk About Platforms” Bottcher (2018)
• “CNCF Platforms White Paper”
• “How Platform Engineering Works” McElligott (2023)
• 『プラットフォームエンジニアリング』Fournier & Nowland (2025) オライリー・ジャパン
• 『実践 プラットフォームエンジニアリング』Chankramath et al. (2026) マイナビブックス

「損益分岐点がある」

こんにち（2026年）では、「プラットフォームエンジニアリング」という言葉が定着しつつあるため、このデシジョンツリーを使うなどして「プラットフォームエンジニアリングをするかどうか」というメタ認知を持ってプラットフォームチームを立ち上げられる。 プラットフォームチームにとって（もちろん組織全体にとって）、これは本当に大きい利点だ。

この言葉がなかった頃から、形を変えながら続いてきたプラットフォームチームでは、プラットフォームとして必ずしも適切とはいえない責務を抱えていることがあると思う。

「常に必要な自問」

「自分たちはPfEingできているか？」

現実世界でちゃんとPfEingするのは本当に難しいので「できているか」を強調してある。

プラットフォームエンジニアは、自分達の働き方について、本当に自覚的になる必要がある。 プラットフォームエンジニアの場合、他チーム¹から見て「いい仕事」をしているように見えても、プラットフォームエンジニアリング的に誤ったアプローチで働いてしまうというケースは、いくらでも生じうる。 顧客の満足が必ずしも

宿命的にROIが重要

これには引用があるわけではなく、発表において言葉の簡潔さとパワーを得るためにこのフレーズを使った。

といっても、プラットフォームエンジニアリングについて色々な情報を読んでいれば意味するところは理解いただけるのではないかと思う。

関連する記述を具体的に揚げるとすれば、『プラットフォームエンジニアリング』では、プラットフォームチームは、より大きいものを管理するために自チームのサイズを大きくすることに慎重になる必要があることを指摘している（13.3「成長をコントロールすることによる複雑性の管理」）。 これは単純にROIの分母が大きくなってしまうだけではなく、働き方の質を変えるための吟味の機会を失うことも意味するからだ。

「PfEingのアプローチ」

どこから取ろうがエッセンスは変わらないが、ここでは代表としてCNCFのPlatforms White Paperからの引用を示した。 このドキュメントは短いが、読むたびに新しいテーマについて考えるきっかけが得られるので、私は定期的に読むようにしている。

ちなみに現時点のPlatforms White Paperは、雑にキーワード検索するとApp Delivery TAG版の古いドキュメントがヒットしがち。 現行のドキュメントはcloudnativeplatforms.comのこちら。

「気を抜くとかんたんに外れうる」

プラットフォームエンジニアリングチームがどう働くべきチームなのかを、組織の中で最もよく理解しているのはプラットフォームチーム自身だ。 そもそも「依頼」という言葉自体、危険な香りがする。 プラットフォームチームとしては、TicketOps的な慣習をアンラーニングし、顧客チームとの関わり方自体も組織として成熟させていく必要がある。 『チームトポロジー』の用語で言うならば、ここで言っているのは「顧客チームとの “コラボレーションモード” を “X-as-a-Service” に変えていけ」という話ではない。 新しいケイパビリティの探索フェーズでは、コラボレーションモードが必要になる。 ここでは「依頼を受けて作る」という働き方を、雑に「コラボレーションモード」と呼んだりはするな、という意味で言っている。

余談だが、参考リンク先の「Terraformスタータキット」のアンチパターンの例²については、もしスタータキットのモジュール配布だけをやっていた場合には少しマシになる³という理解。

「どうしても断れない依頼」

このケースは、最初からプラットフォームチームとして設計されて立ち上がった、新しいプラットフォームチームでは起こりにくいのかもしれない。

一方で、形を変えながら続いてきたプラットフォームチームには、このパターンはよく発生するのではないだろうか。

「…現実世界はいろいろあるけど」

プラットフォームエンジニアリングは全体最適を追求する働き方だ。 全体最適は組織にとって善きものだが、それを推進する取組みもまた善きものと見られるかどうかは、他のタスクとの比重に因っている。 他チームに預けた信頼残高も関わってくる。

謝辞

発表の機会を提供してくださったスリーシェイクさん、enechainさん、ありがとうございました。