Developers Summit 2021 Summer #devsumi #devsumiC https://event.shoeisha.jp/devsumi/20210730/session/3241/
素早く賢く失敗するDeveloper Productivityの実現を目指して2021/07/30Akinori Yamada (@stormcat24)CyberAgent, Inc
View Slide
Whois‣ Akinori Yamada‣ CyberAgent (2012.10〜)‣ Developer Productivity室 室長‣ 日本コンテナビルド組合（日コン組）組合員stormcat24
Agenda‣ CyberAgentについて‣ CyberAgentのエンジニア文化‣ MEDIA TECH VISION 2020-2023‣ Developer Productivityの注力と取り組み‣ Developer Productivityに取り組むエンジニアのこれから
CyberAgentについて
社名 株式会社サイバーエージェント CyberAgent, Inc.本社所在地 〒150-0042 東京都渋谷区宇田川町40番1号 Abema Towers代表者 代表取締役社長 藤田 晋設立 1998年3月18日資本金 7,203百万円（2019年9月末現在）事業内容 メディア事業 インターネット広告事業 ゲーム事業 投資育成事業会社概要
+ウマ娘
CyberAgentのエンジニア文化
自由と裁量
MediaInternetADGame Startup AI DXCyberAgent Group多様な事業ドメイン多くのグループ会社や事業部たくさんのプロダクトインターネットに連動する領域にはすぐ参入していくスタイル。技術的意思決定は各管轄や事業部、グループ会社、プロダクトに任せられている。
自由と裁量が組織にもたらすもの‣ 事業の高速な立ち上げ‣ 迅速な意思決定‣ 個人の能力の最大化‣ 技術者としてのチャレンジのしやすさPros Cons‣ 複数組織での車輪の再発明‣ スキルやノウハウの分散‣ 開発力がチーム戦力に依存‣ 中長期で育てきれない技術資産組織的な開発手法のアップデートの遅れ品質の高いプロダクトの創出
拡大し続けるエンジニア組織連結従業員数 約5,000名 エンジニア人数 約1,000名
組織的な開発手法のアップデートの遅れこれに向き合わないと、我々の開発力は相対的に下がっていくはずより組織的な取り組みが必要不可欠に
中長期での指針が必要まずはそれぞれの管轄別に技術指針（TECH VISION）を制定今日はメディアでの指針 MEDIA TECH VISIONについてメディア 広告/AI ゲーム
MEDIA TECH VISION2020-2023
MEDIA TECH VISION 2020-2023‣ 今後3年を見越しての基本指針や、中長期のプロダクト開発・技術の戦略をTECH VISIONとして発表‣ 技術者はもちろん、非技術者（役員や事業責任者も含む）に向けて大々的に発表会を実施し、組織としての意思統一を図る
つくる技術から、つくり育てる技術へ
不確実性の高いサービス開発ミッション 市場環境21世紀を代表するサービスを創り中長期の柱に育て上げる不確実性が高く、市場ニーズや技術構造の変化が読めない試行錯誤の精度と物量によって、何とかして成功するカタチを探り当てるような戦いを強いられる
個人の優れたスキルを再現性のある技術に育て共有し組織やチームのミッション実現にインパクトを出せるようにするエンジニアリング、デザインマネジメントなど、あらゆる方法論組織で技術を育て、圧倒的な精度と物量で試行錯誤を実現できる組織になる個人 組織これまでの強みと、組織の大きさをレバレッジとしたスケールメリットの両立が必要
プロダクト開発とどう向き合うか‣ 一見して良いものを作れるだけで終わってしまっていないか‣ その先の価値提供や自身のキャリアと向き合えているのか‣ 価値の定義が変化する中で、事業としても個人としても求められるのは何か‣ 我々は「つくる」ことを通してどのようなインパクトを生み出すのか‣ 技術、品質、数字、ユーザー、組織... 自身は何と向き合って価値を創るのか‣ ひとりひとりが自らの事業貢献を自認できるようにするには？「つくる」だけの閉塞感からの脱却、「つくった先」の新たな価値の創出
指針の元に育てていく領域仮説と検証 データ活用DeveloperProductivity組織に合った実践方法を模索し成果に繋げていくメディア内にあった技術の芽のキュレーション 全体で取り組むことでスケールメリットに
TECH VISION実現の一輪として、Developer Productivity分野に注力
Developer Productivityへの注力と取り組み
Developer Productivity開発者の生産性
広義で生産性に寄与すると思われるもの‣ サクサク動くPCや高機能なサーバ‣ 言語、フレームワーク‣ 高速でスケールするCI、CD環境‣ 市場に存在するSaaSや社内基盤‣ 優れたオンボーディング‣ 情報やノウハウの流動性技術・組織・人・モノ・金といった様々な観点で、腐るほど存在する😇
何に注力すべきか？自動化が未成熟If CI/CD環境の整備リリース後の事故が多いIf フィーチャーフラグの定着エラーレートでの自動ロールバックスケールする組織If レガシーシステムの断捨離マイクロサービスQAリソースが多いIf 自動テストツールの導入と定着改善活動の理解が得られてないIf 生産性改善のROIの提示継続的な改善の指標づくり組織によって、何を選択すべきかは当然異なる。事業やプロダクトの競争力強化に繋がる本質的なものを選択すべき。ThenThenThenThenThen
参考）何が課題かよくわからない場合は？DX Criteriaと自らの組織の現状を照らし合わせてみるのも良い
改善のワナ技術者視点でDP改善と向き合うと、無限にネタが出てくるワナ共通化・抽象化！負債解消！E2Eテスト！UI自動テスト！テストケース自動生成！CI高速化！ フィーチャーフラグ！トランクベース開発！ GitOps! SSOT!マイクロサービス！型だ！型をくれ！Visual Regression Testing!クロスプラットフォーム！コンテナイメージダイエット！全てやった方が良さそうに見えてしまう
手段からではなく、事業やユーザー目線で考える‣ ユーザーに機能や改善を素早く、かつ高頻度で届けられているか？‣ 事業をグロースさせるための本質開発に注力できているか？‣ 品質や安定性を担保するための仕組みが整備されているか？ユーザー価値・事業+プロダクトグロースの上流からDPを考える
CA メディア管轄における課題メディア開発は特に不確実性が強いので、素早く一つでも多くの機能を届け、もっと賢く失敗していきたい
仮説検証する仕組み賢く失敗するために越えるべき課題ビッグバンリリースの不安テストやQAに要する時間もっと安全に素早くリリースしたい障害時のリリース切り戻し‣ 賢く失敗するには設計・実装フェーズよりも、ソフトウェアのリリースサイクルを組織として強化すべきと判断‣ アーキテクチャ、言語、インフラストラクチャ等は引き続き自由と裁量で
メディア管轄として目指す、DPの理想状態開発者と事業がスケールし続けるための高い生産性と品質を生み出す原動力を育てるVision推進部隊としてDeveloper Productivity室（DP室）を設立
3つのsigを編成sig-experimentation sig-buildsig = Special Interest Groupsig-clientFeature Flag ManagementTrunk Based DevelopmentA/B TestingContinuous IntegrationContinuous DeliveryGitOpsProgressive DeliveryComponent TestingUI Component CatalogVisual Regression TestingMulti Device TestingAccessibility Testing‣ それぞれの専門家別にsigを編成‣ サードパーティー活用、独自ツール開発等手段に拘らずに、組織にフィットするベストプラクティスを考案し、定着させていく
sig-experimentation提供のプラクティス‣ Trunk Based Development‣ 本番環境でのQA作業 (Dark Launch)‣ 実験のメトリクス収集、評価‣ ガードレール指標の定義‣ 閾値設定、自動ロールバックフィーチャーフラグ・ABテストプラットフォーム元々はABEMA基盤チームが開発し、DP室が引き続き社内への開発・展開を行っているOptimizely, LaunchDarklyといった競合比でかなり安価で提供できることもあり、自社開発している
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
sig-client提供のプラクティス‣ 画像回帰テスト(VRT)‣ 複数デバイステスト‣ アクセシビリティテスト
開発者マーケティングの強化‣ プロダクトやベストプラクティスをつくるだけではなく、効果的に使ってもらう取り組みが必要不可欠‣ ドキュメント、ブログ、クイックスタート、デモ、トライアル機能等のユーザーが能動的にプロダクトを体験してもらう仕組みを充実
DPの改善をどう評価するか？DP習熟度チェック（定性的）DORA（定量的）
習熟度チェック‣ 3つのsigにおける、各プロジェクトの習熟度チェックを実施‣ 現状把握、プラクティスの認識、今後の戦略・意思決定に活用
DORA‣ DevOps Research and Assessment‣ デプロイ頻度やリードタイム、MTTR等で組織のパフォーマンスを測り、上を目指していく‣ 段階的に各事業への導入を準備中‣ 技術者が常にわかりやすい指標を持って改善を続けていくことが重要
技術者本位の改善に留まらないようにするにはDP習熟度チェック（定性的）DORA（定量的）どちらかというと技術者寄りの指標技術者以外の観点で、開発がどう良くなるのか？自分たちのビジネスにポジティブに影響することは何か？について技術者=事業間でDPについて共通の課題・目標認識、合意形成をできるようにする。事業やプロダクトに大きくヒットし、非技術者が大きく期待してくれる内容を意識する。定性的 開発プロセス定量的人員施策リリース回数改善前 改善後リリースした機能の効果検証が不十分10名2回/月5名10回/月効果検証が用意に行える柔軟にON/OFFが可能になる
職種や領域を越えて、Developer Productivityに向き合うことが大切です
Developer Productivityに取り組むエンジニアのこれから
DP改善マンと事業との微妙な距離感エンドユーザーユーザー企業プロダクト経営層ビジネス職クリエイタープロダクト開発付加価値DP改善サポート事業やプロダクトは、よくわからない技術力でプロダクト開発をサポートして貢献するぞプロダクト開発マンは色々機能を作ってくれてる。DP改善マンは貢献してくれてるようだけどどのように評価すれば良いのだろう？プロダクトや事業に対して、DP改善の貢献度合いが見えにくいもしくは伝えきれていないケースがよくあるDP改善マンはよくやってくれてるよ
ひとりひとりが自らの事業貢献を自認できるようにするには？技術者への問いの1つ（MEDIA TECH VISIONから）プロダクトや事業のKPIに、DPの改善指標が直結するようになっているか？If改善は積み重ねられ、成果も出るが価値を周囲に伝えきれない可能性本人も事業も納得感高本質的改善に集中技術力がプロダクトと事業に直結Not Then Then
Developer Productivityに必要な心持ち‣ エンドユーザーやプロダクト、事業との距離を縮めて、本質的な改善が何かを見定めよう‣ チームから期待してもらえて、わかりやすいDPの目標やKPIを設定しよう‣ 技術力はこれまでと変わらず、磨こう
Thanks✋
stormcat24
prof18
yumakann
octu0
coe401_
ufoo68
mame
manfredsteyer
jmatsu
ledsun
munetoshi
hitokun
tomokusaba
orderedlist
hatefulcrawdad
philhawksworth
sachag
bluesmoon
michaelherold
geoffreycrofte
rasmusluckow
stephaniewalter
carmenintech
sstephenson
brianwarren