こんにちは。取締役兼ACS事業部の責任者の上林です。
前回の記事「なぜDevOpsの発展にプラットフォームエンジニアリングが必要になるのか？」から間が開いてしまいました。前回お約束した通り、プラットフォームエンジニアリングに関して、海外での動向について少しお話をさせて頂ければと思います。掲題の「DevOpsは死んだ？」や「Googleは私たちに嘘をついた」など、過激なことが言われている側面も取り上げます。
まずは世界の動向ということで、少し私なりの解釈でプラットフォームエンジニアリングに関連するここ数年の歴史を見ていきたいと思います。見解についてはあくまでの個人の見解ですのでご了承ください。なお、プラットフォームという言葉で見てしまうと2011年にIDCさんが第三のプラットフォームを提唱したなど話が膨らんでしまう側面がありますので、ここではプラットフォームエンジニアリングに閉じて記載させて頂きたいと思います。なにかのお役に立てば幸いです。
2017年 始まりはいつもThougtWorks？
プラットフォームエンジニアリング自体がワードとして初めて登場したのは、(自分の認識している限り)アジャイルのリーディングカンパニーでもある「ThoughtWorks社の2017年のTechnology Radar」です。記載を読む限り、新しいアイディアというよりは、すでに一部の先行企業が取り組んでいる概念をまとめているものでもあるので、考え方の歴史自体はもっと前と言えると思います。このタイミングですでにセルフサービスという概念、DevOpsと異なるという点は言及されています。
2018年 DigitalPlatformについての記事
そして、2018年には、同じくThougtWorksのEvan Bottcherさんが「DigitalPlatformについての記事」を書かれています。データも含めた広範囲のプラットフォームについて語っており、技術要素がチームごとにサイロ化される問題点について語られています。この記事の中も、セルフサービスAPIやナレッジなど、プラットフォームエンジニアリングの骨格となる複数の要素が定義されています。
2019年 ジャイアントインパクト Team Topologies登場
そして2019年、別の切り口から大きなインパクトがあります。書籍「Team Topologies」の登場です。アジャイル組織に必要な考えを、組織論、コンウェイの法則、数々のアジャイル組織の体験談をもとに、体系的かつ論理的にまとめられたアジャイル組織の構築モデルです。この中にPlatform Teamというものが定義されたことで、概念が広く知られたのではないでしょうか。実際私はこの原書を通じて概念を知りました。なお昨年(2022)や今年(2023)のPlatformConにおいても、Team Topologiesの著者のManuel Paisさんが連続で登壇されるなど、今でもプラットフォームエンジニアリング界隈と近い関係性にあることが見られます。
2021年 Technology RadarにおいてAdoptに
前述したThoughtWorks社のTechnology Radarにおいて、プラットフォームエンジニアリングは「Adopt」すなわち、「プロジェクトで役に立つのであれば採用して良い段階(4段階中一番成熟した段階)」に変更されています。つまり普及期に入ったとお墨付きが出た形です。なお、この中で、Team Topologiesについても言及があり、プラットフォームチームを構成する際にTeam Topologiesを利用することが推薦されています。
2022年 ガートナーのハイプサイクル入り
コミュニティ活動が活発化した年で、プラットフォームエンジニアリングに関するコミュニティイベントである「PlatformCon」が海外にてGoogleをはじめとした複数のツールメーカー主導で初めて開催されました。リモートとは言え第一回にも関わらず、78のセッションと6000人以上の参加者を集めました。そして、その流れを受けてなのか、7月に転換点としてガートナー社のハイプサイクル入りがありました。ここで一気に注目を集めた印象があります。
2022年 DevOpsは死んだ？
さてこのあたりから少し界隈が騒がしくなります。ハイプサイクルからの勢いで記事化されたのか、話題になったのが1か月後に出た記事「DevOpsは死んだ？」です。
「DevOps Is Dead. Embrace Platform Engineering」
拙訳すると「DevOpsは死んだ。プラットフォームエンジニアリング万歳」ということでしょうか。
開発者がOpsをどう感じているかのアンケートやガートナーの記事を引用しつつも、「開発者の生産性を上げるため、プラットフォームエンジニアリングを適用しよう」という記事です。短い記事ですが題名も含めてパンチがある印象です。
ただし、これがとあるツールメーカーの方の書いた記事だったところもあり、それに対して、反論があります。
「Is DevOps Dead? I Don’t Think So!」
拙訳すると「DevOpsが死んだって？ そうは思わないね」というところでしょうか。
反論、と言いつつも読んでみると、かなり冷静な記事で「DevOpsは死んだと言っているのはメーカのマーケティングみたいなもの」「一方で、DevOpsに課題があることは事実だが、死んではないよね」という記事です。
確かに「～は死んだ」的な言い回しはインパクトがあってマーケティング的に使われることが多い印象です。「NoOps論争」や「APIマネジメントは死んだ」など古くから似たような手法を記憶しています。私の書いているこの記事の題名もマーケティングの一種かもしれませんw
一方で、より詳細な課題にメスを入れた記事も登場します。「モノリスからマイクロサービスへ」の著者であるSam Newmanさんの記事です。
「Don't Call It A Platform. Down with The Platform, up with Developer Enablement」
拙訳すると「プラットフォームと呼ぶな、開発者を力を与えろ」というところでしょうか。
一部記事から引用すると、DevOpsやクラウドネイティブのツールについて以下のような強烈なことが書かれています。
「現実には、プラットフォーム エンジニアリングに関する取り組みの多くは、開発者に力を与えることではなく、私たちが集めた膨大ながらくたの山を隠すことであり、そもそもそれを手に入れたと思われる人々から隠す必要があります。それは、子供にプレゼントをたくさん買って、危険すぎて使えないので隠しておき、実際には自分のためにプレゼントを手に入れたようなものです。あなたの子供は本当にその複合狩猟弓を必要としていましたか?」(Chrome翻訳)
The reality is, much of the effort around platform engineering is NOT about empowering developers, it’s about hiding the towering pile of crap we’ve assembled and now have to hide from the people we apparently got it for in the first place. It’s like buying a bunch of presents for a child, then having to hide them because they’re too dangerous for them to use, and in reality you really got them for yourself. Did your kid really need that compound hunting bow?(記事原文)
記事全体を大胆に意訳すると主張は「お金を大量調達しているメーカーのプロモーションは強力」「メーカーは売ることが目的となる」「技術の目的化のリスクがある」というところでしょうか。
一方で、こちらもプラットフォームエンジニアリングを全否定しているわけではなく、「Platformという名前が危険で、本質である開発者の立ち上がりに力を入れるべき」とも言っています。
2023年 Googleは嘘をついた？ あるいはミスリードした
ところ変わって、2023年、日本でも面白い記事が書かれました。HashiCorp社ののCTOが掲題のようなちょっと過激なことを語っています。
「「Platform Engineering」という言葉はなぜ生まれた？ HashiCorpのダドガー氏に聞いた」
これは過激なようにも思いますが、SRE本で私たちが学んできた「Googleが提唱したSREという概念」は大抵の組織には難しすぎる、それを真似すると失敗するぞ、というプラットフォームエンジニアリングの本質を伝えているお話かと思います。確かに、弊社でSREを行っている部隊もおりますが、SREは奥深く、その内容を現場全体全員がしっかりと把握しながら実施している状況は少ないように感じています。正しいけれど難しい、誰しもが簡単にできるわけではないのがSREだという印象です。
プラットフォームエンジニアリングはメーカーのポジショントーク？
このように、プラットフォームエンジニアリングの特性上、コミュニティはツールメーカーが主導していることが多く、マーケティングの一環と見られる少し過激な記事が見られる印象があり、ツールメーカーのマーケティングなのか？と訝ってしまう側面はあると思います。多分事実そういった側面もあるのではないでしょうか。
技術やツールが提供する価値にフォーカスしているのか、技術やツールを売ることが目的になっているのか、目的と手段のはき違えは多かれ少なかれ発生する問題であって、資本主義のルールからすると売ろうと頑張っている企業を否定するのは酷ですし、否定するものではないと考えています。そういったアニマルスピリッツが進化や変革を生むことも事実です。特に一社独占でなにかを扇動しているのであれば別ですが、様々なツールメーカーが入り乱れてて主張や反論がされているのは、議論や選択の自由が担保されていることでもあり、健全なのかなとも感じています。
実際のところ、メーカーのマーケティングかどうか、我々のようなSIerとしてのポジショントークかどうかは実はそんなに重要な問題ではないのかなと考えています。本当に良いものでなければ、一企業が頑張ったところで大きな波を作るのは不可能だからです。いま対話型のAIが大きな流行になっているのは、そのソリューションの価値にインパクトがあるからで、企業のマーケティングだけで起きているものではないと思います。プラットフォームエンジニアリングも事実として海外コミュニティでは、単なる話題を超えて、具体的な事例がすでに多く出てきています。その事実が重要であると考えます。
終わりに
いかがだったでしょうか。このように、プラットフォームエンジニアリング界隈では色々なことが語られつつ、事例が確実に増えてきています。
メーカーのポジショントークがあるのは資本主義において当たり前なのであって、重要なのは選ぶ側が「組織ごとにスキルやシステムの状況は異なること」を把握し「ツールなどの情報をしっかりと把握し適切な技術を選択すること」だと言えます。厳しい選別の目に晒されれば、価値の少ない技術は淘汰されるでしょう。過激なマーケティングが問題なのではなく、本質的な価値と選ぶ側のスキルにこそが大事、というのが私なりの視点です。もちろんそれが難しいわけですが…。
そんな、最新情報を積極的に交換・入手すべく、日本においても、Platform Engineering Meetupというコミュニティ活動が実施されております。次回の第三回では6/8-9に行われるPlatformConのRecapも行う予定です。無料ですので最新情報を入手したい方はぜひご参加頂ければと思います。名古屋で行われますが、リモートで視聴可能です。弊社エンジニアもRecapで登壇させて頂きます。
そして我々は、内製化をビジネスの軸としておいておりますので、独立系企業としてこういったプラットフォームエンジニアリングのツールの選別についても顧客目線でのご支援が可能です。ぜひ選定でお悩みの方はご相談ください。という、SIerのポジショントークで本blogを締めさせて頂ければと思いますw
