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

by Tech Leverages

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

Slide 3

Slide 3 text

レバテックについて

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

本題いつPlatform Engineeringを始めるべきか？

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

|　© Leverages inc. 12 Platform Engineeringを始めるのは、今じゃなくてもいいかもしれない。現場をよく観察・分析して、本当に必要だと思った時、 Platform Engineeringを始めよう伝えたいこと本発表にて

Slide 13

Slide 13 text

|　© Leverages inc. 13 ある日、考え事をしていました。導入 ※若干のフィクションを含みます今後、基盤システムグループをどうしていこうか。。

Slide 14

Slide 14 text

|　© Leverages inc. 14 すると、どこかから声が・・導入 ※若干のフィクションを含みます基盤グループはやることありません。暇です。基盤システムグループ

Slide 15

Slide 15 text

|　© Leverages inc. 15 すると、どこかから声が・・導入 ※若干のフィクションを含みます基盤グループは楽そうでいいなあ・・ストリームアラインドチーム基盤グループはやることありません。暇です。基盤システムグループ

Slide 16

Slide 16 text

|　© Leverages inc. 16 ええ！？

Slide 17

Slide 17 text

|　© Leverages inc. 17 そんな馬鹿な・・やることはいくらでもあるはず・・

Slide 18

Slide 18 text

|　© Leverages inc. 18 とりあえず話を聞いてみよう

Slide 19

Slide 19 text

|　© Leverages inc. 19 基盤グループメンバーに聞くと導入 ※若干のフィクションを含みます確かにやることはありますけど、依存ライブラリのメンテナンスとか、システム利用者の要望に応えるばっかりで目標がありません。

Slide 20

Slide 20 text

|　© Leverages inc. 20 ストリームアラインドチームに聞くと導入 ※若干のフィクションを含みます僕たちは日々の運用や問い合わせ対応で一杯一杯です。それに、技術的負債をたくさん抱えたレガシーシステムを開発するのは開発者体験が悪いです。

Slide 21

Slide 21 text

|　© Leverages inc. 21 どうしてこうなった？

Slide 22

Slide 22 text

|　© Leverages inc. 22 発言について考える回想プラットフォームチーム確かにやることはありますけど、依存ライブラリのメンテナンスとか、システム利用者の要望に応えるばっかりで目標がありません。

Slide 23

Slide 23 text

|　© Leverages inc. 23 Q. プラットフォームチームは目標がない？

Slide 24

Slide 24 text

|　© Leverages inc. 24 A. 当然ある

Slide 25

Slide 25 text

|　© Leverages inc. 25 プラットフォームエンジニアリングの目標は開発者の認知負荷を下げ（開発者体験を上げ）安全に素早くリリースできるようにすること当然あるあるよ基盤グループは違うの？

Slide 26

Slide 26 text

|　© Leverages inc. 26 Platform Engineeringを掲げて始まった組織ではなかったあるよじゃあ、基盤グループの目標ってなんだったの？基盤システムグループはプラットフォームエンジニアリングが注目を浴びるもっと前からあった

Slide 27

Slide 27 text

|　© Leverages inc. 27 レバテックの基盤システムグループはなぜ作られたのか

Slide 28

Slide 28 text

|　© Leverages inc. 28 発端 2020年のこと事業成長のためにあんな機能もこんな機能も欲しい！エンジニア事業時間かかっちゃいますねえ

Slide 29

Slide 29 text

|　© Leverages inc. 29 弊害 2020年のことじゃあスプレッドシートで頑張るわ！エンジニア事業いつの間にか知らない運用がたくさんある・・

Slide 30

Slide 30 text

|　© Leverages inc. 30 業務とシステム間で乖離が発生しやすい状態に。弊害 2020年のこと

Slide 31

Slide 31 text

|　© Leverages inc. 31 基盤システムグループ（プラットフォームチーム）発足 2020年のこと今後のシステムの土台を作ろう！理想的なシステム開発を目指そう！

Slide 32

Slide 32 text

|　© Leverages inc. 32 近頃のPlatform Engineeringと全然違う Platform as a Productは？セルフサービスは？

Slide 33

Slide 33 text

|　© Leverages inc. 33 「共通基盤」を超えよ！今、Platform Engineeringに取り組むべき理由より

Slide 34

Slide 34 text

|　© Leverages inc. 34 基盤システムグループは事業の中心になるレガシーな基幹システムをマイクロサービスに分割して統治することを目論みました。そして同時に、システムでよく使われる機能を共通基盤として提供しようとしました。最初に手を出したのが、マイクロサービス基盤システムグループの軌跡レガシーシステムという名のケーキを分割する図

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

|　© Leverages inc. 41 「案件」という概念は、企業が「案件」を出して募集しフリーランスが「案件」に応募する。というもの案件マイクロサービスプラットフォームチームが業務ドメイン扱うのってどうなの案件募集応募

Slide 42

Slide 42 text

|　© Leverages inc. 42 そのため、toBシステムもtoCシステムも営業支援システムでも「案件」は共通リソース（マスターデータ）として使用される案件マイクロサービスプラットフォームチームが業務ドメイン扱うのってどうなの案件募集応募

Slide 43

Slide 43 text

|　© Leverages inc. 43 案件マイクロサービスプラットフォームチームが業務ドメイン扱うのってどうなの案件募集応募そのため、toBシステムもtoCシステムも営業支援システムでも「案件」は共通リソース（マスターデータ）として使用される

Slide 44

Slide 44 text

|　© Leverages inc. 44 主な機能 ● CRUD機能 ● 単一取得 ● 検索機能案件マイクロサービスプラットフォームチームが業務ドメイン扱うのってどうなの案件MS 営業支援オウンドサイト toC toB データ連携 Readだけ

Slide 45

Slide 45 text

|　© Leverages inc. 45 案件は業務ドメインだけどいろんなコンテキストで使うデータだからプラットフォームとして提供しよう！

Slide 46

Slide 46 text

|　© Leverages inc. 46 結果どうだったか

Slide 47

Slide 47 text

|　© Leverages inc. 47 チームが受け身でしか動けなくなってしまったプラットフォームチームが業務ドメイン扱うのってどうなのリモート可否情報も返すようにして！検索ロジック変えられない？企業の情報も欲しいんだけど・・

Slide 48

Slide 48 text

|　© Leverages inc. 48 「マスタデータのこの情報が欲しい」「マスタデータの検索ロジックを変えたい」こういった要望はそのマスターデータを利用する側からしか生まれないどうして受け身になってしまうのかプラットフォームチームが業務ドメイン扱うのってどうなの

Slide 49

Slide 49 text

|　© Leverages inc. 49 “リソースの各項目の必要性はリソース自体に内在するわけではなく、個々の業務のニーズから決まってくるからです。以前、筆者が経験したプロジェクトでは、業務領域別のチーム以外に「マスター管理チーム」があって、マスター（リソース）の設計を担当していました。そのメンバーが、マスターに何を保持するべきかに関して、いつも困惑していたことをよく記憶しています。今から振り返れば、仕切りに無理があったというべきでしょう。” データが流れる向きと要求の向きは逆方向になるプラットフォームチームが業務ドメイン扱うのってどうなの第9章　マスターの共有──エンティティとロール方式より https://direct.gihyo.jp/view/item/000000003290

Slide 50

Slide 50 text

|　© Leverages inc. 50 こういった状況が、目標を持つことができない一因になっていた目標がない

Slide 51

Slide 51 text

|　© Leverages inc. 51 Q. プラットフォームチームは目標がない？改め

Slide 52

Slide 52 text

|　© Leverages inc. 52 Q. 基盤システムグループは目標がない？

Slide 53

Slide 53 text

|　© Leverages inc. 53 A. 基盤システムグループの成り立ちは近年の Platform Engineeringとは別文脈であり、様々な要素を持つシステムを抱えてしまったことから、目標があやふやになった主な原因は2つ ● 基幹システムの分割と共通機能の提供という2軸 ● 分割により生まれたシステム運用の受け身体制

Slide 54

Slide 54 text

|　© Leverages inc. 54 なるほど。。この状況を変えるには体制も含めて見直す必要がありそうだ。

Slide 55

Slide 55 text

|　© Leverages inc. 55 一旦、理解が深まったところでもう一つの発言について考えみよう

Slide 56

Slide 56 text

|　© Leverages inc. 56 基盤グループは楽そうでいいなあ・・ストリームアラインドチーム

Slide 57

Slide 57 text

|　© Leverages inc. 57 Q.プラットフォームエンジニアリングは「楽」なのか？

Slide 58

Slide 58 text

|　© Leverages inc. 58 楽そうな要素を考えてみる

Slide 59

Slide 59 text

|　© Leverages inc. 59 市場からのプレッシャーに差があるプラットフォームエンジニアリングは楽なのか？ストリームアラインドプラットフォームいつできるの？リリース日は？間に合うの？急いで！ストリームアラインドのみんな、待っててくれよ〜〜 ※常にこうはならない

Slide 60

Slide 60 text

|　© Leverages inc. 60 顧客との距離に差があるプラットフォームエンジニアリングは楽なのか？ストリームアラインドプラットフォームそれエンジニアあるあるだわ〜 ※常にこうはならない話がピンとこない。。

Slide 61

Slide 61 text

|　© Leverages inc. 61 ● 市場からのプレッシャーに晒されづらい ● 顧客が開発者なので距離が近いさらにレバテックでは ● 問い合わせが少ない ● 技術的負債が少ないといった要素もあった心の平穏を保ちやすいプラットフォームエンジニアリングは楽なのか？心理的に楽かも

Slide 62

Slide 62 text

|　© Leverages inc. 62 一方、世間的にはプラットフォームチームが「なんでも屋」になりがちで大変だとかレバテックでは SREや情シスもいるので、何でもかんでもプラットフォームチームにはならなかったあくまで一例に過ぎないプラットフォームエンジニアリングは楽なのか？ Platform Team と社内政治〜出でよ、 Platform Champion 〜 https://speakerdeck.com/kenojiri/pla tform-team-and-internal-politics-plat form-engineering-meetup-number-2

Slide 63

Slide 63 text

|　© Leverages inc. 63 Q. プラットフォームエンジニアリングは「楽」なのか？

Slide 64

Slide 64 text

|　© Leverages inc. 64 A. 環境に依る

Slide 65

Slide 65 text

|　© Leverages inc. 65 A. 環境に依るレバテックにおけるプラットフォームチームは心理的に楽だったかもしれません

Slide 66

Slide 66 text

|　© Leverages inc. 66 A. 環境に依るレバテックにおけるプラットフォームチームは心理的に楽だったかもしれません ※もちろんお仕事している以上、様々な課題や悩みがありましたよ！相対的に楽という意味

Slide 67

Slide 67 text

|　© Leverages inc. 67 なるほど。でも、それだけで「楽そう」なんて言われるかな？

Slide 68

Slide 68 text

|　© Leverages inc. 68 プラットフォームエンジニアリングがストリームアラインドチームのためになっていれば言われないんじゃないの

Slide 69

Slide 69 text

|　© Leverages inc. 69 言われたことを思い出す回想ストリームアラインドチーム僕たちは日々の運用や問い合わせ対応で一杯一杯です。それに、技術的負債をたくさん抱えたレガシーシステムを開発するのは開発者体験が悪いです。

Slide 70

Slide 70 text

|　© Leverages inc. 70 言われたことを思い出す回想ストリームアラインドチーム僕たちは日々の運用や問い合わせ対応で一杯一杯です。それに、技術的負債をたくさん抱えたレガシーシステムを開発するのは開発者体験が悪いです。

Slide 71

Slide 71 text

|　© Leverages inc. 71 Q. プラットフォームエンジニアリングは運用や問い合わせで大変なチームに貢献できるのか？

Slide 72

Slide 72 text

|　© Leverages inc. 72 Webシステムの運用とはプラットフォームエンジニアリングは運用や問い合わせで大変なチームに貢献できるのか？ ● サーバーの設定・監視 ● アプリケーションのデプロイ・監視・定期アップデート ● データベースのチューニング・監視 ● セキュリティ（アカウント発行・アクセス権限設定・脆弱性スキャン） ● ネットワークの監視・DNS設定 ● 監査対応 ● 障害対応他にも色々

Slide 73

Slide 73 text

|　© Leverages inc. 73 対して、プラットフォームエンジニアリングができること ● Infrastructure as Code化 ● コンテナオーケストレーション ● CI/CDパイプライン整備 ● 共通ログ基盤 ● トイルの自動化など他にもありそうプラットフォームエンジニアリングは運用や問い合わせで大変なチームに貢献できるのか？

Slide 74

Slide 74 text

|　© Leverages inc. 74 問い合わせに対しては何かできる？ ● ポータルサイト提供 ● AIチャットボットプラットフォームエンジニアリングは運用や問い合わせで大変なチームに貢献できるのか？

Slide 75

Slide 75 text

|　© Leverages inc. 75 Q. プラットフォームエンジニアリングは運用や問い合わせで大変なチームに貢献できるのか？

Slide 76

Slide 76 text

|　© Leverages inc. 76 A. 貢献できそう！

Slide 77

Slide 77 text

|　© Leverages inc. 77 なんですが

Slide 78

Slide 78 text

|　© Leverages inc. 78 基盤システムグループは近頃のPlatform Engineeringと全然違う Platform as a Productは？セルフサービスは？ ※再掲

Slide 79

Slide 79 text

|　© Leverages inc. 79 だからといって今のシステム・組織のまま方針だけ変えるのも難しい状況「運用を楽にする」はスコープになかった基盤システムグループは違った

Slide 80

Slide 80 text

|　© Leverages inc. 80 本来ストリームアラインドチームの運用に貢献できるけど、うちはできていないことがわかったぞ

Slide 81

Slide 81 text

|　© Leverages inc. 81 あとは、なんて言われてたっけ？

Slide 82

Slide 82 text

|　© Leverages inc. 82 言われたことを思い出す回想ストリームアラインドチーム僕たちは日々の運用や問い合わせ対応で一杯一杯です。それに、技術的負債をたくさん抱えたレガシーシステムを開発するのは開発者体験が悪いです。

Slide 83

Slide 83 text

|　© Leverages inc. 83 Q. プラットフォームエンジニアリングは技術的負債を抱えたレガシーシステムを運用するチームに貢献できるのか？

Slide 84

Slide 84 text

|　© Leverages inc. 84 もう少し具体化「複雑で変更容易性の低いレガシーシステム」技術的負債を抱えたレガシーシステムとは？プラットフォームエンジニアリングは技術的負債を抱えたレガシーシステムを運用するチームに貢献できるのか？

Slide 85

Slide 85 text

|　© Leverages inc. 85 ● 本質的な複雑さ ● 偶有的な複雑さ ● 規模による複雑さ「複雑」とは？プラットフォームエンジニアリングは技術的負債を抱えたレガシーシステムを運用するチームに貢献できるのか？

Slide 86

Slide 86 text

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

Slide 87

Slide 87 text

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

Slide 88

Slide 88 text

|　© Leverages inc. 88 ● 規模による複雑さ ○ 対象とするドメインの広さ、連携するシステムの数など「複雑」とは？プラットフォームエンジニアリングは技術的負債を抱えたレガシーシステムを運用するチームに貢献できるのか？

Slide 89

Slide 89 text

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

Slide 90

Slide 90 text

|　© Leverages inc. 90 ● 本質的な複雑さ ○ 対象とするドメイン知識の複雑さ対して、プラットフォームエンジニアリングが出来ることドメイン知識の複雑さは取り除けないプラットフォームエンジニアリングは技術的負債を抱えたレガシーシステムを運用するチームに貢献できるのか？

Slide 91

Slide 91 text

|　© Leverages inc. 91 ● 偶有的な複雑さ ○ 技術的要因による複雑さ ○ 仕様（業務）とコードの乖離対して、プラットフォームエンジニアリングが出来ること技術的要因による複雑さは減らせるかも仕様とコードの乖離は無くせないプラットフォームエンジニアリングは技術的負債を抱えたレガシーシステムを運用するチームに貢献できるのか？

Slide 92

Slide 92 text

|　© Leverages inc. 92 ● 規模による複雑さ ○ 対象とするドメインの広さ、連携するシステムの数など対して、プラットフォームエンジニアリングが出来ることドメイン分割はプラットフォームの関心事じゃあないプラットフォームエンジニアリングは技術的負債を抱えたレガシーシステムを運用するチームに貢献できるのか？

Slide 93

Slide 93 text

|　© Leverages inc. 93 Q. プラットフォームエンジニアリングは技術的負債を抱えたレガシーシステムを運用するチームに貢献できるのか？

Slide 94

Slide 94 text

|　© Leverages inc. 94 A. 貢献できる事はあるが、複雑さはほとんど減らせない

Slide 95

Slide 95 text

|　© Leverages inc. 95 うーむ、どうやら彼らのようなチームを助けるにはもっと適したアプローチがありそうだ・・

Slide 96

Slide 96 text

|　© Leverages inc. 96 ● Q. 基盤システムグループは目標がない？ここまでの問いと答えまとめ

Slide 97

Slide 97 text

|　© Leverages inc. 97 ● Q. 基盤システムグループは目標がない？ここまでの問いと答えまとめ基盤システムグループの成り立ちは近年のPlatform Engineeringとは別文脈。「基幹システムの分割」と「共通機能の提供」という2軸、そして分割により生まれたシステム運用の受け身体制から目標があやふやになった。

Slide 98

Slide 98 text

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

Slide 99

Slide 99 text

|　© Leverages inc. 99 ● Q. プラットフォームエンジニアリングは楽なのか？ ● Q. プラットフォームエンジニアリングは運用や問い合わせで大変なチームに貢献できるのか？ ● Q. プラットフォームエンジニアリングは技術的負債をたくさん抱えたシステムを運用するチームに貢献できるのか？ここまでの問いと答えまとめ楽かどうかは環境に依る。一般的にはシステム運用に貢献できるが、レバテックの基盤グループは貢献できていなかった。技術的負債と呼ばれる「複雑さ」に対しては本質的なアプローチにならない。

Slide 100

Slide 100 text

|　© Leverages inc. 100 今のままでは、ストリームアラインドチームのためになっていないし、基盤システムグループのためにもならない。

Slide 101

Slide 101 text

|　© Leverages inc. 101 一度、基盤システムグループの責務を整理した方がいいんじゃないか

Slide 102

Slide 102 text

|　© Leverages inc. 102 そしてストリームアラインドチームに入って、直接チカラになった方がいいんじゃないか

Slide 103

Slide 103 text

|　© Leverages inc. 103 変えよう

Slide 104

Slide 104 text

|　© Leverages inc. 104 どうするか

Slide 105

Slide 105 text

Slide 106

Slide 106 text

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

Slide 107

Slide 107 text

|　© Leverages inc. 107 ● Aチーム：3名 ○ 担当システム：案件・通知・流入・社内アカウント ● Bチーム：2名 ○ 担当システム：人材 ● Cチーム：5名 ○ 担当システム：レバテックID As-Is：当時の編成今あるチーム・システムを再編成する業務ドメイン機能軸

Slide 108

Slide 108 text

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

Slide 109

Slide 109 text

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

Slide 110

Slide 110 text

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

Slide 111

Slide 111 text

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

Slide 112

Slide 112 text

|　© Leverages inc. 112 ● Aチーム：3名 ○ 担当システム：案件・流入 Aチーム解散、ストリームアラインド（ドメイン）チームへ今あるチーム・システムを再編成する案件ドメインチーム組閣：2名流入ドメインチーム組閣：1名 + 他チームから人員追加バイバイ

Slide 113

Slide 113 text

|　© Leverages inc. 113 ● Aチーム：3名 ○ 担当システム：案件・流入 ● Bチーム：2名 ○ 担当システム：人材・通知 ● Cチーム：5名 ○ 担当システム：レバテックID・社内アカウント残るはBチームとCチーム今あるチーム・システムを再編成する

Slide 114

Slide 114 text

Slide 115

Slide 115 text

Slide 116

Slide 116 text

Slide 117

Slide 117 text

Slide 118

Slide 118 text

Slide 119

Slide 119 text

|　© Leverages inc. 119 ● SREが追うのは信頼性 ● Platform Engineeringが追うのは開発生産性や開発者体験 DevOpsという思想は同じだが、責務は違う SREがPlatform Engineeringの責務を持つのってどうなの？

Slide 120

Slide 120 text

|　© Leverages inc. 120 ● SREが追うのは信頼性 ● Platform Engineeringが追うのは開発生産性や開発者体験 DevOpsという思想は同じだが、責務は違う SREがPlatform Engineeringの責務を持つのってどうなの？じゃあ組織も分けた方がいいじゃん

Slide 121

Slide 121 text

Slide 122

Slide 122 text

|　© Leverages inc. 122 ● チームには適切な人数の目安がある ○ 2ピザルール ■ チームの参加者は2枚の大きなピザで満たされるぐらいの大きさ ○ 故J.リチャード・ハックマン氏の研究 ■ プロジェクトチームの最適なメンバー数は4人から6人であり、10人以上のメンバーを持つべきではない ○ DXクライテリア TEAM-1-1 ■ システムを開発する１チームの構成人数は、3人以上10人以下か分けない方がいいこともあると思う理由① SREがPlatform Engineeringの責務を持つのってどうなの？参考 https://dxcriteria.cto-a.org/8a4cd78ec4c546b083f1be075da2106e

Slide 123

Slide 123 text

|　© Leverages inc. 123 ● チームには適切な人数の目安がある分けない方がいいこともあると思う理由① SREがPlatform Engineeringの責務を持つのってどうなの？概ね3人以上10人以下！人数が少なすぎてもよくない！

Slide 124

Slide 124 text

|　© Leverages inc. 124 ● プラットフォームチームやSRE（イネイブリングチーム）はストリームアラインドチームありきの存在分けない方がいいこともあると思う理由② SREがPlatform Engineeringの責務を持つのってどうなの？

Slide 125

Slide 125 text

|　© Leverages inc. 125 ● プラットフォームチームやSRE（イネイブリングチーム）はストリームアラインドチームありきの存在 ○ ストリームアラインドチームが必要十分な人数と能力を有している状態で、そこからストリームアラインドチームの負荷を下げたり複数チームにスケールしやすくするために初めてプラットフォームやSREが必要になる。分けない方がいいこともあると思う理由② SREがPlatform Engineeringの責務を持つのってどうなの？

Slide 126

Slide 126 text

|　© Leverages inc. 126 ● 現実は、組織よりも先に事業が大きくなって、チームが必要十分な人数と能力を満たさないまま、システムやチームが増えるプラットフォームチームやSRE（イネイブリングチーム）はストリームアラインドチームありきの存在の補足 SREがPlatform Engineeringの責務を持つのってどうなの？

Slide 127

Slide 127 text

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

Slide 128

Slide 128 text

|　© Leverages inc. 128 ● 現実は、組織よりも先に事業が大きくなって、チームが必要十分な人数と能力を満たさないまま、システムやチームが増える ● システムやチームが増えると... ○ 共通化してコストを下げたくなるので、基盤（プラットフォームチーム）が求められるようになる ○ 全てのチームに人を増やして能力を満たすことが難しくなる（長期的な取り組みになる）ので、別のアプローチとして教育（イネイブリングチーム）が求められるようになるプラットフォームチームやSRE（イネイブリングチーム）はストリームアラインドチームありきの存在の補足 SREがPlatform Engineeringの責務を持つのってどうなの？

Slide 129

Slide 129 text

|　© Leverages inc. 129 Q. SREがPlatform Engineeringの責務を持つのってどうなの？組織の状態によっては持っても良いと思う。 A. ストリームアラインドチームが必要十分な人数と能力を満たしていない状態でプラットフォームチームとSREを分けて構成するほど人数をかけなくて良いのではないか？と考える ※レバテックでは今後、SREチームでPlatform Engineeringをやっていく

Slide 130

Slide 130 text

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

Slide 131

Slide 131 text

|　© Leverages inc. 131 ● Aチーム：3名 ○ 担当システム：案件・流入 ● Bチーム：2名 ○ 担当システム：人材・通知 ● Cチーム：5名 ○ 担当システム：レバテックID・社内アカウント Cチームはそのまま？今あるチーム・システムを再編成する検討中

Slide 132

Slide 132 text

Slide 133

Slide 133 text

Slide 134

Slide 134 text

Slide 135

Slide 135 text

|　© Leverages inc. 135 長年蓄積された技術的負債や組織課題に苦しんでいるチームがいるなら、その課題を優先的に解決した方が良さそう始める前に向き合うべき課題を見極めよういつPlatform Engineeringを始めるべきか？

Slide 136

Slide 136 text

|　© Leverages inc. 136 長年蓄積された技術的負債や組織課題に苦しんでいるチームがいるなら、その課題を優先的に解決した方が良さそう Platform Engineeringはエンジニアだけで完結することが多い分、手を出しやすいのが罠になることも始める前に向き合うべき課題を見極めよういつPlatform Engineeringを始めるべきか？

Slide 137

Slide 137 text

|　© Leverages inc. 137 長年蓄積された技術的負債や組織課題に苦しんでいるチームがいるなら、その課題を優先的に解決した方が良さそう Platform Engineeringはエンジニアだけで完結することが多い分、手を出しやすいのが罠になることも大切なのは、ストリームアラインドチームが事業に貢献できているか、できていないとしたら、阻害要因はなにかを考えること始める前に向き合うべき課題を見極めよういつPlatform Engineeringを始めるべきか？

Slide 138

Slide 138 text

Slide 139

Slide 139 text

|　© Leverages inc. 139 始めるべきかの優先度は会社が取り組んでいる事業内容にも依るのではないか ● プロダクトが事業の中心なら、優先度が高くなる ○ 開発生産性が上がることでリリースサイクルが速くなり事業価値を生みやすくなる事業内容も考慮するいつPlatform Engineeringを始めるべきか？

Slide 140

Slide 140 text

|　© Leverages inc. 140 始めるべきかの優先度は会社が取り組んでいる事業内容にも依るのではないか ● プロダクトが事業の中心なら、優先度が高くなる ○ 開発生産性が上がることでリリースサイクルが速くなり事業価値を生みやすくなる ● 人が事業の中心なら、優先度が低くなる ○ その人達の生産性・体験を上げる方が事業価値に繋がりやすい ■ 今のレバテックはこっち事業内容も考慮するいつPlatform Engineeringを始めるべきか？

Slide 141

Slide 141 text

Slide 142

Slide 142 text

Slide 143

Slide 143 text

Slide 144

Slide 144 text

|　© Leverages inc. 144 ● ストリームアラインドチームは今、どんな課題を抱えていますか？ ● その課題は、Platform Engineeringによって解決できますか？ ● その課題を解決すると、事業や会社にどんな影響を与えられそうですか？ ● Platform Engineering専門のチームが必要ですか？SREに含めたり、チームを組閣せずともできることがありませんか？示唆を得られるかもしれない4つの問いいつPlatform Engineeringを始めるべきか？

Slide 145

Slide 145 text

|　© Leverages inc. 145 Platform Engineeringを始めるのは、今じゃなくてもいいかもしれない。現場をよく観察・分析して、本当に必要だと思った時、 Platform Engineeringを始めよう伝えたいこと再掲

Slide 146

Slide 146 text

Slide 147

Slide 147 text

📣この後ちょっとだけ宣伝があります！

Slide 148

Slide 148 text

Slide 149

Slide 149 text

|　© 2024 Levtech Co., Ltd. 149 こんなこと話しましょう！ ● PlatformEngineeringやってるけどうまくいかない ● PE組織のマネジメントが難しい ● PEこれからやり始めようと思うけどどうしよう ● レバテックのPE、こうやればええんちゃう？　　　　　　　　　　　　　　　　　　　　　　　　　などオフラインの人はブースにて、オンラインの方はカジュアル面談お願いします！ 👈フォームはこちら https://hrmos.co/pages/leverages/jobs/A_c_00071