はじめに
こんにちは、ひよつくです。
みなさんプラットフォームエンジニアリングには興味ありますか？
私は業務でもプラットフォームエンジニアリングを頑張ろうとしているところです！
本稿は2025年9月18日に参加したPlatform Engineering Kaigi 2025に関する参加レポート・感想です。
だいぶ日が空いてしまいましたが、お付き合いください。
プラットフォームエンジニアリングって何？
そもそもプラットフォームエンジニアリングってなんでしたっけって話ですよね。
よくIT技術のハイプ・サイクルなどを発表しているGartner社によると以下のように定義されています。
プラットフォーム・エンジニアリングとは、ソフトウェアの開発とデリバリを目的とした、セルフサービス型の開発者プラットフォームの構築と運用に関する専門分野です。
要するに開発者向けの社内製プラットフォームということですね。
このプラットフォーム・エンジニアリングは、Gartner社によって 「2024年の戦略的テクノロジートップ・トレンド」の一つに選出され、今後5年間でソフトウェアエンジニアリング組織の実に80%が採用するとの予測が示されています。
また、「2025年のGoogle Cloudレポート」では、プラットフォーム・エンジニアリングの導入が市場投入までの時間を大幅に短縮するという具体的な成果も報告されていてますます重要度が上がってきていると言えるでしょう。
そろそろみなさんも気になってきたんじゃないでしょうか。
Platform Engineering Kaigi 2025
Platform Engineering Kaigi(以後PEK)はそういうプラットフォームエンジニアリングに関するオフラインイベントでした！
面白かったセッションを紹介します。
認知負荷理論で挑むPlatform Engineering
認知負荷ってIT業界でよく聞く言葉ですよね。
今までなんとなく使ってましたけど、認知負荷への対策を論理的に分析したところが面白かったです。
中でも認知負荷の種類を3種類に分け、「学習関連負荷」だけは発生させた方が認知負荷が結果的に下がるという点が興味深い結果でした。
以下は認知負荷の種類をセッションから引用したものです。
認知負荷の種類
- 課題外的負荷（extraneous cognitive load）
理解・目的に無関係な要因による余計な負荷。できるだけ削減すべき
例：ツールのインターフェースが使いにくいために生じる負荷- 課題内的負荷（intrinsic cognitive load）
課題そのものの複雑さから生じる負荷。その対象を理解するためには避けられない
例：新しい言語の文法を理解する際の、文法そのものの難しさによる負荷- 学習関連負荷（germane cognitive load）
知識を定着させ、理解を深めるための処理で生じる生産的な負荷。積極的に発生させるべき
例：習得した文法を使って、問題を解決しようと試行錯誤している際に生じる負荷
課題外的負荷と課題内的負荷は当然下げた方がいいですが、学習関連負荷はむしろ高めた方がいいという結論でした。
つまり何も学習せず使うプラットフォームは結果的にユーザーの認知負荷を高める状態になってしまうということです。
確かにAWSとかも何も知らずにポチポチしてたらなんとなくでもアプリが動くけど、ちゃんと仕組みを勉強しておかないとあとあと大変なことになりますしね。
段階的スキーマの構築による認知負荷対策
でも学習関連負荷を多く発生させると言っても、ただ勉強するだけでは人によって効率がバラバラですよね。
そこで出してきたのが「段階的スキーマの構築」という概念で、要するに現状の知識量に応じた学習負荷をかけるのが効率がいいということですね。
（※スキーマとは「知識のネットワーク」のようなもので、特定の知識を領域化したもの）
すでに持っているスキーマと関連する知識の領域から学習関連負荷を高めて行けば、もっとも効率よく認知負荷を下げられるということです。
エンジニアにとって学習すること自体の抵抗は少ないと思いますが、限られた時間の中でどれを効率よく学習するかの問題はあると思うので、心理的な負担なく学習関連負荷を上げられる工夫がプラットフォームには問われますね〜
使いづらい社内プラットフォーム
セッションでも懇親会でもよく聞く話が、結局社内プラットフォームがあっても使いづらくて使ってないという意見でした。
これはなかなか難しい問題で、最近はAWSやGoogleCloudといった大手ITベンダーも開発者向けプラットフォームを出しているので大手ITベンダーとの競合になるのは辛いところですよね〜
従量課金でちょっとお金払えばほぼ完成された開発プラットフォームがクラウド上でサーバーレスですぐ使えるわけなので、内製化を相当頑張らないとこことの競合は難しいですよね〜
SREとしては「本当に開発者が欲しいもの」はたまに見えなくなるものなので、やっぱりプラットフォームをプロダクトとしてミニマルで良いものにすることが最重要課題だと感じています。
まとめ
もうこのイベントに参加してから2ヶ月も経ちましたが、その間に個人的にもいろんなことがありました...
やっぱりプラットフォームって可能な限りミニマルにスタートして、認知されないうちにしれっと導入されてユーザー数を増やし、いつの間にか社内でメジャーなソリューションになってるのが理想だと思いました。（Plaque.inc作戦）
自ら苦労して検証もされてない社内製のプラットフォームを使いたがる人はなかなか少ないと思いますしね！
まずはドキュメントとこういうブログから地道に頑張っていこうと思っていますので今後ともよろしくお願いいたします〜
Discussion