認知負荷理論で挑むPlatform Engineering：サイボウズにおけるKubernetesプラットフォームの拡大に向けて

認知負荷理論で挑むPlatform Engineering サイボウズにおけるKubernetes プラットフォームの拡大に向けて サイボウズ株式会社 池添 明宏 山田 高大 1

自己紹介 • 池添 明宏（X: @zoetro） • サイボウズにてKubernetesをベースとしたインフラ基盤の開発に従事 • PDX（Platform Developer Experience）チームを立ち上げ、プラットフォーム エンジニアリングを推進中 • Kubernetesのカスタムコントローラー関連の情報を発信 （つくって学ぶKubebuilderなど） • 山田 高大 • 大学・大学院修士課程にて認知負荷理論を援用した心理学研究を行う • 新卒でグループウェアのカスタマーサクセスに従事後、サイボウズにてクラウド 基盤のQAを経て、現在 PDX チームに参加 • Zenn: 認知負荷および認知負荷理論(Cognitive Load Theory) をもう少し正確に 理解するための心理学研究・知見の紹介 2

• https://zoetrope.github.io/kubebuilder-training/
• https://zenn.dev/kangetsu_121/articles/6b31565dda6053

皆さんへの質問 皆さんに質問です 1. 「認知負荷」や「認知負荷理論」という言葉を見聞きしたことがあるでしょうか？ 2. 認知負荷は下げるべきものでしょうか？ 3. 認知負荷を下げた後は、どうするのが良いのでしょうか？ 3

概要 • Platform Engineeringの分野でも認知負荷理論がよく言及される • 認知負荷を「下げる」ことに着目されがちだが、負荷を下げるのはあくまで過程 本来的にはその先の「（深い）学習を達成すること」が目的 • サイボウズでのプラットフォーム構築・運用の経験から、この見逃されがちな観点への意識が Platform Engineeringでも同様に有用であることを提案 4

目次 1. 認知負荷理論の基礎 • 前提となる認知負荷理論の基礎的な内容を紹介 2. 認知負荷理論 x Platform Engineering • Platform Engineeringのプラクティスの一部を認知負荷理論の観点で解釈 3. サイボウズでの実践例 • サイボウズでのプラットフォーム構築・運用の取り組みを認知負荷理論を交えて解説 5

認知負荷理論の基礎 6

認知負荷理論の基礎 認知負荷理論とは • 認知科学・教育心理学の分野で発展 • 最初の研究は教育心理学者、John Swellerによる論文 (Cognitive load during problem solving: Effects on learning. Cognitive Science, 1988) • 人間にとってのRAMであるワーキングメモリの能力と限界に着目し、 効果的な学習デザインを探るために考えられた • 情報処理中にワーキングメモリを圧迫する負荷 = 認知負荷を3種類に分類し、 それぞれをコントロールする方法を研究 負荷C 負荷B 負荷A ワーキングメモリ 7

認知負荷理論の基礎 認知負荷の種類 1. 課題外在的負荷（extraneous cognitive load） • 理解・目的に無関係な要因による余計な負荷。できるだけ削減すべき ▪ 例：ツールのインターフェースが使いにくいために生じる負荷 2. 課題内在的負荷（intrinsic cognitive load） • 課題そのものの複雑さから生じる負荷。その対象を理解するためには避けられない ▪ 例：新しい言語の文法を理解する際の、文法そのものの難しさによる負荷 3. 学習関連負荷（germane cognitive load） • 知識を定着させ、理解を深めるための処理で生じる生産的な負荷。積極的に発生させるべき ▪ 例：習得した文法を使って、問題を解決しようと試行錯誤している際に生じる負荷 8

認知負荷理論の基礎 認知負荷理論の目的である "学習" の定義 • 認知負荷理論は効果的な学習デザインを探るためのものだった → "学習" とは？ → 豊かなスキーマの獲得 • スキーマ：知識のネットワークのようなもの※諸説有 • ある分野に熟達している人はその分野のスキーマが豊か コンテナ学習済み・K8s初学者のスキーマの一部 • スキーマの利用は断片的な知識 (フラグメント) をバラバラに想起して利用するより認知負荷が小さい • ココナラさんの記事はプログラミングにおけるスキーマ獲得による変化を説明する好例 『同じ5行のコードが全く違って見える12の瞬間、なぜ私たちは学ぶのか？』 https://zenn.dev/coconala/articles/reasons-for-continuing-to-learn 9

• https://zenn.dev/coconala/articles/reasons-for-continuing-to-learn

認知負荷理論の基礎 "同じ5行のコードが全く違って見える12の瞬間、なぜ私たちは学ぶのか？" より https://zenn.dev/coconala/articles/reasons-for-continuing-to-learn 10

• https://zenn.dev/coconala/articles/reasons-for-continuing-to-learn

認知負荷理論の基礎 認知負荷の種類に応じた対応 • 課題外在的負荷はシンプルにできるだけ減らす • 課題内在的負荷は学習内容に固有なので直接減らすことはできない o スキーマの獲得による情報量の圧縮で間接的に減らすことができる (例：K8s学習でコンテナを知っていればその部分は圧縮できる) o 課題の提示方法によって相対的に負荷を下げられる ▪ 初学者には詳細な説明、熟達者には要点を捉えた説明が効果的 逆にするとかえって負荷が高まる（Expertise Reversal Effect） • 学習関連負荷はできるだけ増やす o ただしモチベーションなどが主に関わり、コントロールが難しく、まだ議論が多い分野 これらに注意し、段階的にスキーマを構築していくことが重要 11

認知負荷理論の基礎 段階的スキーマの構築 スキーマは原則、一足飛びに豊かにならない 学習者の段階を見極め、ワーキングメモリから溢れない程度の認知負荷にコントロールする (ref. 理想は筋トレと同じくギリギリな負荷) • 初学者 o スキーマの構築ができておらず、知識の一つ一つが負荷になる • 中級者 o スキーマが構築されていき、ある程度の知識のまとまりを一単位として扱える • 熟達者 o 豊かなスキーマと、その利用の自動化まで達成できている 12

認知負荷理論の基礎 スキーマの転移による学習の加速 • スキーマは原則、一足飛びに豊かにならない → 一足飛びに豊かになるケースもある • 2つ目以降に学習したプログラミング言語は、1つ目より習得が容易ではなかったでしょうか？ o 習熟したスキーマの利用は認知負荷が小さい (ref. 車の運転) → 1つ目の言語のスキーマが "転移" され、獲得済みの知識をベースに学習を進められた • スキーマの獲得は単に認知負荷を圧縮するだけでなく、 類似分野の学習にも寄与する • 豊かなスキーマの獲得は労力がかかるが、一度獲得できると、 適切な転移などで加速度的な学習曲線を描きやすい 13

認知負荷理論の基礎 ここまでのまとめ 認知負荷理論は、 • ワーキングメモリ (RAM) にかかる3種の認知負荷をコントロールして、 • 豊かなスキーマの獲得を促すことを目指した理論 認知負荷への対応は、 • 課題外在的負荷と課題内在的負荷は減らし、 • 学習関連負荷は増やすことが望ましい 豊かなスキーマは、 負荷C • 該当分野の処理を効率化し、 • 隣接分野の学習も促進する 負荷B 負荷A ワーキングメモリ 14

認知負荷理論 x Platform Engineering 15

認知負荷理論 x Platform Engineering Platform Engineeringの目的 “ ユーザーの認知負荷を軽減。プラットフォームの重要な目標は、プロ ダクトチームにおける認知負荷を軽減することです。プラットフォー ムは実装の詳細をカプセル化し、そのアーキテクチャから生じる可能 性のあるあらゆる複雑性を隠蔽すべきです。 CNCFプラットフォームホワイトペーパー https://tag-app-delivery.cncf.io/ja/wgs/platforms/whitepaper/ https://tag-app-delivery.cncf.io/ja/wgs/platforms/whitepaper/ 16

• https://tag-app-delivery.cncf.io/ja/wgs/platforms/whitepaper/

認知負荷理論 x Platform Engineering 本当にあらゆる複雑性を隠蔽してしまっていいのだろうか？ • プラットフォームエンジニアリングでは「認知負荷を軽減する」ことに着目されがち。 • しかし、必要な認知負荷まで削減すると、適切なスキーマを構築できなくなってしまう。 • ユーザーは提示された方法のみでしかプラットフォームの機能を利用できず、新たな使い方を自分た ちで探索できなくなる。 • プラットフォームチームとユーザー間のコミュニケーションがうまくとれず、適切な質問や依頼を出 せなくなる。 • 運用時に問題が発生した場合、ユーザーは自分たちで原因を調査することができなくなる。 17

認知負荷理論 x Platform Engineering 認知負荷理論をどのようにPlatform Engineeringに適用するか • 認知負荷理論に照らし合わせると、認知負荷は単純に減らせばよいものではない。 • ユーザーはプラットフォームを学習し、適切に利用するためのスキーマを段階的に構築するこ とが大事。 可能な限りなくす 課題外在的負荷 プラットフォームを利用する上 で本来は必要のない負荷 例: Podをデプロイするために事前に 空き容量を確認し、必要に応じて リソース確保の申請をする ユーザーを支援し 間接的に軽減する 課題内在的負荷 できるだけ増やす 学習関連負荷 プラットフォームそのものの 複雑さによる負荷 プラットフォームの理解を 深めるための負荷 例: Kubernetesの仕組みや GitOpsツールの利用方法の理解 例: プラットフォームが提供する機能を 応用し、効率的な運用方法を発見する 18

認知負荷理論 x Platform Engineering 認知負荷理論をどのようにPlatform Engineeringに適用するか • Platform Engineeringのプラクティスが、各種認知負荷にどのように影響 するのかを考えてみよう 認知負荷理論のアプローチ Platform Engineeringのプラクティス 課題外在的負荷の削減 ・厳選した機能の提供（Curated Product） ・抽象化レイヤーの提供 課題内在的負荷の軽減 ・ナレッジの共有 ・テンプレートの提供 ・ガードレールの整備 学習関連負荷の増加 ・セルフサービスインタフェース ・安定運用やサポートによる信頼の獲得 19

サイボウズでの実践例 20

サイボウズでの実践例 サイボウズのプラットフォーム事情 • サイボウズでは、オンプレミス環境で1,000台以上の物理サーバーを利用してKubernetesク ラスタを構築し、マルチテナント環境で複数の開発チームがKubernetesを利用している。 • 旧プラットフォームからの移行 • VMベースの基盤から新しいKubernetes基盤に順次移行している • 同時にDevOpsを推進し、開発チームがアプリケーションの運用も担うように体制を変更 • 参考: 【連載】Cybozu.comクラウド基盤の全貌 21

• https://blog.cybozu.io/entry/2025/03/19/112000

サイボウズでの実践例 サイボウズのPlatform Engineering • 課題外在的負荷の削減 • Kubernetesをベースとした抽象化レイヤーの提供 • 各種サービス（ロードバランサー、データベース、オブザーバビリティ、CI/CDなど）の提供 • 問い合わせ窓口の整備、ドキュメントの集約 • 課題内在的負荷の軽減 • 初歩的なチュートリアルから、高度な活用のためのドキュメントまでを整備 • 必要に応じてユーザーの習熟度に応じた導入支援 • ガードレールを整備し、安全にアプリケーションのデプロイが可能 • 学習関連負荷の増加 • セルフサービスインタフェースの提供 • 安定運用や細やかな依頼への対応による信頼の獲得 22

サイボウズでの実践例 マルチテナントKubernetes • チームごとに適切に権限分離された環境を TeamA 提供。 • 利用の流れ • 開発チームからの依頼に応じて初期設定 • 開発チームはArgo CD, Grafana, Teleport などのツールを使って環境にアクセス • カスタムリソースを利用して、ストレージ、 設定 プラットフォーム チーム 利用申請 TeamB デプロイ ロードバランサー、データベースなどの機 能を利用可能。 利用 • ほとんどの機能はセルフサービスで利用可 • バリデーションやRBACにより、危険な操 作は禁止 開発チーム Kubernetesクラスタ 23

サイボウズでの実践例 Kubernetesをベースにした抽象化レイヤー提供の例 統一されたメンタルモデル 共通のインタフェースで利用可能 開発チーム 抽象 レイヤー 実装 レイヤー Kubernetes Resources Network Storage Custom Resources Custom Resources Custom Controller Custom Operator 開発・運用 様々な自動化 Managed Pod Node プラットフォーム チーム 標準Kubernetes 拡張機能 各種サービス 24

サイボウズでの実践例 Kubernetesは適切な抽象化？ • アプリケーション開発者からは「アプリケーションを開発したいだけなのに、Kubernetesの ような複雑なものを学習したくない」という意見もある。 • DevOps推進のためには、Kubernetesは適切な抽象化レイヤーを提供していると感じる • 大規模なアプリケーションを本格的に運用するには、Kubernetesレイヤーの理解が必須。 • Kubernetesは、宣言的記述、Reconciliation Loop, Kubernetes Resource Modelのような、統一 された理解しやすいメンタルモデルを提供している。標準で様々な設定項目があり、拡張性も高く、 セルフサービスの自由度も高い。 • Kubernetesのメンタルモデルに従った形で拡張すれば、ユーザーも理解して使いやすくなる。 apply diff 理想の状態 Controller 対象のシステム 宣言 実際の状態 observe 25

サイボウズでの実践例 セルフサービスを実現する自作OSSの例 • https://github.com/cybozu-go/accurate • ユーザーがセルフサービスでNamespaceを作成できるようにするカスタムコントローラー • HNC（Hierarchical Namespace Controller ※2025年4月にArchived）の代替におすすめ • https://github.com/cybozu-go/cattage • Argo CDのマルチテナント機能を補助するカスタムコントローラー • accurateで作成したNamespaceに応じて、Argo CDからデプロイ可能なNamespaceを更新 • ユーザーがセルフサービスでSyncWindow（同期する時間枠の制限）を設定する機能を提供 • OSSとして公開することにより、実装がサイロ化してしまうことを防止。 26

• https://github.com/cybozu-go/accurate
• https://github.com/cybozu-go/cattage

サイボウズでの実践例 実際のところうまくいっているのか • 良かった点 • プラットフォームを的確に理解したユーザーが、応用的な利用方法を編み出し、効率的な開発・運用 が実現できている。 • ユーザーからプラットフォームチームへの的確なフィードバックに基づいて、プラットフォームの改 良が実施できている。 • 先行したユーザーの知見を、後発のユーザーが活用する流れができている。 • Kubernetesに慣れていないユーザーに対しては、レクチャーやレビューなどを通じて支援できた。 • ガードレールで保護されているため、大きなセキュリティ事故を起こすことなく運用できている。 • 課題 • KubernetesやGitOpsの知識が前提となっているため、慣れるまで苦労しているユーザーも多い。 • AWSとの機能比較で負けてしまい、プラットフォームを使ってもらえない。 • 「独自プラットフォームは情報が少なく使いづらそう」というイメージがあり使ってもらえない。 27

まとめ 28

まとめ • 認知負荷理論は深い学習を達成することが目的 • 認知負荷は3種類存在し、単純に減らせば良いものではなく、それぞれに応じた対応が必要 • Platform Engineeringにおいても、すべての複雑性を隠蔽し認知負荷を減らすのではなく、 プラットフォームを効率的に活用してもらうために、段階的なスキーマの構築をおこなうこと が重要ではないかと提案 • その実践例として、サイボウズでの取り組みを紹介 • 課題外在的負荷を削減するためのKubernetesをベースにした抽象化レイヤー • 課題内在的負荷を軽減するためのガードレールやドキュメントの整備、導入支援 • 学習関連負荷を増大させるためのセルフサービスインタフェースの提供 • 課題は山積みなので、今後もPlatform Engineeringを推進していく 29