Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

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

stormcat24

July 30, 2021
Tweet

More Decks by stormcat24

Other Decks in Programming

Transcript

  1. 素早く賢く失敗する


    Developer Productivityの実現を目指して
    2021/07/30


    Akinori Yamada (@stormcat24)


    CyberAgent, Inc

    View full-size slide

  2. Whois
    ‣ Akinori Yamada


    ‣ CyberAgent (2012.10〜)


    ‣ Developer Productivity室 室長


    ‣ 日本コンテナビルド組合(日コン組)組合員
    stormcat24

    View full-size slide

  3. Agenda
    ‣ CyberAgentについて


    ‣ CyberAgentのエンジニア文化


    ‣ MEDIA TECH VISION 2020-2023


    ‣ Developer Productivityの注力と取り組み


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

    View full-size slide

  4. CyberAgentについて

    View full-size slide

  5. 社名     株式会社サイバーエージェント CyberAgent, Inc.


    本社所在地  〒150-0042 


           東京都渋谷区宇田川町40番1号 Abema Towers


    代表者    代表取締役社長 藤田 晋


    設立     1998年3月18日


    資本金    7,203百万円(2019年9月末現在)


    事業内容   メディア事業


           インターネット広告事業


           ゲーム事業


           投資育成事業


    会社概要

    View full-size slide

  6. CyberAgentのエンジニア文化

    View full-size slide

  7. 自由と裁量

    View full-size slide

  8. Media
    Internet


    AD
    Game Startup AI DX
    CyberAgent Group
    多様な


    事業ドメイン
    多くの


    グループ会社


    や事業部
    たくさんの


    プロダクト
    インターネットに連動する領域にはすぐ参入していくスタイル。


    技術的意思決定は各管轄や事業部、グループ会社、プロダクトに任せられている。

    View full-size slide

  9. 自由と裁量が組織にもたらすもの
    ‣ 事業の高速な立ち上げ


    ‣ 迅速な意思決定


    ‣ 個人の能力の最大化


    ‣ 技術者としてのチャレンジのしやすさ
    Pros Cons
    ‣ 複数組織での車輪の再発明


    ‣ スキルやノウハウの分散


    ‣ 開発力がチーム戦力に依存


    ‣ 中長期で育てきれない技術資産
    組織的な開発手法のアップデートの遅れ
    品質の高いプロダクトの創出

    View full-size slide

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

    View full-size slide

  11. 組織的な開発手法の


    アップデートの遅れ
    これに向き合わないと、


    我々の開発力は相対的に下がっていくはず


    より組織的な取り組みが必要不可欠に

    View full-size slide

  12. 中長期での指針が必要
    まずはそれぞれの管轄別に技術指針(TECH VISION)を制定


    今日はメディアでの指針 MEDIA TECH VISIONについて
    メディア 広告/AI ゲーム

    View full-size slide

  13. MEDIA TECH VISION


    2020-2023

    View full-size slide

  14. MEDIA TECH VISION 2020-2023
    ‣ 今後3年を見越しての基本指針や、中長期のプロダクト開発・技術の戦略
    をTECH VISIONとして発表


    ‣ 技術者はもちろん、非技術者(役員や事業責任者も含む)に向けて大々的
    に発表会を実施し、組織としての意思統一を図る

    View full-size slide

  15. つくる技術から、


    つくり育てる技術へ

    View full-size slide

  16. 不確実性の高いサービス開発
    ミッション 市場環境
    21世紀を代表するサービスを創り


    中長期の柱に育て上げる
    不確実性が高く、市場ニーズや


    技術構造の変化が読めない
    試行錯誤の精度と物量によって、


    何とかして成功するカタチを探り当てるような戦いを強いられる

    View full-size slide

  17. 個人の優れたスキルを


    再現性のある技術に育て共有し


    組織やチームのミッション実現に


    インパクトを出せるようにする
    エンジニアリング、デザイン


    マネジメントなど、あらゆる方法論


    組織で技術を育て、圧倒的な精度と物量で


    試行錯誤を実現できる組織になる
    個人 組織
    これまでの強みと、組織の大きさをレバレッジとした


    スケールメリットの両立が必要

    View full-size slide

  18. プロダクト開発とどう向き合うか
    ‣ 一見して良いものを作れるだけで終わってしまっていないか


    ‣ その先の価値提供や自身のキャリアと向き合えているのか


    ‣ 価値の定義が変化する中で、事業としても個人としても求められるのは何か


    ‣ 我々は「つくる」ことを通してどのようなインパクトを生み出すのか


    ‣ 技術、品質、数字、ユーザー、組織... 自身は何と向き合って価値を創るのか


    ‣ ひとりひとりが自らの事業貢献を自認できるようにするには?
    「つくる」だけの閉塞感からの脱却、「つくった先」の新たな価値の創出

    View full-size slide

  19. 指針の元に育てていく領域
    仮説と検証 データ活用
    Developer


    Productivity
    組織に合った実践方法を模索し


    成果に繋げていく
    メディア内にあった技術の芽のキュレーション 全体で取り組むことでスケールメリットに

    View full-size slide

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

    View full-size slide

  21. Developer Productivityへの


    注力と取り組み

    View full-size slide

  22. Developer Productivity
    開発者の生産性

    View full-size slide

  23. 広義で生産性に寄与すると思われるもの
    ‣ サクサク動くPCや高機能なサーバ


    ‣ 言語、フレームワーク


    ‣ 高速でスケールするCI、CD環境


    ‣ 市場に存在するSaaSや社内基盤


    ‣ 優れたオンボーディング


    ‣ 情報やノウハウの流動性
    技術・組織・人・モノ・金といった


    様々な観点で、腐るほど存在する😇

    View full-size slide

  24. 何に注力すべきか?
    自動化が未成熟
    If CI/CD環境の整備
    リリース後の事故が多い
    If フィーチャーフラグの定着


    エラーレートでの自動ロールバック
    スケールする組織
    If レガシーシステムの断捨離


    マイクロサービス
    QAリソースが多い
    If 自動テストツールの導入と定着
    改善活動の理解が


    得られてない
    If 生産性改善のROIの提示


    継続的な改善の指標づくり
    組織によって、何を選択すべきかは当然異なる。


    事業やプロダクトの競争力強化に繋がる本質的なものを選択すべき。
    Then
    Then
    Then
    Then
    Then

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  27. 手段からではなく、事業やユーザー目線で考える
    ‣ ユーザーに機能や改善を素早く、かつ高頻度で届けられているか?


    ‣ 事業をグロースさせるための本質開発に注力できているか?


    ‣ 品質や安定性を担保するための仕組みが整備されているか?
    ユーザー価値・事業+プロダクトグロースの上流からDPを考える


    View full-size slide

  28. CA メディア管轄における課題
    メディア開発は特に不確実性が強いので、


    素早く一つでも多くの機能を届け、もっと賢く失敗していきたい

    View full-size slide

  29. 仮説検証する仕組み
    賢く失敗するために越えるべき課題
    ビッグバン


    リリースの不安
    テストやQAに


    要する時間
    もっと安全に


    素早くリリース


    したい
    障害時の


    リリース切り戻し
    ‣ 賢く失敗するには設計・実装フェーズ
    よりも、ソフトウェアのリリースサイ
    クルを組織として強化すべきと判断


    ‣ アーキテクチャ、言語、インフラスト
    ラクチャ等は引き続き自由と裁量で

    View full-size slide

  30. メディア管轄として目指す、DPの理想状態
    開発者と事業がスケールし続けるための


    高い生産性と品質を生み出す原動力を育てる
    Vision
    推進部隊としてDeveloper Productivity室(DP室)を設立

    View full-size slide

  31. 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を編成


    ‣ サードパーティー活用、独自ツール開発等手段に拘らずに、組織にフィッ
    トするベストプラクティスを考案し、定着させていく

    View full-size slide

  32. sig-experimentation提供のプラクティス
    ‣ Trunk Based Development


    ‣ 本番環境でのQA作業 (Dark Launch)


    ‣ 実験のメトリクス収集、評価


    ‣ ガードレール指標の定義


    ‣ 閾値設定、自動ロールバック
    フィーチャーフラグ・ABテストプラットフォーム


    元々はABEMA基盤チームが開発し、


    DP室が引き続き社内への開発・展開を行っている


    Optimizely, LaunchDarklyといった競合比で


    かなり安価で提供できることもあり、


    自社開発している

    View full-size slide

  33. 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

    View full-size slide

  34. sig-client提供のプラクティス
    ‣ 画像回帰テスト(VRT)


    ‣ 複数デバイステスト


    ‣ アクセシビリティテスト

    View full-size slide

  35. 開発者マーケティングの強化
    ‣ プロダクトやベストプラクティスを
    つくるだけではなく、効果的に使っ
    てもらう取り組みが必要不可欠


    ‣ ドキュメント、ブログ、クイックス
    タート、デモ、トライアル機能等の
    ユーザーが能動的にプロダクトを体
    験してもらう仕組みを充実

    View full-size slide

  36. DPの改善をどう評価するか?
    DP習熟度チェック


    (定性的)
    DORA


    (定量的)

    View full-size slide

  37. 習熟度チェック
    ‣ 3つのsigにおける、各プロジェクトの習熟度チェックを実施


    ‣ 現状把握、プラクティスの認識、今後の戦略・意思決定に活用

    View full-size slide

  38. DORA
    ‣ DevOps Research and Assessment


    ‣ デプロイ頻度やリードタイム、MTTR
    等で組織のパフォーマンスを測り、上
    を目指していく


    ‣ 段階的に各事業への導入を準備中


    ‣ 技術者が常にわかりやすい指標を持っ
    て改善を続けていくことが重要

    View full-size slide

  39. 技術者本位の改善に留まらないようにするには
    DP習熟度チェック


    (定性的)
    DORA


    (定量的)
    どちらかというと


    技術者寄りの指標
    技術者以外の観点で、開発がどう良くなるのか?


    自分たちのビジネスにポジティブに影響することは何か?について


    技術者=事業間でDPについて共通の課題・目標認識、合意形成をできるようにする。


    事業やプロダクトに大きくヒットし、非技術者が大きく期待してくれる内容を意識する。
    定性的 開発プロセス
    定量的
    人員
    施策リリース回数
    改善前 改善後
    リリースした機能の


    効果検証が不十分
    10名
    2回/月
    5名
    10回/月
    効果検証が用意に行える


    柔軟にON/OFFが可能になる

    View full-size slide

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

    View full-size slide

  41. Developer Productivityに取り組む


    エンジニアのこれから

    View full-size slide

  42. DP改善マンと事業との微妙な距離感
    エンドユーザー
    ユーザー企業
    プロダクト
    経営層
    ビジネス職
    クリエイター
    プロダクト開発
    付加価値
    DP改善
    サポート
    事業やプロダクトは、よくわからない


    技術力でプロダクト開発を


    サポートして貢献するぞ
    プロダクト開発マンは色々機能を作ってくれてる。


    DP改善マンは貢献してくれてるようだけど


    どのように評価すれば良いのだろう?
    プロダクトや事業に対して、DP改善の貢献度合いが見えにくい


    もしくは伝えきれていないケースがよくある
    DP改善マンは


    よくやってくれてるよ

    View full-size slide

  43. ひとりひとりが自らの事業貢献を自認できるようにするには?
    技術者への問いの1つ(MEDIA TECH VISIONから)
    プロダクトや事業のKPIに、DPの改善指標が直結するようになっているか?
    If
    改善は積み重ねられ、成果も出るが


    価値を周囲に伝えきれない可能性
    本人も事業も納得感高


    本質的改善に集中


    技術力がプロダクトと事業に直結
    Not Then Then

    View full-size slide

  44. Developer Productivityに必要な心持ち
    ‣ エンドユーザーやプロダクト、事業との距離を縮めて、本質的な改善が何
    かを見定めよう


    ‣ チームから期待してもらえて、わかりやすいDPの目標やKPIを設定しよう


    ‣ 技術力はこれまでと変わらず、磨こう

    View full-size slide