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

Transcript

1. 小塚健太 - Developer Productivity室 室長 前田 拓 - ABEMA Live/CyberFight/FANBASE ARENA 技術責任者 (各兼務) InnerSourcing Gathering Tokyo 2024 サイバーエージェントにおける インナーソーシングの取り組み
2. 1.インナーソースの推進と Dグレード制度 2.PipeCDでのインナーソースとオープンソース 3.FanTech事業とPipeCD Terraform Provider開発 4.事業プロダクトでのインナーソース活動 5.今後のインナーソース推進に向けて
3. 小塚 健太 Developer Productivity室 室長 Engineer at CyberAgent #PipeCD #Bucketeer ✈🎾🏃⛰ X: @kenta_kozuka GitHub: @kentakozuka
4. インナーソースの推進と Dグレード制度
5. CAの抱えていた課題 元々グループ内では、社内共通基盤や個人による OSS活動も活発だったこともあり多くの技 術資産が存在 しかし、 1. 技術資産が十分に流動しておらず、全体での生産性向上に活かしきれていない 2. 車輪の再発明 3. 技術資産を支援していく枠組みが不十分だったため、継続性に乏しかった → 作りっぱなしで、利用者が増えず、ゆっくり廃れていく
6. Dグレード •グループ内の技術資産を中長期で支援し、開発生産性を高めるための制度 •D = Developer, DevTool •2021年に発案、制度化 •継続的に改善を重ね、現在は Ver.4 •個人・チームの申請制 2020年5月 GitHub Enterpriseへの契約一本化によって Internalリポジトリが利用可能になっていた
7. Dグレードの目的 ① 中長期での技術資産開発、 OSS育成 ② 全社レベルでの技術資産の流動と有効活用 ③ 情報共有促進・車輪の再発明の抑制 ④ 技術力を使った組織貢献の活性化 技術資産をこれまで以上に流動・活性化させ、 全社でのシナジー発揮を目指す
8. Dグレード対象となる技術資産 1. 事業プロダクトの開発や運用を効率化する技術資産である 2. CAグループ社員がオーナーである技術資産に限定 3. 社内に導入実績があること 4. 利用者向けドキュメントが整備されている
9. Dグレード対象技術資産の凡例① 開発・運用支援系 SaaS • IaaS ◦ プライベートクラウド開発と運営 ◦ 独自Kubernetesエンジン(XKE, XKS) • ライブラリ ◦ アプリケーションに組み込めることができるもの ◦ アプリケーション開発フレームワーク ◦ SaaSのクライアント SDK ◦ ゲームエンジン • ソフトウェアデザイン ◦ 体系化、明文化されたアーキテクチャパターン ◦ 体系化、明文化された方法論
10. Dグレード評価指標 グループ内 導入数 GitHub Star数 メンテナンス 状況 導入・運用 期間 OR これらを元に 1年に1回、D1〜D5の5段階のグレードを決定する
11. Dグレードサポートプログラム 価値のある技術資産を功労したり、中長期での継続的な開発をサポートするためにグレー ドに応じたサポートプログラムを用意 • 技術広報のサポート • パブリッククラウドや開発ツール利用料負担 • 懇親会・カンファレンス参加費用負担 など
12. 数値で見るDグレード
13. PipeCDでのインナーソースとオー プンソース
14. PipeCD • DP室が中心となって開発している CD基盤 • GitOpsのプラクティス • アプリケーションの可視化 • デプロイの自動化 • Enterpriseを想定したセキュリティ • マルチプロバイダー & マルチテナント
15. 解決したかった課題 • CIとCDが密結合 • 一元化されたプラットフォームが存在 しない • 各チームは、独自のCDシステムを選 択し、維持する全責任を負わなけれ ばならない • チーム異動の際のオンボーディング コストが高い • マルチクラウド環境で使いにくい • CIとCDの分離 • プラットフォームに依存しない一貫し たDevEx • 各チームの運用は最小限に抑える • 高いセキュリティ • 迅速かつ有用なフィードバックを提供 する
16. 〜2023年まで 2019-2020年頭ぐらい 構想〜調査 2020年5月 提案〜開発スタート 2020年10月 リポジトリを公開 2021年11月 社内Saas提供開始 2023年5月 CNCF Sandboxに参加 Dグレードには初年度から参加
17. 社内基盤への投資と利益の考え方 1. ソリューションにより減る不必要な仕事 2. 浮いた時間を再投資した場合に、得られうる売 3. ソリューションがプロダクトにもたらす付加価値 CA独自のカルチャー • 様々なドメインへの事業展開 • 最適な技術スタックを自由に選択する裁量 → 統一した基盤を導入することは難易度が高い 持続可能な社内基盤を目指す 過去の反省を活かす 社内基盤が直面する困難さ • 希薄な中長期ビジョン • 市場での競争力に晒される • 役員への説明責任と継続性（お金と人材）
18. OSSのライフサイクルを確立し、開発資源を最大化する 成果 事例創出 コミュニティ 活性化 市場 拡大化 ▪OSS公開 ▪ベストプラクティスの啓蒙 ▪カンファレンス発表 ▪CNCF等参加での知名度・信頼性獲得 ▪社外の利用・事例が増える ▪個人or企業コントリビューター獲得 ▪採用チャンス増 ▪社外コンサル活動 ▪要望サポート ▪プロダクトグロース
19. 社内基盤のライフサイクルもほぼ同じ 社内成果 事例創出 コミュニティ 活性化 市場 拡大化 ▪社内公開 ▪社内勉強会への登壇 ▪Dグレードでの社内広報 ▪社外・社内の利用・事例が増える ▪部署外コントリビューター獲得 ▪異動チャンス増 ▪社内要望サポート ▪社内SaaSの提供 ▪プロダクトグロース ▪社内Enablingチーム活動
20. 現在 GitHub リポジトリ • ~4k commits • 90+ contributors （~30名が社内の別部署のcontributor） • 1k+ stars 社内SaaS • 20以上のプロジェクト • 3,700+のアプリケーション • 1日3,000回以上のデプロイ
21. FanTech事業と PipeCD Terraform Provider開発
22. •株式会社サイバーエージェント 2020年度新卒入社 CyberFight、FANBASE ARENA、ABEMA Live技術責任者 FanTech領域で新卒エンジニアの育成責任者 •趣味 配信機材集め カメラ📸 GitHub: @arabian9ts 前田 拓
24. エンタメテックとFanTech事業 •エンタメテック サイバーエージェント注力領域の1つ 音楽ライブやスポーツ・格闘技などを中心に、海外進出を後押しするプロダクトを多数提供 デジタルプラットフォームでの配信、PPVによる収益化支援など •FanTech事業 エンタメテック領域の1つで、ファンビジネスを中心に多数のプロダクトを展開 映像配信や多言語対応しているファンコミュニティサービスを多数展開 ファンとアーティストの双方向性を重要視
25. FanTech事業 •WRESTLE UNIVERSE サブスク制・PPVプロレス動画配信サービス 海外ユーザーに向けて、UIやコンテンツ、実況音声を多 言語化 •FANBASE ARENA 独自にカスタマイズされたファンコミュニティ・ファンクラ ブサービスを構築 エンタメテックでもバックエンド基盤として利用 WRESTLE UNIVERSEもFANBASE ARENAで構築 ※FanTech事業の一部のみを記載しています
26. •WRESTLE UNIVERSE プロレスをサブスク・PPVで国内外に配信（ライブ・オンデマンド） •ABEMA Live 海外向けABEMA PPV配信プラットフォーム •AG! SEISHUN CLUB 海外向けのファンコミュニティサービス ファンとアーティスト、ファン同士のコミュニケーションを主体としたコミュニティ 共通基盤のプロダクト事例 ※記載以外にも多数のプロダクトを展開しています
27. FanTech事業の特徴 •海外展開の強化 多言語化や決済のローカライズ対応、マルチリージョン展開を前提としたアーキテクチャ •多岐にわたるコンテンツ 複数のドメインに対して迅速に高品質なサービスを展開 多くのプロダクトを抱えることになり、事業ニーズに応じて迅速な立ち上げ •コードベースの共通化 バックエンドと管理画面のコードベースを共通化
28. FanTech事業でのPipeCDの活用 •メインブランチを正とする全環境の同期 デプロイマニフェストをバックエンドリポジトリ内で集約管理 メインブランチのマニフェストを正とし、dev/prodに同時にSync（dev/prod同時デプロイ） •プロダクト数の増加に対しての Pull型デプロイ マルチリージョン×分割されたアプリケーション×プロダクト数のデプロイを管理 メインブランチの変更をPipeCDが検知しデプロイ → プロダクト数が増えても、メインブランチのマニフェストを最新に保てば良い
29. FanTech事業が抱えていた課題 •手動でのデプロイ管理 プロダクトや展開リージョンの増加に合わせて、PipeCDの設定追加を手動で行う必要があった 同じアプリケーション設定を何度も追加 /削除することが多いので、 IaC管理したかった モジュラーモノリスで160近いアプリケーションのデプロイを管理している
30. 社内での課題感の共有 1.社内サポートへの問い合わせ CDをIaC管理したいのはニッチかと思いつつ、社 内サポート用チャンネルに問い合わせ すぐに対応は難しい様子
31. 社内での課題感の共有 1.社内サポートへの問い合わせ CDをIaC管理したいのはニッチかと思いつつ、社 内サポート用チャンネルに問い合わせ すぐに対応は難しい様子 2.timesで呼びかけてみた 黒崎が開発に参加 🎉 関心を持つエンジニア数名がジョイン
32. 社内での課題感の共有 1時間半で共同プロジェクトが始動 🚀
33. 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室と連携 数日でほとんどの実装が完了しました 🚀
34. プロジェクトの振り返り •組織規模に対する “発見可能性 ” 知らないだけ、同じ課題や関心を持っているエンジニアは一定数いる 社内で相互に認知できる場が有効（今回は、サポートチャンネルや黒崎がtimesにいたこと） •整っていた条件 推進者である前田、黒崎が所属組織の技術責任者レイヤーであり、合意形成が容易だった 開発メンバーがOSS開発フローを心得ていた 資産はCNCFプロジェクトであるPipeCDに寄贈することが明確だった •サイバーエージェントの文化的側面 技術的なチャレンジ精神を持ったエンジニアが多く、プロジェクト化のフットワークが軽い
35. •インナーソースにおけるコミュニティ形成 PipeCDの一部なので、PipeCDで形成されているコミュニティ内で一緒に運用していく 社内ニーズに応じて、機能開発はインナーソーシング予定 •Developer Productivity室との連携 社内SaaSとしてのサポートにマージ 技術課題にフィットするプロダクトへの導入支援 Terraform Provider PipeCDの運用
36. •プロダクトでの運用を経て PipeCD、Terraform Provider PipeCDはDグレード制度を利用 社内広報や開発費用支援を受ける予定 インナーソースで重要な “発見可能性” を高める制度として利用 Dグレードの利用
37. 事業プロダクトでの インナーソース活動
38. FanTech事業の特徴 •海外展開の強化 多言語化や決済のローカライズ対応、マルチリージョン展開を前提としたアーキテクチャ •多岐にわたるコンテンツ 複数のドメインに対して迅速に高品質なサービスを展開 多くのプロダクトを抱えることになり、事業ニーズに応じて迅速な立ち上げ •コードベースの共通化 バックエンドと管理画面のコードベースを共通化
39. コードベースの共通化 •1リポジトリ運用 1リポジトリで複数のプロダクトを同時開発・ 同時運用 •機能の汎用性・拡張性 プロダクトごとの条件分岐を設けず、汎用性 や拡張性を重要視した設計を実施 •リポジトリの再利用性 それぞれ目標の異なる複数事業で再利用が できている → インナーソーシング 不採用 採用
40. バックエンドのデプロイフロー
41. •事業横断チームが複数事業に均等にコミット 情報流通量が多過ぎることで、認知負荷の上昇につながっていた 2023年までの体制
42. 組織の成り立ち •高速なプロダクトの立ち上げ要求 周年イベントなど期日が決まった立ち上げが発生しやすい FANBASE ARENAでは、都度チームを組織するのではなく、1チームで複数プロダクトを運用できる仕組み 化を行ってきた •海外へのチャレンジ WRESTLE UNIVERSEで海外へのサービス展開を行っていた ABEMAでも海外展開を始めるにあたり、初期は高速な立ち上げが可能なチームで担当
43. •各事業の主担当を決定 結果として、インナーソーシングとしての共通資産投資へと変化 ※ABEMAは2025年からインナーソースプロジェクトへジョイン 2024年以降の体制
44. インナーソースを通じた共通資産へ •2025年以降の体制 横断する事業が増えても、事業貢献を損なわない組織体制へ 集約的な組織構造から、分散的な組織へ変化 OSSのプラクティスを実践できる情報の “発見可能性” を強化
45. 今後のインナーソース推進に 向けて
46. 実践者視点でのインナーソーシング •サイバーエージェントでのインナーソーシングの難しさ プロダクトごとに技術選定が大きく異なる 技術スタックの共通化が前提となるような、アプリケーションレベルの開発では難しい •取り組みやすい領域 OSSの社内用プラグインなど、専任チームが不要な粒度の開発 技術の多様化の影響が少ないスコープで、開発体験を上げるツール(Terraform Provider PipeCD) 事業をまたいで、横断的にプロダクトを開発 •ハードルを下げつつコラボレーションを促進する制度設計 １人または少数の開発者が気軽に始められるようにハードルを下げる一方、技術資産を有効活用し、コラ ボレーションによって継続的な価値を作っていくための制度設計が大切
47. ありがとうございました