こんにちは。取締役兼ACS事業部の責任者の上林です。
突然ですが、先日こんな記事がASCIIさんに掲載されました。
「メディア向けの勉強会に呼んでもらったのだが……プラットフォームエンジニアリングがわからない」
実は、これ小職がメディア向けの勉強会を実施させて頂き、それを記事にして頂いたものです。
「一般的なメディアに向けてもわかってもらう」というテーマで、なるべく詳細になりすぎずイメージを伝えることを狙ったのですが、結果恥ずかしながら「わからない」ということで、今後精進していきたいと考えています。勉強会にご参加いただいた記者の方からは「Whyは大事。これが腹に落ちないと、話の全体を理解しきれない。「業界の人じゃないとわからないだろうから」と諦めず、背景・既存の仕組み・課題、を丁寧に説明をした方がいい」、というありがたいフィードバックも頂きました。開発に明るくない方にも伝わりやすくなればと、料理の鉄人を題材に例えてWhyの説明を試みましたが、それがかえって伝わりにくくしてしまったので、次回は開発の話をわかりやすく伝えられるようがんばります。
今回はその反省を踏まえてた第一弾として、「なぜPlatform Engineeringはわかりづらいのか」をちょっと考察してみました。
自分自身、これまで営業の一環で、主にお客様を中心に「インフラチーム」「開発チーム」「CTOやアーキテクト」「情報システム部」「経営の方」「記者の方」など、様々な立場や役割の方にPlatform Engineeringの説明を試みて来ましたが、立場によって大きく反応が異なるのが特徴だと感じています。新しい言葉なんだから当たり前と言われるかもしれませんが、例えばLLMなどの用語と比べても捉え方のブレ幅が大きいように感じます。
一例をあげると、経営の方だと「標準化の営みである」との反応があったり、エンジニアの方だと「これはXXと同じじゃないの？」「これはXXと違うものでしょ」と対比するXXもいろいろ異なることが多いです。
この理由ですが、Platform Engineeringは前提として「これまで存在する様々な概念やプラクティス、提供価値や技術、組織論や文化などを全部入りレベルで盛り込みつつ新しい形で整理しているから」が源泉にあるからと考えています。その結果、論理的にも心理的にも以下のことが発生しているのではないかと考察します。
①これまで考えと特別な違いやなにが変わったかがわかりづらい
②誰にどんな具体的な価値を届けることにフォーカスしているのかわかりづらい
③誰のどんな具体的な課題をどのように解決するのかがわかりづらい
④過去を否定されていると感じるからわかりづらい
個別に考察させて頂きます。
「①これまで考えと特別な違い、なにが変わったかがわかりづらい」
例えば「DevOps、SRE、IaC化、CI/CD…そこと何が違うの、今やっているよ、それでは解決できないの？」「プラットフォームって社内共通基盤でプラットフォームチームって共通基盤チームでしょ、今までと何が違うの？」という「わかりづらさ」かと考えています。
前者については、それらのプラクティスを適用/導入しようとする際に発生する課題やそれに伴う複雑性を解決しようとしている、それがPlatform Engineeringと言えると思います。以前と違って、開発チームはコンテナのYAMLファイル、デプロイメントパイプラインの使いこなし、複数リポジトリの把握、などなど、運用後の品質を保ちながらリリース速度を向上するべく、やるべきことや使いこなすツールが増えているのです。
また後者については今までの共通基盤という考えで実現できなかったことを解決していくのもPlatform Engineeringだと考えています。
フォーカスすべき課題と、これまでのやり方の違いを明確にしていくのが今後のポイントでしょうか。
「②誰になんの価値を届けるものなのかわかりづらい」
Platform Engineeringを説明するのに登場人物が多くなる場合があり、この「わかりづらさ」に繋がっていると考えています。Platformという名前から、インフラの話？と誤解される側面もあります。
メインのフォーカスは「開発チームの開発者体験」でよいと思いますが、それ自体も概念的ですし、その結果ついてくるリリース速度の向上や開発組織の拡大の容易さなど、関係する様々な立場の人に様々なベネフィットが得られるところが、理解においてはつまづきになっていそうです(もちろんベネフィットが多いことがPlatform Engineeringの意義でもあります)。ベネフィットが得られる関係者も「インフラチーム」「開発チーム」「CTOやアーキテクト、テックリード」「情報システム部」「事業責任者」「経営」など様々です。例えばDXを推進したい経営が既存の情報システム部のリソース課題を抱えている場合、Platform Teamの立ち上げはそれを解決する価値を生む可能性があります。そういった意味で価値は広範囲にわたりそうです。
Platform Engineeringの対話において、誰に対してのどの価値の文脈で話しているかを明確にするのは今後のポイントでしょうか。
「③誰のなんの課題を解決するのかがわかりづらい」
②の裏側にもなりますが、ここについても「この課題」と議論が一つにまとまりづらく、わかりづらさに繋がっていると考えています。
メインのフォーカスは「開発チームの認知負荷の増大や体制拡大の課題」と自分は捉えていますが、その課題の原因となる様々な課題も嘘ではないからです。例えば「共通基盤の進め方の難しさ」「テックリードの方への属人的な負担」「インフラチームや情報システム部への依頼の増大」などなど、数々な問題があり、結果メインの課題に繋がっているからです。
こちらについても、誰のどんな課題の文脈で話しているかについて明確にするのは今後のポイントでしょうか。
「④過去を否定されていると感じるからわかりづらい」
これは心理的な側面です。わかりづらい、というより「受け入れづらい」が近いかもしれません。
Platform Engineeringには、改善ではなく改革、という側面があると考えています。ある種、これまで誠実に開発チームからの作業依頼をさばいて来たり、地道に改善を積み上げてきた方々のやりかたではなく、違ったアプローチを期待されている、という側面があると考えています。それはこれまでのやり方で仕事を実施してきている方々からすると、仕事の仕方やプライドを否定されている、ことに繋がっているのではないかと推察しています。例えば、「DevOpsは死んだ」などと煽情的に書かれた記事などはマーケティング目的かもしれませんが、そういった効果を生んでいる可能性がありそうです。実際には対立する概念ではなく、これまでSREなどを実施された方々のお持ちのスキルは、Platform Engineeringの世界で更に生かせるものです。
このような対立や分断ではなく、本質的な目的に対してよいところは取り入れていくスタンスも重要そうです。
ちなみにPlatform EngineeringとSREの違いについては、次回の「Platform Engineering MeetUp #5」でも取り上げられるようですので、是非ご参加ください(コミュニティの宣伝です)。
platformengineering.connpass.com
取り急ぎまとめてみましたが、いかがでしょうか。今後それぞれの項目について、別のblogでもう少し深堀していきたいと考えております。もっとこういう部分もあるんじゃない？ などフィードバック頂ければありがたいです！
我々は、クラウドネイティブ技術・Team Topologies・Platform Engineeringなどを活用し、技術/組織/プロセスにおける企業のDX推進の支援を実施しております。このPlatform Engineeringも企業がDXを推進する重要なファクターになっていくものだと考えており、活用することでその発展に貢献していきたいと考えています。またその中でACS事業部では企業のPlatform Engineering推進に携わりたい方も募集もしております。CultureDeckもありますので、ご興味のある方はぜひご一読ください。
