開発者体験を見える化し「計器飛行」の実現を目指す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 アウトプットが恐ろしく速いプロダクト開発チーム

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

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

50 ビルドトラップ •ビルドトラップ： •組織がアウトカムではなくアウトプットで成功を計測しようとして、行き詰まっている状況＊ •実際に生み出された価値ではなく、機能の開発とリリースに集中してしまっている状態＊誰もプロダクトを使わない足りない機能を作る
顧客に足りない機能を聞くプロダクトの死のサイクル(デイビッド・ブランド) https://twitter.com/davidjbland/status/467096015318036480 * 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 顧客プロダクト・サービス提供良かった！

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

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

Flow 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で強いチームづくりを！プロダクトの力で、お客さまにベネフィットを！

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

開発者体験を見える化し「計器飛行」の実現を目指すSODA構想 〜事業の成長とプロダクト組織能力...

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

More Decks by Visional Engineering ＆ Design

Other Decks in Technology

Featured

Transcript

開発者体験を見える化し「計器飛行」の実現を目指すSODA構想〜事業の成長とプロダクト組織能力...

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