Upgrade to Pro — share decks privately, control downloads, hide ads and more …

[CLONE] 開発者体験を見える化し「計器飛行」の実現を目指すSODA構想 〜事業の成長とプ...

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

会社として正式にはこちらで公開しています。同じものです。
https://speakerdeck.com/visional_engineering_and_design/developer-experience-day-2023

Hiroyuki TAKAHASHI

June 15, 2023
Tweet

More Decks by Hiroyuki TAKAHASHI

Other Decks in Technology

Transcript

  1. 2 本コンテンツの⽬的 本⽇お伝えしたいこと Learning Outcome エグゼクティブ、マネジャーの⽅へ • プロダクト開発チームの「内側」で起きやすい事象を認識しよう • ビジネス(事業)とプロダクト開発の相関関係を⾒出そう

    • DORA Metrics(Four Keysなど)以外にもいっぱい測ろう • ビジネスを成⻑させるために「計器⾶⾏」を実現しよう 1. ⾃⼰紹介 2. 株式会社ビズリーチ紹介 3. 開発者体験とは 4. 開発者体験の誤解 5. 計測指標(メトリクス)の内側と外側 6. エビデンスベースの計器⾶⾏ 7. SODA構想とは 8. ビズリーチ版SODA アジェンダ プロダクト開発者・エンジニアの⽅へ • プロダクト開発チームの「外側」も意識しよう • 開発者体験はイメージよりエビデンスに価値を置こう
  2. 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)
  3. 会社概要 株式会社ビズリーチ / BizReach, Inc. 創業 :2009年4⽉ 代表者 :株式会社ビズリーチ 代表取締役社⻑

    酒井 哲也 グループ従業員数:1,821名(2022年7⽉末時点) 拠点 :東京、⼤阪、名古屋、福岡、静岡、広島 資本⾦ :1億3,000万円 事業内容:HR Techのプラットフォーム・SaaS事業
  4. 14 ウガンダのAirQoプロジェクト アフリカの都市部では⼤気汚染が深刻で 毎年700万⼈もの⼈が亡くなっている。 ウガンダの⾸都カンパラも例外ではなく ⼈々は⼤気汚染に苦しんでいる。 が、そもそもカンパラの⼈たちは『空気 がどれぐらい汚れているか』を知らな かった。 マケレレ⼤学のバイノムギシャ⽒は安価

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

    な⼤気センサーを開発し、バイクタク シー(ボタボタ)や建物の屋上に⼤気セ ンサーを取り付け市内全域の⼤気汚染 データを収集し、汚染の予測や⼤気質の 改善に役⽴つようにした。 https://about.google/intl/ja_AI/stories/clean-air-for-kampala/ まず「測る」ことが⼤事
  6. 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
  7. 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. フロー状態 認知負荷 フィードバックループ
  8. 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.
  9. 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 フィードバックループ
  10. 20 DevExの3コア・ダイヤモンド (参考)ݪాӻࢠ, ڮຊӳಸ, & ਢ౻ஐ. (2016). ໼ҹΛ༻͍ͨň૊Έ߹Θ͞Εͨํ޲αΠϯʼnͷ Θ͔Γ΍͢͞ɿߏ଄ɼΞΠίϯɼՃྸͷޮՌ. ೔ຊೝ஌Պֶձୈ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 認知負荷 フィードバックループ
  11. 21 DevExの3コア・ダイヤモンド (参考)ݪాӻࢠ, ڮຊӳಸ, & ਢ౻ஐ. (2016). ໼ҹΛ༻͍ͨň૊Έ߹Θ͞Εͨํ޲αΠϯʼnͷ Θ͔Γ΍͢͞ɿߏ଄ɼΞΠίϯɼՃྸͷޮՌ. ೔ຊೝ஌Պֶձୈ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 認知負荷 フィードバックループ
  12. 22 DevExの3コア・ダイヤモンド (参考)ݪాӻࢠ, ڮຊӳಸ, & ਢ౻ஐ. (2016). ໼ҹΛ༻͍ͨň૊Έ߹Θ͞Εͨํ޲αΠϯʼnͷ Θ͔Γ΍͢͞ɿߏ଄ɼΞΠίϯɼՃྸͷޮՌ. ೔ຊೝ஌Պֶձୈ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 認知負荷 フィードバックループ
  13. 23 DevExの3コア・ダイヤモンド (参考)ݪాӻࢠ, ڮຊӳಸ, & ਢ౻ஐ. (2016). ໼ҹΛ༻͍ͨň૊Έ߹Θ͞Εͨํ޲αΠϯʼnͷ Θ͔Γ΍͢͞ɿߏ଄ɼΞΠίϯɼՃྸͷޮՌ. ೔ຊೝ஌Պֶձୈ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 認知負荷 フィードバックループ
  14. 24 DevExの3コア・ダイヤモンド (参考)ݪాӻࢠ, ڮຊӳಸ, & ਢ౻ஐ. (2016). ໼ҹΛ༻͍ͨň૊Έ߹Θ͞Εͨํ޲αΠϯʼnͷ Θ͔Γ΍͢͞ɿߏ଄ɼΞΠίϯɼՃྸͷޮՌ. ೔ຊೝ஌Պֶձୈ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 認知負荷 フィードバックループ
  15. 25 DevExの3コア・ダイヤモンド (参考)ݪాӻࢠ, ڮຊӳಸ, & ਢ౻ஐ. (2016). ໼ҹΛ༻͍ͨň૊Έ߹Θ͞Εͨํ޲αΠϯʼnͷ Θ͔Γ΍͢͞ɿߏ଄ɼΞΠίϯɼՃྸͷޮՌ. ೔ຊೝ஌Պֶձୈ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 認知負荷 フィードバックループ
  16. 26 DevExの3コア・ダイヤモンド (参考)ݪాӻࢠ, ڮຊӳಸ, & ਢ౻ஐ. (2016). ໼ҹΛ༻͍ͨň૊Έ߹Θ͞Εͨํ޲αΠϯʼnͷ Θ͔Γ΍͢͞ɿߏ଄ɼΞΠίϯɼՃྸͷޮՌ. ೔ຊೝ஌Պֶձୈ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 フロー状態 認知負荷 フィードバックループ
  17. 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.
  18. 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. 「開発者体験」は測れる
  19. 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)
  20. 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) 呪⾔
  21. 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)
  22. 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)
  23. 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. フロー状態 認知負荷 フィードバックループ
  24. 38 開発者体験の誤解 ねぇ、◯◯の機能って 6⽉のリリースに乗 るっていってたよね? ⼊ってなくない? あぁ、アレはボクたち 開発チームのスプリン トプランニングで⼊ら なかったんだ

    ええっ! お客様、あの機能ずっーと 待ってるんだぞ! 6⽉には必ず!ってお伝え しちゃってるんだよ〜! 他のPBIを優先させ たしね。アレは6⽉ リリースからはド ロップさせてもらっ たよ
  25. 39 開発者体験の誤解 そんなわけで、私た ちのチームは今回余 裕があったので例の △ △ 対応画⾯の実装 を終えたわ ちょいちょい、待てよ!

    俺たちバックエンドチー ムは聞いてないぞ! キミらだけ出来てどーす んだよ! スプリントプランニングどおり なんだから仕⽅ないじゃない、 私たちのチームは⾃律性を⼤切 にしてるのよ!
  26. 43 開発者体験の誤解 PO SM 開発者 DevEx Flow State Feedback Loops

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

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

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

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

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

    Cognitive Load 顧客 機能A 機能B 機能C 機能D アウトプットが恐ろしく速いプロダクト開発チーム
  32. 49 ビルドトラップ •組織がアウトカムではなくアウトプットで成功を計測しようとして、⾏き詰まっている状況* •実際に⽣み出された価値ではなく、機能の開発とリリースに集中してしまっている状態* 誰もプロダ クトを使わ ない ⾜りない機 能を作る 顧客に⾜り

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

    顧客に⾜り ない機能を 聞く ϓϩμΫτͷࢮͷαΠΫϧ σΠϏουɾϒϥϯυ IUUQTUXJUUFSDPNEBWJEKCMBOETUBUVT * Perri, M. (2018). ϓϩμΫτϚωδϝϯτ ―ϏϧυτϥοϓΛආ͚ސ٬ʹՁ஋Λಧ͚Δ (٢Ӌ ཾଠ࿠, Trans.). O'Reilly Japan, Inc. 内側しか⾒てないとこうなる
  34. 56 計測指標(メトリクス)の内側と外側 プロダクト開発チーム PO SM 開発者 DevEx Flow State Feedback

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

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

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

    Feedback Loops Cognitive Load 顧客 プロダクト・サービス提供 継続 アウトカム向上 内側 ⾃組織を測る メトリクス 外側 顧客を測る メトリクス
  38. 60 DORA Metrics •Four Keys とは DORA社(DevOps Research and Assessment,

    現Google)が⻑年の の研究から導いた開発チームのパフォーマンス指標 •アジャイルでもウォーターフォールでも計測可能 リードタイム コードがコミットされてか ら本番環境で正常に実⾏さ れるまでの時間 デプロイ頻度 コードを本番環境にデプロ イまたはエンドユーザーに リリースした頻度 平均サービス 回復時間(MTRS) サービスインシデント または不具合が発⽣したと きにサービスの復元にどれ くらいの時間がかかるか 変更失敗率 本番環境に変更を加えた、 またはユーザーへのリリー スを実施した結果サービス が低下し、その後修正を⾏ う必要が⽣じた割合
  39. DORA Metrics “⽣産性”に代わる開発チームのパフォーマンス計測を! ソフトウェア開発の“⽣産性”指標の難しさ 「書いたコードの量」が ⽣産性とは限らない 「ベロシティ(速度)」は ⽣産性とは限らない 「リソース効率(利⽤率)」が ⽣産性とは限らない

    品質 スピード リードタイムが短くなると学 習スピードが増し、品質が向 上する 品質が向上するとリードタイ ムは短くなり、頻繁なデプロ イが容易になる リードタイム デプロイ頻度 平均サービス 回復時間(MTRS) 変更失敗率
  40. 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)
  41. 信頼・対価(売上) 63 Four Keys は内側か外側か? プロダクト開発チーム PO SM 開発者 DevEx

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

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

    State Feedback Loops Cognitive Load プロダクトのアウトカムや品質の定量的計測を中⼼とした 「市場価値」(アウトカム)も計測したい=外側の指標 もっと重要なのは、世界を変えるような、ある いは企業やビジネスのあり⽅を変えるようなソ フトウェアを作るという「変⾰」です。 Tom DeMarco(2009)
  44. 69 エビデンスベースドマネジメント(EBM) 市場に出すまでの時間(反応性) (T2M: Time to Market) 新しい能⼒、サービス、製品を迅速 に提供する能⼒ イノベーションの能⼒(効果性)

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

    (A2I: Ability to Innovate) 顧客やユーザーのニーズにより良く 応えられるような新しい能⼒を提供 する能⼒ 現在の価値 (CV: Current Value) 現在、顧客やユーザーに提供された 価値 未実現の価値 (UV: Unrealized Value) 顧客やユーザーの潜在的なニーズを すべて満たすことによって実現しう る価値 重要価値領域(KVA) 市場価値(外側) 組織的な能⼒(内側)
  46. 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)
  47. 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)
  48. 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
  49. 75 IT企業の価値は⾔葉に宿る •Mission、Vision、Valueの⼤切さ ü Mission(⽬的): ⾃分たちの会社は何のためにあるのか。 ü Vision(夢): どういう未来を築きたいと、⾃分たちは思っているか。 ü

    Value(信念): どういうバリューや信念(ビリーフ)を、⾃分たちは⼤事にしているか。 “現代では世界のほぼすべての企業が「社是」とか、「経営理念」とか、 「⾏動指針」とか、「企業理念」とか、その他、それに類したもの掲げてい る。⼩さいカードにその⾔葉を印刷して、全員に常に持ち歩かせている企業 もある。そのねらいは、バリューを社内の隅々にまで浸透させることで、社 員全員が⽇々、そのバリューに従って⾏動できるようにするためである。” ワイズカンパニー: 知識創造から知識実践への新しいモデル (野中 郁次郎 (著), ⽵内 弘⾼ (著), ⿊輪 篤嗣 (翻訳), 2020, p.034)
  50. 77 Value มΘΓଓ͚ΔͨΊʹɺֶͼଓ͚Δ ͓٬༷ͷຊ࣭త՝୊ղܾ ͦͷߦಈͰɺϒϨΠΫεϧʔ ࣄۀͮ͘Γ͸ɺ஥ؒͮ͘Γ Ձ஋͋Δ͜ͱΛɺਖ਼͘͠΍Ζ͏ Ұ౓͖Γͷਓੜɺ͔ͤͬ͘Կ͔ʹऔΓ૊ΉͳΒɺ ୭ʹͰ΋ڳΛுͬͯ఻͑ΒΕΔ࢓ࣄΛ͠Α͏ɻ ͓٬༷ɺגओɺࣾ಺֎ͷ஥ؒɺՈ଒ɺͦͯࣗ͠෼ɻ

    ؔΘΔ͢΂ͯͷਓ͕޾ͤʹͳΔࣄۀΛ૑Δɻ ͜ͷࢥ͍Λৗʹ๨Εͣɺ ͜Ε͔Β΋ಓͷਅΜதΛಊʑͱಥ͖ਐ΋͏ɻ มԽ͠ଓ͚Δ࣌୅ͰɺԿ͔Λม͍͑ͨͱࢥ͏ͷͳΒɺ ࣗ෼ࣗ਎͕Ұ൪มΘ͍ͬͯ͜͏ɻ ֶͼ͸มΘΔ͜ͱΛޙԡͯ͘͠͠ΕΔɻ มΘΓଓ͚Δ͜ͱ͸೉͘͠ɺ࣌ʹ͍͚ۤ͠ΕͲɺ ͋ͳͨͷࢹ໺ͱՄೳੑΛ޿͛ɺ ݁Ռͱͯ͠ਓੜͷ޾ͤ΁ͱͭͳ͕͍ͬͯ͘ɻ Ϣʔβʔͱ͍͏ݴ༿΋ؚΊɺ ҰਓҰਓ͕༗ػతͳ৺Λ࣋ͭʮ͓٬༷ʯͰ͋Δͱఆٛ͠ɺ ͓٬༷ͷମݧΛৗʹ૝૾͠ͳ͕Βɺ ຊ࣭తͳ՝୊ΛҾ͖ग़͠ɺൈຊతʹղܾ͠Α͏ɻ ͦΕ͕ͦ͜ظ଴Ҏ্ͷ੒Ռ΍඼࣭ɺ ͻ͍ͯ͸ࢲ͕ͨͪड͚औΔରՁͱͳΔͷ͔ͩΒɻ ୭͔ͷओମੑʹཔΔ͜ͱͳ͘ɺ ࣗΒ͕ࣄۀ΍αʔϏεͷΦʔφʔγοϓΛ࣋ͬͯ ߟ͑ɺൃݴ͠ɺߦಈ͍ͯ͜͠͏ɻ ͦ͏͢Ε͹ ɺ୹ظతͳ੒ՌͷͨΊʹ ௕ظతͳՁ஋Λ٘ਜ਼ʹ͢Δ͜ͱ΋ͳ͍ɻ ͍·ࣗ෼ʹͰ͖Δ͜ͱΛߟ͑ɺ࠷ॳͷҰาΛ౿Έग़͠ɺ ҰਓҰਓ͕ϒϨΠΫεϧʔ͍ͯ͜͠͏ɻ ࣄۀͮ͘Γʹ͓͍ͯɺ ҰਓͷྗͰ੒͠਱͛ΒΕΔ͜ͱʹ͸ݶք͕͋Δɻ ͔ͩΒͦ͜ɺࢤΛԕྀͳ͘ൃ৴͠ɺ஥ؒΛݟ͚ͭɺ ͲΜͲΜר͖ࠐΜͰ͍͘͜ͱʹΑͬͯɺ ૝૾΋Ͱ͖ͳ͍΄Ͳͷେ͖ͳਪਐྗΛੜΈग़ͦ͏ɻ ͦͯ͠ɺ࠷ߴͷ஥ؒͱྺ࢙Λ૑Ζ͏ɻ 01 02 03 04 05
  51. 計測の重要性:Opinion vs Fact(意⾒か事実か) Problem(問題) Solution(解決策) Fact(事実) Opinion(意⾒) 設計 デプロイ 仮説を実装

    する 仮説を 動かす 結果を 検証する 仮説 対策の仮説 を⽴てる 計測 (参考) https://slide.meguro.ryuzee.com/slides/78 吉⽻⿓太郎さん「カイゼンの基本」の図を変更 仮説を⽴てるには、 計測データを検証す る必要がある。
  52. 85 指標構造|全体のイメージ اۀ ࣄۀ αʔϏε ϓϩμΫτ ϓϩδΣΫτ ։ൃνʔϜ プロダクト開発指標 各ブロックが複数指標を保有し、

    さらに各ブロックの指標やアウトカムが下層から上層へ影響を及ぼすも のとして設計しています。 将来的には企業ミッションや企業アウトカム指標との相関性を可視化し ますが、まずはプロダクト開発指標の可視化を⾏います。
  53. 86 指標構造|プロダクト下 - 3つの指標領域 アウトカム指標 現在の品質、維持向上 開発進捗 障害 開発パフォーマンス 顧客満⾜度

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

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

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

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

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

    現在は右図のような構成で考えています。 深さ 広さ 構造 時間 型 • 上記のSODA Prototypeを元に、ビズリーチに合 わせてテーラリングを⾏いました。 • テーラリング後のSODA PrototypeをSODA BizReachと呼ぶことにします。
  62. 147

  63. 148

  64. 149

  65. Software Outcome Delivery Architecture(SODA): BizReach ver. 市場に出すまでの時間(反応性) (T2M: Time-to-Market) 新しい能⼒、サービス、製品を迅速

    に提供する能⼒ イノベーションの能⼒(効果性) (A2I: Ability to Innovate) 顧客やユーザーのニーズにより良く 応えられるような新しい能⼒を提供 する能⼒ 現在の価値 (CV: Current Value) 現在、顧客やユーザーに提供された 価値 未実現の価値 (UV: Unrealized Value) 顧客やユーザーの潜在的なニーズを すべて満たすことによって実現しう る価値