Slide 1

Slide 1 text

開発者体験を見える化し 「計器飛行」の実現を目指すSODA構想 〜事業の成長とプロダクト組織能力の相関関係を見いだすには〜 Developer eXperience Day 2023: Day2, 2023/6/15 Visionalグループ 株式会社ビズリーチ 管理執行管掌プロセス改善部 高橋裕之

Slide 2

Slide 2 text

2 本コンテンツの目的 本日お伝えしたいこと Learning Outcome エグゼクティブ、マネジャーの方へ • プロダクト開発チームの「内側」で起きやすい事象を認識しよう • ビジネス(事業)とプロダクト開発の相関関係を見出そう • DORA Metrics(Four Keysなど)以外にもいっぱい測ろう • ビジネスを成長させるために「計器飛行」を実現しよう 1. 自己紹介 2. 株式会社ビズリーチ紹介 3. 開発者体験とは 4. 開発者体験の誤解 5. 計測指標(メトリクス)の内側と外側 6. エビデンスベースの計器飛行 7. SODA構想とは 8. ビズリーチ版SODA アジェンダ プロダクト開発者・エンジニアの方へ • プロダクト開発チームの「外側」も意識しよう • 開発者体験はイメージよりエビデンスに価値を置こう

Slide 3

Slide 3 text

3 ビズリーチ・ジャーニー JJUG CCC 2022 Fall (2022/11/27) DevOpsDays Tokyo2022 (2022/4/21) 本 日 発 表 す る の は こ れ ら の 続 編 で す Regional Scrum Gathering Tokyo 2023 (2023/1/11) DevOpsDays Tokyo2023 (2023/4/18)

Slide 4

Slide 4 text

4 自己紹介 数々の受託プロジェクトを経験し、フリーランスを経て、1996年に日立通信システム株式会社 (現・日立情報通信エンジニアリング)に入社。同社で交換機やIP機器の開発に携わった。2002 年にソニーデジタルネットワークアプリケーションズ株式会社に入社し、コンシューマ向けカメラ 開発や全社プロセス改善に取り組んだ。2013年にウイングアーク1st株式会社に入社。2018年 から品質管理部部長、製品品質管理責任者、およびOSS管理責任者を兼任。2021年7月に株式会社 ビズリーチに入社し、同年11月からプロセス改善部の部長を務めている。 Certified ScrumMaster® Advanced Certified ScrumMaster® Certified Scrum Product Owner® Certified Scrum Professional® - ScrumMaster Certified Scrum Professional® - Product Owner Certified Agile Leadership I Mobius Outcome Delivery Certified Practitioner PRINCE2® Foundation Certificate in Project Management Management 3.0 licensed facilitator. 高橋 裕之(Hiroyuki TAKAHASHI) 趣味 山、海、小説、漫画、映画、ランニング 経歴

Slide 5

Slide 5 text

株式会社ビズリーチ紹介 5

Slide 6

Slide 6 text

会社概要 株式会社ビズリーチ / BizReach, Inc. 創業 :2009年4月 代表者 :株式会社ビズリーチ 代表取締役社長 酒井 哲也 グループ従業員数:1,821名(2022年7月末時点) 拠点 :東京、大阪、名古屋、福岡、静岡、広島 資本金 :1億3,000万円 事業内容:HR Techのプラットフォーム・SaaS事業

Slide 7

Slide 7 text

株式会社ビズリーチのサービス

Slide 8

Slide 8 text

開発者体験とは Developer Experience (DevEx) 8

Slide 9

Slide 9 text

9 開発者体験とは •昨日、エンジニアが選ぶ「開発者体験が良い」イメージのある企業 「Developer eXperience AWARD 2023」ランキング上位30が発表されました。 •選出企業様、おめでとうございます!! https://cto-a.org/news/2023/06/14/8859/

Slide 10

Slide 10 text

10 開発者体験とは •昨日、エンジニアが選ぶ「開発者体験が良い」イメージのある企業 「Developer eXperience AWARD 2023」ランキング上位30が発表されました。 •選出企業様、おめでとうございます!! https://cto-a.org/news/2023/06/14/8859/ イメージってナニ?

Slide 11

Slide 11 text

11 イメージは大事だ。 でも「開発者体験が良い」ってどんなこと? ツール? フルリモート? テックブログ? カルチャー? 大喜利? 川柳?

Slide 12

Slide 12 text

12 開発者体験とは “開発者体験とは、開発者が高速な仮説検証を行うための企業における環境や習 慣、文化のことを指します” 日本CTO協会 “開発者体験は、開発者が自分の仕事についてどう感じ、どう考え、どう評価す るかを包含する。(中略) 例えば、中断、非現実的な納期、開発ツールのフリク ション(摩擦)はDevExに悪影響を及ぼし、明確なタスク、整理されたコー ド、負担のないリリースはDevExを向上させます。” Abi Noda, Margaret-Anne Storey, Nicole Forsgren, & Greiler, M. (2023). 引用: DevEx: What Actually Drives Productivity: The developer-centric approach to measuring and improving productivity. ACM Queue, Vol.21, No.2, p.35-53. 引用: https://dxd2023.cto-a.org/

Slide 13

Slide 13 text

13 なるほど。 では「開発者体験が良い」は イメージではなく可視化できるのでは?

Slide 14

Slide 14 text

14 ウガンダのAirQoプロジェクト アフリカの都市部では大気汚染が深刻で 毎年700万人もの人が亡くなっている。 ウガンダの首都カンパラも例外ではなく 人々は大気汚染に苦しんでいる。 が、そもそもカンパラの人たちは『空気 がどれぐらい汚れているか』を知らな かった。 マケレレ大学のバイノムギシャ氏は安価 な大気センサーを開発し、バイクタク シー(ボタボタ)や建物の屋上に大気セ ンサーを取り付け市内全域の大気汚染 データを収集し、汚染の予測や大気質の 改善に役立つようにした。 https://about.google/intl/ja_AI/stories/clean-air-for-kampala/

Slide 15

Slide 15 text

15 ウガンダのAirQoプロジェクト アフリカの都市部では大気汚染が深刻で 毎年700万人もの人が亡くなっている。 ウガンダの首都カンパラも例外ではなく 人々は大気汚染に苦しんでいる。 が、そもそもカンパラの人たちは『空気 がどれぐらい汚れているか』を知らな かった。 マケレレ大学のバイノムギシャ氏は安価 な大気センサーを開発し、バイクタク シー(ボタボタ)や建物の屋上に大気セ ンサーを取り付け市内全域の大気汚染 データを収集し、汚染の予測や大気質の 改善に役立つようにした。 https://about.google/intl/ja_AI/stories/clean-air-for-kampala/ まず「測る」ことが大事

Slide 16

Slide 16 text

16 開発者体験とは •"DevEx: What Actually Drives Productivity: The developer- centric approach to measuring and improving productivity" (DevEx: 何が実際に生産性を向上させるのか: 生産性を測定し改善 するための開発者中心のアプローチ) • Association for Computing Machinery(ACM)が発行する雑誌 "acmqueue" 2023年3月-4月号に載った論文 •著者 •Abi Noda: DX社創業者兼CEO。以前は2019年にGitHubに買収されたPull Panda を設立 •Margaret-Anne Storey: ビクトリア大学コンピューターサイエンス教授。DX社チーフサイエ ンティスト •Nicole Forsgren: Microsoft ResearchのパートナーでDeveloper Velocity Labを率いる。 "Accelerate: The Science of Lean Software and DevOps"(和名 「LeanとDevOpsの科学」)の筆頭筆者 •Michaela Greiler: DX社研究責任者。以前はチューリッヒ大学およびMicrosoft Researchの研究員 https://mydigitalpublication.com/publication/?m=38068&i=791199&p=1&ver=html5

Slide 17

Slide 17 text

17 DevExの3コア・ダイヤモンド DevEx Flow State Feedback Loops Cognitive Load (参考) Noda, A., Storey, M. A., Forsgren, N., & Greiler, M. (2023). DevEx: What Actually Drives Productivity: The developer-centric approach to measuring and improving productivity. ACM Queue, Vol.21, No.2, p.35-53. フロー状態 認知負荷 フィードバックループ

Slide 18

Slide 18 text

18 DevExの3コア・ダイヤモンド DevEx Flow State Feedback Loops Cognitive Load 1. Feedback Loops(フィードバックループ):ソフトウェアの開発とテスト、 コードレビュー、マニュアルテスト、実際のユーザーフィードバックなど、ソ フトウェア配信には多くのフィードバックループが関与しています。これらの ループはすべて短くなければならず、特にタスクがまだ活動中の間に完了する ことが理想的です。フィードバックループがタスクの一部として中断すると、 それは次の作業を中断し、認知負荷を増加させます。 2. Cognitive Load(認知負荷):ソフトウェアを作成し維持する作業は大量の精神 的処理を必要とします。開発者が多くのツールや技術を持っていると、タスク の自然な認知負荷が増加します。ソフトウェアのアーキテクチャも負荷を増加 させることがあります。ツールチェーンの摩擦を減らす、ドキュメンテーショ ンを最新の状態に保つ、システムのアーキテクチャを改善する、プロセスの遅 延を排除することで認知負荷を軽減できます。 3. Flow State(フロー状態):フロー状態は、エネルギーに満ちた集中した感覚を 伴う完全な没頭感として説明されます。この状態は、作業の構造に対するコン トロール、明確な目標、魅力的な作業があるときに自然に発生します。フロー をもたらすためには、中断や遅延からの邪魔を防ぐことが必要です。 (参考) Noda, A., Storey, M. A., Forsgren, N., & Greiler, M. (2023). DevEx: What Actually Drives Productivity: The developer-centric approach to measuring and improving productivity. ACM Queue, Vol.21, No.2, p.35-53.

Slide 19

Slide 19 text

19 DevExの3コア・ダイヤモンド DevEx Flow State Feedback Loops Cognitive Load Ian Maddox, CC BY-SA 4.0, via Wikimedia Commons Ian Maddox, CC BY-SA 4.0, via Wikimedia Commons フィードバックループ

Slide 20

Slide 20 text

20 DevExの3コア・ダイヤモンド (参考)原田悦子, 橋本英奈, & 須藤智. (2016). 矢印を用いた「組み合わされた方向サイン」の わかりやすさ:構造,アイコン,加齢の効果. 日本認知科学会第33回大会. P2-42. (図1) DevEx Flow State Feedback Loops Cognitive Load Ian Maddox, CC BY-SA 4.0, via Wikimedia Commons Ian Maddox, CC BY-SA 4.0, via Wikimedia Commons 認知負荷 フィードバックループ

Slide 21

Slide 21 text

21 DevExの3コア・ダイヤモンド (参考)原田悦子, 橋本英奈, & 須藤智. (2016). 矢印を用いた「組み合わされた方向サイン」の わかりやすさ:構造,アイコン,加齢の効果. 日本認知科学会第33回大会. P2-42. (図1) DevEx Flow State Feedback Loops Cognitive Load Ian Maddox, CC BY-SA 4.0, via Wikimedia Commons Ian Maddox, CC BY-SA 4.0, via Wikimedia Commons 認知負荷 フィードバックループ

Slide 22

Slide 22 text

22 DevExの3コア・ダイヤモンド (参考)原田悦子, 橋本英奈, & 須藤智. (2016). 矢印を用いた「組み合わされた方向サイン」の わかりやすさ:構造,アイコン,加齢の効果. 日本認知科学会第33回大会. P2-42. (図1) DevEx Flow State Feedback Loops Cognitive Load Ian Maddox, CC BY-SA 4.0, via Wikimedia Commons Ian Maddox, CC BY-SA 4.0, via Wikimedia Commons 認知負荷 フィードバックループ

Slide 23

Slide 23 text

23 DevExの3コア・ダイヤモンド (参考)原田悦子, 橋本英奈, & 須藤智. (2016). 矢印を用いた「組み合わされた方向サイン」の わかりやすさ:構造,アイコン,加齢の効果. 日本認知科学会第33回大会. P2-42. (図1) DevEx Flow State Feedback Loops Cognitive Load Ian Maddox, CC BY-SA 4.0, via Wikimedia Commons Ian Maddox, CC BY-SA 4.0, via Wikimedia Commons 認知負荷 フィードバックループ

Slide 24

Slide 24 text

24 DevExの3コア・ダイヤモンド (参考)原田悦子, 橋本英奈, & 須藤智. (2016). 矢印を用いた「組み合わされた方向サイン」の わかりやすさ:構造,アイコン,加齢の効果. 日本認知科学会第33回大会. P2-42. (図1) DevEx Flow State Feedback Loops Cognitive Load Ian Maddox, CC BY-SA 4.0, via Wikimedia Commons Ian Maddox, CC BY-SA 4.0, via Wikimedia Commons 認知負荷 フィードバックループ

Slide 25

Slide 25 text

25 DevExの3コア・ダイヤモンド (参考)原田悦子, 橋本英奈, & 須藤智. (2016). 矢印を用いた「組み合わされた方向サイン」の わかりやすさ:構造,アイコン,加齢の効果. 日本認知科学会第33回大会. P2-42. (図1) DevEx Flow State Feedback Loops Cognitive Load Ian Maddox, CC BY-SA 4.0, via Wikimedia Commons Ian Maddox, CC BY-SA 4.0, via Wikimedia Commons 認知負荷 フィードバックループ

Slide 26

Slide 26 text

26 DevExの3コア・ダイヤモンド (参考)原田悦子, 橋本英奈, & 須藤智. (2016). 矢印を用いた「組み合わされた方向サイン」の わかりやすさ:構造,アイコン,加齢の効果. 日本認知科学会第33回大会. P2-42. (図1) DevEx Flow State Feedback Loops Cognitive Load Georgios Liakopoulos, CC BY-SA 2.0, via Wikimedia Commons Ian Maddox, CC BY-SA 4.0, via Wikimedia Commons Ian Maddox, CC BY-SA 4.0, via Wikimedia Commons フロー状態 認知負荷 フィードバックループ

Slide 27

Slide 27 text

27 DevEx Metrics Feedback Loops フィードバックループ Cognitive Load 認知負荷 Flow State フロー状態 Perceptions 認識(態度、感情、意見) Human attitudes and opinions • 自動テストのスピードと出力 に対する満足度 • ローカル変更の検証にかかる 時間に対する満足度 • 変更を本番に導入するまでの 時間に対する満足度 • コードベースの複雑さの認識 • プロダクションシステムのデ バッグのしやすさ • ドキュメントの理解しやすさ • 集中力と中断を回避する能力 の認識 • タスクやプロジェクトの目標 が明確であることの満足度 • オンコールがもたらす混乱に ついての認識 Workflows ワークフロー System and process behaviors • CIの結果生成にかかる時間 • コードレビューのターンアラ ウンドタイム • デプロイメント・リードタイ ム(変更が本番環境にリリー スされるまでの時間) • 技術的な質問に対する回答を 得るまでにかかる時間 • 変更を適用するために必要な 手動手順 • ドキュメントの改善頻度 • ミーティングや割り込みがな い時間帯の数 • 予定外のタスクやリクエスト の発生頻度 • チームの対応を必要とするイ ンシデントの発生頻度 KPIs North star metrics • ソフトウェア提供の容易さに関する総合的な認識 • 従業員エンゲージメントまたは満足度 • 生産性の認識 (参考) Noda, A., Storey, M. A., Forsgren, N., & Greiler, M. (2023). DevEx: What Actually Drives Productivity: The developer-centric approach to measuring and improving productivity. ACM Queue, Vol.21, No.2, p.35-53.

Slide 28

Slide 28 text

28 DevExメトリクスの例 Feedback Loops フィードバックループ Cognitive Load 認知負荷 Flow State フロー状態 Perceptions 知覚 Human attitudes and opinions • 自動テストのスピードと出力に 対する満足度 • ローカル変更の検証にかかる時 間に対する満足度 • 変更を本番に導入するまでの時 間に対する満足度 • コードベースの複雑さの認識 • プロダクションシステムのデ バッグのしやすさ • ドキュメントの理解しやすさ • 集中力と中断を回避する能力の 認識 • タスクやプロジェクトの目標が 明確であることの満足度 • オンコールがもたらす混乱につ いての認識 Workflows ワークフロー System and process behaviors • CIの結果生成にかかる時間 • コードレビューのターンアラウ ンドタイム • デプロイメント・リードタイム (変更が本番環境にリリースさ れるまでの時間) • 技術的な質問に対する回答を得 るまでにかかる時間 • 変更を適用するために必要な手 動手順 • ドキュメントの改善頻度 • ミーティングや割り込みがない 時間帯の数 • 予定外のタスクやリクエストの 発生頻度 • チームの対応を必要とするイン シデントの発生頻度 KPIs North star metrics • ソフトウェア提供の容易さに関する総合的な認識 • 従業員エンゲージメントまたは満足度 • 生産性の認識 (参考) Noda, A., Storey, M. A., Forsgren, N., & Greiler, M. (2023). DevEx: What Actually Drives Productivity: The developer-centric approach to measuring and improving productivity. ACM Queue, Vol.21, No.2, p.35-53. 「開発者体験」は測れる

Slide 29

Slide 29 text

29 やっぱり測れそうだね。 昔から 「計測できないものは制御できない」 って言うもんね。

Slide 30

Slide 30 text

30 ソフトウェアエンジニアリングの歴史的「格言」 「計測できないものは制御できない」 “You can’t control what you can’t measure.” Tom DeMarco(1982) ”Controlling Software Projects: Management, Measurement, and Estimation” (Prentice Hall/Yourdon Press, 1982)

Slide 31

Slide 31 text

31 ソフトウェアエンジニアリングの歴史的「格言」 「計測できないものは制御できない」 “You can’t control what you can’t measure.” Tom DeMarco(1982) ”Controlling Software Projects: Management, Measurement, and Estimation” (Prentice Hall/Yourdon Press, 1982) 呪言

Slide 32

Slide 32 text

32 「測定できないものは制御できない」は誤りだった? •2009年7月、Tom DeMarco がIEEE Software誌7月8月合 併号に、衝撃的な記事を寄稿しました。タイトル は ”Software Engineering: An Idea Whose Time Has Come and Gone?(ソフトウェアエンジニアリング:その 考えは、もう終わったことなのか?)” •この文章は当時、Tom DeMarco 自身が「測定できないも のは制御できない」は誤りだったと認めた!ということで 業界に衝撃が走りました。 https://www.cs.uni.edu/~wallingf/teaching/172/resources/demarco-on-se.pdf 「計測できないものは制御できない」 “You can’t control what you can’t measure.” このセリフには本当の真実が含まれているのですが、私はこのセリ フを使うことに違和感を覚えるようになりました。 (中略)例えば、 過去40年間、私たちはソフトウェアプロジェクトを時間通り、予算 通りに終わらせることができないことで自らを苦しめてきました。 (Tom DeMarco, 2009)

Slide 33

Slide 33 text

33 「測定できないものは制御できない」は誤りだった? •2009年7月、Tom DeMarco がIEEE Software誌7月8月合 併号に、衝撃的な記事を寄稿しました。タイトル は ”Software Engineering: An Idea Whose Time Has Come and Gone?(ソフトウェアエンジニアリング:その 考えは、もう終わったことなのか?)” •この文章は当時、Tom DeMarco 自身が「測定できないも のは制御できない」は誤りだったと認めた!ということで 業界に衝撃が走りました。 https://www.cs.uni.edu/~wallingf/teaching/172/resources/demarco-on-se.pdf 「計測できないものは制御できない」 “You can’t control what you can’t measure.” このセリフには本当の真実が含まれているのですが、私はこのセリ フを使うことに違和感を覚えるようになりました。 (中略)例えば、 過去40年間、私たちはソフトウェアプロジェクトを時間通り、予算 通りに終わらせることができないことで自らを苦しめてきました。 (Tom DeMarco, 2009) 例えば、過去40年間、私たちはソフトウェアプ ロジェクトを時間通り、予算通りに終わらせる ことができないことに自責の念を抱いてきまし た。しかし、先ほども申し上げたように、これ は決して至上命題ではありませんでした。 もっと重要なのは、世界を変えるような、ある いは企業やビジネスのあり方を変えるようなソ フトウェアを作るという「変革」です。 Tom DeMarco(2009)

Slide 34

Slide 34 text

34 例えば、過去40年間、私たちはソフトウェアプ ロジェクトを時間通り、予算通りに終わらせる ことができないことに自責の念を抱いてきまし た。しかし、先ほども申し上げたように、これ は決して至上命題ではありませんでした。 もっと重要なのは、世界を変えるような、ある いは企業やビジネスのあり方を変えるようなソ フトウェアを作るという「変革」です。 Tom DeMarco(2009)

Slide 35

Slide 35 text

開発者体験の誤解 35

Slide 36

Slide 36 text

36 開発者体験の誤解 DevEx Flow State Feedback Loops Cognitive Load (参考) Noda, A., Storey, M. A., Forsgren, N., & Greiler, M. (2023). DevEx: What Actually Drives Productivity: The developer-centric approach to measuring and improving productivity. ACM Queue, Vol.21, No.2, p.35-53. フロー状態 認知負荷 フィードバックループ

Slide 37

Slide 37 text

37 開発者体験の誤解 プロダクト開発チーム 開発者 DevEx Flow State Feedback Loops Cognitive Load one for all, all for one !! スクラムは 楽しいぜ! チーム外の 要求は受け 付けない! 俺たち 自己組織化 してる 心理的安全 性が高い

Slide 38

Slide 38 text

38 開発者体験の誤解 ねぇ、◯◯の機能って 6月のリリースに乗 るっていってたよね? 入ってなくない? セールス あぁ、アレはボクたち 開発チームのスプリン トプランニングで入ら なかったんだ ええっ! お客様、あの機能ずっーと 待ってるんだぞ! 6月には必ず!ってお伝え しちゃってるんだよ〜! 開発者 他のPBIを優先させ たしね。アレは6月 リリースからはド ロップさせてもらっ たよ

Slide 39

Slide 39 text

39 開発者体験の誤解 そんなわけで、私た ちのチームは今回余 裕があったので例の △ △ 対応画面の実装 を終えたわ ちょいちょい、待てよ! 俺たちバックエンドチー ムは聞いてないぞ! キミらだけ出来てどーす んだよ! スプリントプランニングどおり なんだから仕方ないじゃない、 私たちのチームは自律性を大切 にしてるのよ! 開発者 他チームの開発者

Slide 40

Slide 40 text

40 開発者体験の誤解 one for all, all for one !! スクラムは 楽しいぜ! チーム外の 要求は受け 付けない! 成果が出てない んだよなぁ…… 俺たち 自己組織化 してる 他のチームのこ と考えてないん だよなぁ… 約束、守らない んだよなぁ… 心理的安全 性が高い

Slide 41

Slide 41 text

41 開発者体験の誤解 one for all, all for one !! スクラムは 楽しいぜ! チーム外の 要求は受け 付けない! 成果が出てない んだよなぁ…… 俺たち 自己組織化 してる 他のチームのこ と考えてないん だよなぁ… 約束、守らない んだよなぁ… 心理的安全 性が高い 内側しか見てないとこうなる

Slide 42

Slide 42 text

42 開発者体験の誤解 アウトプットが恐ろしく速いプロダクト開発チーム PO SM 開発者 DevEx Flow State Feedback Loops Cognitive Load

Slide 43

Slide 43 text

43 開発者体験の誤解 PO SM 開発者 DevEx Flow State Feedback Loops Cognitive Load 顧客 アウトプットが恐ろしく速いプロダクト開発チーム

Slide 44

Slide 44 text

44 開発者体験の誤解 PO SM 開発者 DevEx Flow State Feedback Loops Cognitive Load 顧客 機能A アウトプットが恐ろしく速いプロダクト開発チーム

Slide 45

Slide 45 text

45 開発者体験の誤解 PO SM 開発者 DevEx Flow State Feedback Loops Cognitive Load 顧客 機能A 機能B アウトプットが恐ろしく速いプロダクト開発チーム

Slide 46

Slide 46 text

46 開発者体験の誤解 PO SM 開発者 DevEx Flow State Feedback Loops Cognitive Load 顧客 機能A 機能B 機能C アウトプットが恐ろしく速いプロダクト開発チーム

Slide 47

Slide 47 text

47 開発者体験の誤解 PO SM 開発者 DevEx Flow State Feedback Loops Cognitive Load 顧客 機能A 機能B 機能C 機能D アウトプットが恐ろしく速いプロダクト開発チーム

Slide 48

Slide 48 text

48 開発者体験の誤解 PO SM 開発者 DevEx Flow State Feedback Loops Cognitive Load 顧客 コレ じゃない! 機能A 機能B 機能C 機能D アウトプットが恐ろしく速いプロダクト開発チーム

Slide 49

Slide 49 text

49 ビルドトラップ •組織がアウトカムではなくアウトプットで成功を計測しようとして、行き詰まっている状況* •実際に生み出された価値ではなく、機能の開発とリリースに集中してしまっている状態* 誰もプロダ クトを使わ ない 足りない機 能を作る 顧客に足り ない機能を 聞く プロダクトの死のサイクル(デイビッド・ブランド) https://twitter.com/davidjbland/status/467096015318036480 * Perri, M. (2018). プロダクトマネジメント―ビルドトラップを避け顧客に価値を届ける(吉羽龍太郎, Trans.). O'Reilly Japan, Inc​​.

Slide 50

Slide 50 text

50 ビルドトラップ •ビルドトラップ: •組織がアウトカムではなくアウトプットで成功を計測しようとして、行き詰まっている状況* •実際に生み出された価値ではなく、機能の開発とリリースに集中してしまっている状態* 誰もプロダ クトを使わ ない 足りない機 能を作る 顧客に足り ない機能を 聞く プロダクトの死のサイクル(デイビッド・ブランド) https://twitter.com/davidjbland/status/467096015318036480 * Perri, M. (2018). プロダクトマネジメント―ビルドトラップを避け顧客に価値を届ける(吉羽龍太郎, Trans.). O'Reilly Japan, Inc​​. 内側しか見てないとこうなる

Slide 51

Slide 51 text

計測指標(メトリクス)の内側と外側 ソフトウェアの力で世界を変えるようなプロダクトを生み出す 51

Slide 52

Slide 52 text

52 計測指標(メトリクス)の内側と外側 プロダクト開発チーム PO SM 開発者 DevEx Flow State Feedback Loops Cognitive Load

Slide 53

Slide 53 text

53 計測指標(メトリクス)の内側と外側 プロダクト開発チーム PO SM 開発者 DevEx Flow State Feedback Loops Cognitive Load 顧客 困った

Slide 54

Slide 54 text

54 計測指標(メトリクス)の内側と外側 プロダクト開発チーム PO SM 開発者 DevEx Flow State Feedback Loops Cognitive Load 顧客 困った プロダクト・サービス提供

Slide 55

Slide 55 text

55 計測指標(メトリクス)の内側と外側 プロダクト開発チーム PO SM 開発者 DevEx Flow State Feedback Loops Cognitive Load 顧客 プロダクト・サービス提供 良かった!

Slide 56

Slide 56 text

56 計測指標(メトリクス)の内側と外側 プロダクト開発チーム PO SM 開発者 DevEx Flow State Feedback Loops Cognitive Load 顧客 プロダクト・サービス提供 良かった! アウトカム向上

Slide 57

Slide 57 text

信頼・対価(売上) 57 計測指標(メトリクス)の内側と外側 プロダクト開発チーム PO SM 開発者 DevEx Flow State Feedback Loops Cognitive Load 顧客 プロダクト・サービス提供 良かった! アウトカム向上

Slide 58

Slide 58 text

信頼・対価(売上) 58 計測指標(メトリクス)の内側と外側 プロダクト開発チーム PO SM 開発者 DevEx Flow State Feedback Loops Cognitive Load 顧客 プロダクト・サービス提供 良かった! 継続 アウトカム向上

Slide 59

Slide 59 text

信頼・対価(売上) 59 計測指標(メトリクス)の内側と外側 プロダクト開発チーム PO SM 開発者 DevEx Flow State Feedback Loops Cognitive Load 顧客 プロダクト・サービス提供 良かった! 継続 アウトカム向上 内側 自組織を測る メトリクス 外側 顧客を測る メトリクス

Slide 60

Slide 60 text

60 DORA Metrics •Four Keys とは DORA社(DevOps Research and Assessment, 現Google)が長年の の研究から導いた開発チームのパフォーマンス指標 •アジャイルでもウォーターフォールでも計測可能 リードタイム コードがコミットされてか ら本番環境で正常に実行さ れるまでの時間 デプロイ頻度 コードを本番環境にデプロ イまたはエンドユーザーに リリースした頻度 平均サービス 回復時間(MTRS) サービスインシデント または不具合が発生したと きにサービスの復元にどれ くらいの時間がかかるか 変更失敗率 本番環境に変更を加えた、 またはユーザーへのリリー スを実施した結果サービス が低下し、その後修正を行 う必要が生じた割合

Slide 61

Slide 61 text

DORA Metrics “生産性”に代わる開発チームのパフォーマンス計測を! ソフトウェア開発の“生産性”指標の難しさ 「書いたコードの量」が 生産性とは限らない 「ベロシティ(速度)」は 生産性とは限らない 「リソース効率(利用率)」が 生産性とは限らない 品質 スピード リードタイムが短くなると学 習スピードが増し、品質が向 上する 品質が向上するとリードタイ ムは短くなり、頻繁なデプロ イが容易になる リードタイム デプロイ頻度 平均サービス 回復時間(MTRS) 変更失敗率

Slide 62

Slide 62 text

62 DORA Metrics リードタイム デプロイ頻度 平均サービス 回復時間(MTRS) 変更失敗率 信頼性(可用性) Four Keys 27のケイパビリティ 統計的相関 (参考)Google Cloud. ” Explore DORA's research program”. Google Cloud. https://www.devops-research.com/research.html. (参照 2023-1-10)

Slide 63

Slide 63 text

信頼・対価(売上) 63 Four Keys は内側か外側か? プロダクト開発チーム PO SM 開発者 DevEx Flow State Feedback Loops Cognitive Load 顧客 プロダクト・サービス提供 良かった! 継続 アウトカム向上

Slide 64

Slide 64 text

良かった! 顧客 プロダクト・サービス提供 信頼・対価(売上) 64 Four Keys は内側か外側か? プロダクト開発チーム DevEx Flow State Feedback Loops Cognitive Load 継続

Slide 65

Slide 65 text

良かった! 顧客 プロダクト・サービス提供 信頼・対価(売上) 65 Four Keys は内側か外側か? プロダクト開発チーム プロダクト開発チームの“現在の姿”=内側の指標 DevEx Flow State Feedback Loops Cognitive Load

Slide 66

Slide 66 text

良かった! 顧客 プロダクト・サービス提供 信頼・対価(売上) 66 Four Keys は内側か外側か? プロダクト開発チーム DevEx Flow State Feedback Loops Cognitive Load プロダクトのアウトカムや品質の定量的計測を中心とした 「市場価値」(アウトカム)も計測したい=外側の指標

Slide 67

Slide 67 text

良かった! 顧客 プロダクト・サービス提供 信頼・対価(売上) 67 Four Keys は内側か外側か? プロダクト開発チーム DevEx Flow State Feedback Loops Cognitive Load プロダクトのアウトカムや品質の定量的計測を中心とした 「市場価値」(アウトカム)も計測したい=外側の指標 もっと重要なのは、世界を変えるような、ある いは企業やビジネスのあり方を変えるようなソ フトウェアを作るという「変革」です。 Tom DeMarco(2009)

Slide 68

Slide 68 text

68 エビデンスベースドマネジメント(EBM) •エビデンスベースドマネジメントは、Scrum.org、Professional Scrum Trainer の コミュニティ、Ken Schwaber、Christina Schwaberによって共同開発された。 •価値を俊敏に、計測・管理・改善するためのフレームワーク (参考)Scrum.org ”Evidence-Based Management Guide” https://www.scrum.org/resources/evidence-based-management-guide (参照 2023-1-10)

Slide 69

Slide 69 text

69 エビデンスベースドマネジメント(EBM) 市場に出すまでの時間(反応性) (T2M: Time to Market) 新しい能力、サービス、製品を迅速 に提供する能力 イノベーションの能力(効果性) (A2I: Ability to Innovate) 顧客やユーザーのニーズにより良く 応えられるような新しい能力を提供 する能力 現在の価値 (CV: Current Value) 現在、顧客やユーザーに提供された 価値 未実現の価値 (UV: Unrealized Value) 顧客やユーザーの潜在的なニーズを すべて満たすことによって実現しう る価値 重要価値領域(KVA)

Slide 70

Slide 70 text

70 エビデンスベースドマネジメント(EBM) 市場に出すまでの時間(反応性) (T2M: Time to Market) 新しい能力、サービス、製品を迅速 に提供する能力 イノベーションの能力(効果性) (A2I: Ability to Innovate) 顧客やユーザーのニーズにより良く 応えられるような新しい能力を提供 する能力 現在の価値 (CV: Current Value) 現在、顧客やユーザーに提供された 価値 未実現の価値 (UV: Unrealized Value) 顧客やユーザーの潜在的なニーズを すべて満たすことによって実現しう る価値 重要価値領域(KVA) 市場価値(外側) 組織的な能力(内側)

Slide 71

Slide 71 text

71 EBMの重要価値指標(KVM)の例 KVM Measuring 従業員1人あたりの収益 この⽐率(総収益 / 従業員数)は業界内の主要な競争 指標である。業界によって大きく異なる。 プロダクトコスト⽐率 計測対象のプロダクトやシステムにかかる総費用およ びコスト。運用コストも含まれる。 従業員満⾜度 従業員のエンゲージメント、エネルギー、熱意を計測 するのに役立つ感情分析の一種。 顧客満⾜度 プロダクトに 対する顧客のエンゲージメ ントと幸福度を計測す プロダクトに対する顧客のエンゲージメントと幸福度 を計測するのに役立つ感情分析の一種。 顧客使用指標 機能別の利用状況を計測して、顧客がプロダクトをど の程度有益だと思っているかを推測する。また、機能 にかける実際の使用時間が、期待と一致しているかを 確認する。 現在の価値(CV) 未実現の価値(UV) KVM Measuring 市場占有率 プロダクトが市場を占める相対的な割合。顧客 のニーズをよりよく満たした場合、そのプロダ クトが達成できるであろう潜在的な市場シェア。 顧客(ユーザー)満⾜度ギャップ 顧客またはユーザーが望む体験と実際の体験の 格差。 望ましい顧客体験または満⾜度 顧客が望んでいる体験を⽰す指標。 KVM Measuring ビルドと統合の頻度 単位時間あたりのビルド(統合されてテストされたもの)の回数。 頻繁にあるいは継続的にリリースしているチームであれば、実際のリ リース回数を計測する。 リリースの頻度 単位時間あたり(継続的、日次、週次、月次、四半期ごとなど)のリ リース回数。これは、新規的で競争力のあるプロダクトにおいて、顧 客を満足させるために必要な時間を評価するのに役立つ。 リリースの安定期間 開発者がリリースの準備ができたと言ったときから、プロダクトの問 題を修正して、実際に顧客にリリースされるまでにかかった時間。こ れは、貧弱な開発プラクティス、その基盤となる設計やコードベース の影響を表すのに役立つ。 平均修復時間 エラーが発見されてから修正されるまでの平均時間。これは、組織が エラーを修正するときの効率性を明らかにする。 顧客サイクルタイム リリース作業に着手してから実際にリリースするまでの時間。組織が 顧客にリーチするための能力を計測するのに役立つ。 リードタイム アイデアが提案されて仮説が形成されてから、顧客がそのアイデアを 享受できるようになるまでの時間。顧客やプロダクトによって、この 指標は大きく異なる。顧客満足度の要因でもある。 変更のリードタイム コードがコミットされてから本番環境で正常に実行されるまでの時間。 Four Keysのひとつ。 デプロイ頻度 組織がプロダクトの新規バージョンを顧客またはユーザーにデプロイ (またはリリース)する回数。Four Keysのひとつ。 サービス復元時間 サービスの停⽌が開始されてからサービスの可用性が完全に回復する までの時間。Four Keysのひとつ。 学習時間 アイデアや改善をスケッチして、構築して、ユーザーに提供して、そ の利用を学習するまでにかかる時間。 障害物除去時間 障害物が発生してから解決さるまでの平均時間。リードタイムや従業 員満足度の要因でもある。 ピボットまでの時間 真のビジネスアジリティの指標で、組織がフィードバックや新しい情 報を得てから、そのフィードバックに対応するまでの経過時間を表す。 例えば、競合他社が新たな市場獲得のための機能を提供したことを 知ってから、組織が顧客体験を計測できるほどに改善する新機能ある いはそれを超える機能を提供したりするまでの時間。 市場に出すまでの時間(T2M) KVM Measuring イノベーション率 新しいプロダクトの機能に費やした労力やコストを、すべてのプロダ クトに費やした労力やコストで割ったもの。新しいプロダクトの機能 を提供する組織のキャパシティについてのインサイトが 得られる。 ⽋陥のトレンド 前回の計測から⽋陥の変化を計測したもの。⽋陥とは、顧客、ユー ザー、組織にとってのプロダクトの価値を低下させるものである。一 般的には、意図したとおりに動作しないことを指す。 オンプロダクト指標 チームがプロダクトと価値に費やす時間の割合。 インストールされた バージョンの指標 現在サポートしているプロダクトのバージョン数。これは、組織が古 いバージョンのサポートや保守にかけている労力を表している。 技術的負債 プログラミングにおける概念であり、「クイック・アンド・ダー ティ」なソリューションをあとで修正することになったときに発生す る。追加の開発やテストの作業を表したもの。価値の提供に 望ましくない影響を与え、回避可能な無駄とリスクの増加を生み出す。 本番環境のインシデ ントの数 インストールされたプロダクトの問題を修正するために開発チームが 特定の期間中断された回数。本番環境でのインシデントの回数は、本 番環境の安定性を⽰すのに役立つ。 プロダクト(コー ド)のアクティブな ブランチ数 プロダクトやサービスの異なるバージョン(または種類)の数。変更 による潜在的な影響とそれに伴う作業の複雑さについてのインサイト が得られる。 ブランチ間でコード をマージする時間 プロダクトやサービスの異なるバーション間で変更を適用するために 費やした時間。変更による潜在的な影響とそれに伴う作業の複雑さに ついてのインサイトが得られる。 コンテキストスイッ チにかかる時間 例えば、ミーティングや電話による中断された時間、タスクの切り替 えに費やした時間、チームメンバーがチーム外の人を助けるために中 断された時間がある。問題の規模を把握するのに役立 つ。 変更失敗率 リリースされたプロダクトのうち、サービスが低下し、修正を行う必 要が生じた割合(例: ホットフィックス、ロールバック、パッチ)。 Four Keysのひとつ。 イノベーションの能力(A2I) (参考) Scrum.org 長沢智治、⾓征典(翻訳)“Evidence-Based Management Guide” 2020-9 p.13-P.16 https://www.scrum.org/resources/evidence-based-management-guide (参照2023-1-10)

Slide 72

Slide 72 text

72 EBMの重要価値指標(KVM)の例 KVM Measuring 従業員1人あたりの収益 この⽐率(総収益 / 従業員数)は業界内の主要な競争 指標である。業界によって大きく異なる。 プロダクトコスト⽐率 計測対象のプロダクトやシステムにかかる総費用およ びコスト。運用コストも含まれる。 従業員満⾜度 従業員のエンゲージメント、エネルギー、熱意を計測 するのに役立つ感情分析の一種。 顧客満⾜度 プロダクトに 対する顧客のエンゲージメ ントと幸福度を計測す プロダクトに対する顧客のエンゲージメントと幸福度 を計測するのに役立つ感情分析の一種。 顧客使用指標 機能別の利用状況を計測して、顧客がプロダクトをど の程度有益だと思っているかを推測する。また、機能 にかける実際の使用時間が、期待と一致しているかを 確認する。 現在の価値(CV) 未実現の価値(UV) KVM Measuring 市場占有率 プロダクトが市場を占める相対的な割合。顧客 のニーズをよりよく満たした場合、そのプロダ クトが達成できるであろう潜在的な市場シェア。 顧客(ユーザー)満⾜度ギャップ 顧客またはユーザーが望む体験と実際の体験の 格差。 望ましい顧客体験または満⾜度 顧客が望んでいる体験を⽰す指標。 KVM Measuring ビルドと統合の頻度 単位時間あたりのビルド(統合されてテストされたもの)の回数。 頻繁にあるいは継続的にリリースしているチームであれば、実際のリ リース回数を計測する。 リリースの頻度 単位時間あたり(継続的、日次、週次、月次、四半期ごとなど)のリ リース回数。これは、新規的で競争力のあるプロダクトにおいて、顧 客を満足させるために必要な時間を評価するのに役立つ。 リリースの安定期間 開発者がリリースの準備ができたと言ったときから、プロダクトの問 題を修正して、実際に顧客にリリースされるまでにかかった時間。こ れは、貧弱な開発プラクティス、その基盤となる設計やコードベース の影響を表すのに役立つ。 平均修復時間 エラーが発見されてから修正されるまでの平均時間。これは、組織が エラーを修正するときの効率性を明らかにする。 顧客サイクルタイム リリース作業に着手してから実際にリリースするまでの時間。組織が 顧客にリーチするための能力を計測するのに役立つ。 リードタイム アイデアが提案されて仮説が形成されてから、顧客がそのアイデアを 享受できるようになるまでの時間。顧客やプロダクトによって、この 指標は大きく異なる。顧客満足度の要因でもある。 変更のリードタイム コードがコミットされてから本番環境で正常に実行されるまでの時間。 Four Keysのひとつ。 デプロイ頻度 組織がプロダクトの新規バージョンを顧客またはユーザーにデプロイ (またはリリース)する回数。Four Keysのひとつ。 サービス復元時間 サービスの停⽌が開始されてからサービスの可用性が完全に回復する までの時間。Four Keysのひとつ。 学習時間 アイデアや改善をスケッチして、構築して、ユーザーに提供して、そ の利用を学習するまでにかかる時間。 障害物除去時間 障害物が発生してから解決さるまでの平均時間。リードタイムや従業 員満足度の要因でもある。 ピボットまでの時間 真のビジネスアジリティの指標で、組織がフィードバックや新しい情 報を得てから、そのフィードバックに対応するまでの経過時間を表す。 例えば、競合他社が新たな市場獲得のための機能を提供したことを 知ってから、組織が顧客体験を計測できるほどに改善する新機能ある いはそれを超える機能を提供したりするまでの時間。 市場に出すまでの時間(T2M) KVM Measuring イノベーション率 新しいプロダクトの機能に費やした労力やコストを、すべてのプロダ クトに費やした労力やコストで割ったもの。新しいプロダクトの機能 を提供する組織のキャパシティについてのインサイトが 得られる。 ⽋陥のトレンド 前回の計測から⽋陥の変化を計測したもの。⽋陥とは、顧客、ユー ザー、組織にとってのプロダクトの価値を低下させるものである。一 般的には、意図したとおりに動作しないことを指す。 オンプロダクト指標 チームがプロダクトと価値に費やす時間の割合。 インストールされた バージョンの指標 現在サポートしているプロダクトのバージョン数。これは、組織が古 いバージョンのサポートや保守にかけている労力を表している。 技術的負債 プログラミングにおける概念であり、「クイック・アンド・ダー ティ」なソリューションをあとで修正することになったときに発生す る。追加の開発やテストの作業を表したもの。価値の提供に 望ましくない影響を与え、回避可能な無駄とリスクの増加を生み出す。 本番環境のインシデ ントの数 インストールされたプロダクトの問題を修正するために開発チームが 特定の期間中断された回数。本番環境でのインシデントの回数は、本 番環境の安定性を⽰すのに役立つ。 プロダクト(コー ド)のアクティブな ブランチ数 プロダクトやサービスの異なるバージョン(または種類)の数。変更 による潜在的な影響とそれに伴う作業の複雑さについてのインサイト が得られる。 ブランチ間でコード をマージする時間 プロダクトやサービスの異なるバーション間で変更を適用するために 費やした時間。変更による潜在的な影響とそれに伴う作業の複雑さに ついてのインサイトが得られる。 コンテキストスイッ チにかかる時間 例えば、ミーティングや電話による中断された時間、タスクの切り替 えに費やした時間、チームメンバーがチーム外の人を助けるために中 断された時間がある。問題の規模を把握するのに役立 つ。 変更失敗率 リリースされたプロダクトのうち、サービスが低下し、修正を行う必 要が生じた割合(例: ホットフィックス、ロールバック、パッチ)。 Four Keysのひとつ。 イノベーションの能力(A2I) (参考) Scrum.org 長沢智治、⾓征典(翻訳)“Evidence-Based Management Guide” 2020-9 p.13-P.16 https://www.scrum.org/resources/evidence-based-management-guide (参照2023-1-10)

Slide 73

Slide 73 text

73 EBMの重要価値指標(KVM)の例 KVM Measuring 従業員1人あたりの収益 この⽐率(総収益 / 従業員数)は業界内の主要な競争 指標である。業界によって大きく異なる。 プロダクトコスト⽐率 計測対象のプロダクトやシステムにかかる総費用およ びコスト。運用コストも含まれる。 従業員満⾜度 従業員のエンゲージメント、エネルギー、熱意を計測 するのに役立つ感情分析の一種。 顧客満⾜度 プロダクトに 対する顧客のエンゲージメ ントと幸福度を計測す プロダクトに対する顧客のエンゲージメントと幸福度 を計測するのに役立つ感情分析の一種。 顧客使用指標 機能別の利用状況を計測して、顧客がプロダクトをど の程度有益だと思っているかを推測する。また、機能 にかける実際の使用時間が、期待と一致しているかを 確認する。 現在の価値(CV) 未実現の価値(UV) KVM Measuring 市場占有率 プロダクトが市場を占める相対的な割合。顧客 のニーズをよりよく満たした場合、そのプロダ クトが達成できるであろう潜在的な市場シェア。 顧客(ユーザー)満⾜度ギャップ 顧客またはユーザーが望む体験と実際の体験の 格差。 望ましい顧客体験または満⾜度 顧客が望んでいる体験を⽰す指標。 KVM Measuring ビルドと統合の頻度 単位時間あたりのビルド(統合されてテストされたもの)の回数。 頻繁にあるいは継続的にリリースしているチームであれば、実際のリ リース回数を計測する。 リリースの頻度 単位時間あたり(継続的、日次、週次、月次、四半期ごとなど)のリ リース回数。これは、新規的で競争力のあるプロダクトにおいて、顧 客を満足させるために必要な時間を評価するのに役立つ。 リリースの安定期間 開発者がリリースの準備ができたと言ったときから、プロダクトの問 題を修正して、実際に顧客にリリースされるまでにかかった時間。こ れは、貧弱な開発プラクティス、その基盤となる設計やコードベース の影響を表すのに役立つ。 平均修復時間 エラーが発見されてから修正されるまでの平均時間。これは、組織が エラーを修正するときの効率性を明らかにする。 顧客サイクルタイム リリース作業に着手してから実際にリリースするまでの時間。組織が 顧客にリーチするための能力を計測するのに役立つ。 リードタイム アイデアが提案されて仮説が形成されてから、顧客がそのアイデアを 享受できるようになるまでの時間。顧客やプロダクトによって、この 指標は大きく異なる。顧客満足度の要因でもある。 変更のリードタイム コードがコミットされてから本番環境で正常に実行されるまでの時間。 Four Keysのひとつ。 デプロイ頻度 組織がプロダクトの新規バージョンを顧客またはユーザーにデプロイ (またはリリース)する回数。Four Keysのひとつ。 サービス復元時間 サービスの停⽌が開始されてからサービスの可用性が完全に回復する までの時間。Four Keysのひとつ。 学習時間 アイデアや改善をスケッチして、構築して、ユーザーに提供して、そ の利用を学習するまでにかかる時間。 障害物除去時間 障害物が発生してから解決さるまでの平均時間。リードタイムや従業 員満足度の要因でもある。 ピボットまでの時間 真のビジネスアジリティの指標で、組織がフィードバックや新しい情 報を得てから、そのフィードバックに対応するまでの経過時間を表す。 例えば、競合他社が新たな市場獲得のための機能を提供したことを 知ってから、組織が顧客体験を計測できるほどに改善する新機能ある いはそれを超える機能を提供したりするまでの時間。 市場に出すまでの時間(T2M) KVM Measuring イノベーション率 新しいプロダクトの機能に費やした労力やコストを、すべてのプロダ クトに費やした労力やコストで割ったもの。新しいプロダクトの機能 を提供する組織のキャパシティについてのインサイトが 得られる。 ⽋陥のトレンド 前回の計測から⽋陥の変化を計測したもの。⽋陥とは、顧客、ユー ザー、組織にとってのプロダクトの価値を低下させるものである。一 般的には、意図したとおりに動作しないことを指す。 オンプロダクト指標 チームがプロダクトと価値に費やす時間の割合。 インストールされた バージョンの指標 現在サポートしているプロダクトのバージョン数。これは、組織が古 いバージョンのサポートや保守にかけている労力を表している。 技術的負債 プログラミングにおける概念であり、「クイック・アンド・ダー ティ」なソリューションをあとで修正することになったときに発生す る。追加の開発やテストの作業を表したもの。価値の提供に 望ましくない影響を与え、回避可能な無駄とリスクの増加を生み出す。 本番環境のインシデ ントの数 インストールされたプロダクトの問題を修正するために開発チームが 特定の期間中断された回数。本番環境でのインシデントの回数は、本 番環境の安定性を⽰すのに役立つ。 プロダクト(コー ド)のアクティブな ブランチ数 プロダクトやサービスの異なるバージョン(または種類)の数。変更 による潜在的な影響とそれに伴う作業の複雑さについてのインサイト が得られる。 ブランチ間でコード をマージする時間 プロダクトやサービスの異なるバーション間で変更を適用するために 費やした時間。変更による潜在的な影響とそれに伴う作業の複雑さに ついてのインサイトが得られる。 コンテキストスイッ チにかかる時間 例えば、ミーティングや電話による中断された時間、タスクの切り替 えに費やした時間、チームメンバーがチーム外の人を助けるために中 断された時間がある。問題の規模を把握するのに役立 つ。 変更失敗率 リリースされたプロダクトのうち、サービスが低下し、修正を行う必 要が生じた割合(例: ホットフィックス、ロールバック、パッチ)。 Four Keysのひとつ。 イノベーションの能力(A2I) (参考) Scrum.org 長沢智治、⾓征典(翻訳)“Evidence-Based Management Guide” 2020-9 p.13-P.16 https://www.scrum.org/resources/evidence-based-management-guide (参照2023-1-10) 市 場 価 値 ( 外 側 ) 組織的な能力(内側) DevEx Flow State Feedback Loops Cognitive Load

Slide 74

Slide 74 text

エビデンスベースの計器飛行 74

Slide 75

Slide 75 text

75 IT企業の価値は言葉に宿る •Mission、Vision、Valueの大切さ ✓ Mission(目的): 自分たちの会社は何のためにあるのか。 ✓ Vision(夢): どういう未来を築きたいと、自分たちは思っているか。 ✓ Value(信念): どういうバリューや信念(ビリーフ)を、自分たちは大事にしているか。 “現代では世界のほぼすべての企業が「社是」とか、「経営理念」とか、 「行動指針」とか、「企業理念」とか、その他、それに類したもの掲げてい る。小さいカードにその言葉を印刷して、全員に常に持ち歩かせている企業 もある。そのねらいは、バリューを社内の隅々にまで浸透させることで、社 員全員が日々、そのバリューに従って行動できるようにするためである。” ワイズカンパニー: 知識創造から知識実践への新しいモデル (野中 郁次郎 (著), 竹内 弘高 (著), 黒輪 篤嗣 (翻訳), 2020, p.034)

Slide 76

Slide 76 text

Mission

Slide 77

Slide 77 text

77 Value 変わり続けるために、学び続ける お客様の本質的課題解決 その行動で、ブレイクスルー 事業づくりは、仲間づくり 価値あることを、正しくやろう 一度きりの人生、せっかく何かに取り組むなら、 誰にでも胸を張って伝えられる仕事をしよう。 お客様、株主、社内外の仲間、家族、そして自分。 関わるすべての人が幸せになる事業を創る。 この思いを常に忘れず、 これからも道の真ん中を堂々と突き進もう。 変化し続ける時代で、何かを変えたいと思うのなら、 自分自身が一番変わっていこう。 学びは変わることを後押ししてくれる。 変わり続けることは難しく、時に苦しいけれど、 あなたの視野と可能性を広げ、 結果として人生の幸せへとつながっていく。 ユーザーという言葉も含め、 一人一人が有機的な心を持つ「お客様」であると定義し、 お客様の体験を常に想像しながら、 本質的な課題を引き出し、抜本的に解決しよう。 それこそが期待以上の成果や品質、 ひいては私たちが受け取る対価となるのだから。 誰かの主体性に頼ることなく、 自らが事業やサービスのオーナーシップを持って 考え、発言し、行動していこう。 そうすれば 、短期的な成果のために 長期的な価値を犠牲にすることもない。 いま自分にできることを考え、最初の一歩を踏み出し、 一人一人がブレイクスルーしていこう。 事業づくりにおいて、 一人の力で成し遂げられることには限界がある。 だからこそ、志を遠慮なく発信し、仲間を見つけ、 どんどん巻き込んでいくことによって、 想像もできないほどの大きな推進力を生み出そう。 そして、最高の仲間と歴史を創ろう。 01 02 03 04 05

Slide 78

Slide 78 text

78 Vision

Slide 79

Slide 79 text

No content

Slide 80

Slide 80 text

日本の「キャリアインフラ」になる

Slide 81

Slide 81 text

81 日本のキャリアインフラになる

Slide 82

Slide 82 text

82 日本のキャリアインフラになる

Slide 83

Slide 83 text

計測の重要性:Opinion vs Fact(意見か事実か) Problem(問題) Solution(解決策) Fact(事実) Opinion(意見) 設計 デプロイ 仮説を実装 する 仮説を 動かす 結果を 検証する 仮説 対策の仮説 を立てる 計測 (参考) https://slide.meguro.ryuzee.com/slides/78 吉羽龍太郎さん「カイゼンの基本」の図を変更 仮説を立てるには、 計測データを検証す る必要がある。

Slide 84

Slide 84 text

84 指標構造|全体のイメージ 企業 事業 サービス プロダクト プロジェクト 開発チーム 各ブロックが複数指標を保有し、 さらに各ブロックの指標やアウトカムが下層から上層へ影響を及ぼすも のとして設計しています。

Slide 85

Slide 85 text

85 指標構造|全体のイメージ 企業 事業 サービス プロダクト プロジェクト 開発チーム プロダクト開発指標 各ブロックが複数指標を保有し、 さらに各ブロックの指標やアウトカムが下層から上層へ影響を及ぼすも のとして設計しています。 将来的には企業ミッションや企業アウトカム指標との相関性を可視化し ますが、まずはプロダクト開発指標の可視化を行います。

Slide 86

Slide 86 text

86 指標構造|プロダクト下 - 3つの指標領域 アウトカム指標 現在の品質、維持向上 開発進捗 障害 開発パフォーマンス 顧客満足度 プロダクト開発指標 営業指標 マーケティング指標 市場占有率 売上 利益 契約企業数 登録ユーザー数 スカウト数 求人数 内定率 入社人数 レジュメ数 応募数 内定承諾率 計画リリース率 緊急リリース率 FourKeys オンプロダクト指標 スコープ 時間 予算 デリバリーの変更率 進捗率 スコープの達成率 マイルストーン達成率 人件費 固定費 開発ツール費 ケイパビリティ e-NPS パルスサーベイ DiSC (行動特性) 勤怠 勤務年数 開発チームの能力・コンディション 開発チーム組成 年齢 性別 職位 アウトカム指標はプロダクト/プロジェクトにより変わります 1〜複数存在します アウトカム指標は、3つの指標群(営業、マーケティング、プロダクト開発)により可視化できると考えています。 ● 記載の指標、順序等は仮です ● 指標単体のみでなく、相関性をもたせた可視化も行います

Slide 87

Slide 87 text

87 指標構造|プロダクト下 - 3つの指標領域 アウトカム指標 現在の品質、維持向上 開発進捗 障害 開発パフォーマンス 顧客満足度 プロダクト開発指標 営業指標 マーケティング指標 市場占有率 売上 利益 契約企業数 登録ユーザー数 スカウト数 求人数 内定率 入社人数 レジュメ数 応募数 内定承諾率 計画リリース率 緊急リリース率 FourKeys オンプロダクト指標 スコープ 時間 予算 デリバリーの変更率 進捗率 スコープの達成率 マイルストーン達成率 人件費 固定費 開発ツール費 ケイパビリティ e-NPS パルスサーベイ DiSC (行動特性) 勤怠 勤務年数 開発チームの能力・コンディション 開発チーム組成 年齢 性別 職位 アウトカム指標はプロダクト/プロジェクトにより変わります 1〜複数存在します アウトカム指標は、3つの指標群(営業、マーケティング、プロダクト開発)により可視化できると考えています。 ● 記載の指標、順序等は仮です ● 指標単体のみでなく、相関性をもたせた可視化も行います ブラックボックスになりがち

Slide 88

Slide 88 text

88 指標構造|相関性の例 アウトカム指標 現在の品質、維持向上 開発進捗 障害 開発パフォーマンス 顧客満⾜度 プロダクト開発指標 営業指標 マーケティング指標 市場占有率 売上 利益 契約企業数 登録ユーザー数 スカウト数 求人数 内定率 入社人数 レジュメ数 応募数 内定承諾率 計画リリース率 緊急リリース率 FourKeys オンプロダクト指標 (工数) スコープ 時間 予算 デリバリーの変更率 進捗率 スコープの達成率 マイルストーン達成率 人件費 固定費 開発ツール費 ケイパビリティ e-NPS パルスサーベイ DiSC (行動特性) 勤怠 勤務年数 開発チームの能力・コンディション 開発チーム組成 年齢 性別 職位 アウトカム指標はプロダクト/プロジェクトにより変わります 1〜複数存在します 例えば、このような相関性が見られる可能性があります。 ● 記載の指標、順序等は仮です ● 指標単体のみでなく、相関性をもたせた可視化も行います ブラックボックスになりがち

Slide 89

Slide 89 text

89 指標構造|相関性の例 アウトカム指標 現在の品質、維持向上 開発進捗 障害 開発パフォーマンス 顧客満⾜度 プロダクト開発指標 営業指標 マーケティング指標 市場占有率 売上 利益 契約企業数 登録ユーザー数 スカウト数 求人数 内定率 入社人数 レジュメ数 応募数 内定承諾率 計画リリース率 緊急リリース率 FourKeys オンプロダクト指標 (工数) スコープ 時間 予算 デリバリーの変更率 進捗率 スコープの達成率 マイルストーン達成率 人件費 固定費 開発ツール費 ケイパビリティ e-NPS パルスサーベイ DiSC (行動特性) 勤怠 勤務年数 開発チームの能力・コンディション 開発チーム組成 年齢 性別 職位 アウトカム指標はプロダクト/プロジェクトにより変わります 1〜複数存在します 例えば、このような相関性が見られる可能性があります。 ● 記載の指標、順序等は仮です ● 指標単体のみでなく、相関性をもたせた可視化も行います

Slide 90

Slide 90 text

90 指標構造|相関性の例 アウトカム指標 現在の品質、維持向上 開発進捗 障害 開発パフォーマンス 顧客満⾜度 プロダクト開発指標 営業指標 マーケティング指標 市場占有率 売上 利益 契約企業数 登録ユーザー数 スカウト数 求人数 内定率 入社人数 レジュメ数 応募数 内定承諾率 計画リリース率 緊急リリース率 FourKeys オンプロダクト指標 (工数) スコープ 時間 予算 デリバリーの変更率 進捗率 スコープの達成率 マイルストーン達成率 人件費 固定費 開発ツール費 ケイパビリティ e-NPS パルスサーベイ DiSC (行動特性) 勤怠 勤務年数 開発チームの能力・コンディション 開発チーム組成 年齢 性別 職位 アウトカム指標はプロダクト/プロジェクトにより変わります 1〜複数存在します 例えば、このような相関性が見られる可能性があります。 ● 記載の指標、順序等は仮です ● 指標単体のみでなく、相関性をもたせた可視化も行います プロダクト開発が見えていないと、 対策が間違っている可能性がある……

Slide 91

Slide 91 text

91 計器飛行を実現する ボーイング787のグラスコックピット Brandrodungswanderfeldhackbau, Public domain, via Wikimedia Commons

Slide 92

Slide 92 text

92 パイロット/客室乗務員 航空管制官/ グランドクルー

Slide 93

Slide 93 text

93 プロダクト開発チーム 経営チーム

Slide 94

Slide 94 text

ビズリーチが目指すプロダクト組織の「計器飛行」 ボーイング787のグラスコックピット Brandrodungswanderfeldhackbau, Public domain, via Wikimedia Commons

Slide 95

Slide 95 text

ビズリーチが目指すプロダクト組織の「計器飛行」 ボーイング787のグラスコックピット Brandrodungswanderfeldhackbau, Public domain, via Wikimedia Commons 注)数値はダミーです

Slide 96

Slide 96 text

ビズリーチが目指すプロダクト組織の「計器飛行」 注)数値はダミーです

Slide 97

Slide 97 text

97 ビズリーチが目指すプロダクト組織の「計器飛行」

Slide 98

Slide 98 text

98 ビズリーチが目指すプロダクト組織の「計器飛行」 Software Outcome Delivery Architecture SODA構想

Slide 99

Slide 99 text

SODA構想とは Software Outcome Delivery Architecture 99

Slide 100

Slide 100 text

100 SODA構想とは プロダクト開発チーム プロダクトマネジメント プロダクト品質マネジメント プロセス改善マネジメント プロダクト組織マネジメント(事業経営) プロジェクト マネジメント プロダクト開発チームは、あらゆる側面の「マネジメント」に包まれている

Slide 101

Slide 101 text

101 SODA構想とは •“相互に関連した責任感のあるチーム ”を組織に「実装」するうえで必要なマネジ メント関連のナレッジ・スキル体系・フレームワークなどを集め組織への実装イ メージを「設計」しメタ的なアーキテクチャを作成した。 •これを Software Outcome Delivery Architecture (SODA) と名付けました。

Slide 102

Slide 102 text

102 SODA構想とは 自組織を視座高く点検するためのアーキテクチャ。 足りない機能を実装したり、学習計画を立てることができる。

Slide 103

Slide 103 text

Software Outcome Delivery Architecture(SODA): prototype

Slide 104

Slide 104 text

Software Outcome Delivery Architecture(SODA): prototype

Slide 105

Slide 105 text

Software Outcome Delivery Architecture(SODA): prototype 継続的に良質なアウトプットを出す仕組み

Slide 106

Slide 106 text

Software Outcome Delivery Architecture(SODA): prototype 継続的に開発チームの QCDSをマネジメントする仕組み

Slide 107

Slide 107 text

Software Outcome Delivery Architecture(SODA): prototype

Slide 108

Slide 108 text

No content

Slide 109

Slide 109 text

継続的に顧客アウトカムを 達成する仕組み

Slide 110

Slide 110 text

No content

Slide 111

Slide 111 text

継続的に適切な品質を 達成する仕組み

Slide 112

Slide 112 text

No content

Slide 113

Slide 113 text

継続的に改善を繰り返し Factデータで効果を検証で きる仕組み

Slide 114

Slide 114 text

No content

Slide 115

Slide 115 text

継続的にビジネスと ベネフィットを達成させる仕組み

Slide 116

Slide 116 text

No content

Slide 117

Slide 117 text

継続的にイノベーション を起こす仕組み

Slide 118

Slide 118 text

No content

Slide 119

Slide 119 text

プロダクトの世界観

Slide 120

Slide 120 text

No content

Slide 121

Slide 121 text

122 SODAのキーメソッド •Software Outcome Delivery Architecture (SODA) を組織にインストールするため のキーメソッドを以下のように定義している。 •「仮説と実験」を繰り返しながら成長する組織を目指す。 ((SODA)) Team Performance ✓すべてのプロダクトにFour Keysの計測を定着させ、改善サイクルを作る ((SODA)) Quality Value ✓プロダクトごとに有意な品質指標を見極めフィードバックプロセスを増やし、プロダ クト品質を向上させる ((SODA)) Outcome Delivery ✓プロダクトごとにアウトカム指標を見極め、計測する ((SODA)) Project Value ✓プロジェクトごとに有意なマネジメント指標を計測し段階や例外によるマネジメント を行えるようにする ((SODA)) Evidence Viewer ✓プロダクト開発チームのエビデンスデータを見える化する ((SODA)) Playbook ✓プロダクトに関するナレッジベースを作成しSECIモデルを作る

Slide 122

Slide 122 text

No content

Slide 123

Slide 123 text

Software Outcome Delivery Architecture(SODA): prototype

Slide 124

Slide 124 text

ビズリーチ版SODA 125

Slide 125

Slide 125 text

127 SODAのキーメソッド •Software Outcome Delivery Architecture (SODA) を組織にインストールするため のキーメソッドを以下のように定義している。 •「仮説と実験」を繰り返しながら成長する組織を目指す。 ((SODA)) Team Performance ✓すべてのプロダクトにFour Keysの計測を定着させ、改善サイクルを作る ((SODA)) Quality Value ✓プロダクトごとに有意な品質指標を見極めフィードバックプロセスを増やし、プロダ クト品質を向上させる ((SODA)) Outcome Delivery ✓プロダクトごとにアウトカム指標を見極め、計測する ((SODA)) Project Value ✓プロジェクトごとに有意なマネジメント指標を計測し段階や例外によるマネジメント を行えるようにする ((SODA)) Evidence Viewer ✓プロダクト開発チームのエビデンスデータを見える化する ((SODA)) Playbook ✓プロダクトに関するナレッジベースを作成しSECIモデルを作る

Slide 126

Slide 126 text

129 SODAのキーメソッド •Software Outcome Delivery Architecture (SODA) を組織にインストールするため のキーメソッドを以下のように定義している。 •「仮説と実験」を繰り返しながら成長する組織を目指す。 ((SODA)) Team Performance ✓すべてのプロダクトにFour Keysの計測を定着させ、改善サイクルを作る ((SODA)) Quality Value ✓プロダクトごとに有意な品質指標を見極めフィードバックプロセスを増やし、プロダ クト品質を向上させる ((SODA)) Outcome Delivery ✓プロダクトごとにアウトカム指標を見極め、計測する ((SODA)) Project Value ✓プロジェクトごとに有意なマネジメント指標を計測し段階や例外によるマネジメント を行えるようにする ((SODA)) Evidence Viewer ✓プロダクト開発チームのエビデンスデータを見える化する ((SODA)) Playbook ✓プロダクトに関するナレッジベースを作成しSECIモデルを作る これらのメソッドを 組織にインプリメントする

Slide 127

Slide 127 text

Software Outcome Delivery Architecture(SODA): prototype

Slide 128

Slide 128 text

テーラリング Software Outcome Delivery Architecture(SODA): BizReach ver. •SODA BizReachは、今後プロダクト組織の成熟度 に合わせて仕組みを変えていく必要がありますが、 現在は右図のような構成で考えています。 深さ 広さ 構造 時間 型 • 上記のSODA Prototypeを元に、ビズリーチに合 わせてテーラリングを行いました。 • テーラリング後のSODA PrototypeをSODA BizReachと呼ぶことにします。

Slide 129

Slide 129 text

Software Outcome Delivery Architecture(SODA): BizReach ver.

Slide 130

Slide 130 text

Software Outcome Delivery Architecture(SODA): BizReach ver.

Slide 131

Slide 131 text

No content

Slide 132

Slide 132 text

No content

Slide 133

Slide 133 text

No content

Slide 134

Slide 134 text

すべてのプロダクト にFour Keysの計測 を定着させ、改善サ イクルを作る

Slide 135

Slide 135 text

No content

Slide 136

Slide 136 text

プロダクトごとに有意な品質 指標を見極めフィードバック プロセスを増やし、プロダク ト品質を向上させる

Slide 137

Slide 137 text

プロダクトごとに アウトカム指標を見極め、 計測する

Slide 138

Slide 138 text

No content

Slide 139

Slide 139 text

プロジェクトごとに有意なマネ ジメント指標を計測し段階や例 外によるマネジメントを行える ようにする

Slide 140

Slide 140 text

No content

Slide 141

Slide 141 text

プロダクトに関するナ レッジベースを作成し SECIモデルを作る

Slide 142

Slide 142 text

No content

Slide 143

Slide 143 text

プロダクト開発チーム のエビデンスデータを 見える化する

Slide 144

Slide 144 text

147

Slide 145

Slide 145 text

148

Slide 146

Slide 146 text

149

Slide 147

Slide 147 text

Software Outcome Delivery Architecture(SODA): BizReach ver.

Slide 148

Slide 148 text

Software Outcome Delivery Architecture(SODA): BizReach ver. 市場に出すまでの時間(反応性) (T2M: Time-to-Market) 新しい能力、サービス、製品を迅速 に提供する能力 イノベーションの能力(効果性) (A2I: Ability to Innovate) 顧客やユーザーのニーズにより良く 応えられるような新しい能力を提供 する能力 現在の価値 (CV: Current Value) 現在、顧客やユーザーに提供された 価値 未実現の価値 (UV: Unrealized Value) 顧客やユーザーの潜在的なニーズを すべて満たすことによって実現しう る価値

Slide 149

Slide 149 text

152 SODAで強いチームづくりを! プロダクトの力で、お客さまにベネフィットを!

Slide 150

Slide 150 text

Blog Twitter https://engineering.visional.inc/blog/ @VISIONAL_ENG Visionalグループで働くエンジニアの技術的な取り組みや、イベント・登壇情報などをお届けします。 153 BlogとTwitterで発信中!