サイバーエージェントにおけるインナーソーシングの取り組み

Slide 1

Slide 1 text

小塚健太 - Developer Productivity室室長前田拓 - ABEMA Live/CyberFight/FANBASE ARENA 技術責任者 (各兼務) InnerSourcing Gathering Tokyo 2024 サイバーエージェントにおけるインナーソーシングの取り組み

Slide 2

Slide 2 text

1.インナーソースの推進と Dグレード制度 2.PipeCDでのインナーソースとオープンソース 3.FanTech事業とPipeCD Terraform Provider開発 4.事業プロダクトでのインナーソース活動 5.今後のインナーソース推進に向けて

Slide 3

Slide 3 text

小塚健太 Developer Productivity室室長 Engineer at CyberAgent #PipeCD #Bucketeer ✈🎾🏃⛰ X: @kenta_kozuka GitHub: @kentakozuka

Slide 4

Slide 4 text

インナーソースの推進と Dグレード制度

Slide 5

Slide 5 text

CAの抱えていた課題元々グループ内では、社内共通基盤や個人による OSS活動も活発だったこともあり多くの技術資産が存在しかし、 1. 技術資産が十分に流動しておらず、全体での生産性向上に活かしきれていない 2. 車輪の再発明 3. 技術資産を支援していく枠組みが不十分だったため、継続性に乏しかった → 作りっぱなしで、利用者が増えず、ゆっくり廃れていく

Slide 6

Slide 6 text

Dグレード •グループ内の技術資産を中長期で支援し、開発生産性を高めるための制度 •D = Developer, DevTool •2021年に発案、制度化 •継続的に改善を重ね、現在は Ver.4 •個人・チームの申請制 2020年5月 GitHub Enterpriseへの契約一本化によって Internalリポジトリが利用可能になっていた

Slide 7

Slide 7 text

Dグレードの目的 ① 中長期での技術資産開発、 OSS育成 ② 全社レベルでの技術資産の流動と有効活用 ③ 情報共有促進・車輪の再発明の抑制 ④ 技術力を使った組織貢献の活性化技術資産をこれまで以上に流動・活性化させ、全社でのシナジー発揮を目指す

Slide 8

Slide 8 text

Dグレード対象となる技術資産 1. 事業プロダクトの開発や運用を効率化する技術資産である 2. CAグループ社員がオーナーである技術資産に限定 3. 社内に導入実績があること 4. 利用者向けドキュメントが整備されている

Slide 9

Slide 9 text

Dグレード対象技術資産の凡例① 開発・運用支援系 SaaS ● IaaS ○ プライベートクラウド開発と運営 ○ 独自Kubernetesエンジン(XKE, XKS) ● ライブラリ ○ アプリケーションに組み込めることができるもの ○ アプリケーション開発フレームワーク ○ SaaSのクライアント SDK ○ ゲームエンジン ● ソフトウェアデザイン ○ 体系化、明文化されたアーキテクチャパターン ○ 体系化、明文化された方法論

Slide 10

Slide 10 text

Dグレード評価指標グループ内導入数 GitHub Star数メンテナンス状況導入・運用期間 OR これらを元に 1年に1回、D1〜D5の5段階のグレードを決定する

Slide 11

Slide 11 text

Dグレードサポートプログラム価値のある技術資産を功労したり、中長期での継続的な開発をサポートするためにグレードに応じたサポートプログラムを用意 • 技術広報のサポート • パブリッククラウドや開発ツール利用料負担 • 懇親会・カンファレンス参加費用負担など

Slide 12

Slide 12 text

数値で見るDグレード

Slide 13

Slide 13 text

PipeCDでのインナーソースとオープンソース

Slide 14

Slide 14 text

PipeCD • DP室が中心となって開発している CD基盤 • GitOpsのプラクティス • アプリケーションの可視化 • デプロイの自動化 • Enterpriseを想定したセキュリティ • マルチプロバイダー & マルチテナント

Slide 15

Slide 15 text

解決したかった課題 • CIとCDが密結合 • 一元化されたプラットフォームが存在しない • 各チームは、独自のCDシステムを選択し、維持する全責任を負わなければならない • チーム異動の際のオンボーディングコストが高い • マルチクラウド環境で使いにくい • CIとCDの分離 • プラットフォームに依存しない一貫したDevEx • 各チームの運用は最小限に抑える • 高いセキュリティ • 迅速かつ有用なフィードバックを提供する

Slide 16

Slide 16 text

〜2023年まで 2019-2020年頭ぐらい構想〜調査 2020年5月提案〜開発スタート 2020年10月リポジトリを公開 2021年11月社内Saas提供開始 2023年5月 CNCF Sandboxに参加 Dグレードには初年度から参加

Slide 17

Slide 17 text

社内基盤への投資と利益の考え方 1. ソリューションにより減る不必要な仕事 2. 浮いた時間を再投資した場合に、得られうる売 3. ソリューションがプロダクトにもたらす付加価値 CA独自のカルチャー • 様々なドメインへの事業展開 • 最適な技術スタックを自由に選択する裁量 → 統一した基盤を導入することは難易度が高い持続可能な社内基盤を目指す過去の反省を活かす社内基盤が直面する困難さ • 希薄な中長期ビジョン • 市場での競争力に晒される • 役員への説明責任と継続性（お金と人材）

Slide 18

Slide 18 text

OSSのライフサイクルを確立し、開発資源を最大化する成果事例創出コミュニティ活性化市場拡大化 ■OSS公開 ■ベストプラクティスの啓蒙 ■カンファレンス発表 ■CNCF等参加での知名度・信頼性獲得 ■社外の利用・事例が増える ■個人or企業コントリビューター獲得 ■採用チャンス増 ■社外コンサル活動 ■要望サポート ■プロダクトグロース

Slide 19

Slide 19 text

社内基盤のライフサイクルもほぼ同じ社内成果事例創出コミュニティ活性化市場拡大化 ■社内公開 ■社内勉強会への登壇 ■Dグレードでの社内広報 ■社外・社内の利用・事例が増える ■部署外コントリビューター獲得 ■異動チャンス増 ■社内要望サポート ■社内SaaSの提供 ■プロダクトグロース ■社内Enablingチーム活動

Slide 20

Slide 20 text

現在 GitHub リポジトリ ● ~4k commits ● 90+ contributors （~30名が社内の別部署のcontributor） ● 1k+ stars 社内SaaS ● 20以上のプロジェクト ● 3,700+のアプリケーション ● 1日3,000回以上のデプロイ

Slide 21

Slide 21 text

FanTech事業と PipeCD Terraform Provider開発

Slide 22

Slide 22 text

•株式会社サイバーエージェント 2020年度新卒入社 CyberFight、FANBASE ARENA、ABEMA Live技術責任者 FanTech領域で新卒エンジニアの育成責任者 •趣味配信機材集めカメラ📸 GitHub: @arabian9ts 前田拓

Slide 23

Slide 23 text

No content

Slide 24

Slide 24 text

エンタメテックとFanTech事業 •エンタメテックサイバーエージェント注力領域の1つ音楽ライブやスポーツ・格闘技などを中心に、海外進出を後押しするプロダクトを多数提供デジタルプラットフォームでの配信、PPVによる収益化支援など •FanTech事業エンタメテック領域の1つで、ファンビジネスを中心に多数のプロダクトを展開映像配信や多言語対応しているファンコミュニティサービスを多数展開ファンとアーティストの双方向性を重要視

Slide 25

Slide 25 text

FanTech事業 •WRESTLE UNIVERSE サブスク制・PPVプロレス動画配信サービス海外ユーザーに向けて、UIやコンテンツ、実況音声を多言語化 •FANBASE ARENA 独自にカスタマイズされたファンコミュニティ・ファンクラブサービスを構築エンタメテックでもバックエンド基盤として利用 WRESTLE UNIVERSEもFANBASE ARENAで構築 ※FanTech事業の一部のみを記載しています

Slide 26

Slide 26 text

•WRESTLE UNIVERSE プロレスをサブスク・PPVで国内外に配信（ライブ・オンデマンド） •ABEMA Live 海外向けABEMA PPV配信プラットフォーム •AG! SEISHUN CLUB 海外向けのファンコミュニティサービスファンとアーティスト、ファン同士のコミュニケーションを主体としたコミュニティ共通基盤のプロダクト事例 ※記載以外にも多数のプロダクトを展開しています

Slide 27

Slide 27 text

FanTech事業の特徴 •海外展開の強化多言語化や決済のローカライズ対応、マルチリージョン展開を前提としたアーキテクチャ •多岐にわたるコンテンツ複数のドメインに対して迅速に高品質なサービスを展開多くのプロダクトを抱えることになり、事業ニーズに応じて迅速な立ち上げ •コードベースの共通化バックエンドと管理画面のコードベースを共通化

Slide 28

Slide 28 text

FanTech事業でのPipeCDの活用 •メインブランチを正とする全環境の同期デプロイマニフェストをバックエンドリポジトリ内で集約管理メインブランチのマニフェストを正とし、dev/prodに同時にSync（dev/prod同時デプロイ） •プロダクト数の増加に対しての Pull型デプロイマルチリージョン×分割されたアプリケーション×プロダクト数のデプロイを管理メインブランチの変更をPipeCDが検知しデプロイ → プロダクト数が増えても、メインブランチのマニフェストを最新に保てば良い

Slide 29

Slide 29 text

FanTech事業が抱えていた課題 •手動でのデプロイ管理プロダクトや展開リージョンの増加に合わせて、PipeCDの設定追加を手動で行う必要があった同じアプリケーション設定を何度も追加 /削除することが多いので、 IaC管理したかったモジュラーモノリスで160近いアプリケーションのデプロイを管理している

Slide 30

Slide 30 text

社内での課題感の共有 1.社内サポートへの問い合わせ CDをIaC管理したいのはニッチかと思いつつ、社内サポート用チャンネルに問い合わせすぐに対応は難しい様子

Slide 31

Slide 31 text

社内での課題感の共有 1.社内サポートへの問い合わせ CDをIaC管理したいのはニッチかと思いつつ、社内サポート用チャンネルに問い合わせすぐに対応は難しい様子 2.timesで呼びかけてみた黒崎が開発に参加 🎉 関心を持つエンジニア数名がジョイン

Slide 32

Slide 32 text

社内での課題感の共有 1時間半で共同プロジェクトが始動 🚀

Slide 33

Slide 33 text

Terraform Provider PipeCDの開発 •開発内容 Terraform Providerの開発と、必要なPipeCDのAPI開発を同時に進行インナーソースプロジェクトを実践する中で、OSSであるPipeCDにもコントリビュート Add EnableApplication rpc for grpc api service #4274 Add RegisterPiped api for grpcapi #4314 Add GetPiped grpc api #4316 Add UpdatePiped grpc api #4318 •公開に向けて PipeCDへのリポジトリTransferや、PipeCDのDocsへの追記、Community MeetingでのデモをDeveloper Productivity室と連携数日でほとんどの実装が完了しました 🚀

Slide 34

Slide 34 text

プロジェクトの振り返り •組織規模に対する “発見可能性 ” 知らないだけ、同じ課題や関心を持っているエンジニアは一定数いる社内で相互に認知できる場が有効（今回は、サポートチャンネルや黒崎がtimesにいたこと） •整っていた条件推進者である前田、黒崎が所属組織の技術責任者レイヤーであり、合意形成が容易だった開発メンバーがOSS開発フローを心得ていた資産はCNCFプロジェクトであるPipeCDに寄贈することが明確だった •サイバーエージェントの文化的側面技術的なチャレンジ精神を持ったエンジニアが多く、プロジェクト化のフットワークが軽い

Slide 35

Slide 35 text

•インナーソースにおけるコミュニティ形成 PipeCDの一部なので、PipeCDで形成されているコミュニティ内で一緒に運用していく社内ニーズに応じて、機能開発はインナーソーシング予定 •Developer Productivity室との連携社内SaaSとしてのサポートにマージ技術課題にフィットするプロダクトへの導入支援 Terraform Provider PipeCDの運用

Slide 36

Slide 36 text

•プロダクトでの運用を経て PipeCD、Terraform Provider PipeCDはDグレード制度を利用社内広報や開発費用支援を受ける予定インナーソースで重要な “発見可能性” を高める制度として利用 Dグレードの利用

Slide 37

Slide 37 text

事業プロダクトでのインナーソース活動

Slide 38

Slide 38 text

Slide 39

Slide 39 text

コードベースの共通化 •1リポジトリ運用 1リポジトリで複数のプロダクトを同時開発・同時運用 •機能の汎用性・拡張性プロダクトごとの条件分岐を設けず、汎用性や拡張性を重要視した設計を実施 •リポジトリの再利用性それぞれ目標の異なる複数事業で再利用ができている → インナーソーシング不採用採用

Slide 40

Slide 40 text

バックエンドのデプロイフロー

Slide 41

Slide 41 text

•事業横断チームが複数事業に均等にコミット情報流通量が多過ぎることで、認知負荷の上昇につながっていた 2023年までの体制

Slide 42

Slide 42 text

組織の成り立ち •高速なプロダクトの立ち上げ要求周年イベントなど期日が決まった立ち上げが発生しやすい FANBASE ARENAでは、都度チームを組織するのではなく、1チームで複数プロダクトを運用できる仕組み化を行ってきた •海外へのチャレンジ WRESTLE UNIVERSEで海外へのサービス展開を行っていた ABEMAでも海外展開を始めるにあたり、初期は高速な立ち上げが可能なチームで担当

Slide 43

Slide 43 text

•各事業の主担当を決定結果として、インナーソーシングとしての共通資産投資へと変化 ※ABEMAは2025年からインナーソースプロジェクトへジョイン 2024年以降の体制

Slide 44

Slide 44 text

インナーソースを通じた共通資産へ •2025年以降の体制横断する事業が増えても、事業貢献を損なわない組織体制へ集約的な組織構造から、分散的な組織へ変化 OSSのプラクティスを実践できる情報の “発見可能性” を強化

Slide 45

Slide 45 text

今後のインナーソース推進に向けて

Slide 46

Slide 46 text

実践者視点でのインナーソーシング •サイバーエージェントでのインナーソーシングの難しさプロダクトごとに技術選定が大きく異なる技術スタックの共通化が前提となるような、アプリケーションレベルの開発では難しい •取り組みやすい領域 OSSの社内用プラグインなど、専任チームが不要な粒度の開発技術の多様化の影響が少ないスコープで、開発体験を上げるツール(Terraform Provider PipeCD) 事業をまたいで、横断的にプロダクトを開発 •ハードルを下げつつコラボレーションを促進する制度設計１人または少数の開発者が気軽に始められるようにハードルを下げる一方、技術資産を有効活用し、コラボレーションによって継続的な価値を作っていくための制度設計が大切

Slide 47

Slide 47 text

ありがとうございました