【KubeCon + CloudNativeCon 2026 EU】 FREEDOME THROUGH BOUNDARIES

皆さんこんにちは。エーピーコミュニケーションズ ACS事業部亀崎です。私は2026年3月23日〜26日に開催されているKubeCon + CloudNativeCon 2026 Europeに参加のため、現在アムステルダムに来ております。今日3月26日はDay 3の様子をお送りします。

少しでも皆さんに生の情報をお届けすべく、時間のある限り本ブログで紹介したいと思います。

例えば、Platform Teamが開発者に対して Helm Chartによるリソースプロビジョニングを提供しているとしましょう。

こうした場合に、望ましいのはその両者が「自由」であることです。過度に依存することもなく、一定のルール（規約）により『明確な境界線』を設けることが、その「自由」をもたらすことになります。

その「自由」ですが、最初の段階ではうまくいっているのに途中から制御不能に陥っていくことがあると思います。

こうしたことが起きる大きな原因は場当たり的な機能追加です。ユーザーの要望事項にあわせて必要以上に多機能化してしまい設定ファイルが膨大、かつ複雑になります。例えば以下のような状況に陥っていきます。

こうしたことを防止するために必要なのが適切な境界を作ることです。

適切な境界では以下のような点を維持するようにします。

無効な状態を作らせない。矛盾する設定などは「無通知で動いてしまう」のではなく、失敗として通知することが重要です。
Platform Teamではなく、開発チームの視点にたったインターフェース定義。実装詳細（内部フラグ）は隠すようにし、ユーザーには「何が起きるか」「どういったオプション機能を有効にするか」だけを選択できるようにします
暗黙のデフォルト値での挙動の変化を避けます。変更前後でも同じ設定をしたら同じ挙動となるようにします
計画的な破壊的変更の実施。破壊的変更が皆無ということはありません。非推奨期間など移行パスを用意することで計画定期に更新を行うようにします
未知のフィールドはエラーに。タイポなどによる設定ミスを無視するのではなくエラーとして扱うことで、誤った指定を避けることができます。

一言でいえば、Helm Chartのvalues.yaml がPlatform Teamと開発チームの間の「契約（Contract）」となり、これが明確な境界となるようにすることが重要です。

今回はHelm Chartという事例でしたが、Platform Teamと開発チームとの間の関係はこうした「契約（Contract）」をベースにすると良いと感じました。

アプリケーション設計でいうところの「Design by Contract」のPlatform Engineering版といってもいいのかもしれません。

チーム間のコミュニケーションは重要ですが、双方が依存しすぎてもよくありません。また、その関係性は中長期にわたって継続できるものでなければ双方の「自由」を享受することが難しくなります。

今回示されたように「適切な境界」を作ることで、中長期にわたる「自由」（そして「統制」）が実現できるようになると思います。

「適切なBoundary」。皆さんもこの言葉を覚えておきましょう。

APC 技術ブログ