Upgrade to Pro — share decks privately, control downloads, hide ads and more …

いつPlatform Engineeringを始めるべきか?〜レバテックのケーススタディ〜 P...

いつPlatform Engineeringを始めるべきか?〜レバテックのケーススタディ〜 Platform Engineering Kaigi 2024

# Platform Engineering Kaigi 2024
Track B 14:30 - 15:00

# 概要
2022年、ガートナーのハイプサイクルでPlatform Engineeringが登場すると、一気に注目が集まり今ではハイプサイクル上で「過度な期待」とされています。
レバテックでは、Platform Engineeringが注目されるより前、2020年に基盤システムグループ(すなわちプラットフォームチーム)が組閣され、活動を続けてきました。
レバテックにおけるプラットフォームとはなんだったのか、その経験から感じるPlatform Engineeringへの想い。
そして多くの人が感じるであろう「いつPlatform Engineeringを始めるべきなのか?」という疑問に対して考察します。

Tech Leverages

July 09, 2024
Tweet

More Decks by Tech Leverages

Other Decks in Technology

Transcript

  1. | © 2024 Levtech Co., Ltd. 2 レバテック開発部 基盤システムグループリーダー 小堺 拓実

    TAKUMI KOSAKAI #任天堂ゲーマー #一児の父 #お酒飲めません #初登壇 #写真はノラネコ
  2. | © 2024 Levtech Co., Ltd. 5 事業ポートフォリオ レバテックについて エージェント プログラミング

    スクール コンテンツ メディア プラット フォーム ダイレクト リクルーティング ITエンジニア・クリエイターの フリーランス・転職・就職・教育の すべてを備える採用プラットフォーム エージェントを中心に、求人媒体、 プログラミング教育まで IT専門職のキャリアを厚くサポート。
  3. | © 2024 Levtech Co., Ltd. 6 プロダクト・サービス レバテックについて コンテンツメディア マイページ

    採用管理ツール 案件/求人サイト スマホアプリ LP/サービスサイト
  4. | © 2024 Levtech Co., Ltd. 7 技術広報 レバテックについて カンファレンススポンサー や

    テックブログ に力を入れてます!  もフォローしてね! etc.
  5. | © Leverages inc. 9 1. レバテックで起きたこと a. 基盤システムグループの 成り立ちとその課題 b.

    課題から生まれる問いと 答え 2. いつPlatform Engineeringを始めるべき か 目次
  6. | © Leverages inc. 10 1. レバテックで起きたこと a. 基盤システムグループの 成り立ちとその課題 b.

    課題から生まれる問いと 答え 2. いつPlatform Engineeringを始めるべき か 目次
  7. | © Leverages inc. 11 1. レバテックで起きたこと a. 基盤システムグループの 成り立ちとその課題 b.

    課題から生まれる問いと 答え 2. いつPlatform Engineeringを始めるべき か 目次
  8. | © Leverages inc. 35 • 案件マイクロサービス • 人材マイクロサービス • 流入情報連携マイクロサービス

    • 通知マイクロサービス • レバテックID(認証・認可マイクロサービス) • 社内アカウントマイクロサービス • 社内共通ライブラリ 結果、いくつかのマイクロサービスが誕生 基盤システムグループの軌跡 これ プラットフォームか? うんうん、 それもまた プラットフォーム だね
  9. | © Leverages inc. 36 • 案件マイクロサービス • 人材マイクロサービス • 流入情報連携マイクロサービス

    • 通知マイクロサービス • レバテックID(認証・認可マイクロサービス) • 社内アカウントマイクロサービス • 社内共通ライブラリ 特性の違うマイクロサービス 基盤システムグループの軌跡 業務ドメイン 機能軸 共通機能の提供 基幹システムの分割
  10. | © Leverages inc. 37 • 案件マイクロサービス • 人材マイクロサービス • 流入情報連携マイクロサービス

    特性の違うマイクロサービス 基盤システムグループの軌跡 業務ドメイン 基幹システムの分割
  11. | © Leverages inc. 38 • 案件マイクロサービス • 人材マイクロサービス • 流入情報連携マイクロサービス

    • 通知マイクロサービス • レバテックID(認証・認可マイクロサービス) • 社内アカウントマイクロサービス • 社内共通ライブラリ 特性の違うマイクロサービス 基盤システムグループの軌跡 業務ドメイン 機能軸 共通機能の提供 基幹システムの分割
  12. | © Leverages inc. 39 • 案件マイクロサービス • 人材マイクロサービス • 流入情報連携マイクロサービス

    特性の違うマイクロサービス 基盤システムグループの軌跡 業務ドメイン プラットフォームチームが 業務ドメインを扱うの? 業務ドメインはストリーム アラインドチームの領域 じゃないの?
  13. | © Leverages inc. 40 • 案件マイクロサービス • 人材マイクロサービス • 流入情報連携マイクロサービス

    プラットフォームチームが業務ドメインを持つとどうなるか 基盤システムグループの軌跡 業務ドメイン プラットフォームチームが 業務ドメインを扱うの? 業務ドメインはストリーム アラインドチームの領域 じゃないの?
  14. | © Leverages inc. 44 主な機能 • CRUD機能 • 単一取得 •

    検索機能 案件マイクロサービス プラットフォームチームが業務ドメイン扱うのってどうなの 案件MS 営業支援 オウンド サイト toC toB データ連携 Readだけ
  15. | © Leverages inc. 49 “リソースの各項目の必要性はリソース自体に内在するわ けではなく、個々の業務のニーズから決まってくるからで す。以前、筆者が経験したプロジェクトでは、業務領域別 のチーム以外に「マスター管理チーム」があって、マス ター(リソース)の設計を担当していました。そのメン バーが、マスターに何を保持するべきかに関して、いつも

    困惑していたことをよく記憶しています。今から振り返れ ば、仕切りに無理があったというべきでしょう。” データが流れる向きと要求の向きは逆方向になる プラットフォームチームが業務ドメイン扱うのってどうなの 第9章 マスターの共有──エンティティとロール方式より https://direct.gihyo.jp/view/item/000000003290
  16. | © Leverages inc. 61 • 市場からのプレッシャーに晒されづらい • 顧客が開発者なので距離が近い さらにレバテックでは •

    問い合わせが少ない • 技術的負債が少ない といった要素もあった 心の平穏を保ちやすい プラットフォームエンジニアリングは楽なのか? 心理的に楽かも
  17. | © Leverages inc. 62 一方、世間的にはプラットフォームチームが 「なんでも屋」になりがちで大変だとか レバテックでは SREや情シスもいるので、何でもかんでも プラットフォームチームにはならなかった あくまで一例に過ぎない

    プラットフォームエンジニアリングは楽なのか? Platform Team と 社内政治 〜 出でよ、 Platform Champion 〜 https://speakerdeck.com/kenojiri/pla tform-team-and-internal-politics-plat form-engineering-meetup-number-2
  18. | © Leverages inc. 72 Webシステムの運用とは プラットフォームエンジニアリングは運用や問い合わせで大変なチームに貢献できるのか? • サーバーの設定・監視 • アプリケーションのデプロイ・監視・定期アップデート

    • データベースのチューニング・監視 • セキュリティ(アカウント発行・アクセス権限設定・脆弱性スキャン) • ネットワークの監視・DNS設定 • 監査対応 • 障害対応 他にも色々
  19. | © Leverages inc. 73 対して、プラットフォームエンジニアリングができること • Infrastructure as Code化 •

    コンテナオーケストレーション • CI/CDパイプライン整備 • 共通ログ基盤 • トイルの自動化 など 他にもありそう プラットフォームエンジニアリングは運用や問い合わせで大変なチームに貢献できるのか?
  20. | © Leverages inc. 85 • 本質的な複雑さ • 偶有的な複雑さ • 規模による複雑さ

    「複雑」とは? プラットフォームエンジニアリングは技術的負債を抱えたレガシーシステムを運用するチームに貢献できるのか?
  21. | © Leverages inc. 87 • 偶有的な複雑さ ◦ 技術的要因による複雑さ ◦ 仕様(業務)とコードの乖離

    「複雑」とは? プラットフォームエンジニアリングは技術的負債を抱えたレガシーシステムを運用するチームに貢献できるのか?
  22. | © Leverages inc. 89 • 本質的な複雑さ ◦ 対象とするドメイン知識の複雑さ • 偶有的な複雑さ

    ◦ 技術的要因による複雑さ ◦ 仕様(業務)とコードの乖離 • 規模による複雑さ ◦ 対象とするドメインの広さ、連携するシステムの数など 「複雑」とは? 余談: これらの複雑さを起因としたレガシーシステムに対するアプローチを システム思考した記事を書きました https://zenn.dev/levtech/articles/fb8b8974a3b633 プラットフォームエンジニアリングは技術的負債を抱えたレガシーシステムを運用するチームに貢献できるのか?
  23. | © Leverages inc. 90 • 本質的な複雑さ ◦ 対象とするドメイン知識の複雑さ 対して、プラットフォームエンジニアリングが出来ること ドメイン知識の

    複雑さは取り除けない プラットフォームエンジニアリングは技術的負債を抱えたレガシーシステムを運用するチームに貢献できるのか?
  24. | © Leverages inc. 91 • 偶有的な複雑さ ◦ 技術的要因による複雑さ ◦ 仕様(業務)とコードの乖離

    対して、プラットフォームエンジニアリングが出来ること 技術的要因による 複雑さは減らせるかも 仕様とコードの乖離は 無くせない プラットフォームエンジニアリングは技術的負債を抱えたレガシーシステムを運用するチームに貢献できるのか?
  25. | © Leverages inc. 92 • 規模による複雑さ ◦ 対象とするドメインの広さ、連携するシステムの数など 対して、プラットフォームエンジニアリングが出来ること ドメイン分割は

    プラットフォームの 関心事じゃあない プラットフォームエンジニアリングは技術的負債を抱えたレガシーシステムを運用するチームに貢献できるのか?
  26. | © Leverages inc. 97 • Q. 基盤システムグループは目標がない? ここまでの問いと答え まとめ 基盤システムグループの成り立ちは近年のPlatform

    Engineeringとは 別文脈。「基幹システムの分割」と「共通機能の提供」という2軸、そ して分割により生まれたシステム運用の受け身体制から目標があやふや になった。
  27. | © Leverages inc. 98 • Q. プラットフォームエンジニアリングは楽なのか? • Q. プラットフォームエンジニアリングは運用や問い合わせで大変な

    チームに貢献できるのか? • Q. プラットフォームエンジニアリングは技術的負債を抱えたレガ シーシステムを運用するチームに貢献できるのか? ここまでの問いと答え まとめ
  28. | © Leverages inc. 99 • Q. プラットフォームエンジニアリングは楽なのか? • Q. プラットフォームエンジニアリングは運用や問い合わせで大変なチーム

    に貢献できるのか? • Q. プラットフォームエンジニアリングは技術的負債をたくさん抱えたシス テムを運用するチームに貢献できるのか? ここまでの問いと答え まとめ 楽かどうかは環境に依る。 一般的にはシステム運用に貢献できるが、レバテックの基盤グループは 貢献できていなかった。 技術的負債と呼ばれる「複雑さ」に対しては本質的なアプローチになら ない。
  29. | © Leverages inc. 106 • Aチーム:3名 ◦ 担当システム:案件・通知・流入・社内アカウント • Bチーム:2名

    ◦ 担当システム:人材 • Cチーム:5名 ◦ 担当システム:レバテックID As-Is:当時の編成 今あるチーム・システムを再編成する
  30. | © Leverages inc. 107 • Aチーム:3名 ◦ 担当システム:案件・通知・流入・社内アカウント • Bチーム:2名

    ◦ 担当システム:人材 • Cチーム:5名 ◦ 担当システム:レバテックID As-Is:当時の編成 今あるチーム・システムを再編成する 業務ドメイン 機能軸
  31. | © Leverages inc. 108 • Aチーム:3名 ◦ 担当システム:案件・流入 • Bチーム:2名

    ◦ 担当システム:人材・通知 • Cチーム:5名 ◦ 担当システム:レバテックID・社内アカウント まずは負荷分散と責務整理 今あるチーム・システムを再編成する ちょっと楽になった 業務ドメインだけになった 認証・認可に集中!
  32. | © Leverages inc. 109 • Aチーム:3名 ◦ 担当システム:案件・流入 • Bチーム:2名

    ◦ 担当システム:人材・通知 • Cチーム:5名 ◦ 担当システム:レバテックID・社内アカウント まずは負荷分散と責務整理 今あるチーム・システムを再編成する ちょっと楽になった 業務ドメインだけになった 認証・認可に集中!
  33. | © Leverages inc. 110 • Aチーム:3名 ◦ 担当システム:案件・流入 • Bチーム:2名

    ◦ 担当システム:人材・通知 • Cチーム:5名 ◦ 担当システム:レバテックID・社内アカウント まずは負荷分散と責務整理 今あるチーム・システムを再編成する ちょっと楽になった 業務ドメインだけになった 認証・認可に集中!
  34. | © Leverages inc. 111 • Aチーム:3名 ◦ 担当システム:案件・流入 • Bチーム:2名

    ◦ 担当システム:人材・通知 • Cチーム:5名 ◦ 担当システム:レバテックID・社内アカウント まずは負荷分散と責務整理 今あるチーム・システムを再編成する ちょっと楽になった 業務ドメインだけになった 認証・認可に集中!
  35. | © Leverages inc. 113 • Aチーム:3名 ◦ 担当システム:案件・流入 • Bチーム:2名

    ◦ 担当システム:人材・通知 • Cチーム:5名 ◦ 担当システム:レバテックID・社内アカウント 残るはBチームとCチーム 今あるチーム・システムを再編成する
  36. | © Leverages inc. 122 • チームには適切な人数の目安がある ◦ 2ピザルール ▪ チームの参加者は2枚の大きなピザで満たされるぐらいの大き

    さ ◦ 故J.リチャード・ハックマン氏の研究 ▪ プロジェクトチームの最適なメンバー数は4人から6人であ り、10人以上のメンバーを持つべきではない ◦ DXクライテリア TEAM-1-1 ▪ システムを開発する1チームの構成人数は、3人以上10人以下 か 分けない方がいいこともあると思う理由① SREがPlatform Engineeringの責務を持つのってどうなの? 参考 https://dxcriteria.cto-a.org/8a4cd78ec4c546b083f1be075da2106e
  37. | © Leverages inc. 125 • プラットフォームチームやSRE(イネイブリングチーム)は ストリームアラインドチームありきの存在 ◦ ストリームアラインドチームが必要十分な人数と能力を 有している状態で、そこからストリームアラインドチー

    ムの負荷を下げたり複数チームにスケールしやすくする ために初めてプラットフォームやSREが必要になる。 分けない方がいいこともあると思う理由② SREがPlatform Engineeringの責務を持つのってどうなの?
  38. | © Leverages inc. 127 • 現実は、組織よりも先に事業が大きくなって、チームが必要十分な 人数と能力を満たさないまま、システムやチームが増える • システムやチームが増えると... ◦

    共通化してコストを下げたくなるので、基盤(プラットフォー ムチーム)が求められるようになる プラットフォームチームやSRE(イネイブリングチーム)は ストリームアラインドチームありきの存在 の補足 SREがPlatform Engineeringの責務を持つのってどうなの?
  39. | © Leverages inc. 128 • 現実は、組織よりも先に事業が大きくなって、チームが必要十分な 人数と能力を満たさないまま、システムやチームが増える • システムやチームが増えると... ◦

    共通化してコストを下げたくなるので、基盤(プラットフォー ムチーム)が求められるようになる ◦ 全てのチームに人を増やして能力を満たすことが難しくなる (長期的な取り組みになる)ので、別のアプローチとして教育 (イネイブリングチーム)が求められるようになる プラットフォームチームやSRE(イネイブリングチーム)は ストリームアラインドチームありきの存在 の補足 SREがPlatform Engineeringの責務を持つのってどうなの?
  40. | © Leverages inc. 129 Q. SREがPlatform Engineeringの責務を持つのって どうなの? 組織の状態によっては持っても良いと思う。 A.

    ストリームアラインドチームが必要十分な人数と能力を満たしていない状態で プラットフォームチームとSREを分けて構成するほど人数をかけなくて良いのでは ないか?と考える ※レバテックでは今後、SREチームでPlatform Engineeringをやっていく
  41. | © Leverages inc. 130 • Aチーム:3名 ◦ 担当システム:案件・流入 • Bチーム:2名

    ◦ 担当システム:人材・通知 • Cチーム:5名 ◦ 担当システム:レバテックID・社内アカウント To-Be:そしてCチームだけが残った 今あるチーム・システムを再編成する
  42. | © Leverages inc. 131 • Aチーム:3名 ◦ 担当システム:案件・流入 • Bチーム:2名

    ◦ 担当システム:人材・通知 • Cチーム:5名 ◦ 担当システム:レバテックID・社内アカウント Cチームはそのまま? 今あるチーム・システムを再編成する 検討中
  43. | © Leverages inc. 134 1. レバテックで起きたこと a. 基盤システムグループの 成り立ちとその課題 b.

    課題から生まれる問いと 答え 2. いつPlatform Engineeringを始めるべき か 目次
  44. | © Leverages inc. 140 始めるべきかの優先度は会社が取り組んでいる事業内容 にも依るのではないか • プロダクトが事業の中心なら、優先度が高くなる ◦ 開発生産性が上がることでリリースサイクルが

    速くなり事業価値を生みやすくなる • 人が事業の中心なら、優先度が低くなる ◦ その人達の生産性・体験を上げる方が事業価値 に繋がりやすい ▪ 今のレバテックはこっち 事業内容も考慮する いつPlatform Engineeringを始めるべきか?
  45. | © Leverages inc. 144 • ストリームアラインドチームは今、どんな課題を抱えていますか? • その課題は、Platform Engineeringによって解決できますか? •

    その課題を解決すると、事業や会社にどんな影響を与えられそうで すか? • Platform Engineering専門のチームが必要ですか?SREに含めた り、チームを組閣せずともできることがありませんか? 示唆を得られるかもしれない4つの問い いつPlatform Engineeringを始めるべきか?
  46. | © 2024 Levtech Co., Ltd. 149 こんなこと話しましょう! • PlatformEngineeringやってるけどうまくいかない •

    PE組織のマネジメントが難しい • PEこれからやり始めようと思うけどどうしよう • レバテックのPE、こうやればええんちゃう?                          など オフラインの人はブースにて、 オンラインの方はカジュアル面談お願いします! 👈フォームはこちら https://hrmos.co/pages/leverages/jobs/A_c_00071