事業環境の変化に対応するインフラ組織　その取り組みと現状

by gree_tech

Slide 1

Slide 1 text

グリー株式会社　シニアマネージャー　舟橋弘兼事業環境の変化に対応するインフラ組織その取り組みと現状グリー株式会社　マネージャー　黒木誠士

Slide 2

Slide 2 text

2  自己紹介舟橋弘兼（ふなはしひろかず） 2012年入社 2017年インフラ部マネージャ 2019年インフラ部シニアマネージャ所属開発本部インフラ部サービスインストレーショングループ

Slide 3

Slide 3 text

3  自己紹介(黒木) 黒木誠士（くろきまさし） 2020年入社 2021年インフラ部マネージャ所属開発本部インフラ部サービスインストレーショングループ

Slide 4

Slide 4 text

4  はじめにグリー株式会社は「インターネットを通じて、世界をより良くする。」というミッションを掲げ2004年に創業しました。今もミッションは変わらずにいますが、時代の変化に伴い事業の変化や拡大を続けてきました。前半は、その変化の中でも変わらずに存続し続けてきたインフラ部の変遷を、事業の変化と合わせてご説明していきます。後半は、現在のインフラ部のエンジニアマネージャーの業務や取り組みについてご紹介いたします。

Slide 5

Slide 5 text

5  アジェンダ • 組織変遷 • グリープラットフォーム(GPF)を中心とした組織 • AWS移行による組織 • 現在の組織 • 事業環境の変化にインフラ組織がどう対応しているか • 組織の変化に対応する • テクノロジーの変化に対応する

Slide 6

Slide 6 text

6  グリーは2004年に設立されてからこれまでの間、グリーがなければできなかった、この世に起こらなかったことを実現してきましたそしてこれからも、自ら新しい歴史を刻んでいきますグリーの歩み 2022年 2020年 2018年 2016年 2014年 2012年 2010年 2008年 2006年 2004年「GREE」誕生モバイルSNS提供開始モバイルSNS本格導入世界初モバイルソーシャルゲーム公開 GREEプラットフォーム提供開始 GREEプラットフォームをグローバルで提供開始ネイティブシフト初タイトルリリース新規事業サービスリリース VRゲームリリース REALITYリリースメタバース事業マンガ事業 Web3事業

Slide 7

Slide 7 text

7  グリーは2004年に設立されてからこれまでの間、グリーがなければできなかった、この世に起こらなかったことを実現してきましたそしてこれからも、自ら新しい歴史を刻んでいきますグリーの歩み 2022年 2020年 2018年 2016年 2014年 2012年 2010年 2008年 2006年 2004年「GREE」誕生モバイルSNS提供開始モバイルSNS本格導入世界初モバイルソーシャルゲーム公開 GREEプラットフォーム提供開始 GREEプラットフォームをグローバルで提供開始ネイティブシフト初タイトルリリース新規事業サービスリリース VRゲームリリース REALITYリリースメタバース事業マンガ事業 GREEプラットフォーム AWS移行現在 Web3事業

Slide 8

Slide 8 text

GPF時代グリープラットフォーム LWF データセンター cascade yoyamagic MySQL memecached monitoring debian flare

Slide 9

Slide 9 text

GPF事業を第一にインフラとしてコミットする組織 • 技術要素 • オンプレ中心 • 内部での独自改修したOSSの利用 • 内製ツールの開発(https://github.com/gree) • 事業要素 • GPF事業が中心 9  GPF時代

Slide 10

Slide 10 text

運用 GPF時代 ~この頃の組織~ デ｜タセンタ｜インフラストラクチャ統括部ネットワ｜クサ | ビスリライアビリティセキュリティサ | バマネジメントビッグデ |タモニタリング費用最適化ハ｜ドウェア事業推進

Slide 11

Slide 11 text

GPF時代 ~この頃の組織~ インフラストラクチャ統括部データセンタ、サーバのコスト最適化運用デ｜タセンタ｜ネットワ｜クサ | ビスリライアビリティセキュリティサ | バマネジメントビッグデ |タモニタリング費用最適化ハ｜ドウェア事業推進

Slide 12

Slide 12 text

GPF時代 ~この頃の組織~ インフラストラクチャ統括部オンプレ環境の円滑な運用 24/365で無停止で運用を継続する運用デ｜タセンタ｜ネットワ｜クサ | ビスリライアビリティセキュリティサ | バマネジメントビッグデ |タモニタリング費用最適化ハ｜ドウェア事業推進

Slide 13

Slide 13 text

GPF時代 ~この頃の組織~ インフラストラクチャ統括部セキュリティを含めた管理/監視大量のユーザ行動のビッグデータによる解析運用デ｜タセンタ｜ネットワ｜クサ | ビスリライアビリティセキュリティサ | バマネジメントビッグデ |タモニタリング費用最適化ハ｜ドウェア事業推進

Slide 14

Slide 14 text

GPF時代 ~この頃の組織~ インフラストラクチャ統括部内製MW / VMの運用保守自社独自のモニタリングシステムの構築運用デ｜タセンタ｜ネットワ｜クサ | ビスリライアビリティセキュリティサ | バマネジメントビッグデ |タモニタリング費用最適化ハ｜ドウェア事業推進

Slide 15

Slide 15 text

AWS移行時代グリープラットフォームデータセンター ubuntu monitoring ※ イメージ図 Managed Service 新規事業ネイティブシフト LWF cascade yoyamagi c MySQL memecach ed flare apache

Slide 16

Slide 16 text

16  • 技術要素 • オンプレ中心からオンプレクラウドのハイブリッド運用 • 内部独自運用を極力減らしたOSSの利用 • インフラ部が独立した組織として組成 • 事業要素 • ネイティブゲームの新規事業の立ち上がり AWS移行時代 • 内製ツールの管理維持 • ハイブリッドクラウド環境の継続的な費用最適化

Slide 17

Slide 17 text

17  AWS移行時代 ~この頃の組織~ 開発本部インフラサービス部インフラサービスグループインフラ導入チームデータセンタチームツール開発チーム費用最適化チーム運用チームエンジニアリングチーム開発運用グループ情シス部セキュリティ部デザイン部管理部 GPF部

Slide 18

Slide 18 text

18  AWS移行時代 ~この頃の組織~ 開発本部インフラサービス部インフラサービスグループ開発運用グループ情シス部セキュリティ部デザイン部管理部 GPF部内製ツールの開発と、開発資産の運用保守インフラ導入チームデータセンタチーム費用最適化チーム運用チームエンジニアリングチームツール開発チーム

Slide 19

Slide 19 text

AWS移行時代 ~この頃の組織~ 開発本部インフラサービス部インフラサービスグループ開発運用グループ情シス部セキュリティ部デザイン部管理部 GPF部オンプレとクラウドのハイブリッド環境の継続的な費用最適化インフラ導入チームデータセンタチームツール開発チーム費用最適化チーム運用チームエンジニアリングチーム

Slide 20

Slide 20 text

さらなる課題

Slide 21

Slide 21 text

GPF以外の複数の事業を支えるための課題

Slide 22

Slide 22 text

事業部とのコミュニケーションコスト増

Slide 23

Slide 23 text

23  AWS移行時代 ~この頃の組織~ 開発本部インフラサービス部インフラサービスグループインフラ導入チームデータセンタチームツール開発チーム費用最適化チーム運用チームエンジニアリングチーム開発運用グループ情シス部セキュリティ部デザイン部管理部 GPF部事業部のオーダをインフラ設計に落とし込み、解決策を検討して実行までもっていく

Slide 24

Slide 24 text

コミュニケーションコストの削減事業部サービス導入チーム運用チームエンジニアリングチーム事業オーダープラン策定作業依頼可能な範囲は自チームで対応作業実施手順整備技術課題解決案作成

Slide 25

Slide 25 text

現在グリープラットフォームデータセンター monitoring ※ イメージ図 ManagedService

Slide 26

Slide 26 text

26  • 技術 • オンプレ + AWS + GCPのハイブリッド/マルチクラウド • SaaS、マネージドサービスの利用拡大 • 事業要素 • 子会社化、新規事業の立ち上がり • 事業拡大による社内開発案件の拡大 • 複雑化するハイブリッド/マルチクラウドの運用 • 調達部門としての計数管理（SaaSの利用拡大）現在の組織

Slide 27

Slide 27 text

運用チーム開発グループ運用改善チームサービス開発チーム企画チーム DC/Network チーム部門戦略グループ現在の組織開発本部インフラ部運用グループサービス導入グループ業務改善チーム導入1チーム導入2チーム導入3チーム PMチーム

Slide 28

Slide 28 text

運用チーム開発グループ運用改善チームサービス開発チーム企画チーム DC/Network チーム部門戦略グループ現在の組織開発本部インフラ部運用グループサービス導入グループ業務改善チーム導入1チーム導入2チーム導入3チーム PMチーム事業拡大による社内開発案件の対応

Slide 29

Slide 29 text

運用チーム開発グループ運用改善チームサービス開発チーム企画チーム DC/Network チーム部門戦略グループ現在の組織開発本部インフラ部運用グループサービス導入グループ業務改善チーム導入1チーム導入2チーム導入3チーム PMチーム複雑化するクラウド環境の運用保守対応ハイブリッド、マルチクラウドによるネットワーク保守長期運営プロダクトの MW ver UP

Slide 30

Slide 30 text

運用チーム開発グループ運用改善チームサービス開発チーム企画チーム DC/Network チーム部門戦略グループ現在の組織開発本部インフラ部運用グループサービス導入グループ業務改善チーム導入1チーム導入2チーム導入3チーム PMチーム調達部門としてのインフラの計数管理 SaaS利用など増加する外部との請求処理研修や学習機会の創出

Slide 31

Slide 31 text

事業のグループ会社化、新規事業立ち上がりによるさらなるコミュニケーションコスト増

Slide 32

Slide 32 text

運用チーム開発グループ改善チームサービス開発チーム企画チーム DC/Network チーム部門戦略グループ現在の組織開発本部インフラ部運用グループサービス導入グループ業務改善チーム導入1チーム導入2チーム導入3チーム PMチームより強固に事業部と連携したサービスのリリース支援

Slide 33

Slide 33 text

コミュニケーションコストの削減運用チームユニット制事業オーダープラン策定作業依頼可能な範囲は自チームで対応作業実施手順整備事業オーダー事業オーダー導入1チーム導入2チーム導入3チーム各子会社に特化したチームを組成技術課題解決案作成

Slide 34

Slide 34 text

コミュニケーションコストの削減運用チームユニット制事業オーダープラン策定作業依頼可能な範囲は自チームで対応作業実施手順整備事業オーダー事業オーダー導入1チーム導入2チーム導入3チーム技術課題解決案作成新制度

Slide 35

Slide 35 text

部門戦略企画 35  ユニット体制とは業務改善サービス導入1 サービス導入3 運用改善 PM RDBMS Frontend+Image Infra Platform Cloud サービス導入2 Datacenter/ Network サービス開発運用縦割り組織：チーム横串組織技術ユニットサービス導入運用開発 Infrastructure KVS Monitoring Dev Environment エンジニアは各チームに所属しつつ、自分の得意分野となるユニットに所属 (1つ以上)し、得意分野の深度を増し、技術で事業に貢献する構成

Slide 36

Slide 36 text

36  • 費用の集約 • 全社のインフラ関連の調達をすることでコスト最適化 • 技術の集約 • インフラ業務を集約することで、全社のインフラ環境を一定のレベル以上担保する • グループ会社間でのインフラに関するナレッジの共有 • ユニット制による広く、深い技術スタックの醸成 • 技術をベースとした事業への貢献大きなインフラ組織のメリットコミュニケーションコスト増などはあるものの

Slide 37

Slide 37 text

事業環境の変化に対応する取り組み後半 37 

Slide 38

Slide 38 text

前半では組織としての対応をお伝えしました。後半は複雑化するコミュニケーションと変化の激しいテクノロジーに対する現在の取り組みについてお話ししますはじめに後半でお伝えすること 38 

Slide 39

Slide 39 text

いろいろと書いてはいますが、実際の現場でできていること・できていないことは個別にあると思います社内の方は暖かく見守っていただけると幸いです󰢙 はじめに後半でお伝えすること

Slide 40

Slide 40 text

1. 組織の変化により発生する課題 • 「初対面から始まるプロジェクトの難しさ」 • 組織の変化によるコミュニケーションコストが課題となっている • 意外な「○○○○○」が実は役に立つことも • インフラに限らずプロジェクトの円滑化に活用できる 2. テクノロジーの変化により発生する課題 • 「技術の変化はスピードが早く、新技術への対応難易度が高い」 • サーバはオンプレ+AWS+GCPになり、SaaSの利用も増加、インフラのカバー範囲はさらに広がった環境の変化による課題にどう対応しているか後半でお伝えすること

Slide 41

Slide 41 text

組織の変化に対応する 41 

Slide 42

Slide 42 text

おさらい運用チームユニット制事業オーダープラン策定作業依頼可能な範囲は自チームで対応作業実施手順整備事業オーダー事業オーダー導入1チーム導入2チーム導入3チーム各子会社に特化したチームを組成技術課題解決案作成

Slide 43

Slide 43 text

•課題：初対面から始まるプロジェクトの難しさ • 組織や事業体の変化に応じて、初対面のメンバーでプロジェクトを進めることがよくある • 組織や事業体の変化に応じて、コミュニケーションコストが増大している初対面から始まるプロジェクトの難しさ組織の変化に対応する 43 

Slide 44

Slide 44 text

コミュニケーションコストについて • 一般的には事業とインフラは一体化していることも多いが、前半の通り現在のグリーはインフラが事業から独立している • チームや組織が分離しているとコミュニケーションコストは上がる初対面から始まるプロジェクトの難しさ組織の変化に対応する

Slide 45

Slide 45 text

初対面から始まるプロジェクトの難しさどのようにプロジェクトが始まるか • それなりに長い期間を共に走ることになるプロダクトとインフラが初対面のところからプロジェクトが始まる • 慣れたメンバー同士だと人となりがわかっている・お互いのできることの期待値がある程度共有できているが、それがない　→何が必要か組織の変化に対応するキックオフ設計構築負荷試験リリース運用

Slide 46

Slide 46 text

• 関係性を作る組織の変化に対応する 46  初対面から始まるプロジェクトの難しさ

Slide 47

Slide 47 text

• 関係性を作る • 期待値の共有 • お互いどんな事ができるかある程度把握できている • 何を求めているかある程度把握できている • コミュニケーションのとり方で迷わない • タスクをどのように管理しているか • お互いの担当領域はどこまでかなんだかんだ人間、知らない人と仕事をするよりは知ってる人と仕事をしたほうがやりやすい組織の変化に対応する 47  初対面から始まるプロジェクトの難しさ

Slide 48

Slide 48 text

組織の変化に対応する 48  • 初対面・基本ゼロベースで始まるプロジェクト • 関係性がない • 関係性を作って円滑にプロジェクトを進める • 関係性を作るためにはどうすればよいか • なにかしらの貢献をして、成果を出す →継続的な貢献のためにどうすればよいか？初対面から始まるプロジェクトの難しさ

Slide 49

Slide 49 text

• 意思決定のフレームワークを活用する： OODAループ組織の変化に対応する 49  初対面から始まるプロジェクトの難しさ

Slide 50

Slide 50 text

組織の変化に対応する 50  継続的な貢献のためにOODAループを回す参考：変化の激しいWebの世界でコンスタントに局面局面で勝つ方法論「OODAループ」 https://speakerdeck.com/netmarkjp/bian-hua-falseji-siiwebfalseshi-jie-dekonsutantoniju-mian -ju-mian-desheng-tufang-fa-lun-oodarupu OODAループとはなにか Observe 観察情報を取得しにいく Orient 情勢判断情報を解釈する Decide 意思決定行動を決定する Action 行動行動する/ 実行する Afterの状況観察 Beforeの状況観察

Slide 51

Slide 51 text

組織の変化に対応する 51  なぜOODAなのか • プロジェクトによってやるべきことは様々 • プロダクトからインフラへ何を求めているかが不確実 • コストはどのくらいを期待しているか • 開発期間中に何を求めているか • 負荷試験はどう行うか • リリース直後はどのような体制で臨むか • プロダクト側も最初から全て見通せているわけではない • 不確実性に対応するためにOODAを活用初対面から始まるプロジェクトの難しさ

Slide 52

Slide 52 text

組織の変化に対応する 52  OODAの対応例 Observe 観察情報を取得しにいく Orient 情勢判断情報を解釈する Decide 意思決定行動を決定する Action 行動行動する/ 実行する Afterの状況観察 Beforeの状況観察 EKS クラスタの k8s のバージョンが古そうだな 👀 updateするための情報をお持ちでないかも🤔 選択肢とメリット・デメリットをまとめて共有しよう 🧐 リリースタイミングで最適なverになるように、ロードマップを作成して提案した 💡

Slide 53

Slide 53 text

○○○○○を活用して関係性を作る組織の変化に対応する 53  • 観察とアクション、それに対するフィードバック • このサイクルが○○○○○で強化できる

Slide 54

Slide 54 text

定例MTGを活用して関係性を作る組織の変化に対応する 54  定例MTG もしかするとあんまり好きではない方もいらっしゃるかもしれませんが、使い方次第で。

Slide 55

Slide 55 text

• OODAのサイクルが定例MTGで強化できる • 知らない人同士だとコミュニケーションに障壁が出来がち • 習慣があればコミュニケーションが取れる • 定期的に必ず会って話す場を設定することで、観察からActionまでの機会が増える→課題解決の機会が増える定例MTGを活用して関係性を作る組織の変化に対応する 55  もちろん、常に定例をやっていればいいというわけではなく。 OODAループが回り、関係性が出来てきたら頻度を調節するというのも必要

Slide 56

Slide 56 text

定例MTGを活用して関係性を作る組織の変化に対応する 56  • OODAのサイクルが定例MTGで強化できる • OODAの繰り返しにより、インフラへどのような支援を頼めるのか/インフラからどう支援すべきか　という期待値のすり合わせができる →関係性が構築できる • 関係性ができるとプロジェクトの進行がスムーズになる • プロジェクトがスムーズに進行していると、技術的なチャレンジにも繋げやすくなる（後述）

Slide 57

Slide 57 text

• 組織変化への対応 • 組織の変化に起因したコミュニケーションコストへの対応として関係性を作る必要がある • OODAループを活用して関係性を作る • 成果を積み重ねて関係性を作り、円滑にプロジェクトを進める組織の変化に対応する　まとめ 57 

Slide 58

Slide 58 text

テクノロジーの変化に対応する 58 

Slide 59

Slide 59 text

• 課題：技術の変化はスピードが早く、新技術への対応難易度が高い • サーバはオンプレ+AWS+GCPになり、SaaSの利用も増加、インフラのカバー範囲はさらに広がった • 各プロダクトごとに検証や導入試験をやっていると効率が悪い • 新しいものが次々と出てくる • 新しいものを取り入れるにもコストがかかるテクノロジーの変化に対応する 59 

Slide 60

Slide 60 text

部門戦略企画 60  業務改善サービス導入1 サービス導入3 運用改善 PM RDBMS Frontend+Image Infra Platform Cloud サービス導入2 Datacenter/ Network サービス開発運用縦割り組織：チーム横串組織技術ユニットサービス導入運用開発 Infrastructure KVS Monitoring Dev Environment エンジニアは各チームに所属しつつ、自分の得意分野となるユニットに所属 (1つ以上)し、得意分野の深度を増し、技術で事業に貢献する構成前提：ユニット体制

Slide 61

Slide 61 text

• 各技術Unitで知見を溜め、プロダクト支援に活かしている • オンプレからAWS、GCPと、インフラの基盤も変化を続けてきた中、マネージドサービスの活用など、利用する技術も変化してきた →いくつか事例をご紹介しますテクノロジーの変化に対応する、技術Unitのしくみテクノロジーの変化に対応する 61 

Slide 62

Slide 62 text

データベース分野の支援：RDBMS Unit • DBの運用支援ツール開発 • MySQLの運用ツール • Spannerのオートスケール・ウォームアップツール • MySQL 8.0 バージョンアップ支援 • クエリチューニング、パフォーマンスチューニングテクノロジーの変化に対応する 62  テクノロジーの変化に対応する、技術Unitのしくみ

Slide 63

Slide 63 text

モニタリング分野の支援：Monitoring Unit • インフラの変化に合わせOSS/内製ツールを組み合わせ多様なプロダクト環境にObservability基盤を提供 • 既存ツールに不足があればカスタマイズ/内製ツール提供 • Spannerを新しく導入した際には必要なツール作成 • Spanner内部で集計しているstatisticsを Cloud Monitoringに記録テクノロジーの変化に対応する 63  テクノロジーの変化に対応する、技術Unitのしくみ

Slide 64

Slide 64 text

• Unitが先行して新しいサービスの技術を取り込み、プロダクトで使いやすいように展開するテクノロジーの変化に対応する 64  テクノロジーの変化に対応する、技術Unitのしくみ

Slide 65

Slide 65 text

• インフラチームでも新しい技術を取り入れやすくするテクノロジーの変化に対応する、チームでの取り組みテクノロジーの変化に対応する 65 

Slide 66

Slide 66 text

• インフラチームでも新しい技術を取り入れやすくする • 目標設定の際に技術的なチャレンジを促進するようにしているテクノロジーの変化に対応する 66  テクノロジーの変化に対応する、チームでの取り組み

Slide 67

Slide 67 text

• インフラチームでも新しい技術を取り入れやすくする • 目標設定の際に技術的なチャレンジを促進するようにしている • チャレンジにもコストがかかるテクノロジーの変化に対応するテクノロジーの変化に対応する、チームでの取り組み

Slide 68

Slide 68 text

• インフラチームでも新しい技術を取り入れやすくする • 目標設定の際に技術的なチャレンジを促進するようにしている • チャレンジにもコストがかかる • チャレンジにかかるコストは、コスト削減案を同時に盛り込むなど、ある程度マネージャーの調整で解決していく • OODAのループによる信頼の積み重ねにより、プロダクトとインフラで技術的なチャレンジを共有しやすい地盤を作る • 一定の導入コストをかけて新しい技術やサービスの導入で運用を楽にしておくと、次のチャレンジがしやすくなるといったループを回せるテクノロジーの変化に対応するテクノロジーの変化に対応する、チームでの取り組み

Slide 69

Slide 69 text

• プロダクトとインフラで技術的なチャレンジを繰り返し、より良いプロダクトを作れる地盤を固めていくテクノロジーの変化に対応するテクノロジーの変化に対応する、チームでの取り組みインフラ技術チャレンジプロダクト技術チャレンジインフラ技術チャレンジプロダクト技術チャレンジいちばん大事なのは、プロダクトのために何ができるかを真剣に考え続けること、そしてそれを実行することだと思っています。マネージャーレイヤとしては、メンバーへのこのマインドの伝達・共有が大事だなと考えています。（なかなかできていませんが）

Slide 70

Slide 70 text

• 組織変遷 • グリープラットフォーム(GPF)を中心とした組織 • オンプレ環境を内製で支える組織 • AWS移行による組織 • 新規事業とクラウド活用の開始 • 現在の組織 • 事業の多角化、マルチクラウド環境 • 事業環境の変化にインフラ組織がどう対応しているか • 組織の変化に対応する • OODAループと定例MTGを活用して関係性を作る • テクノロジーの変化に対応する • 技術Unitでの知見の蓄積 • インフラチーム内での目標設定＋信頼関係全体のまとめ

Slide 71

Slide 71 text

採用強化中です！！一緒にインフラの課題解決にぶつかっていきたい方、ぜひご応募下さい！！ • インフラエンジニア • https://hrmos.co/pages/gree/jobs/00030561 • インフラテクニカルPM • https://hrmos.co/pages/gree/jobs/00030562 We are hiring!! 71 

Slide 72

Slide 72 text

• アンケートへのご協力をいただけますと幸いです！ご清聴ありがとうございました！ 72 