依頼文化をやめる日 EM視点で語るPlatform EngineeringとInclusive SRE / Discussing Platform Engineering and Inclusive SRE from an EM's Perspective

Transcript

1. 依頼⽂化をやめる⽇ EM視点で語るPlatform EngineeringとInclusive SRE SRE NEXT 2026 登壇資料 2026年7⽉11⽇ 株式会社ログラス 勝丸 真 1
2. ⾃⼰紹介 勝丸 真 X: @shin1988 ∕ GitHub: katsukamaru 株式会社ログラス 技術基盤本部 技術基盤部 SRE / Engineering Manager 新卒で株式会社ビズリーチ（現: ビジョナル株式会社）、その後Supership株式会社を経 て2020年からログラス。 現在はSREチームのEMとして、Platform Engineering推進‧EKS移⾏の3カ年計画を主導 マネジメントと並⾏して、SRE採⽤‧セキュリティ領域‧CRE領域も管掌 顔写真 2
8. 本セッションの⽴ち位置 • EKSの技術詳細は話しません。意思決定のリアルを話します • 後半は皆さんへの具体的な提案（処⽅箋）に時間を使います SREsではなくEMとして、信頼性を担う「構造」への投資判断を語ります こんな⽅に（メイン） インフラ⼤型投資や意思決定の判断に悩む EM‧マネージャーの⽅ こんな⽅に（サブ） マネージャーに技術提案を 通したいエンジニアの⽅ 8
9. 技術的な詳細について • EKS移⾏の技術的な意思決定‧アーキテクチャの詳細はこちらをご覧ください ‐ セッション名：スタートアップにAmazon EKSは早すぎる？ マルチプロダクト戦略を加速する Platform Engineering実践 ‐ 資料URL： https://speakerdeck.com/elmodev09/is-amazon-eks-too-soon-for-startups-practical-platform-engineering-to-accelerate-a-multi -product-strategy 同じ取り組みの「技術的側⾯」は、チームメンバーがAWS Summit の登壇でお話ししています 9
10. 本⽇の流れ 後半の2つの「提案」パートが、本⽇の持ち帰りです 1 依頼⽂化とは何か — Before 構造上ボトルネックにならざるを得なかった話 2 依頼⽂化をやめる — After 1つのEKS基盤への転換と、その代償 3 Mgrが越えた「3つの壁」 妥当性の説明‧時間の捻出‧仲間づくり 4 メンバー向け提案 提案が通りやすくなるかも知れない⽅法 5 Mgr向け提案 モチベを下げずに上位戦略と紐づけながら前に進める⽅法 6 まとめ EMの投資判断の軸（2分） 10
11. 01 依頼⽂化とは何か — Before 11
12. 1. 依頼⽂化とは｜Before の構造 ほぼすべてのインフラ作業を、クラウド基盤チームが持っていた（創業 - 2024年年末にかけて） インフラ‧監視‧CI/CD設定の依頼 プロダクト A（ECS） プロダクト B（ECS） プロダクト C（ECS） 新プロダクト…（ECS） クラウド基盤 チーム ‧新規事業が始まるたびに ECSで各プロダクトをまるっ と構築 ‧担当者を1⼈アサインして 1つずつ対応 当時は既存事業のECSをそのまま横に建てるのが最速という意思決定。プロダクトが増えるたび、⼈が張り付く 12
13. 1. 依頼⽂化とは｜そこに⾛り出した構想 • マルチプロダクト構想が⾛り出す（2025年1⽉頃〜） ‐ 企業の「企業価値向上」を⽬的とし、経営管理（xP&A）領域 やIR領域など、経営のあらゆる課題を解決する複数のプロ ダクトを次々と⽴ち上げ、統合的な経営プラットフォームを構築する戦略 • ただし、隅々までアラインして⾛り出していたわけではなかった ‐ 構想を実現させるためのエンジニアリソースを精緻に⾒越してスタートした訳ではなかった ‐ AIが出始めた時期であり、AIがどこまでエンジニアリソースを削減できるか、全然分からない時期だった ‐ 初期プロダクトを出すスピードだけは速くなる • この体制で⾏くのが、どこまで現実的なのかが不明なまま突⼊する可能性 マルチプロダクト構想と、⾒えていなかったリソースの現実 13
14. 1. 依頼⽂化とは｜依頼は並列、対応は直列 依頼は並列に来る。しかし専任でアサイン出来る戦⼒は1⼈ ⸺ 対応は直列にしか進まない プロダクト A プロダクト B プロダクト C プロダクト D • 依頼が届く（ほぼ同時） 対応（1⼈） 対応（1⼈） 対応（1⼈） 対応（1⼈） 待ち時間 時間 並列に依頼が来ても、直列にしか受けられない。後ろの依頼ほど待ちが伸びる 14
15. 1. 依頼⽂化とは｜ボトルネックの正体 • 結果、クラウド基盤チームはボトルネックになった ‐ 1プロダクト = 1⼈張り付きの構造では、並列で作れる数に上限がある • 依頼⽂化：何かを⽣み出すためにクラウド基盤チームの「⼈の⼒」を⼊⼒し続けないといけない構造をなんとかしたかっ た ‐ ⼈の採⽤はこれからどんどん厳しくなることが想定されてた ‐ いつかは構造変⾰を推進しないと、と思いつつ、踏ん切りがつかなかった 誰かの実⼒不⾜ではない。構造上、そうならざるを得なかった N個のプロダクトを並列で開発する ＝ N⼈分の採⽤が必要、という⽅程式 15
16. 02 依頼⽂化をやめる — After 16
17. 2. 依頼⽂化をやめる｜構造の転換 1つのコンピュート基盤の上に、各事業のコンテナを乗せる⽅式へ Before：依頼⽂化 プロダクトA（ECS） プロダクトB（ECS） プロダクトC（ECS） クラウド基盤チーム プロダクトが増えるたび、⼈⼒が必要 After：1つのPlatformへ 事業A 事業B 事業C 新規… 1つのコンピュート基盤（Platform） クラウド基盤チームは、下のPlatformだけを管理 事業成⻑が組織（チーム⼈員）の成⻑を前提としない構造への変換 17
18. 2. 依頼⽂化をやめる｜Platform の 概念図 最終構成の共有 18 再掲
19. 2. 依頼⽂化をやめる｜EKS基盤 利⽤者の声 開発者は⾃⾛し始めた。ただし、新しい課題も⾒えている 開発の進めやすさ 4.2 / 5 インフラ⾃⾛度 3.4 / 5 2026/05 社内アンケート（回答11名‧原⽂ママ） ポジティブ ネガティブ‧課題 K8sを具体的に理解しなくても、インフラが構築できてしまいます。 依頼しなくても良くなったというポイントはポジティブ サーバーの実装などは⾮常に簡単で、2⽇で欲しかったインフラ基盤が できたのは素晴らしい。 ECS時代はCodeBuild / Step Functions / Lambda等を組み合わせてい た処理が、EKSではvalues数⼗⾏で成⽴。実装量‧認知負荷とも⼤き く下がった。 基盤がブラックボックスになっているので、何か問題があったときにこ ちらで解決できるかはあまり⾃信がない。 ECSと違ってキャッチアップコストがかかるので、そこはデメリットだと 思っている。 原因特定はできても、k8sレイヤの対処は基盤チーム依頼となる場⾯が増 えた。 ポジもネガも、そのまま受け取る ⸺ ⾃⾛度3.4を5に近づけるのがこれからの仕事 19
20. 2. 依頼⽂化をやめる｜効果と、Mgrに残された問い • 依頼ベースだった作業が、少しずつ解消されてきた（現在進⾏形） • しかし ⸺ Mgrの⽴場でこれを推進するには、トレードオフがたくさんあった ‐ やったほうがいいのは、よく分かるが、これを共通認識に出来るのか？という問いがありました。 結論: 依頼ベースの作業は少しずつ解消されてきた。ただし、そこに⾄るまでは紆余曲折あった 問題は、誰を説得して、どの順番で進めるのか 20
21. 03 依頼⽂化をやめるために越えた「3つの壁」 21
22. 3. 3つの壁｜全体像 越える壁は3つ 壁① 妥当性の説明 ‧合理性を説明し、妥当であると説明す る ‧実⾏⼿段としての合理性や経済的合理 性 ‧このチームなら「やりきれる」という 周りから思われる 壁② 時間の捻出 既存事業を進めながら、⼩さく失敗でき る形を作る。⼩さな信頼を積み重ねる。 壁③ 仲間づくり 22 開発のEMに触ってもらい、 PF構想の推進者になってもらう 。実ユー スケースを⾒つけに⾏く。
23. 3. 3つの壁｜壁① を越えたとき • 2024/11頃：⼊社直後のメンバー2名からのPFE推進提案を⾃分が断った ‐ 実⾏⼒が未知数（構成や課題感を捉えられているか ）‧技術の⽬的化への懸念‧巻き込みの⾒通しがなかった • 2025/1頃：具体的なEKS移⾏のために、ネットワーク図を書いて再提案 ‐ 既存システムの理解が深まっていることを感じたが、全⾯的なGoは出さず ‐ その時に考えていたこと • 技術ベースの資料のままでは合意は得られないと思っていた / ⾃分たちのやりたいだけでは進まないと思っていた • 上位レイヤー / 現場レイヤー に認めてもらって初めて推進できる • そのために既存業務を正しく実⾏し続けることが重要 • 2025/7頃：現場レイヤーのEMにPoCを触ってもらい良さそうと感じてもらう ‐ 作ったPoCを元に開発サイドのEMに触ってもらった ‐ 良さそうを感じてもらい、本格的にチームの⽬標に⼊れ始めて推進 時系列的な整理 23
24. 3. 3つの壁｜壁① 「妥当性」の分解 妥当性は、「誰にとっての妥当性か」で変わる 誰が問うか 問われる妥当性 具体的な問い 経営‧上位レイヤー 経済的‧戦略的‧時期の妥当性 上位戦略へのメリットは何か。コストに⾒合うか。なぜ「今」か 開発チーム（利⽤者） 組織受容の妥当性 受け⼊れて運⽤が回るか。認知負荷に耐えられるか。「なぜ今やる必 要？」 チームメンバー ⼿段‧実⾏の妥当性 なぜEKSか。代替案と⽐べて筋が良いか。やりきれる体制か EM⾃⾝ リスクの妥当性 失敗したら撤退できるか。⼩さく失敗できる設計になっているか ⼤きな意思決定は別々の妥当性を説明する仕事 ⸺ 当初の技術的資料に⽋けていたのは「ステークホルダーへの妥当性説明」
25. 3. 3つの壁｜壁② 時間の捻出 • チーム内の「⼩さなGo」：全体の10%以下の時間でPoCを作る ‐ ⼩さく失敗しながら「できそうか」を確認する • PoCに割く時間を絞って、チームの成果は出し続ける ‐ 半分をPoCに注げば「あのチームは何をやっているんだ？」となる。あくまでも通常業務の品質を下げないように。 • PoCをユーザ（社内エンジニア）に触ってもらう ‐ 「これはいいものだ」と感じてもらうところまでが検証。逆にここまでは周りのチームに⼤々的にやりますとは⾔ってな い。余計なハレーションを⽣みたくない。 既存事業を⽌めずに、⼩さく失敗できる形を作る このプロセスを経て⾃分⾃⾝もイケるかも？🤔 と強く感じていった 25
26. 3. 3つの壁｜壁③ 仲間づくり • 基盤チームが旗を振るだけでは、全社には広がらない • 開発のEMに実際に触ってもらう ‐ 触った体験が、⼈を「評論家」から「推進者」に変える • 推進者が開発チームの中にいることで、依頼⽂化の外側に運⽤が根付く 開発チームのEngineering Managerに触ってもらい、推進者になってもらう 26
27. 3. 3つの壁｜ • 2025/8頃：AIブームで、開発者が「⼩さなアプリを動かす基盤」を求めていた ‐ CTOとPlatform Engineering 推進の進捗説明をしているときに、「それ使いたいんだけど」という話になった ‐ 準備していた基盤を社内向けに調整し、⼩さな基盤を提供した ‐ みんな⾃分のアプリを動かしたくてどんどん乗っかってきた ‐ 実際に触ってもらうことで、EKSへのアレルギーが少しずつ減っていった • 2025/10頃：⼤型の新規開発案件が⼊ってきた ‐ 準備していたEKS基盤の全⾯採⽤を提案（実需との接続） ‐ ある程度の作り込みが完了していたが、まだまだ⾜りない状態ではあった。が、ここは全⼒で「やれます！」をアピール • 2026/1頃：先⾏数チームがPlatform上で稼働しはじめる AIブームが、最初のユーザを連れてきた。そして全⾯採⽤へ こちらから使って欲しいと強く説得するのではなく、ニーズに接続することができた（偶然） 解像度が⼀定のラインを超えたら推進者に変わるを感じられた瞬間 27
28. 04 メンバー向け提案：提案が通りやすくなるか も知れない⽅法 28
29. 4. メンバー向け提案｜その1‧その2 • 提案① 実⾏⼒は、⾔葉ではなく「証拠」で⽰す ‐ Mgrの懸念は「やる気」ではなく「実⾏⼒」に向いている ‐ 実例：断られた2名は、具体的なネットワーク図を書いて再提案してきた • 提案② ⼀つ上の⽴場の「関⼼事の⾔語」で書く ‐ ⾦銭的な合理性‧実⾏⼿段の合理性‧組織体制 ⸺ 上位レイヤーはここで判断する • いきなり上位レイヤーの⾔葉で書けるわけではないので、1つ上のレイヤーが何を気にしているのかを気にしよう ✔ cf. 「マネージャーって何の仕事しているか分からない」 ‐ 1つ上の理解は、やりたいことの実現への近道であり、評価への接続でもある（かもしれない） 実⾏⼒は「証拠」で⽰し、⼀つ上の⽴場の「関⼼事の⾔語」で書く 29
30. 4. メンバー向け提案｜その3‧その4 • 提案③ 「Mgrが出しやすいGo」のサイズで提案する ‐ 全⾯移⾏のYes/Noを迫ると、MgrはNoと⾔わざるを得ない ‐ 実例：チーム時間の10%以下でのPoCという形なら、Mgrにとって「出せるGo」になる • 提案④ Noは辞めて欲しいではない場合もあると⼼得る、デモチしない ‐ Noは「中⾝の否定」ではなく「判断するための材料がまだ揃っていない」のサインかもしれない ‐ 実例：既存構成の学習を続けて証拠を持って再提案してきた積み重ねが、最終的なGoにつながった 「Mgrが出しやすいGo」のサイズで提案し、断られてもやめない 30
31. 05 Mgr向け提案：メンバーのモチベを下げずに 上位戦略と紐づけながら前に進めるには 31
32. 5. Mgr向け提案｜その1‧その2 • 提案① 断るときは「何が揃えばGoか」を⼀緒に⽰す ‐ 課題感が⼀致していることは、明⽰的に⾔葉にして伝える（デモチ防⽌） • 提案② Goは0/1ではない。「⼩さなGo」という中間の選択肢を持つ ‐ 10% PoCなら、⾒え⽅リスクを管理しつつメンバーの提案を殺さない ‐ ちゃんと適切なトレードオフにするのは腕の⾒せどころ 断るときは「何が揃えばGoか」を⽰し、「⼩さなGo」という中間の選択肢を持つ No ⼩さなGo （10% PoC） 全⾯Go ▲ ここを持てるかがEMの腕 32
33. 5. Mgr向け提案｜その3‧その4‧その5 • 提案③ 実⾏⼒ ＝ チームのケイパビリティ × 信頼残⾼ × ラストマンシップ ‐ ケイパビリティはチームの能⼒ ‐ 信頼残⾼と姿勢は⽇頃の仕事をどれだけ愚直にこなすか ‐ ラストマンシップを発揮するメンバーには応援者が現れる ‐ ⽋けてると感じるときは回り道をしたほうがいいかもしれない • 提案④ ニーズが来る前に⼩さく仕込み、来たら接続する ‐ （正直ここは偶然が重なったと思う） ‐ チャンスはいつ来るのか分からないので、「うまくいってる時」に仕込むのがいい ‐ うまく⾏ってないときにやり始めるのは難しい（説得難易度も上がる） • 提案⑤ 上位戦略との「翻訳」はEMの仕事と⼼得る ‐ 技術の確からしさはメンバーが、⾦銭‧組織体制‧事業タイミングへの翻訳はEMが担う 観察し、仕込み、翻訳する ⸺ それがEMの仕事 33
34. 06 まとめ 34
35. 6. まとめ｜依頼⽂化をやめる⽇ 変えたかったのは組織構造。Platform Engineeringは、そのHowにすぎない。提案推進のために戦略を持つ。 1 ログラスは1年以上かけて、既存事業を伸ばしながら、次の成⻑の基盤への投資を続けてきた 2 変えたかったのは「依頼⽂化」という組織構造 ⸺ EKS / Platform EngineeringはそのHow 3 推進できたのは、技術の外側（お⾦‧組織‧信頼）に関⼼を広げて戦略的に取り組んだから Inclusive SRE 技術は今も昔も⼤事。⼀⽅で包括的なスキルを伸ばすということにも、タイミングをみて意識を広げる。 AIの発展で「技術だけ」の価値は相対的に下がるかもしれない。 技術と経営と組織をつなげられるエンジニアの価値は上がる。