Kubernetes標準化と技術選定の難しさ

昨年はPlatform Engineeringに現地参加できましたが、今年は仕事の都合でオンライン参加となりました。

オンラインでも、ウルシステムズさんのランチセッション、サイボウズさんやサイバーエージェントさんの登壇、そして公式のセッションなど、多くのセッションを拝見することができました（詳細スケジュールはこちら：https://www.cnia.io/pek2025/schedules/）。

今回のイベントでは、多くの企業がKubernetesへの移行事例や、開発者の認知負荷軽減に関する取り組みを紹介していました。

私自身も多くの気づきを得たため、ここでまとめとして共有したいと思います。

1. Platform Engineeringは難しい

まず全体を通じて強く感じたのは、Platform Engineering自体が抽象的であり、企業ごとに最適解が異なるという点です。

「Platform Engineering」という言葉自体には完璧な定義はなく、存在も抽象的であるため、全体に適応できる『これがベスト』という形はありません。各社は自分たちの開発文化や組織構造に合わせて工夫しているように見えました。
Internal Development PlatformやTeam Topologiesなどが話題に挙がることも多いですが、単に流行として導入するのではなく、会社の現状を分析したうえで方針を決め、必要に応じて自社開発も併用しているケースが多い印象でした。

言い換えれば、Platform Engineeringは“試すだけ”ではなく、自社の課題や開発者の体験を起点にした設計が重要であると感じました。

次に印象的だったのは、Kubernetesの採用が事実上の標準になりつつあることです。

昨年のKaigiでも感じましたが、多くの企業でKubernetesを利用することが一般的になっている様子でした。

一方で、Application Developerの視点から見ると、Kubernetesは扱いづらい面があるのも事実です。そのため、Backstageや独自サービスを開発して開発者体験を改善する取り組みが多く見られました。

例えば、Kubernetesの複雑な設定やデプロイ作業を抽象化して、開発者がよりアプリケーションの価値に集中できる環境を作っている企業が多かったです。

このことから、Kubernetesは導入すれば解決というわけではなく、周辺サービスや仕組みづくりを含めた全体設計が重要だと改めて感じました。

もう一つの大きなテーマは、技術選定の難しさです。

生成AIやクラウドサービスなど、新しいサービスや技術が次々に登場しており、選択肢が増えすぎている印象を受けました。

技術選定は「評判が良いから」「流行だから」では決められません。目的やチームの習熟度、運用コスト、メンテナンスの頻度など、さまざまな要因を踏まえて決める必要があります。

そのため、一朝一夕で決められるものではなく、Platform担当がApplication担当とフィードバックループを回しながら、中長期の視点で最適化していくことが求められます。

技術選定は、単に「便利そうだから導入」するのではなく、自社の文脈に合わせて継続的に評価・改善するプロセスであることが重要だと感じました。

今回のKaigiを通じて、私が特に印象に残ったのは以下の3点です。

1. Platform Engineeringは抽象的で万能解はない。各社の状況に応じた設計が重要。

2. Kubernetesは標準化しつつあるが、開発者体験の改善や周辺サービスの整備が必要。

3. 技術選定は単純ではなく、中長期でのフィードバックと評価が欠かせない。

Kubernetesを中心とした開発基盤は多くの企業で一般化していますが、周辺サービスや技術選定の最適化には、各社独自の試行錯誤が続いています。興味のある方は、各セッションのスライドから具体的な取り組みを確認してみてください。