Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
fukuoka_sre_0_jmaki.pdf
Search
j-maki
June 19, 2026
740
1
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
fukuoka_sre_0_jmaki.pdf
j-maki
June 19, 2026
More Decks by j-maki
See All by j-maki
引いては引き直す Kubernetes運用における境界設計とその見直し
jmakk0301
0
300
おそらくAGIでも代替不可能な、 趣味としての個人コミットの話
jmakk0301
0
180
EKSシークレット管理のつらみと責務分解
jmakk0301
0
120
小さく始める障害訓練
jmakk0301
0
18
Amazon EKS MCP Serverでクラスタの職場環境のストレスチェックをして遊んでみた
jmakk0301
0
210
ギフティにおける プラットフォームエンジニアリングことはじめ
jmakk0301
2
530
probeの勘違いから見直した、Pod運用のアレコレ
jmakk0301
2
260
Featured
See All Featured
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
21
1.5k
GraphQLとの向き合い方2022年版
quramy
50
15k
Noah Learner - AI + Me: how we built a GSC Bulk Export data pipeline
techseoconnect
PRO
0
210
<Decoding/> the Language of Devs - We Love SEO 2024
nikkihalliwell
1
270
Getting science done with accelerated Python computing platforms
jacobtomlinson
2
260
Stewardship and Sustainability of Urban and Community Forests
pwiseman
0
270
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
47
8.2k
Test your architecture with Archunit
thirion
1
2.3k
Leadership Guide Workshop - DevTernity 2021
reverentgeek
1
320
Reality Check: Gamification 10 Years Later
codingconduct
0
2.2k
Groundhog Day: Seeking Process in Gaming for Health
codingconduct
0
240
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
52
6k
Transcript
ラーメンから考える! プラットフォームエンジニアリング Fukuoka.SRE | 2026/06/19 1
自己紹介 じぇまき(牧 純平) とあるweb系の企業で働いてます Platform Engineeringチーム立ち上げ奮闘中 横浜在住 今日はフェリーで22時間かけて来ました! 2
エクスキューズ ネタ枠です。この発表を聞いても持ち帰れるものは特にないと思います! 個人の主観です。おそらくかなりのバイアスを含んでいます! スライドも詰められてないです!今日やろうと思いましたが、スペースワールドで遊んでしま いました! ラーメンガチ勢の方がいてもマサカリを投げないでください!(無用な争いはやめて!笑) 3
プラットフォームエンジニアリングとは 開発チームが安全かつ自律的にソフトウェアを届けるための、社内向け基盤を設計・運用する 取り組み Internal Developer Platform (IDP) により、インフラや運用の複雑さを抽象化する Golden Path
/ self-service により、標準化された方法で開発・デプロイ・運用できるよう にする 目的はツール導入そのものではなく、開発者体験、認知負荷、リードタイム、ガバナンスを改 善すること 出典: Google Cloud / Microsoft Learn 4
3つのラーメンで比較してみる 博多とんこつ(以降、博多) 家系 二郎 プラットフォームの性質を、インターフェース、結合度、プロダクトとしての観点から見ていきま す。 5
インターフェースと認知負荷 プラットフォームの主要な価値は、利用チームの認知負荷を下げること 複雑さを消すのではなく、扱うべき複雑さを適切なインターフェースに閉じ込める 良い抽象化は、重要な判断を隠さず、毎回考えなくてよい判断を標準化する Golden Path / self-service は、迷わず安全に進むための設計 参考:
Martin Fowler / Team Topologies 6
ラーメンで見る! インターフェースと認知負荷 ラーメン 評価 インターフェース 認知負荷 博多 ◎ 基本硬さを指定 初期注文が比較的シンプル。加えてバリカタなどのコア
ユーザ向けのパラメータがある 家系 ◦ 硬さ・濃さ・油のパラメ ータ 困ったら「全部普通」というデフォルト値がある 二郎系 △ コールと言う謎の呪文を 詠唱しなければならない タイミングと作法が暗黙知。 「ニンニク入れますか?」の 返り値の型はbooleanではなく、stringのenum[] 7
結合度と変更容易性 疎結合とは、ある要素の変更が他の要素の変更を要求しにくい状態 プラットフォームは、利用者と基盤の実装詳細を直接結びつけないための境界 安定した API、標準化されたワークフロー、明示的な依存関係が変更容易性を高める 暗黙依存やタイミング依存は、利用側の運用知識を増やし、変更を難しくする 参考: NIST SP 800-204
8
ラーメンで見る! 結合度と変更容易性 ラーメン 評価 構造 変更容易性 博多 ◎ 麺とスープが疎結合 替え玉というシステムにより、スケーラビリティ
を実現している。ただしスープが単一障害点。ペ ース配分が肝 家系 ◦ ラーメン単体でも正常に動作する が、実質ライスへ依存している (暗黙的) 薄い濃いは後から調整できたりするお店がある。 卓上トッピングの拡張性が高い 二郎 △ 初期コールへの依存が強い 野菜マシのロールバックは難しい。己の胃袋のキ ャパがボトルネック 9
Secure by Default 安全な設定をデフォルトにし、利用者が追加の作業をしなくても安全に使えるようにする 危険な変更や強い権限は、暗黙的に有効化せず、明示的な opt-in にする 安全なデフォルトパスを用意し、そこから外れる場合のリスクを利用者に伝える セキュリティ設定の複雑さを、利用チームの責任に押しつけない 参考:
CISA, Secure by Design / Secure by Default 10
ラーメンで見る! Secure by Default ラーメン 評価 セキュアデフォルト 博多 ◦ デフォルトはシンプルな構成。ただし高菜を
opt-in すると、めちゃめちゃ辛いこと がある 家系 ◦ ニンニクも豆板醤も卓上から明示的に追加する。危険な変更はユーザの責務 二郎 ◦ ニンニクはデフォルトでは入らず、 「少し」もコールできる。コールをSSOTとしてい るアプローチ 11
ここまでの観点を踏まえて、3つのラーメンを総合的に評価します。 12
総合評価 ラーメン 評価 コメント 博多 ◎ かなり、うまい。必ず替え玉もいってしまう。 家系 ◎ いろいろ比較した結果、うまい。やっぱりライスとスープと海苔は最高だよね。
二郎 ◎ 総合的に判断してもうまい。野菜も入っているので健康にも良い 13
結局、良いプラットフォームとは 完璧な設計より、使われること 強制ではなく、選ばれること 開発者が迷わず、速く、安全に価値を届けられること 14
美味しいラーメンのように ユーザに選ばれ続けるプラットフォームを 作っていきたいですね 15
ご清聴ありがとうございました!🍜 福岡勢の方、お好きなラーメン屋さんを教えてください! 16