GREE Tech Conference 2022で発表された資料です。 https://techcon.gree.jp/2022/session/TrackA-6
グリー株式会社 シニアマネージャー 舟橋 弘兼事業環境の変化に対応するインフラ組織 その取り組みと現状グリー株式会社 マネージャー 黒木 誠士
View Slide
2 自己紹介舟橋 弘兼（ふなはし ひろかず）2012年 入社2017年 インフラ部マネージャ2019年 インフラ部シニアマネージャ所属開発本部 インフラ部サービスインストレーショングループ
3 自己紹介(黒木)黒木 誠士（くろき まさし）2020年 入社2021年 インフラ部マネージャ所属開発本部 インフラ部サービスインストレーショングループ
4 はじめにグリー株式会社は「インターネットを通じて、世界をより良くする。」というミッションを掲げ2004年に創業しました。今もミッションは変わらずにいますが、時代の変化に伴い事業の変化や拡大を続けてきました。前半は、その変化の中でも変わらずに存続し続けてきたインフラ部の変遷を、事業の変化と合わせてご説明していきます。後半は、現在のインフラ部のエンジニアマネージャーの業務や取り組みについてご紹介いたします。
5 アジェンダ• 組織変遷• グリープラットフォーム(GPF)を中心とした組織• AWS移行による組織• 現在の組織• 事業環境の変化にインフラ組織がどう対応しているか• 組織の変化に対応する• テクノロジーの変化に対応する
6 グリーは2004年に設立されてからこれまでの間、グリーがなければできなかった、この世に起こらなかったことを実現してきましたそしてこれからも、自ら新しい歴史を刻んでいきますグリーの歩み2022年2020年2018年2016年2014年2012年2010年2008年2006年2004年「GREE」誕生モバイルSNS提供開始モバイルSNS本格導入世界初モバイルソーシャルゲーム公開GREEプラットフォーム提供開始GREEプラットフォームをグローバルで提供開始ネイティブシフト初タイトルリリース新規事業サービスリリースVRゲームリリースREALITYリリースメタバース事業マンガ事業Web3事業
7 グリーは2004年に設立されてからこれまでの間、グリーがなければできなかった、この世に起こらなかったことを実現してきましたそしてこれからも、自ら新しい歴史を刻んでいきますグリーの歩み2022年2020年2018年2016年2014年2012年2010年2008年2006年2004年「GREE」誕生モバイルSNS提供開始モバイルSNS本格導入世界初モバイルソーシャルゲーム公開GREEプラットフォーム提供開始GREEプラットフォームをグローバルで提供開始ネイティブシフト初タイトルリリース新規事業サービスリリースVRゲームリリースREALITYリリースメタバース事業マンガ事業GREEプラットフォーム AWS移行 現在Web3事業
GPF時代グリー プラットフォームLWFデータセンターcascade yoyamagic MySQL memecachedmonitoringdebianflare
GPF事業を第一にインフラとしてコミットする組織• 技術要素• オンプレ中心• 内部での独自改修したOSSの利用• 内製ツールの開発(https://github.com/gree)• 事業要素• GPF事業が中心9 GPF時代
運用GPF時代 ~この頃の組織~デ｜タセンタ｜インフラストラクチャ統括部ネットワ｜クサ|ビスリライアビリティセキュリティサ|バマネジメントビッグデ|タモニタリング費用最適化ハ｜ドウェア事業推進
GPF時代 ~この頃の組織~インフラストラクチャ統括部データセンタ、サーバのコスト最適化運用デ｜タセンタ｜ネットワ｜クサ|ビスリライアビリティセキュリティサ|バマネジメントビッグデ|タモニタリング費用最適化ハ｜ドウェア事業推進
GPF時代 ~この頃の組織~インフラストラクチャ統括部オンプレ環境の円滑な運用24/365で無停止で運用を継続する運用デ｜タセンタ｜ネットワ｜クサ|ビスリライアビリティセキュリティサ|バマネジメントビッグデ|タモニタリング費用最適化ハ｜ドウェア事業推進
GPF時代 ~この頃の組織~インフラストラクチャ統括部セキュリティを含めた管理/監視大量のユーザ行動のビッグデータによる解析運用デ｜タセンタ｜ネットワ｜クサ|ビスリライアビリティセキュリティサ|バマネジメントビッグデ|タモニタリング費用最適化ハ｜ドウェア事業推進
GPF時代 ~この頃の組織~インフラストラクチャ統括部内製MW / VMの運用保守自社独自のモニタリングシステムの構築運用デ｜タセンタ｜ネットワ｜クサ|ビスリライアビリティセキュリティサ|バマネジメントビッグデ|タモニタリング費用最適化ハ｜ドウェア事業推進
AWS移行時代グリープラットフォームデータセンターubuntumonitoring※ イメージ図ManagedService新規事業ネイティブシフトLWF cascadeyoyamagicMySQLmemecachedflare apache
16 • 技術要素• オンプレ中心からオンプレクラウドのハイブリッド運用• 内部独自運用を極力減らしたOSSの利用• インフラ部が独立した組織として組成• 事業要素• ネイティブゲームの新規事業の立ち上がりAWS移行時代• 内製ツールの管理維持• ハイブリッドクラウド環境の継続的な費用最適化
17 AWS移行時代 ~この頃の組織~開発本部インフラサービス部インフラサービス グループインフラ導入チームデータセンタチームツール開発チーム費用最適化チーム運用チームエンジニアリングチーム開発運用 グループ情シス部 セキュリティ部 デザイン部 管理部GPF部
18 AWS移行時代 ~この頃の組織~開発本部インフラサービス部インフラサービス グループ 開発運用 グループ情シス部 セキュリティ部 デザイン部 管理部GPF部内製ツールの開発と、開発資産の運用保守インフラ導入チームデータセンタチーム費用最適化チーム運用チームエンジニアリングチームツール開発チーム
AWS移行時代 ~この頃の組織~開発本部インフラサービス部インフラサービス グループ 開発運用 グループ情シス部 セキュリティ部 デザイン部 管理部GPF部オンプレとクラウドのハイブリッド環境の継続的な費用最適化インフラ導入チームデータセンタチームツール開発チーム費用最適化チーム運用チームエンジニアリングチーム
さらなる課題
GPF以外の複数の事業を支えるための課題
事業部とのコミュニケーションコスト増
23 AWS移行時代 ~この頃の組織~開発本部インフラサービス部インフラサービス グループインフラ導入チームデータセンタチームツール開発チーム費用最適化チーム運用チームエンジニアリングチーム開発運用 グループ情シス部 セキュリティ部 デザイン部 管理部GPF部事業部のオーダをインフラ設計に落とし込み、解決策を検討して実行までもっていく
コミュニケーションコストの削減事業部サービス導入チーム運用チームエンジニアリングチーム事業オーダープラン策定作業依頼可能な範囲は自チームで対応作業実施手順整備 技術課題解決案作成
現在グリープラットフォームデータセンターmonitoring※ イメージ図ManagedService
26 • 技術• オンプレ + AWS + GCPのハイブリッド/マルチクラウド• SaaS、マネージドサービスの利用拡大• 事業要素• 子会社化、新規事業の立ち上がり• 事業拡大による社内開発案件の拡大• 複雑化するハイブリッド/マルチクラウドの運用• 調達部門としての計数管理（SaaSの利用拡大）現在の組織
運用チーム開発グループ運用改善チームサービス開発チーム 企画チームDC/Networkチーム部門戦略グループ現在の組織開発本部インフラ部運用グループ サービス導入グループ業務改善チーム導入1チーム導入2チーム導入3チームPMチーム
運用チーム開発グループ運用改善チームサービス開発チーム 企画チームDC/Networkチーム部門戦略グループ現在の組織開発本部インフラ部運用グループ サービス導入グループ業務改善チーム導入1チーム導入2チーム導入3チームPMチーム事業拡大による社内開発案件の対応
運用チーム開発グループ運用改善チームサービス開発チーム 企画チームDC/Networkチーム部門戦略グループ現在の組織開発本部インフラ部運用グループ サービス導入グループ業務改善チーム導入1チーム導入2チーム導入3チームPMチーム 複雑化するクラウド環境の運用保守対応ハイブリッド、マルチクラウドによるネットワーク保守長期運営プロダクトの MW ver UP
運用チーム開発グループ運用改善チームサービス開発チーム 企画チームDC/Networkチーム部門戦略グループ現在の組織開発本部インフラ部運用グループ サービス導入グループ業務改善チーム導入1チーム導入2チーム導入3チームPMチーム 調達部門としてのインフラの計数管理SaaS利用など増加する外部との請求処理研修や学習機会の創出
事業のグループ会社化、新規事業立ち上がりによるさらなるコミュニケーションコスト増
運用チーム開発グループ改善チームサービス開発チーム 企画チームDC/Networkチーム部門戦略グループ現在の組織開発本部インフラ部運用グループ サービス導入グループ業務改善チーム導入1チーム導入2チーム導入3チームPMチーム より強固に事業部と連携したサービスのリリース支援
コミュニケーションコストの削減運用チーム ユニット制事業オーダープラン策定作業依頼可能な範囲は自チームで対応作業実施手順整備事業オーダー事業オーダー導入1チーム導入2チーム導入3チーム各子会社に特化したチームを組成技術課題解決案作成
コミュニケーションコストの削減運用チーム ユニット制事業オーダープラン策定作業依頼可能な範囲は自チームで対応作業実施手順整備事業オーダー事業オーダー導入1チーム導入2チーム導入3チーム技術課題解決案作成新制度
部門戦略企画35 ユニット体制とは業務改善サービス導入1サービス導入3運用改善PMRDBMSFrontend+ImageInfra PlatformCloudサービス導入2Datacenter/Networkサービス開発運用縦割り組織：チーム横串組織技術ユニットサービス導入 運用 開発InfrastructureKVSMonitoringDev Environmentエンジニアは各チームに所属しつつ、自分の得意分野となるユニットに所属 (1つ以上)し、得意分野の深度を増し、技術で事業に貢献する構成
36 • 費用の集約• 全社のインフラ関連の調達をすることでコスト最適化• 技術の集約• インフラ業務を集約することで、全社のインフラ環境を一定のレベル以上担保する• グループ会社間でのインフラに関するナレッジの共有• ユニット制による広く、深い技術スタックの醸成• 技術をベースとした事業への貢献大きなインフラ組織のメリットコミュニケーションコスト増などはあるものの
事業環境の変化に対応する取り組み後半37
前半では組織としての対応をお伝えしました。後半は複雑化するコミュニケーションと変化の激しいテクノロジーに対する現在の取り組みについてお話ししますはじめに後半でお伝えすること38
いろいろと書いてはいますが、実際の現場でできていること・できていないことは個別にあると思います社内の方は暖かく見守っていただけると幸いですはじめに後半でお伝えすること
1. 組織の変化により発生する課題• 「初対面から始まるプロジェクトの難しさ」• 組織の変化によるコミュニケーションコストが課題となっている• 意外な「○○○○○」が実は役に立つことも• インフラに限らずプロジェクトの円滑化に活用できる2. テクノロジーの変化により発生する課題• 「技術の変化はスピードが早く、新技術への対応難易度が高い」• サーバはオンプレ+AWS+GCPになり、SaaSの利用も増加、インフラのカバー範囲はさらに広がった環境の変化による課題にどう対応しているか後半でお伝えすること
組織の変化に対応する41
おさらい運用チーム ユニット制事業オーダープラン策定作業依頼可能な範囲は自チームで対応作業実施手順整備事業オーダー事業オーダー導入1チーム導入2チーム導入3チーム各子会社に特化したチームを組成技術課題解決案作成
•課題：初対面から始まるプロジェクトの難しさ• 組織や事業体の変化に応じて、初対面のメンバーでプロジェクトを進めることがよくある• 組織や事業体の変化に応じて、コミュニケーションコストが増大している初対面から始まるプロジェクトの難しさ組織の変化に対応する43
コミュニケーションコストについて• 一般的には事業とインフラは一体化していることも多いが、前半の通り現在のグリーはインフラが事業から独立している• チームや組織が分離しているとコミュニケーションコストは上がる初対面から始まるプロジェクトの難しさ組織の変化に対応する
初対面から始まるプロジェクトの難しさどのようにプロジェクトが始まるか• それなりに長い期間を共に走ることになるプロダクトとインフラが初対面のところからプロジェクトが始まる• 慣れたメンバー同士だと人となりがわかっている・お互いのできることの期待値がある程度共有できているが、それがない →何が必要か組織の変化に対応するキックオフ 設計 構築 負荷試験 リリース 運用
• 関係性を作る組織の変化に対応する46 初対面から始まるプロジェクトの難しさ
• 関係性を作る• 期待値の共有• お互いどんな事ができるかある程度把握できている• 何を求めているかある程度把握できている• コミュニケーションのとり方で迷わない• タスクをどのように管理しているか• お互いの担当領域はどこまでかなんだかんだ人間、知らない人と仕事をするよりは知ってる人と仕事をしたほうがやりやすい組織の変化に対応する47 初対面から始まるプロジェクトの難しさ
組織の変化に対応する48 • 初対面・基本ゼロベースで始まるプロジェクト• 関係性がない• 関係性を作って円滑にプロジェクトを進める• 関係性を作るためにはどうすればよいか• なにかしらの貢献をして、成果を出す→継続的な貢献のためにどうすればよいか？初対面から始まるプロジェクトの難しさ
• 意思決定のフレームワークを活用する：OODAループ組織の変化に対応する49 初対面から始まるプロジェクトの難しさ
組織の変化に対応する50 継続的な貢献のためにOODAループを回す参考：変化の激しいWebの世界でコンスタントに局面局面で勝つ方法論「OODAループ」https://speakerdeck.com/netmarkjp/bian-hua-falseji-siiwebfalseshi-jie-dekonsutantoniju-mian-ju-mian-desheng-tufang-fa-lun-oodarupuOODAループとはなにかObserve観察情報を取得しにいくOrient情勢判断情報を解釈するDecide意思決定行動を決定するAction行動行動する/実行するAfterの状況観察Beforeの状況観察
組織の変化に対応する51 なぜOODAなのか• プロジェクトによってやるべきことは様々• プロダクトからインフラへ何を求めているかが不確実• コストはどのくらいを期待しているか• 開発期間中に何を求めているか• 負荷試験はどう行うか• リリース直後はどのような体制で臨むか• プロダクト側も最初から全て見通せているわけではない• 不確実性に対応するためにOODAを活用初対面から始まるプロジェクトの難しさ
組織の変化に対応する52 OODAの対応例Observe観察情報を取得しにいくOrient情勢判断情報を解釈するDecide意思決定行動を決定するAction行動行動する/実行するAfterの状況観察Beforeの状況観察EKS クラスタのk8s のバージョンが古そうだな👀updateするための情報をお持ちでないかも🤔選択肢とメリット・デメリットをまとめて共有しよう🧐リリースタイミングで最適なverになるように、ロードマップを作成して提案した💡
○○○○○を活用して関係性を作る組織の変化に対応する53 • 観察とアクション、それに対するフィードバック• このサイクルが○○○○○で強化できる
定例MTGを活用して関係性を作る組織の変化に対応する54 定例MTGもしかするとあんまり好きではない方もいらっしゃるかもしれませんが、使い方次第で。
• OODAのサイクルが定例MTGで強化できる• 知らない人同士だとコミュニケーションに障壁が出来がち• 習慣があればコミュニケーションが取れる• 定期的に必ず会って話す場を設定することで、観察からActionまでの機会が増える→課題解決の機会が増える定例MTGを活用して関係性を作る組織の変化に対応する55 もちろん、常に定例をやっていればいいというわけではなく。 OODAループが回り、関係性が出来てきたら頻度を調節するというのも必要
定例MTGを活用して関係性を作る組織の変化に対応する56 • OODAのサイクルが定例MTGで強化できる• OODAの繰り返しにより、インフラへどのような支援を頼めるのか/インフラからどう支援すべきか という期待値のすり合わせができる→関係性が構築できる• 関係性ができるとプロジェクトの進行がスムーズになる• プロジェクトがスムーズに進行していると、技術的なチャレンジにも繋げやすくなる（後述）
• 組織変化への対応• 組織の変化に起因したコミュニケーションコストへの対応として関係性を作る必要がある• OODAループを活用して関係性を作る• 成果を積み重ねて関係性を作り、円滑にプロジェクトを進める組織の変化に対応する まとめ57
テクノロジーの変化に対応する58
• 課題：技術の変化はスピードが早く、新技術への対応難易度が高い• サーバはオンプレ+AWS+GCPになり、SaaSの利用も増加、インフラのカバー範囲はさらに広がった• 各プロダクトごとに検証や導入試験をやっていると効率が悪い• 新しいものが次々と出てくる• 新しいものを取り入れるにもコストがかかるテクノロジーの変化に対応する59
部門戦略企画60 業務改善サービス導入1サービス導入3運用改善PMRDBMSFrontend+ImageInfra PlatformCloudサービス導入2Datacenter/Networkサービス開発運用縦割り組織：チーム横串組織技術ユニットサービス導入 運用 開発InfrastructureKVSMonitoringDev Environmentエンジニアは各チームに所属しつつ、自分の得意分野となるユニットに所属 (1つ以上)し、得意分野の深度を増し、技術で事業に貢献する構成前提：ユニット体制
• 各技術Unitで知見を溜め、プロダクト支援に活かしている• オンプレからAWS、GCPと、インフラの基盤も変化を続けてきた中、マネージドサービスの活用など、利用する技術も変化してきた→いくつか事例をご紹介しますテクノロジーの変化に対応する、技術Unitのしくみテクノロジーの変化に対応する61
データベース分野の支援：RDBMS Unit• DBの運用支援ツール開発• MySQLの運用ツール• Spannerのオートスケール・ウォームアップツール• MySQL 8.0 バージョンアップ支援• クエリチューニング、パフォーマンスチューニングテクノロジーの変化に対応する62 テクノロジーの変化に対応する、技術Unitのしくみ
モニタリング分野の支援：Monitoring Unit• インフラの変化に合わせOSS/内製ツールを組み合わせ多様なプロダクト環境にObservability基盤を提供• 既存ツールに不足があればカスタマイズ/内製ツール提供• Spannerを新しく導入した際には必要なツール作成• Spanner内部で集計しているstatisticsをCloud Monitoringに記録テクノロジーの変化に対応する63 テクノロジーの変化に対応する、技術Unitのしくみ
• Unitが先行して新しいサービスの技術を取り込み、プロダクトで使いやすいように展開するテクノロジーの変化に対応する64 テクノロジーの変化に対応する、技術Unitのしくみ
• インフラチームでも新しい技術を取り入れやすくするテクノロジーの変化に対応する、チームでの取り組みテクノロジーの変化に対応する65
• インフラチームでも新しい技術を取り入れやすくする• 目標設定の際に技術的なチャレンジを促進するようにしているテクノロジーの変化に対応する66 テクノロジーの変化に対応する、チームでの取り組み
• インフラチームでも新しい技術を取り入れやすくする• 目標設定の際に技術的なチャレンジを促進するようにしている• チャレンジにもコストがかかるテクノロジーの変化に対応するテクノロジーの変化に対応する、チームでの取り組み
• インフラチームでも新しい技術を取り入れやすくする• 目標設定の際に技術的なチャレンジを促進するようにしている• チャレンジにもコストがかかる• チャレンジにかかるコストは、コスト削減案を同時に盛り込むなど、ある程度マネージャーの調整で解決していく• OODAのループによる信頼の積み重ねにより、プロダクトとインフラで技術的なチャレンジを共有しやすい地盤を作る• 一定の導入コストをかけて新しい技術やサービスの導入で運用を楽にしておくと、次のチャレンジがしやすくなるといったループを回せるテクノロジーの変化に対応するテクノロジーの変化に対応する、チームでの取り組み
• プロダクトとインフラで技術的なチャレンジを繰り返し、より良いプロダクトを作れる地盤を固めていくテクノロジーの変化に対応するテクノロジーの変化に対応する、チームでの取り組みインフラ技術チャレンジプロダクト技術チャレンジインフラ技術チャレンジプロダクト技術チャレンジいちばん大事なのは、プロダクトのために何ができるかを真剣に考え続けること、そしてそれを実行することだと思っています。マネージャーレイヤとしては、メンバーへのこのマインドの伝達・共有が大事だなと考えています。（なかなかできていませんが）
• 組織変遷• グリープラットフォーム(GPF)を中心とした組織• オンプレ環境を内製で支える組織• AWS移行による組織• 新規事業とクラウド活用の開始• 現在の組織• 事業の多角化、マルチクラウド環境• 事業環境の変化にインフラ組織がどう対応しているか• 組織の変化に対応する• OODAループと定例MTGを活用して関係性を作る• テクノロジーの変化に対応する• 技術Unitでの知見の蓄積• インフラチーム内での目標設定＋信頼関係全体のまとめ
採用強化中です！！一緒にインフラの課題解決にぶつかっていきたい方、ぜひご応募下さい！！• インフラエンジニア• https://hrmos.co/pages/gree/jobs/00030561• インフラテクニカルPM• https://hrmos.co/pages/gree/jobs/00030562We are hiring!!71
• アンケートへのご協力をいただけますと幸いです！ご清聴ありがとうございました！72
73
gree_tech
rilmayer
yutoy
you
sat
s2terminal
yuya4
lmi
oracle4engineer
coconala_engineer
akkie76
line_developers_tw
yoshiitaka
erikaheidi
searls
schacon
rmw
ammeep
swwweet
michaelherold
nonsquared
bluesmoon
pedronauck
rasmusluckow
panda_program