素早く賢く失敗するDeveloper Productivityの実現を目指して

by stormcat24

Slide 1

Slide 1 text

素早く賢く失敗する Developer Productivityの実現を目指して 2021/07/30 Akinori Yamada (@stormcat24) CyberAgent, Inc

Slide 2

Slide 2 text

Whois ‣ Akinori Yamada ‣ CyberAgent (2012.10〜) ‣ Developer Productivity室室長 ‣ 日本コンテナビルド組合（日コン組）組合員 stormcat24

Slide 3

Slide 3 text

Agenda ‣ CyberAgentについて ‣ CyberAgentのエンジニア文化 ‣ MEDIA TECH VISION 2020-2023 ‣ Developer Productivityの注力と取り組み ‣ Developer Productivityに取り組むエンジニアのこれから

Slide 4

Slide 4 text

CyberAgentについて

Slide 5

Slide 5 text

社名　　　　　株式会社サイバーエージェント　CyberAgent, Inc. 本社所在地　　〒150-0042　　　　　　　　東京都渋谷区宇田川町40番1号 Abema Towers 代表者　　　　代表取締役社長　藤田晋設立　　　　　1998年3月18日資本金　　　　7,203百万円（2019年9月末現在）事業内容　　　メディア事業　　　　　　　インターネット広告事業　　　　　　　ゲーム事業　　　　　　　投資育成事業会社概要

Slide 6

Slide 6 text

+ウマ娘

Slide 7

Slide 7 text

No content

Slide 8

Slide 8 text

CyberAgentのエンジニア文化

Slide 9

Slide 9 text

自由と裁量

Slide 10

Slide 10 text

Media Internet AD Game Startup AI DX CyberAgent Group 多様な事業ドメイン多くのグループ会社や事業部たくさんのプロダクトインターネットに連動する領域にはすぐ参入していくスタイル。技術的意思決定は各管轄や事業部、グループ会社、プロダクトに任せられている。

Slide 11

Slide 11 text

自由と裁量が組織にもたらすもの ‣ 事業の高速な立ち上げ ‣ 迅速な意思決定 ‣ 個人の能力の最大化 ‣ 技術者としてのチャレンジのしやすさ Pros Cons ‣ 複数組織での車輪の再発明 ‣ スキルやノウハウの分散 ‣ 開発力がチーム戦力に依存 ‣ 中長期で育てきれない技術資産組織的な開発手法のアップデートの遅れ品質の高いプロダクトの創出

Slide 12

Slide 12 text

拡大し続けるエンジニア組織連結従業員数約5,000名　　エンジニア人数約1,000名

Slide 13

Slide 13 text

組織的な開発手法のアップデートの遅れこれに向き合わないと、我々の開発力は相対的に下がっていくはずより組織的な取り組みが必要不可欠に

Slide 14

Slide 14 text

中長期での指針が必要まずはそれぞれの管轄別に技術指針（TECH VISION）を制定今日はメディアでの指針 MEDIA TECH VISIONについてメディア広告/AI ゲーム

Slide 15

Slide 15 text

MEDIA TECH VISION 2020-2023

Slide 16

Slide 16 text

MEDIA TECH VISION 2020-2023 ‣ 今後3年を見越しての基本指針や、中長期のプロダクト開発・技術の戦略をTECH VISIONとして発表 ‣ 技術者はもちろん、非技術者（役員や事業責任者も含む）に向けて大々的に発表会を実施し、組織としての意思統一を図る

Slide 17

Slide 17 text

つくる技術から、つくり育てる技術へ

Slide 18

Slide 18 text

不確実性の高いサービス開発ミッション市場環境 21世紀を代表するサービスを創り中長期の柱に育て上げる不確実性が高く、市場ニーズや技術構造の変化が読めない試行錯誤の精度と物量によって、何とかして成功するカタチを探り当てるような戦いを強いられる

Slide 19

Slide 19 text

個人の優れたスキルを再現性のある技術に育て共有し組織やチームのミッション実現にインパクトを出せるようにするエンジニアリング、デザインマネジメントなど、あらゆる方法論組織で技術を育て、圧倒的な精度と物量で試行錯誤を実現できる組織になる個人組織これまでの強みと、組織の大きさをレバレッジとしたスケールメリットの両立が必要

Slide 20

Slide 20 text

プロダクト開発とどう向き合うか ‣ 一見して良いものを作れるだけで終わってしまっていないか ‣ その先の価値提供や自身のキャリアと向き合えているのか ‣ 価値の定義が変化する中で、事業としても個人としても求められるのは何か ‣ 我々は「つくる」ことを通してどのようなインパクトを生み出すのか ‣ 技術、品質、数字、ユーザー、組織... 自身は何と向き合って価値を創るのか ‣ ひとりひとりが自らの事業貢献を自認できるようにするには？「つくる」だけの閉塞感からの脱却、「つくった先」の新たな価値の創出

Slide 21

Slide 21 text

指針の元に育てていく領域仮説と検証データ活用 Developer Productivity 組織に合った実践方法を模索し成果に繋げていくメディア内にあった技術の芽のキュレーション全体で取り組むことでスケールメリットに

Slide 22

Slide 22 text

TECH VISION実現の一輪として、Developer Productivity分野に注力

Slide 23

Slide 23 text

Developer Productivityへの注力と取り組み

Slide 24

Slide 24 text

Developer Productivity 開発者の生産性

Slide 25

Slide 25 text

広義で生産性に寄与すると思われるもの ‣ サクサク動くPCや高機能なサーバ ‣ 言語、フレームワーク ‣ 高速でスケールするCI、CD環境 ‣ 市場に存在するSaaSや社内基盤 ‣ 優れたオンボーディング ‣ 情報やノウハウの流動性技術・組織・人・モノ・金といった様々な観点で、腐るほど存在する😇

Slide 26

Slide 26 text

何に注力すべきか？自動化が未成熟 If CI/CD環境の整備リリース後の事故が多い If フィーチャーフラグの定着エラーレートでの自動ロールバックスケールする組織 If レガシーシステムの断捨離マイクロサービス QAリソースが多い If 自動テストツールの導入と定着改善活動の理解が得られてない If 生産性改善のROIの提示継続的な改善の指標づくり組織によって、何を選択すべきかは当然異なる。事業やプロダクトの競争力強化に繋がる本質的なものを選択すべき。 Then Then Then Then Then

Slide 27

Slide 27 text

参考）何が課題かよくわからない場合は？ DX Criteriaと自らの組織の現状を照らし合わせてみるのも良い

Slide 28

Slide 28 text

改善のワナ技術者視点でDP改善と向き合うと、無限にネタが出てくるワナ共通化・抽象化！負債解消！ E2Eテスト！ UI自動テスト！テストケース自動生成！ CI高速化！フィーチャーフラグ！トランクベース開発！ GitOps! SSOT! マイクロサービス！型だ！型をくれ！ Visual Regression Testing! クロスプラットフォーム！コンテナイメージダイエット！全てやった方が良さそうに見えてしまう

Slide 29

Slide 29 text

手段からではなく、事業やユーザー目線で考える ‣ ユーザーに機能や改善を素早く、かつ高頻度で届けられているか？ ‣ 事業をグロースさせるための本質開発に注力できているか？ ‣ 品質や安定性を担保するための仕組みが整備されているか？ユーザー価値・事業+プロダクトグロースの上流からDPを考える

Slide 30

Slide 30 text

CA メディア管轄における課題メディア開発は特に不確実性が強いので、素早く一つでも多くの機能を届け、もっと賢く失敗していきたい

Slide 31

Slide 31 text

仮説検証する仕組み賢く失敗するために越えるべき課題ビッグバンリリースの不安テストやQAに要する時間もっと安全に素早くリリースしたい障害時のリリース切り戻し ‣ 賢く失敗するには設計・実装フェーズよりも、ソフトウェアのリリースサイクルを組織として強化すべきと判断 ‣ アーキテクチャ、言語、インフラストラクチャ等は引き続き自由と裁量で

Slide 32

Slide 32 text

メディア管轄として目指す、DPの理想状態開発者と事業がスケールし続けるための高い生産性と品質を生み出す原動力を育てる Vision 推進部隊としてDeveloper Productivity室（DP室）を設立

Slide 33

Slide 33 text

3つのsigを編成 sig-experimentation sig-build sig = Special Interest Group sig-client Feature Flag Management Trunk Based Development A/B Testing Continuous Integration Continuous Delivery GitOps Progressive Delivery Component Testing UI Component Catalog Visual Regression Testing Multi Device Testing Accessibility Testing ‣ それぞれの専門家別にsigを編成 ‣ サードパーティー活用、独自ツール開発等手段に拘らずに、組織にフィットするベストプラクティスを考案し、定着させていく

Slide 34

Slide 34 text

sig-experimentation提供のプラクティス ‣ Trunk Based Development ‣ 本番環境でのQA作業 (Dark Launch) ‣ 実験のメトリクス収集、評価 ‣ ガードレール指標の定義 ‣ 閾値設定、自動ロールバックフィーチャーフラグ・ABテストプラットフォーム元々はABEMA基盤チームが開発し、 DP室が引き続き社内への開発・展開を行っている Optimizely, LaunchDarklyといった競合比でかなり安価で提供できることもあり、自社開発している

Slide 35

Slide 35 text

sig-build提供のプラクティス ‣ GitOps, Single Source of Truth ‣ Canary Release, Blue Green Deployment ‣ Progressive Delivery ‣ 分析 ‣ 自動ロールバック ‣ シークレット管理 GitOpsベースの継続的デリバリーツール Kubernetes、ECS、サーバレス、インフラを宣言的に定義しデリバリーする。 Spinnaker, FluxCD, ArgoCD等を検討した結果、大規模組織でSaaSとして運用でき、かつセキュアな仕組みが必要と判断したため独自で開発。既にOSSとしても公開されている。 https://github.com/pipe-cd/pipe

Slide 36

Slide 36 text

sig-client提供のプラクティス ‣ 画像回帰テスト(VRT) ‣ 複数デバイステスト ‣ アクセシビリティテスト

Slide 37

Slide 37 text

開発者マーケティングの強化 ‣ プロダクトやベストプラクティスをつくるだけではなく、効果的に使ってもらう取り組みが必要不可欠 ‣ ドキュメント、ブログ、クイックスタート、デモ、トライアル機能等のユーザーが能動的にプロダクトを体験してもらう仕組みを充実

Slide 38

Slide 38 text

DPの改善をどう評価するか？ DP習熟度チェック（定性的） DORA （定量的）

Slide 39

Slide 39 text

習熟度チェック ‣ 3つのsigにおける、各プロジェクトの習熟度チェックを実施 ‣ 現状把握、プラクティスの認識、今後の戦略・意思決定に活用

Slide 40

Slide 40 text

DORA ‣ DevOps Research and Assessment ‣ デプロイ頻度やリードタイム、MTTR 等で組織のパフォーマンスを測り、上を目指していく ‣ 段階的に各事業への導入を準備中 ‣ 技術者が常にわかりやすい指標を持って改善を続けていくことが重要

Slide 41

Slide 41 text

技術者本位の改善に留まらないようにするには DP習熟度チェック（定性的） DORA （定量的）どちらかというと技術者寄りの指標技術者以外の観点で、開発がどう良くなるのか？自分たちのビジネスにポジティブに影響することは何か？について技術者=事業間でDPについて共通の課題・目標認識、合意形成をできるようにする。事業やプロダクトに大きくヒットし、非技術者が大きく期待してくれる内容を意識する。定性的開発プロセス定量的人員施策リリース回数改善前改善後リリースした機能の効果検証が不十分 10名 2回/月 5名 10回/月効果検証が用意に行える柔軟にON/OFFが可能になる

Slide 42

Slide 42 text

職種や領域を越えて、Developer Productivityに向き合うことが大切です

Slide 43

Slide 43 text

Developer Productivityに取り組むエンジニアのこれから

Slide 44

Slide 44 text

DP改善マンと事業との微妙な距離感エンドユーザーユーザー企業プロダクト経営層ビジネス職クリエイタープロダクト開発付加価値 DP改善サポート事業やプロダクトは、よくわからない技術力でプロダクト開発をサポートして貢献するぞプロダクト開発マンは色々機能を作ってくれてる。 DP改善マンは貢献してくれてるようだけどどのように評価すれば良いのだろう？プロダクトや事業に対して、DP改善の貢献度合いが見えにくいもしくは伝えきれていないケースがよくある DP改善マンはよくやってくれてるよ

Slide 45

Slide 45 text

ひとりひとりが自らの事業貢献を自認できるようにするには？技術者への問いの1つ（MEDIA TECH VISIONから）プロダクトや事業のKPIに、DPの改善指標が直結するようになっているか？ If 改善は積み重ねられ、成果も出るが価値を周囲に伝えきれない可能性本人も事業も納得感高本質的改善に集中技術力がプロダクトと事業に直結 Not Then Then

Slide 46

Slide 46 text

Developer Productivityに必要な心持ち ‣ エンドユーザーやプロダクト、事業との距離を縮めて、本質的な改善が何かを見定めよう ‣ チームから期待してもらえて、わかりやすいDPの目標やKPIを設定しよう ‣ 技術力はこれまでと変わらず、磨こう

Slide 47

Slide 47 text

Thanks✋