AI x Platform Engineeringでスケーラブルな組織を作るには
by
Kazuhiro Hashimoto
×
Copy
Open
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
Slide 1
Slide 1 text
AI x Platform Engineeringで スケーラブルな組織を作るには アーキテクチャConference 2025 - Findy Tools @ 25’ 11/20 株式会社タイミー プラットフォームエンジニアリング 1G Group Manager 橋本 和宏
Slide 2
Slide 2 text
Copyright © Timee All Rights Reserved 2 自己紹介 2002〜2014:SIer x 2社 ネットワークエンジニア 2015〜2024:ゲーム会社 x 2社 サーバインフラ / SREリード 2024/07〜:株式会社タイミー Platform Engineering 1G にICとしてJOIN 2024/11〜:同、株式会社タイミー 同チームにてGroup Manager SRE / Platform Engineering AWS / GCP IaC / GitHub Actions プロダクトセキュリティ
Slide 3
Slide 3 text
1 そもそも Platform Engineeringって?
Slide 4
Slide 4 text
Copyright © Timee All Rights Reserved Platform Engineering? 弊社採用資料より抜粋
Slide 5
Slide 5 text
Copyright © Timee All Rights Reserved Platform Engineering?(つづき) 弊社採用資料より抜粋
Slide 6
Slide 6 text
Copyright © Timee All Rights Reserved Platform Engineering?(つづき) 弊社採用資料より抜粋
Slide 7
Slide 7 text
Copyright © Timee All Rights Reserved Platform Engineering?(つづき) 弊社採用資料より抜粋
Slide 8
Slide 8 text
Copyright © Timee All Rights Reserved 8 Platform Engineering?(つづき) Platform Engineering のきっかけ 開発チームがすべてを担当するのは限界 • Railsアップグレード • AWS管理・クラウドコスト最適化 • CI/CDメンテ • SRE運用 → オフローディングとして PFE部門が生まれた
Slide 9
Slide 9 text
Copyright © Timee All Rights Reserved 9 Platform Engineering?(つづき) SRE・インフラエンジニアな職能。開発チームの認知負荷を軽減し、 スケーラブルなプラットフォームを提供する。 AWS クラウドインフラの 設計・運用 Terraform IaC Infrastructure as Code によるインフラ管理 Datadog モニタリング 可観測性 GitHub Actions CI/CDパイプラインの 構築・運用 主なスキルセット チーム・ミッション ※AWS、Terraform、Datadog、GitHub Actions の名称・ロゴは各社の商標です。
Slide 10
Slide 10 text
Copyright © Timee All Rights Reserved 10 Platform Engineering?(つづき) PFEの支援モデル feat. チームトポロジー Embedded High Cost / 乱発するとリソース枯渇 Enabling Medium cost XaaS Low cost / 最もスケーラブル Embedded は「できれば最後に切りたいカード」 通常は XaaS・Enabling で回す構造が理想
Slide 11
Slide 11 text
2 いまさらですが 弊社タイミーについて
Slide 12
Slide 12 text
Copyright © Timee All Rights Reserved 12 タイミーとは
Slide 13
Slide 13 text
Copyright © Timee All Rights Reserved 13 タイミーの特徴
Slide 14
Slide 14 text
Copyright © Timee All Rights Reserved 14 導入実績
Slide 15
Slide 15 text
Copyright © Timee All Rights Reserved 15 導入企業の例
Slide 16
Slide 16 text
3 PFE x スケーラブル?
Slide 17
Slide 17 text
Copyright © Timee All Rights Reserved 17 なぜこのテーマなのか - 問題意識・モチベ プロダクト・組織が成長すると • 機能増加 • 依存関係の複雑化 • ガバナンス・セキュリティ要求増加 → 認知負荷の増加
Slide 18
Slide 18 text
Copyright © Timee All Rights Reserved 18 なぜこのテーマなのか - 問題意識・モチベ(つづき) PFEは「少数」になりやすく詰まりやすい PFEは7名(約5%) 組織全体の開発者に対して少ない 制約・ガードレール 基盤でありˮ枠ˮ組みになるもの 属人化で全体スピードが落ちる 知識の偏在が組織のボトルネックに → 開発速度の隠れた律速条件になるかもしれない・人を増やすのも難しいし、人を増やした場合のオーバーヘッドも
Slide 19
Slide 19 text
Copyright © Timee All Rights Reserved 19 つまり? PFEボトルネックになりがち
Slide 20
Slide 20 text
Copyright © Timee All Rights Reserved 20 前提となる会社の状況など(個人の感想です) 開発者が全部 PFEがオフロード PFE + xCoE etc. 大規模・分業化 弊社はたぶん このあたり
Slide 21
Slide 21 text
Copyright © Timee All Rights Reserved 21 中間まとめ - 長いまえおきはここまで ● Platform Engineeringは開発者の認知負荷を軽減し、スケーラブルな基盤を提供する ○ 比較的少数のPFEチームは開発組織のボトルネックとなりうる (人がnot スケーラブル 😢) ● 理想的なPFE支援モデルはよりXaaS(工数少なめ) にすること。であるが... ○ Embeddedが一周回って早い説 etc. ● “手厚い”支援を開発者が受けられる状態にしつつ、 PFEもスケーラブルに ○ これ、AIでなんとかできないかな?
Slide 22
Slide 22 text
4 22 AI x スケーラブル?
Slide 23
Slide 23 text
Copyright © Timee All Rights Reserved 23 前置きばかりだと飽きちゃいますよね ※この構成は開発中のものであり実際の仕組みと異なる場合があります。 ※AWS及び各リソース、 GitHub、Devinの名称・ロゴは各社の商標です。
Slide 24
Slide 24 text
Copyright © Timee All Rights Reserved 24 背景情報は ”設定の外 ”にある AIに調査とドキュメント化をさせる 人がAIのドキュメントに補足する AIがドキュメント化→人間が補足を書く(分からないこと・決まってないことをリファイン AI…というループを想定
Slide 25
Slide 25 text
Copyright © Timee All Rights Reserved 25 設定(As-Is)を抽出する仕組みについて terraform(IaC)コード + CodingAgent + MCPじゃ駄目なんですか? →頑張ればできそうではあるんですが、いろいろ大変でした( awscliのdescribe的なものが結局強かった)
Slide 26
Slide 26 text
Copyright © Timee All Rights Reserved 26 DevinがPFEの一人として振る舞ってくれる(はず) Devinは一例。Gitのドキュメントを統合して Chatで答えてくれるのが良い →もちろんLocalPC上でCodingAgent(Claude Code, Cusror, GitHub Copilot etc)に聞くでもOK
Slide 27
Slide 27 text
Copyright © Timee All Rights Reserved 27 やりたい世界観はこう - 結構まだ遠いけれど ... 本番環境のDBの可用性 担保はどうなっています か? 😀 日次バックアップが〜〜 で設定されています。 〇〇の目的により△△に よる保護がされていま す。 ◯◯というs3バケットはど ういう用途ですか?な ぜ〜〜な設定なんでしょ うか? △△環境で〜〜な用途で 利用されています。 public accessが〜〜は XXのためになります。 ここまで背景と設定を AIが理解していれば HCL等IaCコード生成もスムーズ(なはず)
Slide 28
Slide 28 text
Copyright © Timee All Rights Reserved 28 支援モデル x AIで考えると PFEの支援モデル feat. チームトポロジー Embedded High Cost / 乱発するとリソース枯渇 Enabling Medium cost XaaS Low cost / 最もスケーラブル Embedded は「できれば最後に切りたいカード」 通常は XaaS・Enabling で回す構造が理想 ココをAI支援でブースト コラボモードの選択肢を増やす
Slide 29
Slide 29 text
Copyright © Timee All Rights Reserved 29 少し引いて見たときの使われどころ
Slide 30
Slide 30 text
Copyright © Timee All Rights Reserved 30 どういうところに効いてくるのか? AIがプラットフォーム全体を説明で きる 開発者がAI経由で Why を学べる PFE内の知識共有を加速 担当交代やスケーリングが容易に 監査・統制にAIを活用
Slide 31
Slide 31 text
5 31 まとめ
Slide 32
Slide 32 text
Copyright © Timee All Rights Reserved 32 まとめ ● Platform Engineeringは開発者の認知負荷を軽減し、スケーラブルな基盤を提供する ○ 比較的少数のPFEチームは開発組織のボトルネックとなりうる(人が not スケーラブル 😢) ○ PFEのスケーラビリティ (複数のドメイン知識の同期・キャッチアップ etc.)をAI支援で担保 ● 理想的なPFE支援モデルはよりXaaSにすること。ではある”が” ○ AIが開発者に対してEmbedded/Enablingをしてくれるとより良い開発体験となるのでは ○ 開発者がAI支援によりフルサイクル性を獲得 することで開発・価値提供速度が上がるのもアリ ● SDD(仕様駆動開発)と似ている がアプローチ・扱うものが少し異なる ○ AI-DLCは今後の開発のキーになると思うので、これも一つの AI-DLC(かも) ● AIの活用は知識共有を加速し、 AIによってPFEをスケーラブル 😀にしていく!
Slide 33
Slide 33 text
積極採用中です!! タイミーの開発組織は新しいフェーズに突入しており、新しい仲間を募集してます! 是非お気軽にお声がけください!