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

Developers Summit 2021 Summer #devsumi #devsumiC
https://event.shoeisha.jp/devsumi/20210730/session/3241/

Transcript

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