いつ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を始めるべきなのか？」という疑問に対して考察します。

Transcript

1. いつPlatform Engineeringを 始めるべきか？ 〜レバテックのケーススタディ〜
2. |　© 2024 Levtech Co., Ltd. 2 レバテック開発部 基盤システムグループリーダー 小堺 拓実 TAKUMI KOSAKAI #任天堂ゲーマー　#一児の父　#お酒飲めません　#初登壇　#写真はノラネコ
3. レバテックについて
4. |　© 2024 Levtech Co., Ltd. 4 VISIONとMISSION レバテックについて
5. |　© 2024 Levtech Co., Ltd. 5 事業ポートフォリオ レバテックについて エージェント プログラミング スクール コンテンツ メディア プラット フォーム ダイレクト リクルーティング ITエンジニア・クリエイターの フリーランス・転職・就職・教育の すべてを備える採用プラットフォーム エージェントを中心に、求人媒体、 プログラミング教育まで IT専門職のキャリアを厚くサポート。
6. |　© 2024 Levtech Co., Ltd. 6 プロダクト・サービス レバテックについて コンテンツメディア マイページ 採用管理ツール 案件/求人サイト スマホアプリ LP/サービスサイト
7. |　© 2024 Levtech Co., Ltd. 7 技術広報 レバテックについて カンファレンススポンサー や テックブログ に力を入れてます！ 　もフォローしてね！ etc.
8. 本題 いつPlatform Engineeringを始めるべきか？
9. |　© Leverages inc. 9 1. レバテックで起きたこと a. 基盤システムグループの 成り立ちとその課題 b. 課題から生まれる問いと 答え 2. いつPlatform Engineeringを始めるべき か 目次
10. |　© Leverages inc. 10 1. レバテックで起きたこと a. 基盤システムグループの 成り立ちとその課題 b. 課題から生まれる問いと 答え 2. いつPlatform Engineeringを始めるべき か 目次
11. |　© Leverages inc. 11 1. レバテックで起きたこと a. 基盤システムグループの 成り立ちとその課題 b. 課題から生まれる問いと 答え 2. いつPlatform Engineeringを始めるべき か 目次
12. |　© Leverages inc. 12 Platform Engineeringを始めるのは、 今じゃなくてもいいかもしれない。 現場をよく観察・分析して、本当に必要だと思った時、 Platform Engineeringを始めよう 伝えたいこと 本発表にて
13. |　© Leverages inc. 13 ある日、考え事をしていました。 導入 ※若干のフィクションを含みます 今後、基盤システムグループ をどうしていこうか。。
14. |　© Leverages inc. 14 すると、どこかから声が・・ 導入 ※若干のフィクションを含みます 基盤グループは やることありません。 暇です。 基盤システムグループ
15. |　© Leverages inc. 15 すると、どこかから声が・・ 導入 ※若干のフィクションを含みます 基盤グループは 楽そうでいいなあ・・ ストリームアラインドチーム 基盤グループは やることありません。 暇です。 基盤システムグループ
16. |　© Leverages inc. 16 ええ！？
17. |　© Leverages inc. 17 そんな馬鹿な・・ やることはいくらでもあるはず・・
18. |　© Leverages inc. 18 とりあえず話を聞いてみよう
19. |　© Leverages inc. 19 基盤グループメンバーに聞くと 導入 ※若干のフィクションを含みます 確かにやることはありますけど、 依存ライブラリのメンテナンスとか、 システム利用者の要望に応えるばっかり で目標がありません。
20. |　© Leverages inc. 20 ストリームアラインドチームに聞くと 導入 ※若干のフィクションを含みます 僕たちは日々の運用や問い合わせ対応で 一杯一杯です。 それに、技術的負債をたくさん抱えた レガシーシステムを開発するのは 開発者体験が悪いです。
21. |　© Leverages inc. 21 どうしてこうなった？
22. |　© Leverages inc. 22 発言について考える 回想 プラットフォームチーム 確かにやることはありますけど、 依存ライブラリのメンテナンスとか、 システム利用者の要望に応えるばっかり で目標がありません。
23. |　© Leverages inc. 23 Q. プラットフォームチームは目標がない？
24. |　© Leverages inc. 24 A. 当然ある
25. |　© Leverages inc. 25 プラットフォームエンジニアリングの目標は 開発者の認知負荷を下げ（開発者体験を上げ） 安全に素早くリリースできるようにすること 当然ある あるよ 基盤グループは違うの？
26. |　© Leverages inc. 26 Platform Engineeringを掲げて始まった組織ではなかった あるよ じゃあ、基盤グループの 目標ってなんだったの？ 基盤システムグループは プラットフォームエンジニアリングが 注目を浴びるもっと前からあった
27. |　© Leverages inc. 27 レバテックの 基盤システムグループはなぜ作られたのか
28. |　© Leverages inc. 28 発端 2020年のこと 事業成長のためにあんな機能 もこんな機能も欲しい！ エンジニア 事業 時間かかっちゃいますねえ
29. |　© Leverages inc. 29 弊害 2020年のこと じゃあスプレッドシートで 頑張るわ！ エンジニア 事業 いつの間にか知らない運 用がたくさんある・・
30. |　© Leverages inc. 30 業務とシステム間で乖離が発生しやすい状態に。 弊害 2020年のこと
31. |　© Leverages inc. 31 基盤システムグループ（プラットフォームチーム）発足 2020年のこと 今後のシステムの 土台を作ろう！ 理想的なシステム開発を 目指そう！
32. |　© Leverages inc. 32 近頃のPlatform Engineeringと全然違う Platform as a Productは？セルフサービスは？
33. |　© Leverages inc. 33 「共通基盤」を超えよ！ 今、Platform Engineeringに取り組むべき理由より
34. |　© Leverages inc. 34 基盤システムグループは事業の中心になるレガシーな基幹システムを マイクロサービスに分割して統治することを目論みました。 そして同時に、システムでよく使われる機能を 共通基盤として提供しようとしました。 最初に手を出したのが、マイクロサービス 基盤システムグループの軌跡 レガシーシステムという名のケーキを分割する図
35. |　© Leverages inc. 35 • 案件マイクロサービス • 人材マイクロサービス • 流入情報連携マイクロサービス • 通知マイクロサービス • レバテックID（認証・認可マイクロサービス） • 社内アカウントマイクロサービス • 社内共通ライブラリ 結果、いくつかのマイクロサービスが誕生 基盤システムグループの軌跡 これ プラットフォームか？ うんうん、 それもまた プラットフォーム だね
36. |　© Leverages inc. 36 • 案件マイクロサービス • 人材マイクロサービス • 流入情報連携マイクロサービス • 通知マイクロサービス • レバテックID（認証・認可マイクロサービス） • 社内アカウントマイクロサービス • 社内共通ライブラリ 特性の違うマイクロサービス 基盤システムグループの軌跡 業務ドメイン 機能軸 共通機能の提供 基幹システムの分割
37. |　© Leverages inc. 37 • 案件マイクロサービス • 人材マイクロサービス • 流入情報連携マイクロサービス 特性の違うマイクロサービス 基盤システムグループの軌跡 業務ドメイン 基幹システムの分割
38. |　© Leverages inc. 38 • 案件マイクロサービス • 人材マイクロサービス • 流入情報連携マイクロサービス • 通知マイクロサービス • レバテックID（認証・認可マイクロサービス） • 社内アカウントマイクロサービス • 社内共通ライブラリ 特性の違うマイクロサービス 基盤システムグループの軌跡 業務ドメイン 機能軸 共通機能の提供 基幹システムの分割
39. |　© Leverages inc. 39 • 案件マイクロサービス • 人材マイクロサービス • 流入情報連携マイクロサービス 特性の違うマイクロサービス 基盤システムグループの軌跡 業務ドメイン プラットフォームチームが 業務ドメインを扱うの？ 業務ドメインはストリーム アラインドチームの領域 じゃないの？
40. |　© Leverages inc. 40 • 案件マイクロサービス • 人材マイクロサービス • 流入情報連携マイクロサービス プラットフォームチームが業務ドメインを持つとどうなるか 基盤システムグループの軌跡 業務ドメイン プラットフォームチームが 業務ドメインを扱うの？ 業務ドメインはストリーム アラインドチームの領域 じゃないの？
41. |　© Leverages inc. 41 「案件」という概念は、企業が「案件」を出して募集し フリーランスが「案件」に応募する。というもの 案件マイクロサービス プラットフォームチームが業務ドメイン扱うのってどうなの 案件 募集 応募
42. |　© Leverages inc. 42 そのため、toBシステムもtoCシステムも 営業支援システムでも「案件」は 共通リソース（マスターデータ）として使用される 案件マイクロサービス プラットフォームチームが業務ドメイン扱うのってどうなの 案件 募集 応募
43. |　© Leverages inc. 43 案件マイクロサービス プラットフォームチームが業務ドメイン扱うのってどうなの 案件 募集 応募 そのため、toBシステムもtoCシステムも 営業支援システムでも「案件」は 共通リソース（マスターデータ）として使用される
44. |　© Leverages inc. 44 主な機能 • CRUD機能 • 単一取得 • 検索機能 案件マイクロサービス プラットフォームチームが業務ドメイン扱うのってどうなの 案件MS 営業支援 オウンド サイト toC toB データ連携 Readだけ
45. |　© Leverages inc. 45 案件は業務ドメインだけどいろんな コンテキストで使うデータだから プラットフォームとして提供しよう！
46. |　© Leverages inc. 46 結果どうだったか
47. |　© Leverages inc. 47 チームが受け身でしか動けなくなってしまった プラットフォームチームが業務ドメイン扱うのってどうなの リモート可否情報も返 すようにして！ 検索ロジック 変えられない？ 企業の情報も欲し いんだけど・・
48. |　© Leverages inc. 48 「マスタデータのこの情報が欲しい」 「マスタデータの検索ロジックを変えたい」 こういった要望は そのマスターデータを利用する側からしか生まれない どうして受け身になってしまうのか プラットフォームチームが業務ドメイン扱うのってどうなの
49. |　© Leverages inc. 49 “リソースの各項目の必要性はリソース自体に内在するわ けではなく、個々の業務のニーズから決まってくるからで す。以前、筆者が経験したプロジェクトでは、業務領域別 のチーム以外に「マスター管理チーム」があって、マス ター（リソース）の設計を担当していました。そのメン バーが、マスターに何を保持するべきかに関して、いつも 困惑していたことをよく記憶しています。今から振り返れ ば、仕切りに無理があったというべきでしょう。” データが流れる向きと要求の向きは逆方向になる プラットフォームチームが業務ドメイン扱うのってどうなの 第9章　マスターの共有──エンティティとロール方式より https://direct.gihyo.jp/view/item/000000003290
50. |　© Leverages inc. 50 こういった状況が、目標を持つことができない 一因になっていた 目標がない
51. |　© Leverages inc. 51 Q. プラットフォームチームは目標がない？ 改め
52. |　© Leverages inc. 52 Q. 基盤システムグループは目標がない？
53. |　© Leverages inc. 53 A. 基盤システムグループの成り立ちは近年の Platform Engineeringとは別文脈であり、 様々な要素を持つシステムを抱えてしまったこ とから、目標があやふやになった 主な原因は2つ • 基幹システムの分割と共通機能の提供という2軸 • 分割により生まれたシステム運用の受け身体制
54. |　© Leverages inc. 54 なるほど。。 この状況を変えるには体制も含めて 見直す必要がありそうだ。
55. |　© Leverages inc. 55 一旦、理解が深まったところで もう一つの発言について考えみよう
56. |　© Leverages inc. 56 基盤グループは 楽そうでいいなあ・・ ストリームアラインドチーム
57. |　© Leverages inc. 57 Q.プラットフォームエンジニアリングは 「楽」なのか？
58. |　© Leverages inc. 58 楽そうな要素を考えてみる
59. |　© Leverages inc. 59 市場からのプレッシャーに差がある プラットフォームエンジニアリングは楽なのか？ ストリームアラインド プラットフォーム いつできるの？ リリース日は？ 間に合うの？ 急いで！ ストリームアラ インドのみん な、待っててく れよ〜〜 ※常にこうはならない
60. |　© Leverages inc. 60 顧客との距離に差がある プラットフォームエンジニアリングは楽なのか？ ストリームアラインド プラットフォーム それエンジニア あるあるだわ〜 ※常にこうはならない 話がピンとこな い。。
61. |　© Leverages inc. 61 • 市場からのプレッシャーに晒されづらい • 顧客が開発者なので距離が近い さらにレバテックでは • 問い合わせが少ない • 技術的負債が少ない といった要素もあった 心の平穏を保ちやすい プラットフォームエンジニアリングは楽なのか？ 心理的に楽かも
62. |　© Leverages inc. 62 一方、世間的にはプラットフォームチームが 「なんでも屋」になりがちで大変だとか レバテックでは SREや情シスもいるので、何でもかんでも プラットフォームチームにはならなかった あくまで一例に過ぎない プラットフォームエンジニアリングは楽なのか？ Platform Team と 社内政治 〜 出でよ、 Platform Champion 〜 https://speakerdeck.com/kenojiri/pla tform-team-and-internal-politics-plat form-engineering-meetup-number-2
63. |　© Leverages inc. 63 Q. プラットフォームエンジニアリングは 「楽」なのか？
64. |　© Leverages inc. 64 A. 環境に依る
65. |　© Leverages inc. 65 A. 環境に依る レバテックにおけるプラットフォームチームは 心理的に楽だったかもしれません
66. |　© Leverages inc. 66 A. 環境に依る レバテックにおけるプラットフォームチームは 心理的に楽だったかもしれません ※もちろんお仕事している以上、様々な課題や悩み がありましたよ！相対的に楽という意味
67. |　© Leverages inc. 67 なるほど。でも、それだけで 「楽そう」なんて言われるかな？
68. |　© Leverages inc. 68 プラットフォームエンジニアリングが ストリームアラインドチームのために なっていれば言われないんじゃないの
69. |　© Leverages inc. 69 言われたことを思い出す 回想 ストリームアラインドチーム 僕たちは日々の運用や問い合わせ対応で 一杯一杯です。 それに、技術的負債をたくさん抱えた レガシーシステムを開発するのは 開発者体験が悪いです。
70. |　© Leverages inc. 70 言われたことを思い出す 回想 ストリームアラインドチーム 僕たちは日々の運用や問い合わせ対応で 一杯一杯です。 それに、技術的負債をたくさん抱えた レガシーシステムを開発するのは 開発者体験が悪いです。
71. |　© Leverages inc. 71 Q. プラットフォームエンジニアリングは運用や 問い合わせで大変なチームに貢献できるのか？
72. |　© Leverages inc. 72 Webシステムの運用とは プラットフォームエンジニアリングは運用や問い合わせで大変なチームに貢献できるのか？ • サーバーの設定・監視 • アプリケーションのデプロイ・監視・定期アップデート • データベースのチューニング・監視 • セキュリティ（アカウント発行・アクセス権限設定・脆弱性スキャン） • ネットワークの監視・DNS設定 • 監査対応 • 障害対応 他にも色々
73. |　© Leverages inc. 73 対して、プラットフォームエンジニアリングができること • Infrastructure as Code化 • コンテナオーケストレーション • CI/CDパイプライン整備 • 共通ログ基盤 • トイルの自動化 など 他にもありそう プラットフォームエンジニアリングは運用や問い合わせで大変なチームに貢献できるのか？
74. |　© Leverages inc. 74 問い合わせに対しては何かできる？ • ポータルサイト提供 • AIチャットボット プラットフォームエンジニアリングは運用や問い合わせで大変なチームに貢献できるのか？
75. |　© Leverages inc. 75 Q. プラットフォームエンジニアリングは運用や 問い合わせで大変なチームに貢献できるのか？
76. |　© Leverages inc. 76 A. 貢献できそう！
77. |　© Leverages inc. 77 なんですが
78. |　© Leverages inc. 78 基盤システムグループは 近頃のPlatform Engineeringと全然違う Platform as a Productは？セルフサービスは？ ※再掲
79. |　© Leverages inc. 79 だからといって今のシステム・組織のまま 方針だけ変えるのも難しい状況 「運用を楽にする」はスコープになかった 基盤システムグループは違った
80. |　© Leverages inc. 80 本来ストリームアラインドチームの 運用に貢献できるけど、うちは できていないことがわかったぞ
81. |　© Leverages inc. 81 あとは、なんて言われてたっけ？
82. |　© Leverages inc. 82 言われたことを思い出す 回想 ストリームアラインドチーム 僕たちは日々の運用や問い合わせ対応で 一杯一杯です。 それに、技術的負債をたくさん抱えた レガシーシステムを開発するのは 開発者体験が悪いです。
83. |　© Leverages inc. 83 Q. プラットフォームエンジニアリングは技術的 負債を抱えたレガシーシステムを運用するチー ムに貢献できるのか？
84. |　© Leverages inc. 84 もう少し具体化 「複雑で変更容易性の低いレガシーシステム」 技術的負債を抱えたレガシーシステムとは？ プラットフォームエンジニアリングは技術的負債を抱えたレガシーシステムを運用するチームに貢献できるのか？
85. |　© Leverages inc. 85 • 本質的な複雑さ • 偶有的な複雑さ • 規模による複雑さ 「複雑」とは？ プラットフォームエンジニアリングは技術的負債を抱えたレガシーシステムを運用するチームに貢献できるのか？
86. |　© Leverages inc. 86 • 本質的な複雑さ ◦ 対象とするドメイン知識の複雑さ 「複雑」とは？ プラットフォームエンジニアリングは技術的負債を抱えたレガシーシステムを運用するチームに貢献できるのか？
87. |　© Leverages inc. 87 • 偶有的な複雑さ ◦ 技術的要因による複雑さ ◦ 仕様（業務）とコードの乖離 「複雑」とは？ プラットフォームエンジニアリングは技術的負債を抱えたレガシーシステムを運用するチームに貢献できるのか？
88. |　© Leverages inc. 88 • 規模による複雑さ ◦ 対象とするドメインの広さ、連携するシステムの数など 「複雑」とは？ プラットフォームエンジニアリングは技術的負債を抱えたレガシーシステムを運用するチームに貢献できるのか？
89. |　© Leverages inc. 89 • 本質的な複雑さ ◦ 対象とするドメイン知識の複雑さ • 偶有的な複雑さ ◦ 技術的要因による複雑さ ◦ 仕様（業務）とコードの乖離 • 規模による複雑さ ◦ 対象とするドメインの広さ、連携するシステムの数など 「複雑」とは？ 余談： これらの複雑さを起因としたレガシーシステムに対するアプローチを システム思考した記事を書きました https://zenn.dev/levtech/articles/fb8b8974a3b633 プラットフォームエンジニアリングは技術的負債を抱えたレガシーシステムを運用するチームに貢献できるのか？
90. |　© Leverages inc. 90 • 本質的な複雑さ ◦ 対象とするドメイン知識の複雑さ 対して、プラットフォームエンジニアリングが出来ること ドメイン知識の 複雑さは取り除けない プラットフォームエンジニアリングは技術的負債を抱えたレガシーシステムを運用するチームに貢献できるのか？
91. |　© Leverages inc. 91 • 偶有的な複雑さ ◦ 技術的要因による複雑さ ◦ 仕様（業務）とコードの乖離 対して、プラットフォームエンジニアリングが出来ること 技術的要因による 複雑さは減らせるかも 仕様とコードの乖離は 無くせない プラットフォームエンジニアリングは技術的負債を抱えたレガシーシステムを運用するチームに貢献できるのか？
92. |　© Leverages inc. 92 • 規模による複雑さ ◦ 対象とするドメインの広さ、連携するシステムの数など 対して、プラットフォームエンジニアリングが出来ること ドメイン分割は プラットフォームの 関心事じゃあない プラットフォームエンジニアリングは技術的負債を抱えたレガシーシステムを運用するチームに貢献できるのか？
93. |　© Leverages inc. 93 Q. プラットフォームエンジニアリングは技術的 負債を抱えたレガシーシステムを運用するチー ムに貢献できるのか？
94. |　© Leverages inc. 94 A. 貢献できる事はあるが、 複雑さはほとんど減らせない
95. |　© Leverages inc. 95 うーむ、どうやら彼らのようなチーム を助けるにはもっと適したアプローチ がありそうだ・・
96. |　© Leverages inc. 96 • Q. 基盤システムグループは目標がない？ ここまでの問いと答え まとめ
97. |　© Leverages inc. 97 • Q. 基盤システムグループは目標がない？ ここまでの問いと答え まとめ 基盤システムグループの成り立ちは近年のPlatform Engineeringとは 別文脈。「基幹システムの分割」と「共通機能の提供」という2軸、そ して分割により生まれたシステム運用の受け身体制から目標があやふや になった。
98. |　© Leverages inc. 98 • Q. プラットフォームエンジニアリングは楽なのか？ • Q. プラットフォームエンジニアリングは運用や問い合わせで大変な チームに貢献できるのか？ • Q. プラットフォームエンジニアリングは技術的負債を抱えたレガ シーシステムを運用するチームに貢献できるのか？ ここまでの問いと答え まとめ
99. |　© Leverages inc. 99 • Q. プラットフォームエンジニアリングは楽なのか？ • Q. プラットフォームエンジニアリングは運用や問い合わせで大変なチーム に貢献できるのか？ • Q. プラットフォームエンジニアリングは技術的負債をたくさん抱えたシス テムを運用するチームに貢献できるのか？ ここまでの問いと答え まとめ 楽かどうかは環境に依る。 一般的にはシステム運用に貢献できるが、レバテックの基盤グループは 貢献できていなかった。 技術的負債と呼ばれる「複雑さ」に対しては本質的なアプローチになら ない。
100. |　© Leverages inc. 100 今のままでは、 ストリームアラインドチームのためになっていないし、 基盤システムグループのためにもならない。
101. |　© Leverages inc. 101 一度、基盤システムグループの責務を 整理した方がいいんじゃないか
102. |　© Leverages inc. 102 そしてストリームアラインドチームに入って、 直接チカラになった方がいいんじゃないか
103. |　© Leverages inc. 103 変えよう
104. |　© Leverages inc. 104 どうするか
105. |　© Leverages inc. 105 今あるチーム・システムを 再編成する
106. |　© Leverages inc. 106 • Aチーム：3名 ◦ 担当システム：案件・通知・流入・社内アカウント • Bチーム：2名 ◦ 担当システム：人材 • Cチーム：5名 ◦ 担当システム：レバテックID As-Is：当時の編成 今あるチーム・システムを再編成する
107. |　© Leverages inc. 107 • Aチーム：3名 ◦ 担当システム：案件・通知・流入・社内アカウント • Bチーム：2名 ◦ 担当システム：人材 • Cチーム：5名 ◦ 担当システム：レバテックID As-Is：当時の編成 今あるチーム・システムを再編成する 業務ドメイン 機能軸
108. |　© Leverages inc. 108 • Aチーム：3名 ◦ 担当システム：案件・流入 • Bチーム：2名 ◦ 担当システム：人材・通知 • Cチーム：5名 ◦ 担当システム：レバテックID・社内アカウント まずは負荷分散と責務整理 今あるチーム・システムを再編成する ちょっと楽になった 業務ドメインだけになった 認証・認可に集中！
109. |　© Leverages inc. 109 • Aチーム：3名 ◦ 担当システム：案件・流入 • Bチーム：2名 ◦ 担当システム：人材・通知 • Cチーム：5名 ◦ 担当システム：レバテックID・社内アカウント まずは負荷分散と責務整理 今あるチーム・システムを再編成する ちょっと楽になった 業務ドメインだけになった 認証・認可に集中！
110. |　© Leverages inc. 110 • Aチーム：3名 ◦ 担当システム：案件・流入 • Bチーム：2名 ◦ 担当システム：人材・通知 • Cチーム：5名 ◦ 担当システム：レバテックID・社内アカウント まずは負荷分散と責務整理 今あるチーム・システムを再編成する ちょっと楽になった 業務ドメインだけになった 認証・認可に集中！
111. |　© Leverages inc. 111 • Aチーム：3名 ◦ 担当システム：案件・流入 • Bチーム：2名 ◦ 担当システム：人材・通知 • Cチーム：5名 ◦ 担当システム：レバテックID・社内アカウント まずは負荷分散と責務整理 今あるチーム・システムを再編成する ちょっと楽になった 業務ドメインだけになった 認証・認可に集中！
112. |　© Leverages inc. 112 • Aチーム：3名 ◦ 担当システム：案件・流入 Aチーム解散、ストリームアラインド（ドメイン）チームへ 今あるチーム・システムを再編成する 案件ドメインチーム組閣：2名 流入ドメインチーム組閣：1名 + 他チームから人員追加 バイバイ
113. |　© Leverages inc. 113 • Aチーム：3名 ◦ 担当システム：案件・流入 • Bチーム：2名 ◦ 担当システム：人材・通知 • Cチーム：5名 ◦ 担当システム：レバテックID・社内アカウント 残るはBチームとCチーム 今あるチーム・システムを再編成する
114. |　© Leverages inc. 114 • Bチーム：2名 ◦ 担当システム：人材・通知 Bチーム解散、それぞれの道へ 今あるチーム・システムを再編成する 人材は流入ドメインと合併 通知はSREチームへ移管 バイバイ
115. |　© Leverages inc. 115 • Bチーム：2名 ◦ 担当システム：人材・通知 Bチーム解散、それぞれの道へ 今あるチーム・システムを再編成する 人材は流入ドメインと合併 通知はSREチームへ移管 バイバイ
116. |　© Leverages inc. 116 SREがPlatform Engineeringの責務を 持つのってどうなの？
117. |　© Leverages inc. 117 class SRE Implements DevOps
118. |　© Leverages inc. 118 class PlatformEngineering Implements DevOps
119. |　© Leverages inc. 119 • SREが追うのは信頼性 • Platform Engineeringが追うのは開発生産性や開発者体験 DevOpsという思想は同じだが、責務は違う SREがPlatform Engineeringの責務を持つのってどうなの？
120. |　© Leverages inc. 120 • SREが追うのは信頼性 • Platform Engineeringが追うのは開発生産性や開発者体験 DevOpsという思想は同じだが、責務は違う SREがPlatform Engineeringの責務を持つのってどうなの？ じゃあ組織も分けた方が いいじゃん
121. |　© Leverages inc. 121 組織規模によっては、分けない方がいいこともあると思う 組織を分けるには人が必要 SREがPlatform Engineeringの責務を持つのってどうなの？
122. |　© Leverages inc. 122 • チームには適切な人数の目安がある ◦ 2ピザルール ▪ チームの参加者は2枚の大きなピザで満たされるぐらいの大き さ ◦ 故J.リチャード・ハックマン氏の研究 ▪ プロジェクトチームの最適なメンバー数は4人から6人であ り、10人以上のメンバーを持つべきではない ◦ DXクライテリア TEAM-1-1 ▪ システムを開発する１チームの構成人数は、3人以上10人以下 か 分けない方がいいこともあると思う理由① SREがPlatform Engineeringの責務を持つのってどうなの？ 参考 https://dxcriteria.cto-a.org/8a4cd78ec4c546b083f1be075da2106e
123. |　© Leverages inc. 123 • チームには適切な人数の目安がある 分けない方がいいこともあると思う理由① SREがPlatform Engineeringの責務を持つのってどうなの？ 概ね3人以上10人以下！ 人数が少なすぎてもよくない！
124. |　© Leverages inc. 124 • プラットフォームチームやSRE（イネイブリングチーム）は ストリームアラインドチームありきの存在 分けない方がいいこともあると思う理由② SREがPlatform Engineeringの責務を持つのってどうなの？
125. |　© Leverages inc. 125 • プラットフォームチームやSRE（イネイブリングチーム）は ストリームアラインドチームありきの存在 ◦ ストリームアラインドチームが必要十分な人数と能力を 有している状態で、そこからストリームアラインドチー ムの負荷を下げたり複数チームにスケールしやすくする ために初めてプラットフォームやSREが必要になる。 分けない方がいいこともあると思う理由② SREがPlatform Engineeringの責務を持つのってどうなの？
126. |　© Leverages inc. 126 • 現実は、組織よりも先に事業が大きくなって、チームが必要十分な 人数と能力を満たさないまま、システムやチームが増える プラットフォームチームやSRE（イネイブリングチーム）は ストリームアラインドチームありきの存在 の補足 SREがPlatform Engineeringの責務を持つのってどうなの？
127. |　© Leverages inc. 127 • 現実は、組織よりも先に事業が大きくなって、チームが必要十分な 人数と能力を満たさないまま、システムやチームが増える • システムやチームが増えると... ◦ 共通化してコストを下げたくなるので、基盤（プラットフォー ムチーム）が求められるようになる プラットフォームチームやSRE（イネイブリングチーム）は ストリームアラインドチームありきの存在 の補足 SREがPlatform Engineeringの責務を持つのってどうなの？
128. |　© Leverages inc. 128 • 現実は、組織よりも先に事業が大きくなって、チームが必要十分な 人数と能力を満たさないまま、システムやチームが増える • システムやチームが増えると... ◦ 共通化してコストを下げたくなるので、基盤（プラットフォー ムチーム）が求められるようになる ◦ 全てのチームに人を増やして能力を満たすことが難しくなる （長期的な取り組みになる）ので、別のアプローチとして教育 （イネイブリングチーム）が求められるようになる プラットフォームチームやSRE（イネイブリングチーム）は ストリームアラインドチームありきの存在 の補足 SREがPlatform Engineeringの責務を持つのってどうなの？
129. |　© Leverages inc. 129 Q. SREがPlatform Engineeringの責務を持つのって どうなの？ 組織の状態によっては持っても良いと思う。 A. ストリームアラインドチームが必要十分な人数と能力を満たしていない状態で プラットフォームチームとSREを分けて構成するほど人数をかけなくて良いのでは ないか？と考える ※レバテックでは今後、SREチームでPlatform Engineeringをやっていく
130. |　© Leverages inc. 130 • Aチーム：3名 ◦ 担当システム：案件・流入 • Bチーム：2名 ◦ 担当システム：人材・通知 • Cチーム：5名 ◦ 担当システム：レバテックID・社内アカウント To-Be：そしてCチームだけが残った 今あるチーム・システムを再編成する
131. |　© Leverages inc. 131 • Aチーム：3名 ◦ 担当システム：案件・流入 • Bチーム：2名 ◦ 担当システム：人材・通知 • Cチーム：5名 ◦ 担当システム：レバテックID・社内アカウント Cチームはそのまま？ 今あるチーム・システムを再編成する 検討中
132. |　© Leverages inc. 132 かくして、レバテックの 基盤システムグループは大幅に縮小しました。
133. |　© Leverages inc. 133 曖昧だったグループの責務を整理し、 今の組織に本当に必要なことを考え変化できた のは良かったと思っています。
134. |　© Leverages inc. 134 1. レバテックで起きたこと a. 基盤システムグループの 成り立ちとその課題 b. 課題から生まれる問いと 答え 2. いつPlatform Engineeringを始めるべき か 目次
135. |　© Leverages inc. 135 長年蓄積された技術的負債や組織課題に苦しんでいるチー ムがいるなら、その課題を優先的に解決した方が良さそう 始める前に向き合うべき課題を見極めよう いつPlatform Engineeringを始めるべきか？
136. |　© Leverages inc. 136 長年蓄積された技術的負債や組織課題に苦しんでいるチー ムがいるなら、その課題を優先的に解決した方が良さそう Platform Engineeringはエンジニアだけで完結することが 多い分、手を出しやすいのが罠になることも 始める前に向き合うべき課題を見極めよう いつPlatform Engineeringを始めるべきか？
137. |　© Leverages inc. 137 長年蓄積された技術的負債や組織課題に苦しんでいるチー ムがいるなら、その課題を優先的に解決した方が良さそう Platform Engineeringはエンジニアだけで完結することが 多い分、手を出しやすいのが罠になることも 大切なのは、ストリームアラインドチームが事業に貢献で きているか、できていないとしたら、阻害要因はなにかを 考えること 始める前に向き合うべき課題を見極めよう いつPlatform Engineeringを始めるべきか？
138. |　© Leverages inc. 138 始めるべきかの優先度は会社が取り組んでいる事業内容 にも依るのではないか 事業内容も考慮する いつPlatform Engineeringを始めるべきか？
139. |　© Leverages inc. 139 始めるべきかの優先度は会社が取り組んでいる事業内容 にも依るのではないか • プロダクトが事業の中心なら、優先度が高くなる ◦ 開発生産性が上がることでリリースサイクルが 速くなり事業価値を生みやすくなる 事業内容も考慮する いつPlatform Engineeringを始めるべきか？
140. |　© Leverages inc. 140 始めるべきかの優先度は会社が取り組んでいる事業内容 にも依るのではないか • プロダクトが事業の中心なら、優先度が高くなる ◦ 開発生産性が上がることでリリースサイクルが 速くなり事業価値を生みやすくなる • 人が事業の中心なら、優先度が低くなる ◦ その人達の生産性・体験を上げる方が事業価値 に繋がりやすい ▪ 今のレバテックはこっち 事業内容も考慮する いつPlatform Engineeringを始めるべきか？
141. |　© Leverages inc. 141 Q. いつPlatform Engineeringを 始めるべきか？ 事業の特性や組織の課題を見極め、 必要だと思った時に始めよう A.
142. |　© Leverages inc. 142 それがわかれば苦労しないよ・・
143. |　© Leverages inc. 143 このままではあんまりなので、示唆が得られる かもしれない問いを用意してみました
144. |　© Leverages inc. 144 • ストリームアラインドチームは今、どんな課題を抱えていますか？ • その課題は、Platform Engineeringによって解決できますか？ • その課題を解決すると、事業や会社にどんな影響を与えられそうで すか？ • Platform Engineering専門のチームが必要ですか？SREに含めた り、チームを組閣せずともできることがありませんか？ 示唆を得られるかもしれない4つの問い いつPlatform Engineeringを始めるべきか？
145. |　© Leverages inc. 145 Platform Engineeringを始めるのは、 今じゃなくてもいいかもしれない。 現場をよく観察・分析して、本当に必要だと思った時、 Platform Engineeringを始めよう 伝えたいこと 再掲
146. |　© Leverages inc. 146 それが出来たとき Platform Engineeringは組織の力になるはず
147. 📣この後ちょっとだけ宣伝があります！
148. |　© 2024 Levtech Co., Ltd. 148 本セッションに関する アンケートにご協力お願いします！ 回答完了1分程度
149. |　© 2024 Levtech Co., Ltd. 149 こんなこと話しましょう！ • PlatformEngineeringやってるけどうまくいかない • PE組織のマネジメントが難しい • PEこれからやり始めようと思うけどどうしよう • レバテックのPE、こうやればええんちゃう？ 　　　　　　　　　　　　　　　　　　　　　　　　　など オフラインの人はブースにて、 オンラインの方はカジュアル面談お願いします！ 👈フォームはこちら https://hrmos.co/pages/leverages/jobs/A_c_00071