事業部を超えた開発生産性向上に挑戦する

Slide 1

Slide 1 text

事業部を超えた開発生産性向上に挑戦する小塚健太

Slide 2

Slide 2 text

● 小塚健太 ● 2018年中途入社 ● Developer Productivity室室長 ● DP室←ABEMA←SIer ● バックエンドエンジニア

Slide 3

Slide 3 text

今日話すこと 1. 全社での取り組み 2. DP室で注力していること 3. 開発生産性向上の文化を作る

Slide 4

Slide 4 text

CyberAgentにおけるエンジニア組織と文化

Slide 5

Slide 5 text

拡大するエンジニア組織 https://www.cyberagent.co.jp/ir/growth/

Slide 6

Slide 6 text

https://www.cyberagent.co.jp/ir/growth/

Slide 7

Slide 7 text

https://www.cyberagent.co.jp/ir/growth/

Slide 8

Slide 8 text

エンジニア組織の文化 ● 多種多様なドメインでの事業展開 ● 複雑な組織図 ● 成長を続ける組織 → 各チームへ「自由と裁量」が与えられている

Slide 9

Slide 9 text

「自由と裁量」がもたらすもの Pros - 事業の高速な立ち上げ - ドメインに特化した技術選定 - 迅速な意思決定 - 個人の能力の最大化 - チャレンジのし易さ Cons - 複数組織での車輪の再発明 - スキルやノウハウの分散 - 開発力がチーム戦力に依存 - 中長期で技術資産を育てられない

Slide 10

Slide 10 text

品質の高さとスケールメリットの低さ自由と裁量に裏打ちされた品質の高いプロダクト開発優れた技術の共有組織的な開発手法のアップデートの遅れ強み弱み競合のアウトプットの品質が追いついてくれば、私たちの開発上の競争力は相対的に下がっていく

Slide 11

Slide 11 text

事業開発に求められる変化 Domain Knowledge Growth Domain Knowledge Test / Veriﬁcation Delivery Design Code Test / Veriﬁcation Delivery Growth Design Code インターネット（と世界）を取り巻く不確実な情勢の中でいかに本質にコミットし続けられるか？

Slide 12

Slide 12 text

「つくる技術から、つくり育てる技術へ」個人の優れたスキルを再現性のある技術に育て共有し組織やチームのミッション実現にインパクトを出せるようになる個人エンジニアリング、デザインマネジメントなど、あらゆる方法論組織で技術を育て、圧倒的な精度と物量で試行錯誤を実現できる組織になる組織これまでの強みを活かしつつも、改めて組織の大きさをレバレッジとしたスケールメリットの両立が必要 →事業部を超えて全社単位での開発生産性へのコミットが必要 DP室の組織化、全社PJの発足

Slide 13

Slide 13 text

開発生産性をどうやって評価するか

Slide 14

Slide 14 text

開発生産性を可視化する理由 DP室が開発するのは、あくまで「方法論」である。方法論を効率的に定着させるための手段として、既存のツールを活用したり新たにプロダクトを開発する ● 「今いる場所」を知る ○ 理想との乖離を知る ○ （もしかしたら改善は必要ないかもしれない） ● 「どこが問題」かを知る ○ 伸びしろがある場所に注力する ○ （改善すべきはエンジニアリングではないかもしれない） ● 「改善を評価」する ○ 打った施策は正しかったのか ○ どのように改善すべきなのか

Slide 15

Slide 15 text

開発生産性を向上させるための全社横断プロジェクトの発足 DP室メンバーもボードメンバーとして参加・組織拡大と共に開発生産性を向上する・生産性を可視化するだけでは弱い・みんなの意識自体を変えたい開発生産性向上を文化として根付かせ事業競争力に繋げる目的・ゴール

Slide 16

Slide 16 text

持続可能な可視化方法を提供する DP室が開発するのは、あくまで「方法論」である。方法論を効率的に定着させるための手段として、既存のツールを活用したり新たにプロダクトを開発する ● 改善には継続的に指標を追っていく必要がある ● 可視化方法 ○ 認知があり納得感のあるもの ○ 属人化しない ● すべてを満たす可視化方法はない

Slide 17

Slide 17 text

生産性がもたらす事業への付加価値は何か？ ● 期待する施策のリリース数の向上や、リードタイムの短縮　 ● 工数、コスト削減による収益構造の改善 ● システムの品質や安定性向上 → ダウンタイムの減少により発生しうる売上事業ドメインを問わない、普遍的な事業競争力 DevOpsを中心とした生産性向上活動を主なスコープに据える ※「DevOpsの改善活動を優先しましょう」というわけではありません事業によっては他の重要な生産性向上施策もあるはずです

Slide 18

Slide 18 text

定量的評価と定性的評価 ● Four Keysだけ追いかけると、KPIハックや定量評価の罠に陥りがち ○ 数字は出ても、エンジニアの生産性の体感と、事業側の満足に直結しないかもしれない ○ 事業コンテキストにも依存する ○ アクティビティデータだけでは生産性を評価してはいけないということ ● アクティビティだけではなく、多面的な生産性評価が提唱され始めた ○ e.g. SPACEフレームワーク ■ 定量的なアクティビティや、アンケート等の定性的な指標から多面的に生産性を評価するためのフレームワーク ○ 現場エンジニアの納得度を上げるためにも多面的な評価が必要 ○ 定性評価もあると、DevOpsの推進役や事業にとっても目標を立てやすい → 定量と定性をセットにした独自評価指標

Slide 19

Slide 19 text

独自のケイパビリティ評価シート four keysとDevOpsの能力をベースに、独自評価指標を作成半年に１度計測 Ver.2では生成AIの活用度などを追加

Slide 20

Slide 20 text

より詳細な定量的測定をサポート 4つの指標を計測するための計測基盤元々DP室でdora-team/fourkeysをfork（＆魔改造）して、社内で提供 →カスタマイズのコスト増加、組織横断で運用するにはもう少し作り込みが必要

Slide 21

Slide 21 text

外部ソリューションの導入複数のソリューションを比較検討した結果、Findy Team+を社内で導入していく方針に少数のPJからスモールスタート

Slide 22

Slide 22 text

Developer Productivity室が注力していること

Slide 23

Slide 23 text

ソフトウェアデリバリのパフォーマンスは組織全体の業績に重要な影響を及ぼす (LeanとDevOpsの科学より）

Slide 24

Slide 24 text

今求められる、アジリティの高い開発チームとは？事業にいる開発者が、本質的な開発だけに集中できており、不確実性の高いサービス開発を素早く行い、賢く失敗して軌道修正できる事業が強いソフトウェアデリバリを横断で高めるための専門部署として、 Developer Productivity室を設立

Slide 25

Slide 25 text

リードタイム短縮のための中核プロダクト継続的デリバリーシステム ● GitOpsスタイルのProgressive Delivery ● k8s, ECS, Terraform等に対応フィーチャーフラグ、ABテストシステム ● トランクベース開発の実現 ● 限定的なリリース ● 優れた分析や実験機能

Slide 26

Slide 26 text

Bucketeerが提供するプラクティス ● Trunk Based Development ● 本番環境でのQA作業 ● ダークローンチ ● 段階的ロールアウト ● 自動ロールバック ● ABテスト

Slide 27

Slide 27 text

PipeCDが提供するプラクティス ● GitOps ● 異なるプラットフォームで統一したUX ● Canary/Blue Green Deployment ● Progressive Delivery ○ 段階的ロールアウト ○ 分析 ○ 自動ロールバック ● シークレット管理

Slide 28

Slide 28 text

「プラクティス」を提供する DP室が開発するのは、あくまで「方法論」である。方法論を効率的に定着させるための手段として、既存のツールを活用したり新たにプロダクトを開発する ● DP室の目標は開発生産性を高めることでの事業貢献 ● プロダクト開発はベストプラクティスを提供する手段であって目的ではない ● より良い方法があれば開発にはこだわらない

Slide 29

Slide 29 text

「プラクティス」を提供する生産性を高められるのであれば、既存ツールを検証・導入する

Slide 30

Slide 30 text

開発生産性の文化を醸成する

Slide 31

Slide 31 text

可視化の先の難しさ Four Keysで可視化したのは良いが、これをどう使うべきか。 DevOpsへの投資インパクトをわかりやすく説明できないか？精度はともかく、かいはつ速度向上がもたらすコスト削減や、付加価値を概算して示すのも方法のひとつ

Slide 32

Slide 32 text

開発速度向上の成果を数値化不要な作業削減で得られる価値新しい機能へ再投資することで得られる価値ダウンタイムの回避によるコスト削減 https://cloud.google.com/blog/ja/products/application-development/show-me-the-money-how-you-can-see-returns-up-to-259 m-with-a-devops-transformation Amazonのような小売業でもよく使われている算出手法 CAにおいてもプロダクトの稼働率が広告や課金収入にリンクする

Slide 33

Slide 33 text

組織として上を狙ったときにどれだけのインパクトが出るか lowやmediumからhigh, eliteになるための投資をした場合、かいはつ速度への投資で売上や利益に影響を及ぼしうるかを示すのも、納得を得るための一つの手法

Slide 34

Slide 34 text

経営サイドに開発生産性へのコミットを理解してもらう

Slide 35

Slide 35 text

継続的な可視化と改善が必要 ● DevOpsを軸に開発組織パフォーマンスを改善していくことが重要 ● 一過性の取り組みではなく、定量・定性評価による評価と継続的な改善を ● 生産性の課題や未知の脅威に直面する前に組織パフォーマンスに向き合う文化を指標の評価生産性指標の測定生産性向上のアクション文化の形成事業競争力

Slide 36

Slide 36 text

各事業部によって課題はそれぞれ Aチームリードタイムを改善したい Bチーム QAの時間と工数がかかりすぎている Cチームドキュメントが散り散りになっていて、学習コストが高い適切な粒度で各チームの課題を解釈して、インパクトが大きい解決方法を見つける

Slide 37

Slide 37 text

開発生産性にコミットしてくれるキーマンを見つける ● 継続的な改善の文化には熱量が大事 ● 各事業部でキーマンを見つける ● キーマン同士の横のつながりを強化しながら文化をつくっていく

Slide 38

Slide 38 text

プロダクトの認知を高める

Slide 39

Slide 39 text

OSSの健全なライフサイクルを確立し、開発資源を最大化する ● 社内支援だけであれば、ユーザーも限られてしまうし、良い意味でも悪い意味でも妥協ができてしまう ● OSSとして成立させ、市場から多くのフィードバック・コントリビュートを得てプロダクトを高いレベルで成熟させたい社内成果事例創出コミュニティ活性化市場拡大化 ■OSS公開 ■ベストプラクティスの啓蒙 ■カンファレンス発表 ■CNCF等参加での知名度・信頼性獲得 ■社外の利用・事例が増える ■個人or企業コントリビューター獲得 ■採用チャンス増 ■社外コンサル活動 ■社内要望サポート ■プロダクトグロース ■社内Enablingチーム活動

Slide 40

Slide 40 text

公式サイト、勉強会、登壇、ブログ

Slide 41

Slide 41 text

● 開発生産性向上は測定から ● 測定 → 評価 → アクションのサイクルを回す ● 測定は共通化できる部分もあるが、アクションは同一ではない場合も多い ● 改善にはビジネスサイドを含めた文化を育てることが必要 ● Developer Productiviyエンジニアには説明責任がある ● DP室はCAの開発生産性を向上する組織 ● DP室の目標は事業貢献、プロダクトに固執しないまとめ

Slide 42

Slide 42 text

ありがとうございました🙇 We’re hiring! https://site.developerproductivity.dev/jobs/