$30 off During Our Annual Pro Sale. View Details »

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

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

GREE Tech Conference 2022で発表された資料です。
https://techcon.gree.jp/2022/session/TrackA-6

gree_tech
PRO

October 25, 2022
Tweet

More Decks by gree_tech

Other Decks in Technology

Transcript

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

    View Slide

  2. 2

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

    View Slide

  3. 3

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

    View Slide

  4. 4

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

    View Slide

  5. 5

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

    View Slide

  6. 6

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

    View Slide

  7. 7

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

    View Slide

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

    View Slide

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

    GPF時代

    View Slide



  10. GPF時代 ~この頃の組織~







    インフラストラクチャ統括部







    |

















    |











    |タ





















    View Slide

  11. GPF時代 ~この頃の組織~
    インフラストラクチャ統括部
    データセンタ、サーバのコスト最適化
















    |

















    |











    |タ





















    View Slide

  12. GPF時代 ~この頃の組織~
    インフラストラクチャ統括部
    オンプレ環境の円滑な運用
    24/365で無停止で運用を継続する
















    |

















    |











    |タ





















    View Slide

  13. GPF時代 ~この頃の組織~
    インフラストラクチャ統括部
    セキュリティを含めた管理/監視
    大量のユーザ行動のビッグデータによる解析
















    |

















    |











    |タ





















    View Slide

  14. GPF時代 ~この頃の組織~
    インフラストラクチャ統括部
    内製MW / VMの運用保守
    自社独自のモニタリングシステムの構築
















    |

















    |











    |タ





















    View Slide

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

    View Slide

  16. 16

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

    View Slide

  17. 17

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

    View Slide

  18. 18

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

    View Slide

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

    View Slide

  20. さらなる課題

    View Slide

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

    View Slide

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

    View Slide

  23. 23

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

    View Slide

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

    View Slide

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

    View Slide

  26. 26

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  35. 部門戦略
    企画
    35

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

    View Slide

  36. 36

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

    View Slide

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


    View Slide

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


    View Slide

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

    View Slide

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

    View Slide

  41. 組織の変化に対応する
    41


    View Slide

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

    View Slide

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


    View Slide

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

    View Slide

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

    View Slide

  46. • 関係性を作る
    組織の変化に対応する
    46

    初対面から始まるプロジェクトの難しさ

    View Slide

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

    初対面から始まるプロジェクトの難しさ

    View Slide

  48. 組織の変化に対応する
    48

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

    View Slide

  49. • 意思決定のフレームワークを活用する:
    OODAループ
    組織の変化に対応する
    49

    初対面から始まるプロジェクトの難しさ

    View Slide

  50. 組織の変化に対応する
    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の
    状況観察

    View Slide

  51. 組織の変化に対応する
    51

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

    View Slide

  52. 組織の変化に対応する
    52

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

    View Slide

  53. ○○○○○を活用して関係性を作る
    組織の変化に対応する
    53

    • 観察とアクション、それに対するフィードバック
    • このサイクルが○○○○○で強化できる

    View Slide

  54. 定例MTGを活用して関係性を作る
    組織の変化に対応する
    54

    定例MTG
    もしかするとあんまり好きではない方もいらっしゃるかもしれませんが、使い方次第で。

    View Slide

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

    もちろん、常に定例をやっていればいいというわけではなく。 OODAループが回り、関係性が出来てきたら頻度を調節するというのも必要

    View Slide

  56. 定例MTGを活用して関係性を作る
    組織の変化に対応する
    56

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

    View Slide

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


    View Slide

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


    View Slide

  59. • 課題:技術の変化はスピードが早く、新技術への対応難易度が高

    • サーバはオンプレ+AWS+GCPになり、SaaSの利用も増
    加、インフラのカバー範囲はさらに広がった
    • 各プロダクトごとに検証や導入試験をやっていると効率が悪

    • 新しいものが次々と出てくる
    • 新しいものを取り入れるにもコストがかかる
    テクノロジーの変化に対応する
    59


    View Slide

  60. 部門戦略
    企画
    60

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

    View Slide

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


    View Slide

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

    テクノロジーの変化に対応する、技術Unitのしくみ

    View Slide

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

    テクノロジーの変化に対応する、技術Unitのしくみ

    View Slide

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

    テクノロジーの変化に対応する、技術Unitのしくみ

    View Slide

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


    View Slide

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

    テクノロジーの変化に対応する、チームでの取り組み

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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


    View Slide

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


    View Slide

  73. 73


    View Slide