[CLONE] 開発者体験を見える化し「計器飛行」の実現を目指すSODA構想〜事業の成長とプロダクト組織能力の相関関係を見いだすには〜 / Developer eXperience Day 2023

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

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

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)

4 ⾃⼰紹介数々の受託プロジェクトを経験し、フリーランスを経て、1996年に⽇⽴通信システム株式会社（現・⽇⽴情報通信エンジニアリング）に⼊社。同社で交換機やIP機器の開発に携わった。2002 年にソニーデジタルネットワークアプリケーションズ株式会社に⼊社し、コンシューマ向けカメラ開発や全社プロセス改善に取り組んだ。2013年にウイングアーク１ｓｔ株式会社に⼊社。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）趣味⼭、海、⼩説、漫画、映画、ランニング経歴

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

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

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

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

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

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

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

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/

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

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

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

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

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. フロー状態認知負荷フィードバックループ

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.

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 フィードバックループ

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 認知負荷フィードバックループ

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 フロー状態認知負荷フィードバックループ

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.

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. 「開発者体験」は測れる

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

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)

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) 呪⾔

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)

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)

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

開発者体験の誤解 35

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. フロー状態認知負荷フィードバックループ

37 開発者体験の誤解プロダクト開発チーム開発者 DevEx Flow State Feedback Loops Cognitive
Load one for all, all for one !!

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

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

40 開発者体験の誤解 one for all, all for one !!

41 開発者体験の誤解 one for all, all for one !! 内側しか⾒てないとこうなる

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

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

Cognitive Load 顧客機能A アウトプットが恐ろしく速いプロダクト開発チーム

Cognitive Load 顧客機能A 機能B アウトプットが恐ろしく速いプロダクト開発チーム

Cognitive Load 顧客機能A 機能B 機能C アウトプットが恐ろしく速いプロダクト開発チーム

Cognitive Load 顧客機能A 機能B 機能C 機能D アウトプットが恐ろしく速いプロダクト開発チーム

49 ビルドトラップ •組織がアウトカムではなくアウトプットで成功を計測しようとして、⾏き詰まっている状況＊ •実際に⽣み出された価値ではなく、機能の開発とリリースに集中してしまっている状態＊誰もプロダクトを使わない⾜りない機能を作る顧客に⾜り
ない機能を聞く ϓϩμΫτͷࢮͷαΠΫϧ σΠϏουɾϒϥϯυ IUUQTUXJUUFSDPNEBWJEKCMBOETUBUVT * Perri, M. (2018). ϓϩμΫτϚωδϝϯτ ―ϏϧυτϥοϓΛආ͚ސ٬ʹՁ஋Λಧ͚Δ (٢Ӌ ཾଠ࿠, Trans.). O'Reilly Japan, Inc.

50 ビルドトラップ •ビルドトラップ： •組織がアウトカムではなくアウトプットで成功を計測しようとして、⾏き詰まっている状況＊ •実際に⽣み出された価値ではなく、機能の開発とリリースに集中してしまっている状態＊誰もプロダクトを使わない⾜りない機能を作る
顧客に⾜りない機能を聞く ϓϩμΫτͷࢮͷαΠΫϧ σΠϏουɾϒϥϯυ IUUQTUXJUUFSDPNEBWJEKCMBOETUBUVT * Perri, M. (2018). ϓϩμΫτϚωδϝϯτ ―ϏϧυτϥοϓΛආ͚ސ٬ʹՁ஋Λಧ͚Δ (٢Ӌ ཾଠ࿠, Trans.). O'Reilly Japan, Inc. 内側しか⾒てないとこうなる

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

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

Loops Cognitive Load 顧客

Loops Cognitive Load 顧客プロダクト・サービス提供

Loops Cognitive Load 顧客プロダクト・サービス提供アウトカム向上

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

Feedback Loops Cognitive Load 顧客プロダクト・サービス提供継続アウトカム向上

Feedback Loops Cognitive Load 顧客プロダクト・サービス提供継続アウトカム向上内側⾃組織を測るメトリクス外側顧客を測るメトリクス

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

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

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)

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

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

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

State Feedback Loops Cognitive Load プロダクトのアウトカムや品質の定量的計測を中⼼とした「市場価値」（アウトカム）も計測したい＝外側の指標

State Feedback Loops Cognitive Load プロダクトのアウトカムや品質の定量的計測を中⼼とした「市場価値」（アウトカム）も計測したい＝外側の指標もっと重要なのは、世界を変えるような、あるいは企業やビジネスのあり⽅を変えるようなソフトウェアを作るという「変⾰」です。 Tom DeMarco(2009)

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)

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

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

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)

計測対象のプロダクトやシステムにかかる総費⽤およびコスト。運⽤コストも含まれる。従業員満⾜度従業員のエンゲージメント、エネルギー、熱意を計測するのに役⽴つ感情分析の⼀種。顧客満⾜度プロダクトに対する顧客のエンゲージメントと幸福度を計測すプロダクトに対する顧客のエンゲージメントと幸福度を計測するのに役⽴つ感情分析の⼀種。顧客使⽤指標機能別の利⽤状況を計測して、顧客がプロダクトをどの程度有益だと思っているかを推測する。また、機能にかける実際の使⽤時間が、期待と⼀致しているかを確認する。現在の価値（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)

計測対象のプロダクトやシステムにかかる総費⽤およびコスト。運⽤コストも含まれる。従業員満⾜度従業員のエンゲージメント、エネルギー、熱意を計測するのに役⽴つ感情分析の⼀種。顧客満⾜度プロダクトに対する顧客のエンゲージメントと幸福度を計測すプロダクトに対する顧客のエンゲージメントと幸福度を計測するのに役⽴つ感情分析の⼀種。顧客使⽤指標機能別の利⽤状況を計測して、顧客がプロダクトをどの程度有益だと思っているかを推測する。また、機能にかける実際の使⽤時間が、期待と⼀致しているかを確認する。現在の価値（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

エビデンスベースの計器⾶⾏ 74

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

Mission

77 Value มΘΓଓ͚ΔͨΊʹɺֶͼଓ͚Δ ͓٬༷ͷຊ࣭త՝୊ղܾ ͦͷߦಈͰɺϒϨΠΫεϧʔ ࣄۀͮ͘Γ͸ɺ஥ؒͮ͘Γ Ձ஋͋Δ͜ͱΛɺਖ਼͘͠΍Ζ͏ Ұ౓͖Γͷਓੜɺ͔ͤͬ͘Կ͔ʹऔΓ૊ΉͳΒɺ ୭ʹͰ΋ڳΛுͬͯ఻͑ΒΕΔ࢓ࣄΛ͠Α͏ɻ ͓٬༷ɺגओɺࣾ಺֎ͷ஥ؒɺՈ଒ɺͦͯࣗ͠෼ɻ
ؔΘΔ͢΂ͯͷਓ͕޾ͤʹͳΔࣄۀΛ૑Δɻ ͜ͷࢥ͍Λৗʹ๨Εͣɺ ͜Ε͔Β΋ಓͷਅΜதΛಊʑͱಥ͖ਐ΋͏ɻ มԽ͠ଓ͚Δ࣌୅ͰɺԿ͔Λม͍͑ͨͱࢥ͏ͷͳΒɺ ࣗ෼ࣗ਎͕Ұ൪มΘ͍ͬͯ͜͏ɻ ֶͼ͸มΘΔ͜ͱΛޙԡͯ͘͠͠ΕΔɻ มΘΓଓ͚Δ͜ͱ͸೉͘͠ɺ࣌ʹ͍͚ۤ͠ΕͲɺ ͋ͳͨͷࢹ໺ͱՄೳੑΛ޿͛ɺ ݁Ռͱͯ͠ਓੜͷ޾ͤ΁ͱͭͳ͕͍ͬͯ͘ɻ Ϣʔβʔͱ͍͏ݴ༿΋ؚΊɺ ҰਓҰਓ͕༗ػతͳ৺Λ࣋ͭʮ͓٬༷ʯͰ͋Δͱఆٛ͠ɺ ͓٬༷ͷମݧΛৗʹ૝૾͠ͳ͕Βɺ ຊ࣭తͳ՝୊ΛҾ͖ग़͠ɺൈຊతʹղܾ͠Α͏ɻ ͦΕ͕ͦ͜ظ଴Ҏ্ͷ੒Ռ΍඼࣭ɺ ͻ͍ͯ͸ࢲ͕ͨͪड͚औΔରՁͱͳΔͷ͔ͩΒɻ ୭͔ͷओମੑʹཔΔ͜ͱͳ͘ɺ ࣗΒ͕ࣄۀ΍αʔϏεͷΦʔφʔγοϓΛ࣋ͬͯ ߟ͑ɺൃݴ͠ɺߦಈ͍ͯ͜͠͏ɻ ͦ͏͢Ε͹ ɺ୹ظతͳ੒ՌͷͨΊʹ ௕ظతͳՁ஋Λ٘ਜ਼ʹ͢Δ͜ͱ΋ͳ͍ɻ ͍·ࣗ෼ʹͰ͖Δ͜ͱΛߟ͑ɺ࠷ॳͷҰาΛ౿Έग़͠ɺ ҰਓҰਓ͕ϒϨΠΫεϧʔ͍ͯ͜͠͏ɻ ࣄۀͮ͘Γʹ͓͍ͯɺ ҰਓͷྗͰ੒͠਱͛ΒΕΔ͜ͱʹ͸ݶք͕͋Δɻ ͔ͩΒͦ͜ɺࢤΛԕྀͳ͘ൃ৴͠ɺ஥ؒΛݟ͚ͭɺ ͲΜͲΜר͖ࠐΜͰ͍͘͜ͱʹΑͬͯɺ ૝૾΋Ͱ͖ͳ͍΄Ͳͷେ͖ͳਪਐྗΛੜΈग़ͦ͏ɻ ͦͯ͠ɺ࠷ߴͷ஥ؒͱྺ࢙Λ૑Ζ͏ɻ 01 02 03 04 05

78 Vision

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

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

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

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

84 指標構造｜全体のイメージ اۀ ࣄۀ αʔϏε ϓϩμΫτ ϓϩδΣΫτ ։ൃνʔϜ 各ブロックが複数指標を保有し、さらに各ブロックの指標やアウトカムが下層から上層へ影響を及ぼすも
のとして設計しています。

85 指標構造｜全体のイメージ اۀ ࣄۀ αʔϏε ϓϩμΫτ ϓϩδΣΫτ ։ൃνʔϜ プロダクト開発指標各ブロックが複数指標を保有し、
さらに各ブロックの指標やアウトカムが下層から上層へ影響を及ぼすものとして設計しています。将来的には企業ミッションや企業アウトカム指標との相関性を可視化しますが、まずはプロダクト開発指標の可視化を⾏います。

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

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

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

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

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

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

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

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

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

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

ビズリーチが⽬指すプロダクト組織の「計器⾶⾏」注）数値はダミーです

97 ビズリーチが⽬指すプロダクト組織の「計器⾶⾏」

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

SODA構想とは Software Outcome Delivery Architecture 99

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

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

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

Software Outcome Delivery Architecture(SODA): prototype

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

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

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

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

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

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

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

プロダクトの世界観

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モデルを作る

ビズリーチ版SODA 125

((SODA)) Team Performance üすべてのプロダクトにFour Keysの計測を定着させ、改善サイクルを作る ((SODA)) Quality Value üプロダクトごとに有意な品質指標を⾒極めフィードバックプロセスを増やし、プロダクト品質を向上させる ((SODA)) Outcome Delivery üプロダクトごとにアウトカム指標を⾒極め、計測する ((SODA)) Project Value üプロジェクトごとに有意なマネジメント指標を計測し段階や例外によるマネジメントを⾏えるようにする ((SODA)) Evidence Viewer üプロダクト開発チームのエビデンスデータを⾒える化する ((SODA)) Playbook üプロダクトに関するナレッジベースを作成しSECIモデルを作る

((SODA)) Team Performance üすべてのプロダクトにFour Keysの計測を定着させ、改善サイクルを作る ((SODA)) Quality Value üプロダクトごとに有意な品質指標を⾒極めフィードバックプロセスを増やし、プロダクト品質を向上させる ((SODA)) Outcome Delivery üプロダクトごとにアウトカム指標を⾒極め、計測する ((SODA)) Project Value üプロジェクトごとに有意なマネジメント指標を計測し段階や例外によるマネジメントを⾏えるようにする ((SODA)) Evidence Viewer üプロダクト開発チームのエビデンスデータを⾒える化する ((SODA)) Playbook üプロダクトに関するナレッジベースを作成しSECIモデルを作るこれらのメソッドを組織にインプリメントする

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

Software Outcome Delivery Architecture(SODA): BizReach ver.

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

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

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

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

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

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

Software Outcome Delivery Architecture(SODA): BizReach ver.

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

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

#MPH 5XJUUFS IUUQTFOHJOFFSJOHWJTJPOBMJOD CMPH !7*4*0/"-@&/( 7JTJPOBMάϧʔϓͰಇ͘ΤϯδχΞͷٕज़తͳऔΓ૊Έ΍ɺΠϕϯτɾొஃ৘ใͳͲΛ͓ಧ͚͠·͢ɻ 153 BlogとTwitterで発信中！

[CLONE] 開発者体験を見える化し「計器飛行」の実現を目指すSODA構想 〜事業の成長とプロダクト組織能力の相関関係を見いだすには〜 / Developer eXperience Day 2023

[CLONE] 開発者体験を見える化し「計器飛行」の実現を目指すSODA構想 〜事業の成長とプロダクト組織能力の相関関係を見いだすには〜 / Developer eXperience Day 2023

More Decks by Hiroyuki TAKAHASHI

Other Decks in Technology

Featured

Transcript

[CLONE] 開発者体験を見える化し「計器飛行」の実現を目指すSODA構想〜事業の成長とプロダクト組織能力の相関関係を見いだすには〜 / Developer eXperience Day 2023

[CLONE] 開発者体験を見える化し「計器飛行」の実現を目指すSODA構想〜事業の成長とプロダクト組織能力の相関関係を見いだすには〜 / Developer eXperience Day 2023