「Platform Engineeringへの招待」、開発者の生産性を高めるプラットフォームを作り、運営していくための考え方とは（後編）。Platform Engineering Meetup #1

今回は「「Platform Engineeringへの招待」、開発者の生産性を高めるプラットフォームを作り、運営していくための考え方とは（後編）。Platform Engineering Meetup #1」についてご紹介します。

関連ワード （何故今注目、大事、大企業等） についても参考にしながら、ぜひ本記事について議論していってくださいね。

本記事は、Publickey様で掲載されている内容を参考にしておりますので、より詳しく内容を知りたい方は、ページ下の元記事リンクより参照ください。

急速に注目を浴びつつある新しいムーブメント「Platform Engineering」についてのコミュニティイベント「Platform Engineering Meetup #1」が3月9日に都内でオンラインとオフラインのハイブリッドで開催されました。

その最初のセッションとして行われた、イベントの主催者である草間一人氏の「Platform Engineeringへの招待 – Platform Engineeringって何？ 何故今注目なの？」の内容を紹介しましょう。

記事は前編と後編に分かれています。いまお読みの記事は後編です。

共通プラットフォームは新しい話ではない

開発者の認知負荷を下げて開発に注力できるように、内部の開発者プラットフォームを作っていきましょう、というのがInternal Developer Platformです、という話をしてきました。

ただ、こういった開発者向けの共通プラットフォームを作るという話は、別に新しい話じゃないよねと、自分も10年前にやってましたよ、という方もいらっしゃるんじゃないかと思うんですよ。

それはイエスで、新しい話ではないんです。クラウドが盛り上がる前から、ある程度大きな会社だったら1回くらいこういう話をしているはずなんですよね。

会場にもオンラインにも、こうした話に関わったことがある人は少なくないと思います。

自己紹介でも少し話しましたが、私もPaaSにたくさん関わってきましたが、PaaSを提供するのとInternal Developer Platformを提供するのはどう違うのだ、ということにもなってきます。

PaaSはCloud FoundryやOpenShiftなど、これまでいろんなものが出てきました。

これらのPaaSが目指していたのは、例えばCloud Foundryでは「cf push」コマンドをソースコードがある場所で打つだけでデプロイができる、という仕組みでした。

ですからPaaSは開発者の認知負荷を下げる意味では、確かに最高に効率がよい仕組みでした。

これがPlatform Engineeringとどう関わるのか、ということにも徐々に触れていきたいと思います。

これまでなぜうまく行かなかったのか？

先ほど、共通プラットフォームに関わってきた方も少なくないのでは、という話をしましたが、そうした方々は、ぜひこの質問に心の中で答えてみてください。「そのプラットフォーム、上手く行きましたか？」

いまなぜPlatform Engineeringという言葉が注目されているのかというと、共通のプラットフォームを作るのはめちゃくちゃ難しいからですね、本当に難しくて、大体うまくいかない。

これは完全に私の主観ですが、感覚的には4割ぐらいのプラットフォームがもう生まれながらに死んでいます。

さらに4割ぐらいの共通プラットフォームはうまく運用できずに死んでいきます。

本当に成功するプラットフォームは2割かそれ以下なんじゃないかな、と思っています。

なんでそんなことになっちゃうんでしょう。

共通プラットフォームの失敗とは

失敗するプラットフォームとは、要するに使われないプラットフォームですよね。誰にも使われずに消えていったプラットフォームを失敗としましょう。

なぜ失敗するのかというと、そのプラットフォームに価値がないから使われないのですね。この言葉は自分にも刺さる音がするんですが。

ここでいうプラットフォームの価値とは誰にとっての価値かというと、それはプラットフォームを利用する人、Platform Engineeringの話でいうと開発者ですね。

その人が価値を感じるかどうかで決まってくるわけです。なので開発者に価値を提供できなければそのプラットフォームは失敗している。

ですからプラットフォームを作るにあたっては、「誰に」「何を」「どうやって」提供していくかを考えることが非常に大事なんです。

けれども、これまでの共通プラットフォームは、技術と「どうやって」というところばかりに注力してきた感じがあるんですよね。

自分も振り返ると、ここばかり見ていたな、と思っていたりします。

生まれながらに死んでるパターンというのは、結局、開発者が欲しくないものを作っちゃった、ということもあれば、2年ぐらい頑張って俺の考えた最強のプラットフォームを作ったけれども、2年のあいだにトレンドは終わってオワコンになってました、みたいなことですね。

運用がうまくまわせずに死んでいくパターンもありますね。できあがりはしたのだけれど、特定の技術に依存してしまったがためにトレンドに乗り遅れました、とか、大企業ではよく聞くんですが、プラットフォームの構築プロジェクトとして実行するんですね。

そしてプロジェクトには必ず終わりがある。

すると構築してプロジェクトが終わりました、予算がなくなりました、人が半減しました、運用がまわせなくなって終わりました、みたいな。

こうやってプラットフォームは使われなくなっていくわけなんです。

認知負荷を下げることは間違いではない

私自身もPaaSを作るのに関わってきました。

開発者の生産性を上げるのは大事ですよね、認知負荷を下げるのは大事ですよね、簡単にデプロイできるのは大事ですよね、という気持ちでやっていました。

そこでCloud FoundryというPaaSを開発者に提供すればいいのではないかと思って提供していたのです。

これは確かに刺さる人には刺さって、期待通りの効果を上げることができたと思います。ただ、多くの方にはうまく刺さらなかったんですね。

だから組織全体で考えると必ずしも効率化できたわけではなかったんです。その後、世の中がKuberenetesとかクラウドネイティブみたいな流れになってきて、結果的にCloud Foundryはそれらにそぐわずにうまく行かなかった、という経験がありました。

これを振り返ると、一番上にある「生産性を挙げるために認知負荷を下げる」ということは間違いじゃなかったと思っています。

Platform Engineeringの考え方でもこれは大事だとされていますし。

ただ、その後は良くなかったですね。これはすごく簡単にデプロイできる仕組みだから、みんなこれを使うべきだ、みたいな形でやっちゃっていたわけなんです。

本当に開発者たちがそこに困っていたのか、というのも分からないまま、これはいいものだから、と押しつけているところもありましたし。

ここは難しいところですが、世の中は変わっていくことを前提にチームとか仕組みを作っていかなくてはいけない。そこも考慮できてなかったなと、今考えると感じます。

開発者のための製品としてプラットフォームを考える

ということで、誰に対してどういった価値を提供するかをちゃんと考えて、しかも作って終わりではなくて、継続的に回していくことがとにかく大事なわけですね。

そこで「Platform as a Product」という考え方があります。

これは「開発者」をプラットフォームを使ってくれる顧客として考え、顧客にプラットフォームというプロダクトを提供する、というアプローチの仕方です。

そうすると、プロダクトを使ってもらってお金を稼ぐということになりまうし、使ってもらうには宣伝しなきゃいけないし、活用し続けてもらえるようにサポートもしていかなくてはいけない、といろんなアイデアは出てくるんじゃないかなと思うんです。

さらにプロダクトとして考えることで、すでに存在している色々なプロダクトマネジメントや管理手法をプラットフォーム作りに取り込んでいくこともできるんですね。

顧客に価値を提供するためには顧客を知らなくてはいけないのでヒアリングをするとか、いつまでに何を提供していくかを優先順位をつけてリリースしていくとか、どうやってサポートや教育をするか。

継続的に運用もしていかなくてはいけないので、チームをどうやって育てていこうか、みたいな視点を持つようになるんです。

こうしたことについて、世の中にあるプロダクトマネジメントの考え方をそのまま適用できるのはメリットです。

なので、プラットフォームチームの中には、プロダクト目線で考えるプロダクトマネージャーを置きます。

プロダクトマネージャーが、そのプラットフォームをどうやって提供していくかを考えて、プライオリティ付けをしていく、というやり方が取れるわけですね。

真のDevOpsを実現していくために

まとめます。

真のDevOpsを実現していくために、開発者の認知負荷を下げて、セルフサービスでできるようなプラットフォームを提供し、開発者のアプリケーション開発体験や生産性を向上させていきましょうと。

その上で、そのプラットフォームは顧客である開発者を理解し、プロダクトを開発していくような知見を取り入れながら作り上げていくのが、Platform Engineeringだと言えるのではないか、と思っています。

ですので、DevOpsからPlatform Engineeringにみんな方向転換していることを皮肉るようなツイートを面白がって紹介しましたが、DevOpsによる継続的な改善をしていくことや、DevやOpsのサイロをなくしていくという考え方は間違っていませんし、いまでも価値があります。

ただ、世の中は進化していくので、本当に機能するDevOpsを実現していく延長線上にあるのがPlatform Engineeringだと考えた方がいいんじゃないかなと思っています。

大変だけどやらなくちゃいけない

Platform Engineeringを紹介する話をしてきましたが、皆さんはエンジニアリングや技術をメインに仕事にしてきた方が多いのかなと思っていて、そういった方がPlatform Engineeringだからプロダクトマネージャーになってくださいと言われても、大変じゃないですか。

めっちゃ大変だと思います。でも、やらなくちゃいけないんです。これからの時代。

最近読んだ「継続的デリバリーのソフトウェア工学」という本に、Engineering、工学についての分かりやすい表現があったので紹介したいのですが、「工学とは、実際的な問題に対する効率的、経済的な解を見つけるための経験的、科学的なアプローチの応用である応用のことである」と書いてあったんですね。

そういったエンジニアリングに関わる人は「学びのエキスパートであり、かつ複雑さ管理のエキスパートになる必要がある」とも書いてあったんです。

Platform Engineeringでも同じかなと思っています。

とにかくいろんなツールなどが出てきますし、開発者が求めるものもどんどん変わっていきます。さらに向こう側のエンドユーザーもどんどん変わっていきます。

例えば、ChatGPTみたいな技術が急に注目されるようになるとか、そういったものに対応していくために、我々は学び続けなくてはいけないし、そういった複雑な世界をシンプルにしていくようなスキルを身につけなくてはいけないのかなというふうに思ってます。

自分がこの勉強会を立ち上げたのは、そういったプラットフォームに関わる皆さんが学びのエキスパートになって、複雑さを管理するエキスパートになるための役に立つような機会を提供して、みんなで学んでいけたらなと考えたからです。

なので、いろいろな方に声をかけて、お話いただきたいなと思っています。

• Platform Engineeringへの招待 – Speaker Deck