組織横断支援チームによるFour Keys計測基盤構築と活用に向けた取り組み

組織横断⽀援チームによるFour Keys計測基盤 構築と活⽤に向けた取り組み 開発⽣産性 Conference 2024 (2024/06/29) サイボウズ株式会社 ⽣産性向上チーム 三村 遼 (@r4mimu)

⾃⼰紹介 ▌Ryo Mimura @r4mimu ▌2022年 4⽉ サイボウズ株式会社 新卒⼊社 n 2022年 7⽉ ⽣産性向上チームジョイン n 社内向け CI/CD 基盤構築・運⽤ n Four Keys 計測基盤の構築・運⽤ n CI/CD 改善 ▌スライドのリンクを 𝕏 でポストしたので参照ください 2

• https://x.com/r4mimu
• https://speakerdeck.com/cybozuinsideout/engineering-productivity-team-recruitment-information

アジェンダ ▌会社と開発組織の紹介 ▌なぜ Four Keys を計測するか ▌Four Keys 計測基盤の構築 ▌Four Keys の活⽤状況 ▌今後の展望 3

会社と開発組織 4

サイボウズという会社 チームワークあふれる 社会を創る サイボウズの理念は「チームワークあふれる社会を創る」こと。 私たちはその理念に沿って世界で⼀番使われるソフトウェアを⽬指して 開発し続けてきました。 5

主⼒製品 開発の知識がなくても 業務に合わせたシステムを かんたんに作成できる クラウドサービス

主⼒製品 スケジュール共有 ワークフローなど 中⼩企業の情報共有を ⽀援するサービス

主⼒製品 管理者も現場も使いやすい 中⼤企業向けの 情報共有を ⽀援するサービス

サイボウズ株式会社 ▌『チームワークあふれる社会を創る』を理念として、チームワークを⽀える 情報共有ツールを提供 ▌1997年創業 n 当初はパッケージソフトウェア形式(いわゆるオンプレ)で製品を販売 n 2011年にリリースした SaaS 事業が現在の主⼒ ▌社員数 n 連結 1400 ⼈超 9

開発本部 ▌国内 300 名、海外 100 名 ▌プロダクト開発 n kintone, Garoon, Office, Mailwise … n Web, Mobile ▌組織横断技術⽀援 n フロントエンドエキスパート n ⽣産性向上 ▌AI, etc… 10

⽣産性向上チーム ▌組織横断⽀援チーム n 組織を横断した開発基盤の整備 n GitHub Actions self-hosted-runner 運⽤ ⽣産性向上チーム紹介スライド n 社内 ID で利⽤可能な AWS SSO 環境の提供 n Four Keys 計測基盤構築 n 開発基盤を活⽤した改善活動の⽀援 n ⽣産性向上技術のキャッチアップ・共有・発信 チームマスコット セイサンシャインくん 11

なぜ Four Keys を計測するか 12

事業構造と規模の変化 連結売上⾼推移(パッケージ/クラウド別) （百万円） 25,000 パッケージ他 クラウド 20,000 15,000 2011年 kintone リリース cybozu.com 開始 10,000 5,000 19 97 19 98 19 99 20 00 20 01 20 02 20 03 20 04 20 05 20 06 20 07 20 08 20 09 20 10 20 11 20 12 20 13 20 14 20 15 20 16 20 17 20 18 20 19 20 20 20 21 20 22 0 13

事業構造と規模の変化 ▌ユーザー数︓クラウド290万契約ユーザー ▌事業内容︓パッケージからクラウド (SaaS) へ ▌パートナー・エコシステム (API,プラグイン) の発展 ▌開発組織の拡⼤︓400名超 ▌プロダクトの機能数、コードの⾏数の増加 14

成⻑に伴う開発⽣産性の鈍化 ▌会社(プロダクト)の成⻑に⽐例してタスクが増⼤ n 問い合わせ、障害 n ライブラリ、インフラのアップデート ▌コミュニケーションパスの増加 n 割り込み依頼 n 依頼対応待ち ▌⼤規模コードベース n キャッチアップ・オンボーディング負荷 n 改善活動 15

パッケージとクラウドの混在 ▌クラウドを主⼒としているがパッケージも継続して提供中 ▌マルチプロダクトかつパッケージとクラウドが混在 n パッケージ製品・仕組みに依存 ▌⽉イチの定期メンテナンスでしかデプロイできない n 年間 20 デプロイを下回る 16

製品進化スピード10倍︕インパクト10倍︕ ▌2023年 開発本部の組織⽬標 n 10倍というのはストレッチな⽬標 ▌製品進化スピード n 検証・学習サイクルを⾼速に回すためのケイパビリティ n ⼿段、先⾏指標、アウトプット ▌インパクト n 事業、顧客、社会への影響 n ⽬的、結果指標、アウトカム 17

⾝軽になってインパクトを⽣み出す ▌スピードが10倍になってもインパクトは10倍にならない ▌が、スピードが出せないと⼤きなインパクトは⽣み出せない ▌インパクトを意識しながらスピードを上げていく 18

インパクトのためのケイパビリティ ▌インパクトを⾼めるためにスピードを上げる n 既存の施策の改善、新しい取り組みの試⾏回数を増やす n スピードを上げるためにケイパビリティモデルを利⽤ n ケイパビリティ向上 → 仮説検証のベロシティ≒アウトプット → インパクト≒アウトカム⤴ https://dora.dev/ より引⽤ 19

• https://dora.dev/research/
• https://dora.dev/

ケイパビリティ向上のために ▌Four Keys 指標がアウトカム増のためのベロシティ計測に合致という仮説 n ケイパビリティ改善 → ベロシティUP → アウトカム⤴ ▌『 Four Keys やっていき委員会』を発⾜ n ⽣産性向上チームが計測・可視化基盤を構築・提供 n 改善活動・事例の共有 n やっていき感を出す ▌既に把握できている負債の解消も⼤事 20

Four Keys 計測基盤の構築 21

開発体制の前提 ▌想定利⽤者は複数プロダクト・複数チームに渡る ▌コード管理は全社的に GitHub を利⽤ n GitHub.com, GitHub Enterprise Server(GHES) が混在 ▌タスク管理 n kintone, GitHub Project, Jira, Linear… ▌デプロイ n Web: kintone & 社内独⾃ツールで⾃社インフラ上にデプロイ n Mobile や⼀部プロダクト: Mobile プラットフォーム、AWS 22

Four Keys 基盤の選定 ▌SaaS(当時) n →社内ネットワーク内にある GHES や社内独⾃システムとの相性 △ ▌ゼロから⾃前で構築 n →要件に合わせられるが、ゼロから検討・実装するコストに⾒合う︖△ ▌OSS(dora-team/fourkeys) n リソースは IaC で定義されているのですぐに始められる n 要件に応じて改造可能 23

• https://github.com/dora-team/fourkeys

dora-team/fourkeys の利⽤ ▌Terraform で Google Cloud 上に環境作成 ▌可⽤性・拡張性にシビアな要件は無く、スモールスタートに必要⼗分 ▌データ加⼯や処理、ダッシュボード作成に集中できる 24

• https://github.com/dora-team/fourkeys

dora-team/fourkeys の利⽤ 1. GitHub Push,PR,Deployment イベントで Webhook が⾶ぶ 25

• https://github.com/dora-team/fourkeys

dora-team/fourkeys の利⽤ 2. イベントを受け、パースして BigQuery に保存 26

• https://github.com/dora-team/fourkeys

dora-team/fourkeys の利⽤ 3. BigQuery をデータソースに可視化 27

• https://github.com/dora-team/fourkeys

dora-team/fourkeys 利⽤の課題 ▌各データは SaaS の Webhook イベントに基づいて計算される n 我々の場合 GitHub の Webhook ▌Push, Commit はともかく、 チケット管理, デプロイ管理 は︖ n チケット管理︓各チームで利⽤ツールが異なる n デプロイ︓社内ツールを⽤いて⾃社インフラへデプロイ → 既存の開発プロセスでは チケットやデプロイ関連の計測ができない 28

• https://github.com/dora-team/fourkeys

複数チームからどうやってデータを収集する︖ ▌開発プラットフォーム・デプロイの仕組み変えてもらう︖ n 導⼊・キャッチアップのコスト多 n 開発⽣産性計測のためにコストを払うのは本末転倒 ▌計測基盤側が複数チームのツール・プラットフォーム・デプロイの 仕組みに対応する︖ n 開発チーム × 利⽤ツール・仕組み の数だけ対応 n 全て網羅しようとすると今後スケールしない 29

ヒアリングの実施 ▌利⽤者と基盤構築側が対応できる着地点を探る n プロトタイプと仮説を準備 ▌⽬的 n デプロイ、変更リードタイム、障害をどのように管理しているか n どのような基盤(API)ならデータを送りやすいか設計の参考に n 関係性の構築 n 同期的にコミュニケーションを取ることでやり取りしやすくなる 30

ヒアリングの実施 ▌オープンな場でヒアリングさせてくれるチームを募集 n こちらからお願いせず挙⼿制 n 6チームが名乗り出てくれた n 積極的なチームからは有益な意⾒がもらえる︖ n 押し付けず、伴⾛する 31

ヒアリング結果 ▌概ね 2 パターンのチーム ▌計測に前向きなチーム n いわゆるイノベーター・アーリーアダプターとなることを期待 ▌前向きではないチーム n 説得したり⾔いたいことはあるが、計測を強いずに⼀旦後回し ▌“最も関⼼を持ちイノベーティブなグループから始める” 『The DevOps ハンドブック』 n ⼩さな成功体験で周りから固めていく n イノベーター理論とキャズム 32

• https://amzn.asia/d/d94B4DT

ヒアリング結果︓デプロイについて ▌課題︓ n 開発チーム、プラットフォームごとにデプロイ⽅法が⼤きく異なる n Web と mobile, アーティファクトとコンテナ, 開発者 と QA n 計測のために既存のフローを変更したくない ▌対応︓ n タイミングやプラットフォーム問わず、⾃動化されているフローは存在する n 任意のデプロイ⽇時を受け取れる Web API を⽤意 n API を叩く処理をラップした GitHub Actions を提供 33

ヒアリング結果︓障害について ▌ 課題︓ n ポストモーテムや不具合管理はしているが障害の管理はしていない n 切り戻し⼿順はあるが障害対応フローは整備されていない n 障害が起きたときにイベントを送る余裕もない ▌ 対応︓ n 障害イベントはリアルタイム(同期的)に送られなくても良い n ポストモーテムや振り返りのタイミングで送ってもらう n 任意の障害発⽣⽇時を受け取れる Web API, GitHub Actions を提供 34

ヒアリング結果から決めたこと ▌Four Keys 計測に積極的なチームに相談や検証の協⼒を仰いでいく n イノベーター・アーリーアダプターからスケールさせる ▌計測に前向きではないチームに強制しない n ⽴ち上がり期から全てのチームに適⽤させるとこちらにもリスク・コスト 35

ヒアリング結果から決めたこと ▌デプロイ・障害 イベントは API を⽤意して任意のタイミングで POST してもらう n 発⽣⽇時と終了⽇時を受け取る n API をラップした GitHub Actions のアクションを⽤意 n ⾃動化や⼿動実⾏可能 ▌任意のプラットフォーム、タイミングから受け取れるように 36

構成図 37

構成図 デプロイ・障害は任意のタイミングで送れるように 38

Four Keys 基盤を提供してみて 39

Four Keys 基盤を提供してみて ▌現在までに6チーム(リポジトリ)が利⽤ ▌基盤を利⽤してもらい、さらにヒアリング n 気付きと変化 n 課題感 40

Four Keys 基盤を提供してみて ▌現在までに6チーム(リポジトリ)が利⽤ ▌基盤を利⽤してもらい、さらにヒアリング n 気付きと変化 n 課題感 → 利⽤に課題あり︕︕ 41

Four Keys 基盤による気付き ▌ プロダクトの新機能開発が落ち着いているチーム n 社内販売管理システムチーム ▌ 全ての指標でエリート ▌ パフォーマンスや品質を落とさない程度に新しい チャレンジに取り組める ▌ すでにエリートだからこそ細かい改善にも取り組める ▌ 積極的に新しい活動への投資🎉 42

Four Keys 指標に基づいた意思決定 ▌Garoon 開発チーム n サービス提供開始から 22 年 n ⽉イチ定期メンテナンスでのデプロイが⼤半 ▌ビジネスサイドはデプロイを増やすことに抵抗 ▌デプロイ頻度を増やしても実際には障害率は上がらなかった ▌定量的に会話してデプロイ頻度を増やし、よりアウトプットを⽣み出せるように🎉 n Four Keysに基づくデプロイプロセスの改善とその成果 43

• https://speakerdeck.com/ak1210/release-process-improvement-based-on-the-four-keys-and-its-results

Four Keys 活⽤の課題 44

エリート、その先は︖ ▌課題︓ n 社内販売管理システム開発チーム、4指標でエリート n Four Keys の改善・変化がビジネスインパクトに影響を与えられているか分かると 嬉しい n 変化がビジネスインパクトに繋がる → 注⼒すべき n 変化がビジネスインパクトに繋がらない → にコストを掛けない 45

エリート、その先は︖ ▌エンジニアリングがどれくらいインパクトにつながるかを測りたい ▌しかしインパクトを定量化、因果関係の把握が難しい n SaaS n B to B n 中・⼤企業向け n コラボレーションツール、業務改善 → 開発者・PMだけでなくビジネスサイドと連携した仮説検証へ 46

ダッシュボードの活⽤⽅法 ▌課題︓ n Four Keys ダッシュボード⾒て、ネクストアクションがわからない ▌施策︓ n Four Keys に拘らずケイパビリティや詳細なデータの可視化 n PBI, PRのリードタイム n コミッターのアクティビティ n CI/CD の実⾏時間 n 事例の共有 n 改善しやすくレバレッジが効くリードタイムから改善していくのが良さそう 47

Four Keys とモバイル開発の相性 ▌iOS, Android 開発チーム ▌課題︓ n 審査・段階的デプロイ n PM「アプリの機能を Web に追いつかせることを優先」 ▌施策︓ n 事例の共有 n iOS, Android 同⼠で情報共有 48

⽀援チームだからこその難しさ ▌ヒアリング結果から活⽤促進のための施策や仮説は考えられた ▌⽀援チーム主導でどうやって進めていくか n 当事者たちの温度感は︖ n どこまで踏み込んでいいか ▌関係性の構築 n 定期的なヒアリング n 同期的なコミュニケーション n アンケート 49

もっと多くのチームに利⽤して欲しい ▌やる気のあるチームから計測したので良いパフォーマンスの傾向 ▌真に利⽤して欲しいチームはパフォーマンスが良くない ▌マジョリティに利⽤してもらう動きが必要 n 知⾒や社内事例の横展開 n アウトカムへの繋がり可視化 50

まとめ ▌事業規模の変化に伴いスピードを上げていく n そのために Four Keys を活⽤ ▌組織横断⽀援チームが主導して Four Keys 計測基盤構築 ▌導⼊に向けたヒアリングの実施 n イノベーター・アーリーアダプターを⾒つける ▌活⽤に課題 n 指標からの意思決定 n ⽀援チームのあり⽅の難しさ 51

今後のやっていき ▌ダッシュボードの活⽤ n 事例共有 n ケイパビリティやその他活動の可視化 n アウトカムへのつながりを可視化 ▌どのように⽀援を⼿伝っていくか n 関係性構築 ▌成功を伝播させ全チームに導⼊ n マジョリティの獲得 52

宣伝 ▌ Software Design 2024年7⽉号にて、サイボウズ⽣産性向上チームで GitHub Actions 特集を執筆したので何卒 ▌ ほぼ毎週、開発⽣産性にまつわる技術やニュースを取り上げている Productivity Weekly を Zenn で連載しているので何卒 ▌ 2024/07/26 サイボウズ⽇本橋オフィスにて サイボウズ × Sansan さんで合同で開発⽣ 産性にまつわるイベントを⾏うので何卒 We're hiring!! 53

• https://zenn.dev/p/cybozu_ept

Reference ▌インパクト10倍を⽬指すB2B SaaSマルチプロダクトなサイボウズ開発組織の取り組 み ▌Four Keysに基づくデプロイプロセスの改善とその成果 ▌Capability catalog ▌Four keys改善の取り組み事例紹介 54

• https://www.docswell.com/s/teppeis/KW1DGY-cybozu-impact-10x
• https://speakerdeck.com/ak1210/release-process-improvement-based-on-the-four-keys-and-its-results
• https://dora.dev/devops-capabilities/
• https://speakerdeck.com/sansantech/sansan-20240409