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

Transcript

1. 事業部を超えた 開発生産性向上に挑戦する 小塚健太
2. • 小塚健太 • 2018年中途入社 • Developer Productivity室 室長 • DP室←ABEMA←SIer • バックエンドエンジニア
3. 今日話すこと 1. 全社での取り組み 2. DP室で注力していること 3. 開発生産性向上の文化を作る
4. CyberAgentにおける エンジニア組織と文化
5. 拡大するエンジニア組織 https://www.cyberagent.co.jp/ir/growth/
6. https://www.cyberagent.co.jp/ir/growth/
7. https://www.cyberagent.co.jp/ir/growth/
8. エンジニア組織の文化 • 多種多様なドメインでの事業展開 • 複雑な組織図 • 成長を続ける組織 → 各チームへ「自由と裁量」が与えられている
9. 「自由と裁量」がもたらすもの Pros - 事業の高速な立ち上げ - ドメインに特化した技術選定 - 迅速な意思決定 - 個人の能力の最大化 - チャレンジのし易さ Cons - 複数組織での車輪の再発明 - スキルやノウハウの分散 - 開発力がチーム戦力に依存 - 中長期で技術資産を育てられない
10. 品質の高さとスケールメリットの低さ 自由と裁量に裏打ちされた 品質の高いプロダクト開発 優れた技術の共有 組織的な開発手法のアップデートの遅れ 強み 弱み 競合のアウトプットの品質が追いついてくれば、 私たちの開発上の競争力は相対的に下がっていく
11. 事業開発に求められる変化 Domain Knowledge Growth Domain Knowledge Test / Verification Delivery Design Code Test / Verification Delivery Growth Design Code インターネット（と世界）を取り巻く不確実な情勢の中で いかに本質にコミットし続けられるか？
12. 「つくる技術から、つくり育てる技術へ」 個人の優れたスキルを 再現性のある技術に育て共有し 組織やチームのミッション実現に インパクトを出せるようになる 個人 エンジニアリング、デザイン マネジメントなど、あらゆる方法論 組織で技術を育て、圧倒的な精度と物量で 試行錯誤を実現できる組織になる 組織 これまでの強みを活かしつつも、 改めて組織の大きさをレバレッジとしたスケールメリットの両立が必要 →事業部を超えて全社単位での開発生産性へのコミットが必要 DP室の組織化、全社PJの発足
13. 開発生産性をどうやって評価するか
14. 開発生産性を可視化する理由 DP室が開発するのは、あくまで「方法論」である。 方法論を効率的に定着させるための手段として、既存のツールを活用したり 新たにプロダクトを開発する • 「今いる場所」を知る ◦ 理想との乖離を知る ◦ （もしかしたら改善は必要ないかもしれない） • 「どこが問題」かを知る ◦ 伸びしろがある場所に注力する ◦ （改善すべきはエンジニアリングではないかもしれない） • 「改善を評価」する ◦ 打った施策は正しかったのか ◦ どのように改善すべきなのか
15. 開発生産性を向上させるための全社横断プロジェクトの発足 DP室メンバーもボードメンバーとして参加 ・組織拡大と共に開発生産性を向上する ・生産性を可視化するだけでは弱い ・みんなの意識自体を変えたい 開発生産性向上を文化として根付かせ 事業競争力に繋げる 目的・ゴール
16. 持続可能な可視化方法を提供する DP室が開発するのは、あくまで「方法論」である。 方法論を効率的に定着させるための手段として、既存のツールを活用したり 新たにプロダクトを開発する • 改善には継続的に指標を追っていく必要がある • 可視化方法 ◦ 認知があり納得感のあるもの ◦ 属人化しない • すべてを満たす可視化方法はない
17. 生産性がもたらす事業への付加価値は何か？ • 期待する施策のリリース数の向上や、リードタイムの短縮　 • 工数、コスト削減による収益構造の改善 • システムの品質や安定性向上 → ダウンタイムの減少により発生しうる売上 事業ドメインを問わない、普遍的な事業競争力 DevOpsを中心とした 生産性向上活動を主なスコープに据える ※「DevOpsの改善活動を優先しましょう」というわけではありません 事業によっては他の重要な生産性向上施策もあるはずです
18. 定量的評価と定性的評価 • Four Keysだけ追いかけると、KPIハックや定量評価の罠に陥りがち ◦ 数字は出ても、エンジニアの生産性の体感と、事業側の満足に直結しないかもしれない ◦ 事業コンテキストにも依存する ◦ アクティビティデータだけでは生産性を評価してはいけないということ • アクティビティだけではなく、多面的な生産性評価が提唱され始めた ◦ e.g. SPACEフレームワーク ▪ 定量的なアクティビティや、アンケート等の定性的な指標から多面的に生産性を評価す るためのフレームワーク ◦ 現場エンジニアの納得度を上げるためにも多面的な評価が必要 ◦ 定性評価もあると、DevOpsの推進役や事業にとっても目標を立てやすい → 定量と定性をセットにした独自評価指標
19. 独自のケイパビリティ評価シート four keysとDevOpsの能力をベースに、 独自評価指標を作成 半年に１度計測 Ver.2では生成AIの活用度などを追加
20. より詳細な定量的測定をサポート 4つの指標を計測するための計測基盤 元々DP室でdora-team/fourkeysをfork（＆魔改造）して、社内で提供 →カスタマイズのコスト増加、組織横断で運用するにはもう少し作り込みが必要
21. 外部ソリューションの導入 複数のソリューションを比較検討した結果、Findy Team+を社内で導入していく方針に 少数のPJからスモールスタート
22. Developer Productivity室が 注力していること
23. ソフトウェアデリバリのパ フォーマンスは 組織全体の業績に重要な 影響を及ぼす (LeanとDevOpsの科学より）
24. 今求められる、アジリティの高い開発チームとは？ 事業にいる開発者が、本質的な開発だけに集中できており、 不確実性の高いサービス開発を素早く行い、賢く失敗して軌道修正できる事業が強い ソフトウェアデリバリを横断で高めるための専門部署として、 Developer Productivity室を設立
25. リードタイム短縮のための中核プロダクト 継続的デリバリーシステム • GitOpsスタイルのProgressive Delivery • k8s, ECS, Terraform等に対応 フィーチャーフラグ、ABテストシステム • トランクベース開発の実現 • 限定的なリリース • 優れた分析や実験機能
26. Bucketeerが提供するプラクティス • Trunk Based Development • 本番環境でのQA作業 • ダークローンチ • 段階的ロールアウト • 自動ロールバック • ABテスト
27. PipeCDが提供するプラクティス • GitOps • 異なるプラットフォームで統一したUX • Canary/Blue Green Deployment • Progressive Delivery ◦ 段階的ロールアウト ◦ 分析 ◦ 自動ロールバック • シークレット管理
28. 「プラクティス」を提供する DP室が開発するのは、あくまで「方法論」である。 方法論を効率的に定着させるための手段として、既存のツールを活用したり 新たにプロダクトを開発する • DP室の目標は開発生産性を高めることでの事業貢献 • プロダクト開発はベストプラクティスを提供する手段であって目的で はない • より良い方法があれば開発にはこだわらない
29. 「プラクティス」を提供する 生産性を高められるのであれば、既存ツールを検証・導入する
30. 開発生産性の文化を醸成する
31. 可視化の先の難しさ Four Keysで可視化したのは良いが、これをどう使うべきか。 DevOpsへの投資インパクトをわかりやすく説明できないか？ 精度はともかく、かいはつ速度向上がもたらすコスト削減や、 付加価値を概算して示すのも方法のひとつ
32. 開発速度向上の成果を数値化 不要な作業削減で 得られる価値 新しい機能へ再投資する ことで得られる価値 ダウンタイムの回避によ るコスト削減 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においてもプロダクトの稼働率が広告や課金収入にリンクする
33. 組織として上を狙ったときにどれだけのインパクトが出るか lowやmediumからhigh, eliteになるための投資をした場合、 かいはつ速度への投資で売上や利益に影響を及ぼしうるかを 示すのも、納得を得るための一つの手法
34. 経営サイドに開発生産性へのコミットを理解してもらう
35. 継続的な可視化と改善が必要 • DevOpsを軸に開発組織パフォーマンスを改善していくことが重要 • 一過性の取り組みではなく、定量・定性評価による評価と継続的な改善を • 生産性の課題や未知の脅威に直面する前に組織パフォーマンスに向き合う文化を 指標の評価 生産性指標 の測定 生産性向上 のアクション 文化の形成 事業競争力
36. 各事業部によって課題はそれぞれ Aチーム リードタイムを改善したい Bチーム QAの時間と工数がかかりすぎている Cチーム ドキュメントが散り散りになっていて、学習コストが高い 適切な粒度で各チームの課題を解釈して、 インパクトが大きい解決方法を見つける
37. 開発生産性にコミットしてくれるキーマンを見つける • 継続的な改善の文化には熱量が大事 • 各事業部でキーマンを見つける • キーマン同士の横のつながりを強化しながら文化をつくっていく
38. プロダクトの認知を高める
39. OSSの健全なライフサイクルを確立し、開発資源を最大化する • 社内支援だけであれば、ユーザーも限られてしまうし、良い意味でも悪い意味でも妥協ができてしまう • OSSとして成立させ、市場から多くのフィードバック・コントリビュートを得てプロダクトを高いレベル で成熟させたい 社内成果 事例創出 コミュニティ 活性化 市場 拡大化 ▪OSS公開 ▪ベストプラクティスの啓蒙 ▪カンファレンス発表 ▪CNCF等参加での知名度・信頼性獲得 ▪社外の利用・事例が増える ▪個人or企業コントリビューター獲得 ▪採用チャンス増 ▪社外コンサル活動 ▪社内要望サポート ▪プロダクトグロース ▪社内Enablingチーム活動
40. 公式サイト、勉強会、登壇、ブログ
41. • 開発生産性向上は測定から • 測定 → 評価 → アクションのサイクルを回す • 測定は共通化できる部分もあるが、アクションは同一ではない場合も多い • 改善にはビジネスサイドを含めた文化を育てることが必要 • Developer Productiviyエンジニアには説明責任がある • DP室はCAの開発生産性を向上する組織 • DP室の目標は事業貢献、プロダクトに固執しない まとめ
42. ありがとうございました🙇 We’re hiring! https://site.developerproductivity.dev/jobs/