Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
サイバーエージェントにおけるインナーソーシングの取り組み
Search
CyberAgent
PRO
August 13, 2024
Technology
3
1.7k
サイバーエージェントにおけるインナーソーシングの取り組み
CyberAgent
PRO
August 13, 2024
Tweet
Share
More Decks by CyberAgent
See All by CyberAgent
生成AIの強みと弱みを理解して、生成AIがもたらすパワーをプロダクトの価値へ繋げるために実践したこと / advance-ai-generating
cyberagentdevelopers
PRO
1
170
SNSマーケティングに革新! ABEMA サッカー動画切り出しを生成AIで自動化し、業務効率化を狙う! / abema-ai-marketing
cyberagentdevelopers
PRO
1
85
新卒1年目が挑む!生成AI × マルチエージェントで実現する次世代オンボーディング / operation-ai-onboarding
cyberagentdevelopers
PRO
1
150
バナー自動生成に向けたオープンなtext-to-templateモデルの構築 / creative-ai-opencole
cyberagentdevelopers
PRO
1
56
Argo Workflowsで構築するLLMを活用したコールセンターの自動要約プロダクトの立ち上げ / ai-argo-summarize
cyberagentdevelopers
PRO
1
58
大規模データ基盤チームのオンプレTiDB運用への挑戦 / dpu-tidb
cyberagentdevelopers
PRO
1
110
カメラを用いた店内計測におけるオプトインの仕組みの実現 / ai-optin-camera
cyberagentdevelopers
PRO
1
120
新しい映像体験WINLIVE競輪選手の体力を可視化するテクノロジーとその裏側 / winlive-sensing
cyberagentdevelopers
PRO
1
48
20周年を迎えたAmebaでのデータチームの挑戦: モノリスなデータ基盤における論理的データメッシュの構築 / ameba-mesh-gemini
cyberagentdevelopers
PRO
1
52
Other Decks in Technology
See All in Technology
pandasはPolarsに性能面で追いつき追い越せるのか
vaaaaanquish
4
3.2k
生成AIと知識グラフの相互利用に基づく文書解析
koujikozaki
1
110
プロダクトエンジニアが活躍する環境を作りたくて 事業責任者になった話 ~プロダクトエンジニアの行き着く先~
gimupop
1
400
オニオンアーキテクチャで実現した 本質課題を解決する インフラ移行の実例
hryushm
14
3k
Java x Spring Boot Warm up
kazu_kichi_67
2
480
とあるユーザー企業におけるリスクベースで考えるセキュリティ業務のお話し
4su_para
2
310
2024-10-30-reInventStandby_StudyGroup_Intro
shinichirokawano
1
560
フルカイテン株式会社 採用資料
fullkaiten
0
36k
サイロ化した金融システムを、packwerk を利用して無事故でリファクタリングした話
coincheck_recruit
3
3.6k
【若手エンジニア応援LT会】AWS Security Hubの活用に苦労した話
kazushi_ohata
0
140
Emacs x Nostr
hakkadaikon
1
140
ExaDB-D dbaascli で出来ること
oracle4engineer
PRO
0
3.6k
Featured
See All Featured
Git: the NoSQL Database
bkeepers
PRO
425
64k
Code Review Best Practice
trishagee
64
17k
Designing Experiences People Love
moore
138
23k
jQuery: Nuts, Bolts and Bling
dougneiner
61
7.5k
It's Worth the Effort
3n
183
27k
Measuring & Analyzing Core Web Vitals
bluesmoon
1
38
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.1k
Rails Girls Zürich Keynote
gr2m
93
13k
Thoughts on Productivity
jonyablonski
67
4.3k
How STYLIGHT went responsive
nonsquared
95
5.2k
Designing on Purpose - Digital PM Summit 2013
jponch
115
6.9k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
9.1k
Transcript
小塚健太 - Developer Productivity室 室長 前田 拓 - ABEMA Live/CyberFight/FANBASE
ARENA 技術責任者 (各兼務) InnerSourcing Gathering Tokyo 2024 サイバーエージェントにおける インナーソーシングの取り組み
1.インナーソースの推進と Dグレード制度 2.PipeCDでのインナーソースとオープンソース 3.FanTech事業とPipeCD Terraform Provider開発 4.事業プロダクトでのインナーソース活動 5.今後のインナーソース推進に向けて
小塚 健太 Developer Productivity室 室長 Engineer at CyberAgent #PipeCD #Bucketeer
✈🎾🏃⛰ X: @kenta_kozuka GitHub: @kentakozuka
インナーソースの推進と Dグレード制度
CAの抱えていた課題 元々グループ内では、社内共通基盤や個人による OSS活動も活発だったこともあり多くの技 術資産が存在 しかし、 1. 技術資産が十分に流動しておらず、全体での生産性向上に活かしきれていない 2. 車輪の再発明 3.
技術資産を支援していく枠組みが不十分だったため、継続性に乏しかった → 作りっぱなしで、利用者が増えず、ゆっくり廃れていく
Dグレード •グループ内の技術資産を中長期で支援し、開発生産性を高めるための制度 •D = Developer, DevTool •2021年に発案、制度化 •継続的に改善を重ね、現在は Ver.4 •個人・チームの申請制
2020年5月 GitHub Enterpriseへの契約一本化によって Internalリポジトリが利用可能になっていた
Dグレードの目的 ① 中長期での技術資産開発、 OSS育成 ② 全社レベルでの技術資産の流動と有効活用 ③ 情報共有促進・車輪の再発明の抑制 ④ 技術力を使った組織貢献の活性化
技術資産をこれまで以上に流動・活性化させ、 全社でのシナジー発揮を目指す
Dグレード対象となる技術資産 1. 事業プロダクトの開発や運用を効率化する技術資産である 2. CAグループ社員がオーナーである技術資産に限定 3. 社内に導入実績があること 4. 利用者向けドキュメントが整備されている
Dグレード対象技術資産の凡例① 開発・運用支援系 SaaS • IaaS ◦ プライベートクラウド開発と運営 ◦ 独自Kubernetesエンジン(XKE, XKS)
• ライブラリ ◦ アプリケーションに組み込めることができるもの ◦ アプリケーション開発フレームワーク ◦ SaaSのクライアント SDK ◦ ゲームエンジン • ソフトウェアデザイン ◦ 体系化、明文化されたアーキテクチャパターン ◦ 体系化、明文化された方法論
Dグレード評価指標 グループ内 導入数 GitHub Star数 メンテナンス 状況 導入・運用 期間 OR
これらを元に 1年に1回、D1〜D5の5段階のグレードを決定する
Dグレードサポートプログラム 価値のある技術資産を功労したり、中長期での継続的な開発をサポートするためにグレー ドに応じたサポートプログラムを用意 • 技術広報のサポート • パブリッククラウドや開発ツール利用料負担 • 懇親会・カンファレンス参加費用負担 など
数値で見るDグレード
PipeCDでのインナーソースとオー プンソース
PipeCD • DP室が中心となって開発している CD基盤 • GitOpsのプラクティス • アプリケーションの可視化 • デプロイの自動化
• Enterpriseを想定したセキュリティ • マルチプロバイダー & マルチテナント
解決したかった課題 • CIとCDが密結合 • 一元化されたプラットフォームが存在 しない • 各チームは、独自のCDシステムを選 択し、維持する全責任を負わなけれ ばならない
• チーム異動の際のオンボーディング コストが高い • マルチクラウド環境で使いにくい • CIとCDの分離 • プラットフォームに依存しない一貫し たDevEx • 各チームの運用は最小限に抑える • 高いセキュリティ • 迅速かつ有用なフィードバックを提供 する
〜2023年まで 2019-2020年頭ぐらい 構想〜調査 2020年5月 提案〜開発スタート 2020年10月 リポジトリを公開 2021年11月 社内Saas提供開始 2023年5月
CNCF Sandboxに参加 Dグレードには初年度から参加
社内基盤への投資と利益の考え方 1. ソリューションにより減る不必要な仕事 2. 浮いた時間を再投資した場合に、得られうる売 3. ソリューションがプロダクトにもたらす付加価値 CA独自のカルチャー • 様々なドメインへの事業展開
• 最適な技術スタックを自由に選択する裁量 → 統一した基盤を導入することは難易度が高い 持続可能な社内基盤を目指す 過去の反省を活かす 社内基盤が直面する困難さ • 希薄な中長期ビジョン • 市場での競争力に晒される • 役員への説明責任と継続性(お金と人材)
OSSのライフサイクルを確立し、開発資源を最大化する 成果 事例創出 コミュニティ 活性化 市場 拡大化 ▪OSS公開 ▪ベストプラクティスの啓蒙 ▪カンファレンス発表
▪CNCF等参加での知名度・信頼性獲得 ▪社外の利用・事例が増える ▪個人or企業コントリビューター獲得 ▪採用チャンス増 ▪社外コンサル活動 ▪要望サポート ▪プロダクトグロース
社内基盤のライフサイクルもほぼ同じ 社内成果 事例創出 コミュニティ 活性化 市場 拡大化 ▪社内公開 ▪社内勉強会への登壇 ▪Dグレードでの社内広報
▪社外・社内の利用・事例が増える ▪部署外コントリビューター獲得 ▪異動チャンス増 ▪社内要望サポート ▪社内SaaSの提供 ▪プロダクトグロース ▪社内Enablingチーム活動
現在 GitHub リポジトリ • ~4k commits • 90+ contributors (~30名が社内の別部署のcontributor)
• 1k+ stars 社内SaaS • 20以上のプロジェクト • 3,700+のアプリケーション • 1日3,000回以上のデプロイ
FanTech事業と PipeCD Terraform Provider開発
•株式会社サイバーエージェント 2020年度新卒入社 CyberFight、FANBASE ARENA、ABEMA Live技術責任者 FanTech領域で新卒エンジニアの育成責任者 •趣味 配信機材集め カメラ📸 GitHub:
@arabian9ts 前田 拓
None
エンタメテックとFanTech事業 •エンタメテック サイバーエージェント注力領域の1つ 音楽ライブやスポーツ・格闘技などを中心に、海外進出を後押しするプロダクトを多数提供 デジタルプラットフォームでの配信、PPVによる収益化支援など •FanTech事業 エンタメテック領域の1つで、ファンビジネスを中心に多数のプロダクトを展開 映像配信や多言語対応しているファンコミュニティサービスを多数展開 ファンとアーティストの双方向性を重要視
FanTech事業 •WRESTLE UNIVERSE サブスク制・PPVプロレス動画配信サービス 海外ユーザーに向けて、UIやコンテンツ、実況音声を多 言語化 •FANBASE ARENA 独自にカスタマイズされたファンコミュニティ・ファンクラ ブサービスを構築
エンタメテックでもバックエンド基盤として利用 WRESTLE UNIVERSEもFANBASE ARENAで構築 ※FanTech事業の一部のみを記載しています
•WRESTLE UNIVERSE プロレスをサブスク・PPVで国内外に配信(ライブ・オンデマンド) •ABEMA Live 海外向けABEMA PPV配信プラットフォーム •AG! SEISHUN CLUB
海外向けのファンコミュニティサービス ファンとアーティスト、ファン同士のコミュニケーションを主体としたコミュニティ 共通基盤のプロダクト事例 ※記載以外にも多数のプロダクトを展開しています
FanTech事業の特徴 •海外展開の強化 多言語化や決済のローカライズ対応、マルチリージョン展開を前提としたアーキテクチャ •多岐にわたるコンテンツ 複数のドメインに対して迅速に高品質なサービスを展開 多くのプロダクトを抱えることになり、事業ニーズに応じて迅速な立ち上げ •コードベースの共通化 バックエンドと管理画面のコードベースを共通化
FanTech事業でのPipeCDの活用 •メインブランチを正とする全環境の同期 デプロイマニフェストをバックエンドリポジトリ内で集約管理 メインブランチのマニフェストを正とし、dev/prodに同時にSync(dev/prod同時デプロイ) •プロダクト数の増加に対しての Pull型デプロイ マルチリージョン×分割されたアプリケーション×プロダクト数のデプロイを管理 メインブランチの変更をPipeCDが検知しデプロイ → プロダクト数が増えても、メインブランチのマニフェストを最新に保てば良い
FanTech事業が抱えていた課題 •手動でのデプロイ管理 プロダクトや展開リージョンの増加に合わせて、PipeCDの設定追加を手動で行う必要があった 同じアプリケーション設定を何度も追加 /削除することが多いので、 IaC管理したかった モジュラーモノリスで160近いアプリケーションのデプロイを管理している
社内での課題感の共有 1.社内サポートへの問い合わせ CDをIaC管理したいのはニッチかと思いつつ、社 内サポート用チャンネルに問い合わせ すぐに対応は難しい様子
社内での課題感の共有 1.社内サポートへの問い合わせ CDをIaC管理したいのはニッチかと思いつつ、社 内サポート用チャンネルに問い合わせ すぐに対応は難しい様子 2.timesで呼びかけてみた 黒崎が開発に参加 🎉 関心を持つエンジニア数名がジョイン
社内での課題感の共有 1時間半で共同プロジェクトが始動 🚀
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室と連携 数日でほとんどの実装が完了しました 🚀
プロジェクトの振り返り •組織規模に対する “発見可能性 ” 知らないだけ、同じ課題や関心を持っているエンジニアは一定数いる 社内で相互に認知できる場が有効(今回は、サポートチャンネルや黒崎がtimesにいたこと) •整っていた条件 推進者である前田、黒崎が所属組織の技術責任者レイヤーであり、合意形成が容易だった 開発メンバーがOSS開発フローを心得ていた 資産はCNCFプロジェクトであるPipeCDに寄贈することが明確だった
•サイバーエージェントの文化的側面 技術的なチャレンジ精神を持ったエンジニアが多く、プロジェクト化のフットワークが軽い
•インナーソースにおけるコミュニティ形成 PipeCDの一部なので、PipeCDで形成されているコミュニティ内で一緒に運用していく 社内ニーズに応じて、機能開発はインナーソーシング予定 •Developer Productivity室との連携 社内SaaSとしてのサポートにマージ 技術課題にフィットするプロダクトへの導入支援 Terraform Provider PipeCDの運用
•プロダクトでの運用を経て PipeCD、Terraform Provider PipeCDはDグレード制度を利用 社内広報や開発費用支援を受ける予定 インナーソースで重要な “発見可能性” を高める制度として利用 Dグレードの利用
事業プロダクトでの インナーソース活動
FanTech事業の特徴 •海外展開の強化 多言語化や決済のローカライズ対応、マルチリージョン展開を前提としたアーキテクチャ •多岐にわたるコンテンツ 複数のドメインに対して迅速に高品質なサービスを展開 多くのプロダクトを抱えることになり、事業ニーズに応じて迅速な立ち上げ •コードベースの共通化 バックエンドと管理画面のコードベースを共通化
コードベースの共通化 •1リポジトリ運用 1リポジトリで複数のプロダクトを同時開発・ 同時運用 •機能の汎用性・拡張性 プロダクトごとの条件分岐を設けず、汎用性 や拡張性を重要視した設計を実施 •リポジトリの再利用性 それぞれ目標の異なる複数事業で再利用が できている
→ インナーソーシング 不採用 採用
バックエンドのデプロイフロー
•事業横断チームが複数事業に均等にコミット 情報流通量が多過ぎることで、認知負荷の上昇につながっていた 2023年までの体制
組織の成り立ち •高速なプロダクトの立ち上げ要求 周年イベントなど期日が決まった立ち上げが発生しやすい FANBASE ARENAでは、都度チームを組織するのではなく、1チームで複数プロダクトを運用できる仕組み 化を行ってきた •海外へのチャレンジ WRESTLE UNIVERSEで海外へのサービス展開を行っていた ABEMAでも海外展開を始めるにあたり、初期は高速な立ち上げが可能なチームで担当
•各事業の主担当を決定 結果として、インナーソーシングとしての共通資産投資へと変化 ※ABEMAは2025年からインナーソースプロジェクトへジョイン 2024年以降の体制
インナーソースを通じた共通資産へ •2025年以降の体制 横断する事業が増えても、事業貢献を損なわない組織体制へ 集約的な組織構造から、分散的な組織へ変化 OSSのプラクティスを実践できる情報の “発見可能性” を強化
今後のインナーソース推進に 向けて
実践者視点でのインナーソーシング •サイバーエージェントでのインナーソーシングの難しさ プロダクトごとに技術選定が大きく異なる 技術スタックの共通化が前提となるような、アプリケーションレベルの開発では難しい •取り組みやすい領域 OSSの社内用プラグインなど、専任チームが不要な粒度の開発 技術の多様化の影響が少ないスコープで、開発体験を上げるツール(Terraform Provider PipeCD) 事業をまたいで、横断的にプロダクトを開発
•ハードルを下げつつコラボレーションを促進する制度設計 1人または少数の開発者が気軽に始められるようにハードルを下げる一方、技術資産を有効活用し、コラ ボレーションによって継続的な価値を作っていくための制度設計が大切
ありがとうございました